idnits 2.17.1 draft-ietf-idr-bgp-tcp-md5-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-18) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** The abstract seems to contain references ([RFC1321]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 12, 1998) is 9534 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 1321 ** Obsolete normative reference: RFC 1323 (Obsoleted by RFC 7323) -- Possible downref: Non-RFC (?) normative reference: ref. 'Dobb' Summary: 12 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Andy Heffernan 2 cisco Systems 3 March 12, 1998 5 Protection of BGP Sessions via the TCP MD5 Signature Option 7 Status of this Memo 9 This document is an Internet Draft. Internet Drafts are working 10 documents of the Internet Engineering Task Force (IETF), its Areas, 11 and its Working Groups. Note that other groups may also distribute 12 working documents as Internet Drafts. 14 Internet Drafts are draft documents valid for a maximum of six 15 months. Internet Drafts may be updated, replaced, or obsoleted by 16 other documents at any time. It is not appropriate to use Internet 17 Drafts as reference material or to cite them other than as a "working 18 draft" or "work in progress." 20 Please check the I-D abstract listing contained in each Internet 21 Draft directory to learn the current status of this or any Internet 22 Draft. 24 IESG Note 26 This document describes currrent existing practice for securing BGP 27 against certain simple attacks. It is understood to have security 28 weaknesses against concerted attacks. 30 Abstract 32 This memo describes a TCP extension to enhance security for BGP. It 33 defines a new TCP option for carrying an MD5 [RFC1321] digest in a 34 TCP segment. This digest acts like a signature for that segment, 35 incorporating information known only to the connection end points. 36 Since BGP uses TCP as its transport, using this option in the way 37 described in this paper significantly reduces the danger from certain 38 security attacks on BGP. 40 This document specifies an experimental protocol for use in the 41 Internet. 43 1.0 Introduction 45 The primary motivation for this option is to allow BGP to protect 46 itself against the introduction of spoofed TCP segments into the 47 connection stream. Of particular concern are TCP resets. 49 To spoof a connection using the scheme described in this paper, an 50 attacker would not only have to guess TCP sequence numbers, but would 51 also have had to obtain the password included in the MD5 digest. 52 This password never appears in the connection stream, and the actual 53 form of the password is up to the application. It could even change 54 during the lifetime of a particular connection so long as this change 55 was synchronized on both ends (although retransmission can become 56 problematical in some TCP implementations with changing passwords). 58 Finally, there is no negotiation for the use of this option in a 59 connection, rather it is purely a matter of site policy whether or 60 not its connections use the option. 62 2.0 Proposal 64 Every segment sent on a TCP connection to be protected against 65 spoofing will contain the 16-byte MD5 digest produced by applying the 66 MD5 algorithm to these items in the following order: 68 1. the TCP pseudo-header (in the order: source IP address, 69 destination IP address, zero-padded protocol number, and segment 70 length) 71 2. the TCP header, excluding options, and assuming a checksum of zero 72 3. the TCP segment data (if any) 73 4. an independently-specified key or password, known to both TCPs 74 and presumably connection-specific 76 The header and pseudo-header are in network byte order. The nature 77 of the key is deliberately left unspecified, but it must be known by 78 both ends of the connection. A particular TCP implementation will 79 determine what the application may specify as the key. 81 Upon receiving a signed segment, the receiver must validate it by 82 calculating its own digest from the same data (using its own key) and 83 comparing the two digest. A failing comparison must result in the 84 segment being dropped and must not produce any response back to the 85 sender. Logging the failure is probably advisable. 87 Unlike other TCP extensions (e.g., the Window Scale option 88 [RFC1323]), the absence of the option in the SYN,ACK segment must not 89 cause the sender to disable its sending of signatures. This 90 negotiation is typically done to prevent some TCP implementations 91 from misbehaving upon receiving options in non-SYN segments. This is 92 not a problem for this option, since the SYN,ACK sent during 93 connection negotiation will not be signed and will thus be ignored. 95 The connection will never be made, and non-SYN segments with options 96 will never be sent. More importantly, the sending of signatures must 97 be under the complete control of the application, not at the mercy of 98 the remote host not understanding the option. 100 3.0 Syntax 102 The proposed option has the following format: 104 +---------+---------+-------------------+ 105 | Kind=19 |Length=18| MD5 digest... | 106 +---------+---------+-------------------+ 107 | | 108 +---------------------------------------+ 109 | | 110 +---------------------------------------+ 111 | | 112 +-------------------+-------------------+ 113 | | 114 +-------------------+ 116 The MD5 digest is always 16 bytes in length, and the option would 117 appear in every segment of a connection. 119 4.0 Some Implications 121 4.1 Connectionless Resets 123 A connectionless reset will be ignored by the receiver of the reset, 124 since the originator of that reset does not know the key, and so 125 cannot generate the proper signature for the segment. This means, 126 for example, that connection attempts by a TCP which is generating 127 signatures to a port with no listener will time out instead of being 128 refused. Similarly, resets generated by a TCP in response to 129 segments sent on a stale connection will also be ignored. 130 Operationally this can be a problem since resets help BGP recover 131 quickly from peer crashes. 133 4.2 Performance 135 The performance hit in calculating digests may inhibit the use of 136 this option. Some measurements of a sample implementation showed 137 that on a 100 MHz R4600, generating a signature for simple ACK 138 segment took an average of 0.0268 ms, while generating a signature 139 for a data segment carrying 4096 bytes of data took 0.8776 ms on 140 average. These times would be applied to both the input and output 141 paths, with the input path also bearing the cost of a 16-byte 142 compare. 144 4.3 TCP Header Size 146 As with other options that are added to every segment, the size of 147 the MD5 option must be factored into the MSS offered to the other 148 side during connection negotiation. Specifically, the size of the 149 header to subtract from the MTU (whether it is the MTU of the 150 outgoing interface or IP's minimal MTU of 576 bytes) is now at least 151 18 bytes larger. 153 The total header size is also an issue. The TCP header specifies 154 where segment data starts with a 4-bit field which gives the total 155 size of the header (including options) in 32-byte words. This means 156 that the total size of the header plus option must be less than or 157 equal to 60 bytes -- this leaves 40 bytes for options. 159 As a concrete example, 4.4BSD defaults to sending window-scaling and 160 timestamp information for connections it initiates. The most loaded 161 segment will be the initial SYN packet to start the connection. With 162 MD5 signatures, the SYN packet will contain the following: 164 -- 4 bytes MSS option 165 -- 4 bytes window scale option (3 bytes padded to 4 in 4.4BSD) 166 -- 12 bytes for timestamp (4.4BSD pads the option as recommended 167 in RFC 1323 Appendix A) 168 -- 18 bytes for MD5 digest 169 -- 2 bytes for end-of-option-list, to pad to a 32-bit boundary. 171 This sums to 40 bytes, which just makes it. 173 4.4 MD5 as a Hashing Algorithm 175 Since this draft was first issued (under a different title), the MD5 176 algorithm has been found to be vulnerable to collision search attacks 177 [Dobb], and is considered by some to be insufficiently strong for 178 this type of application. 180 This draft still specifies the MD5 algorithm, however, since the 181 option has already been deployed operationally, and there was no 182 "algorithm type" field defined to allow an upgrade using the same 183 option number. The original draft did not specify a type field since 184 this would require at least one more byte, and it was felt at the 185 time that taking 19 bytes for the complete option (which would 186 probably be padded to 20 bytes in TCP implementations) would be too 187 much of a waste of the already limited option space. 189 This does not prevent the deployment of another similar option which 190 uses another hashing algorithm (like SHA-1). Also, if most 191 implementations pad the 18 byte option as defined to 20 bytes anyway, 192 it would be just as well to define a new option which contains an 193 algorithm type field. 195 This would need to be addressed in another draft, however. 197 4.5 Key configuration 199 It should be noted that the key configuration mechanism of routers 200 may restrict the possible keys that may be used between peers. 201 Implementors should consider this issue in their design. 203 5.0 Security Considerations 205 This document defines a weak but currently practiced security 206 mechanism for BGP. It is anticipated that future work will provide 207 different stronger mechanisms for dealing with these issues. 209 6.0 References 211 [RFC1321] Rivest, R, "The MD5 Message-Digest Algorithm," RFC 1321, 212 MIT Laboratory for Computer Science, April 1992. 214 [RFC1323] Jacobson, V., Braden, R, and D. Borman, "TCP Extensions for 215 High Performance", RFC 1323, LBL, USC/Information Sciences Institute, 216 Cray Research, May 1992. 218 [Dobb] H. Dobbertin, "The Status of MD5 After a Recent Attack", RSA 219 Labs' CryptoBytes, Vol. 2 No. 2, Summer 1996. 220 http://www.rsa.com/rsalabs/pubs/cryptobytes.html 222 Author's Address 224 Andy Heffernan 225 cisco Systems 226 170 West Tasman Drive 227 San Jose, CA 95134 USA 229 Phone: +1 408 526-8115 230 Email: ahh@cisco.com