idnits 2.17.1 draft-ietf-idr-rfc2385bis-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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 == The page length should not exceed 58 lines per page, but there was 5 longer pages, the longest (page 2) being 60 lines 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 is 1 instance of too long lines in the document, the longest one being 3 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 2002) is 8049 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) == Unused Reference: 'RFC793' is defined on line 246, but no explicit reference was found in the text == Unused Reference: 'RFC2460' is defined on line 249, but no explicit reference was found in the text ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** 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: 13 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Andy Heffernan 3 Juniper Networks 4 March 2002 6 Protection of BGP Sessions via the TCP MD5 Signature Option 8 Status of this Memo 10 This document is an Internet Draft. Internet Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its Areas, 12 and its Working Groups. Note that other groups may also distribute 13 working documents as Internet Drafts. 15 This document is an Internet-Draft and is subject to all provisions 16 of Section 10 of RFC2026. 18 Internet Drafts are draft documents valid for a maximum of six 19 months. Internet Drafts may be updated, replaced, or obsoleted by 20 other documents at any time. It is not appropriate to use Internet 21 Drafts as reference material or to cite them other than as a "working 22 draft" or "work in progress." 24 Please check the I-D abstract listing contained in each Internet 25 Draft directory to learn the current status of this or any Internet 26 Draft. 28 Abstract 30 This memo describes a TCP extension to enhance security for BGP. It 31 defines a new TCP option for carrying an MD5 [RFC1321] digest in a 32 TCP segment. This digest acts like a signature for that segment, 33 incorporating information known only to the connection end points. 34 Since BGP uses TCP as its transport, using this option in the way 35 described in this paper significantly reduces the danger from certain 36 security attacks on BGP. 38 1.0 Introduction 40 The primary motivation for this option is to allow BGP to protect 41 itself against the introduction of spoofed TCP segments into the 42 connection stream. Of particular concern are TCP resets. 44 To spoof a connection using the scheme described in this paper, an 45 attacker would not only have to guess TCP sequence numbers, but would 46 also have had to obtain the password included in the MD5 digest. 47 This password never appears in the connection stream, and the actual 48 form of the password is up to the application. It could even change 49 during the lifetime of a particular connection so long as this change 50 was synchronized on both ends (although retransmission can become 51 problematical in some TCP implementations with changing passwords). 53 Finally, there is no negotiation for the use of this option in a 54 connection, rather it is purely a matter of site policy whether or 55 not its connections use the option. 57 2.0 Proposal 59 Every segment sent on a TCP connection to be protected against 60 spoofing will contain the 16-byte MD5 digest produced by applying the 61 MD5 algorithm to these items in the following order: 63 1. the TCP pseudo-header 64 2. the TCP header, excluding options (but with a correct Data Offset 65 field), and assuming a checksum of zero 66 3. the TCP segment data (if any) 67 4. an independently-specified key or password, known to both TCPs 68 and presumably connection-specific 70 For IPv4, the pseudo-header is as described in RFC 793, namely the 71 32-bit source IP address, 32-bit destination IP address, zero- 72 extended protocol number (to form 16 bits), and 16-bit segment 73 length. Note that this includes use of IPv4 via IPv4-mapped IPv6 74 addresses, in which case the source and destination IP addresses are 75 from the IPv4 portions of the IPv6 source and destination addresses, 76 respectively. 78 For IPv6, the pseudo-header is as described in RFC 2460, namely the 79 128-bit source IPv6 address, 128-bit destination IPv6 address, zero- 80 extended next header value (to form 32 bits), and 32-bit segment 81 length. 83 For any other network protocol, the pseudo-header is as described in 84 the document that defines how upper-level protocols like TCP compute 85 their checksums. 87 The header and pseudo-header are in network byte order. The nature 88 of the key is deliberately left unspecified, but it must be known by 89 both ends of the connection. A particular TCP implementation will 90 determine what the application may specify as the key. 92 Upon receiving a signed segment, the receiver must validate it by 93 calculating its own digest from the same data (using its own key) and 94 comparing the two digest. A failing comparison must result in the 95 segment being dropped and must not produce any response back to the 96 sender. Logging the failure is probably advisable. 98 Unlike other TCP extensions (e.g., the Window Scale option 99 [RFC1323]), the absence of the option in the SYN,ACK segment must not 100 cause the sender to disable its sending of signatures. This 101 negotiation is typically done to prevent some TCP implementations 102 from misbehaving upon receiving options in non-SYN segments. This is 103 not a problem for this option, since the SYN,ACK sent during 104 connection negotiation will not be signed and will thus be ignored. 105 The connection will never be made, and non-SYN segments with options 106 will never be sent. More importantly, the sending of signatures must 107 be under the complete control of the application, not at the mercy of 108 the remote host not understanding the option. 110 3.0 Syntax 112 The proposed option has the following format: 114 +---------+---------+-------------------+ 115 | Kind=19 |Length=18| MD5 digest... | 116 +---------+---------+-------------------+ 117 | | 118 +---------------------------------------+ 119 | | 120 +---------------------------------------+ 121 | | 122 +-------------------+-------------------+ 123 | | 124 +-------------------+ 126 The MD5 digest is always 16 bytes in length, and the option would 127 appear in every segment of a connection. 129 4.0 Some Implications 131 4.1 Connectionless Resets 133 A connectionless reset will be ignored by the receiver of the reset, 134 since the originator of that reset does not know the key, and so 135 cannot generate the proper signature for the segment. This means, 136 for example, that connection attempts by a TCP which is generating 137 signatures to a port with no listener will time out instead of being 138 refused. Similarly, resets generated by a TCP in response to 139 segments sent on a stale connection will also be ignored. 140 Operationally this can be a problem since resets help BGP recover 141 quickly from peer crashes. 143 4.2 Performance 145 The performance hit in calculating digests may inhibit the use of 146 this option. Some measurements of a sample implementation showed 147 that on a 100 MHz R4600, generating a signature for simple ACK 148 segment took an average of 0.0268 ms, while generating a signature 149 for a data segment carrying 4096 bytes of data took 0.8776 ms on 150 average. These times would be applied to both the input and output 151 paths, with the input path also bearing the cost of a 16-byte 152 compare. 154 4.3 TCP Header Size 156 As with other options that are added to every segment, the size of 157 the MD5 option must be factored into the MSS offered to the other 158 side during connection negotiation. Specifically, the size of the 159 header to subtract from the MTU (whether it is the MTU of the 160 outgoing interface or IP's minimal MTU of 576 bytes) is now at least 161 18 bytes larger. 163 The total header size is also an issue. The TCP header specifies 164 where segment data starts with a 4-bit field which gives the total 165 size of the header (including options) in 32-byte words. This means 166 that the total size of the header plus option must be less than or 167 equal to 60 bytes -- this leaves 40 bytes for options. 169 As a concrete example, 4.4BSD defaults to sending window-scaling and 170 timestamp information for connections it initiates. The most loaded 171 segment will be the initial SYN packet to start the connection. With 172 MD5 signatures, the SYN packet will contain the following: 174 -- 4 bytes MSS option 175 -- 4 bytes window scale option (3 bytes padded to 4 in 4.4BSD) 176 -- 12 bytes for timestamp (4.4BSD pads the option as recommended 177 in RFC 1323 Appendix A) 178 -- 18 bytes for MD5 digest 179 -- 2 bytes for end-of-option-list, to pad to a 32-bit boundary. 181 This sums to 40 bytes, which just makes it. (Note that other padding 182 schemes are possible which would reduce the aggregate size.) 184 4.4 Key Configuration 185 It should be noted that the key configuration mechanism of routers 186 may restrict the possible keys that may be used between peers. It is 187 strongly recommended that an implementation be able to support at 188 minimum a key composed of a string of printable ASCII of 80 bytes or 189 less, as this is current practice. 191 5.0 Security Considerations 193 This document defines a weak but currently practiced security 194 mechanism for BGP. It is anticipated that future work will provide 195 different stronger mechanisms for dealing with these issues. 197 5.1 MD5 as a hashing algorithm 199 The MD5 algorithm has been found to be vulnerable to collision search 200 attacks [Dobb], and is considered by some to be insufficiently strong 201 for this type of application. 203 This document specifies the MD5 algorithm, however, since the option 204 has already been deployed operationally, and there is no "algorithm 205 type" field defined to allow an upgrade using the same option number. 206 The original draft did not specify a type field since this would 207 require at least one more byte, and it was felt at the time that 208 taking 19 bytes for the complete option (which would probably be 209 padded to 20 bytes in TCP implementations) would be too much of a 210 waste of the already limited option space. 212 This does not prevent the deployment of another similar option which 213 uses another hashing algorithm (like SHA-1). Also, if most 214 implementations pad the 18 byte option as defined to 20 bytes anyway, 215 it would be just as well to define a new option which contains an 216 algorithm type field. This would need to be addressed in another 217 draft, however. 219 5.2 Signature Coverage 221 A further weakness exists due to the exclusion of option data from 222 the signature. This decision was made to simplify the protocol 223 definition and implementation, but might possibly leave a connection 224 vulnerable since option data can be rewritten without detection. 226 6.0 Changes from RFC 2385 228 The previous version of this specification was published as RFC 2385. 230 The changes in this document are primarly to be more explicit about 231 the data over which the MD5 signature is taken. In particular, 232 Section 2.0 describes the differences between IPv4 and IPv6 and their 233 respective pseudo-header definitions. 235 Additionally, section 4.3 adds a note about option padding. 237 The former section 4.4 ("MD5 has a Hashing Algorithm") has moved to 238 the Security Considerations section of the document as section 5.1 239 and the former section 4.5 ("Key configuration") is now section 4.4. 241 Finally, section 5.2 has been added to mention that the signature 242 does not cover option data, which might be a vulnerability. 244 7.0 References 246 [RFC793] Postel, J., "Transmission Control Protocol," RFC 793, 247 September 1981. 249 [RFC2460] Deering, S., and Hinden, R., "Internet Protocol, 250 Version 6 (IPv6) Specification," RFC 2460, December 1998. 252 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm," RFC 1321, 253 MIT Laboratory for Computer Science, April 1992. 255 [RFC1323] Jacobson, V., Braden, R., and Borman, D., "TCP Extensions 256 for High Performance", RFC 1323, LBL, USC/Information Sciences 257 Institute, Cray Research, May 1992. 259 [Dobb] Dobbertin, H., "The Status of MD5 After a Recent Attack", RSA 260 Labs' CryptoBytes, Vol. 2 No. 2, Summer 1996. 261 http://www.rsa.com/rsalabs/pubs/cryptobytes.html 263 Author's Address 265 Andy Heffernan 266 Juniper Networks 267 1194 N. Mathilda Avenue 268 Sunnyvale, CA 94089 USA 270 Phone: +1 408 745-2037 271 Email: ahh@juniper.net