idnits 2.17.1 draft-iesg-tcpmd5app-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 278. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 6 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 7 pages 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (September 2004) is 7162 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'Dobbertin' -- Possible downref: Non-RFC (?) normative reference: ref. 'Joncheray' -- Possible downref: Non-RFC (?) normative reference: ref. 'Kent' ** Downref: Normative reference to an Informational RFC: RFC 3562 -- Possible downref: Non-RFC (?) normative reference: ref. 'PV1' -- Possible downref: Non-RFC (?) normative reference: ref. 'PV2' ** Downref: Normative reference to an Informational RFC: RFC 1321 ** Downref: Normative reference to an Informational RFC: RFC 2104 ** Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2385 (Obsoleted by RFC 5925) ** Obsolete normative reference: RFC 2401 (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 3036 (Obsoleted by RFC 5036) Summary: 18 errors (**), 0 flaws (~~), 4 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Steven M. Bellovin 2 Internet Draft AT&T Labs Research 3 Expiration Date: May 2005 Alex Zinin 4 Alcatel 6 September 2004 8 Standards Maturity Variance Regarding the TCP MD5 Signature Option (RFC 9 2385) and the BGP-4 Specification 11 draft-iesg-tcpmd5app-01.txt 13 Status of this Memo 15 By submitting this Internet-Draft, I certify that any applicable 16 patent or other IPR claims of which I am aware have been disclosed, 17 or will be disclosed, and any of which I become aware will be 18 disclosed, in accordance with RFC 3668. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet- Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 Abstract 38 The IETF Standards Process requires that all normative references for 39 a document be at the same or higher level of standardization. RFC 40 2026 section 9.1 allows the IESG to grant a variance to the standard 41 practices of the IETF. This document explains why the IESG is 42 considering doing so for the revised version of the BGP-4 43 specification, which refers normatively to RFC 2385, "Protection of 44 BGP Sessions via the TCP MD5 Signature Option". RFC 2385 will remain 45 at the Proposed Standard level. 47 1. Introduction 49 The IETF Standards Process [RFC2026] requires that all normative 50 references for a document be at the same or higher level of 51 standardization. RFC 2026 section 9.1 allows the IESG to grant a 52 variance to the standard practices of the IETF. Pursuant to that, it 53 is considering publishing the updated BGP-4 specification [RLH] as 54 Draft Standard, despite the normative reference to [RFC2385], 55 "Protection of BGP Sessions via the TCP MD5 Signature Option"; that 56 protocol will remain a Proposed Standard. (Note that though the title 57 of [RFC2385] includes the word "signature", the technology described 58 in it is commonly known as a message authentication code or MAC, and 59 should not be confused with digital signature technologies.) 61 [RFC2385], which is widely implemented, is the only transmission 62 security mechanism defined for BGP-4. Other possible mechanisms, 63 such as IPsec [RFC2401] and TLS [RFC2246], are rarely, if ever, used 64 for this purpose. Given the long-standing requirement for security 65 features in protocols, it is not possible to advance BGP-4 with no 66 mandated security mechanism. 68 The conflict of maturity levels between specifications would normally 69 be resolved by advancing the specification being referred to along 70 the standards track to the level of maturity that the referring 71 specification needs to achieve. However, in the particular case 72 considered here, the IESG believes that [RFC2385], though adequate 73 for BGP deployments at this moment, is not strong enough for general 74 use, and thus should not be progressed along the standards track. In 75 this situation, the IESG believes that variance procedure should be 76 used to allow the updated BGP-4 specification to be published as 77 Draft Standard. 79 The following sections of the document give detailed explanations of 80 the statements above. 82 2. Draft Standard Requirements 84 The requirements for Proposed Standards and Draft Standards are given 85 in [RFC2026]. For Proposed Standards, [RFC2026] warns that: 87 Implementors should treat Proposed Standards as immature 88 specifications. It is desirable to implement them in order to 89 gain experience and to validate, test, and clarify the 90 specification. However, since the content of Proposed Standards 91 may be changed if problems are found or better solutions are 92 identified, deploying implementations of such standards into a 93 disruption-sensitive environment is not recommended. 95 In other words, it is considered reasonable for flaws to be 96 discovered in Proposed Standards. 98 The requirements for Draft Standards are higher: 100 A Draft Standard must be well-understood and known to be quite 101 stable, both in its semantics and as a basis for developing an 102 implementation. 104 In other words, any document that has known deficiencies should not 105 be promoted to Draft Standard. 107 3. The TCP MD5 Signature Option 109 [RFC2385], despite its 1998 publication date, describes a Message 110 Authentication Code (MAC) that is considerably older. It utilizes a 111 technique known as a "keyed hash function", using MD5 [RFC1321] as 112 the hash function. At the time the original code was developed, this 113 was believed to be a reasonable technique, especially if the key was 114 appended to the data being protected, rather than being prepended. 115 But cryptographic hash functions were never intended for use as MACs, 116 and later cryptanalytic results showed that the construct was not as 117 strong as was originally believed [PV1,PV2]. Worse yet, the 118 underlying hash function, MD5, has shown signs of weakness 119 [Dobbertin]. Accordingly, the IETF community has adopted HMAC 120 [RFC2104], a scheme with provable security properties, as its 121 standard MAC. 123 Beyond that, [RFC2385] does not include any sort of key management 124 technique. Common practice is to use a password as a shared secret 125 between pairs of sites. This is not a good idea [RFC3562]. 127 Other problems are documented in [RFC2385] itself, including the lack 128 of a type code or version number, and the inability of systems using 129 this scheme to accept certain TCP resets. 131 Despite the widespread deployment of [RFC2385] in BGP deployments, 132 the IESG has thus concluded that it is not appropriate for use in 133 other contexts. [RFC2385] is not suitable for advancement to Draft 134 Standard. 136 4. Usage Patterns for RFC 2385 138 Given the above analysis, it is reasonable to ask why [RFC2385] is 139 still used for BGP. The answer lies in the deployment patterns 140 peculiar to BGP. 142 BGP connections inherently tend to travel over short paths. Indeed, 143 most external BGP links are one hop. Furthermore, though internal 144 BGP sessions are usually multi-hop, the links involved are generally 145 inhabited only by routers rather than general-purpose computers; 146 general-purpose computers are easier for attackers to use as TCP 147 hijacking tools [Joncheray]. 149 It is also the case that BGP peering associations tend to be long- 150 lived and static. By contrast, many other security situations are 151 more dynamic. 153 This is not to say that such attacks cannot happen. (If they 154 couldn't happen at all, there would be no point to any security 155 measures.) Attackers could divert links at layers 1 or 2, or they 156 could (in some situations) use ARP-spoofing at Ethernet-based 157 exchange points. Still, on balance, BGP is employed in an 158 environment that is less susceptible to this sort of attack. 160 There is another class of attack against which BGP is extremely 161 vulnerable: false route advertisements from more than one autonomous 162 system (AS) hop away. However, neither [RFC2385] nor any other 163 transmission security mechanism can block such attacks. Rather, a 164 scheme such as S-BGP [Kent] would be needed. 166 5. LDP 168 The Label Distribution Protocol (LDP) [RFC3036] also uses [RFC2385]. 169 Deployment practices for LDP are very similar to those of BGP: LDP 170 connections are usually confined within a single autonomous system 171 and most frequently span a single link between two routers. This 172 makes LDP threat environment very similar to BGP's. Given this, and a 173 considerable installed base of LDP in service provider networks, we 174 are not deprecating [RFC2385] for use with LDP. 176 6. Security Considerations 178 The IESG believes that the variance described here will not affect 179 the security of the Internet. 181 7. Conclusions 183 Given the above analysis, the IESG is persuaded that waiving the 184 prerequisite requirement is the appropriate thing to do. [RFC2385] 185 is clearly not suitable for Draft Standard. Other existing 186 mechanisms, such as IPsec, would do its job better. However, given 187 the current operational practices in service provider networks at the 188 moment -- and in particular the common use of long-lived standard 189 keys, [RFC3562] notwithstanding -- the marginal benefit of such 190 schemes in this situation would be low, and not worth the transition 191 effort. We would prefer to wait for a security mechanism tailored 192 towards the major threat environment for BGP. 194 8. References 196 [Dobbertin] H. Dobbertin, "The Status of MD5 After a Recent 197 Attack", RSA Labs' CryptoBytes, Vol. 2 No. 2, Summer 198 1996. 200 [Joncheray] Joncheray, L. "A Simple Active Attack Against TCP." 201 Proceedings of the Fifth Usenix Unix Security Symposium, 202 1995. 204 [Kent] Kent, S., C. Lynn, and K. Seo. "Secure Border Gateway 205 Protocol (Secure-BGP)." IEEE Journal on Selected Areas 206 in Communications, vol. 18, no. 4, April, 2000, pp. 207 582-592. 209 [RFC3562] Leech, M. "Key Management Considerations for the TCP 210 MD5 Signature Option". RFC 3562. July 2003. 212 [PV1] B. Preneel and P. van Oorschot, "MD-x MAC and building fast 213 MACs from hash functions," Advances in Cryptology --- 214 Crypto 95 Proceedings, Lecture Notes in Computer Science 215 Vol. 963, D. Coppersmith, ed., Springer-Verlag, 1995. 217 [PV2] B. Preneel and P. van Oorschot, "On the security of two MAC 218 algorithms," Advances in Cryptology --- Eurocrypt 96 219 Proceedings, Lecture Notes in Computer Science, U. 220 Maurer, ed., Springer-Verlag, 1996. 222 [RFC1321] Rivest, R. "The MD5 Message-Digest Algorithm." RFC 223 1321. April, 1992. 225 [RFC2026] Bradner, S. "The Internet Standards Process -- 226 Revision 3." RFC 2026. October 1996. 228 [RFC2104] Krawczyk, H., M. Bellare, and R. Canetti, "HMAC: 229 Keyed-Hashing for Message Authentication." RFC 2104. 230 February 1997. 232 [RFC2246] Dierks, T. and C. Allen. "The TLS Protocol Version 233 1.0." RFC 2246. January, 1999. 235 [RFC2385] Heffernan, A. "Protection of BGP Sessions via the 236 TCP MD5 Signature Option." RFC 2385. August, 1998. 238 [RFC2401] Kent, S. and R. Atkinson. "Security Architecture for 239 the Internet Protocol." RFC 2401. November, 1998. 241 [RFC3036] Andersson, L., P. DOolan, N. Feldman, A. 242 Fredette, and B. Thomas. "LDP Specification." RFC 3036, 243 January 2001. 245 [RLH] Rekhter, Y., T. Li, and S. Hares. "A Border Gateway Protocol 246 4 (BGP-4)." draft-ietf-idr-bgp4, December 2003, work in 247 progress. 249 9. Author Information 251 Steven M. Bellovin 252 AT&T Labs Research 253 Shannon Laboratory 254 180 Park Avenue 255 Florham Park, NJ 07932 256 Phone: +1 973-360-8656 257 email: bellovin@acm.org 259 Alex Zinin 260 Alcatel 261 Mountain View, CA 262 email: zinin@psg.com 264 Copyright Notice 266 Copyright (C) The Internet Society (2004). This document is subject 267 to the rights, licenses and restrictions contained in BCP 78, and 268 except as set forth therein, the authors retain all their rights. 270 Disclaimer 272 This document and the information contained herein are provided on an 273 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 274 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 275 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 276 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 277 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 278 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.