Network Working Group                                        S. Bellovin
Request for Comments: 4278                            AT&T Labs Research
Category: Informational                                         A. Zinin
                                                                Alcatel
                                                           January 2006


 Standards Maturity Variance Regarding the TCP MD5 Signature Option
                (RFC 2385) and the BGP-4 Specification

Status of This Memo

  This memo provides information for the Internet community.  It does
  not specify an Internet standard of any kind.  Distribution of this
  memo is unlimited.

Copyright Notice

  Copyright (C) The Internet Society (2006).

Abstract

  The IETF Standards Process requires that all normative references for
  a document be at the same or higher level of standardization.  RFC
  2026 section 9.1 allows the IESG to grant a variance to the standard
  practices of the IETF.  This document explains why the IESG is
  considering doing so for the revised version of the BGP-4
  specification, which refers normatively to RFC 2385, "Protection of
  BGP Sessions via the TCP MD5 Signature Option".  RFC 2385 will remain
  at the Proposed Standard level.

1.  Introduction

  The IETF Standards Process [RFC2026] requires that all normative
  references for a document be at the same or higher level of
  standardization.  RFC 2026 section 9.1 allows the IESG to grant a
  variance to the standard practices of the IETF.  Pursuant to that, it
  is considering publishing the updated BGP-4 specification [RFC4271]
  as Draft Standard, despite the normative reference to [RFC2385],
  "Protection of BGP Sessions via the TCP MD5 Signature Option".  RFC
  2385 will remain a Proposed Standard.  (Note that although the title
  of [RFC2385] includes the word "signature", the technology described
  in it is commonly known as a Message Authentication Code or MAC, and
  should not be confused with digital signature technologies.)

  [RFC2385], which is widely implemented, is the only transmission
  security mechanism defined for BGP-4.  Other possible mechanisms,
  such as IPsec [RFC2401] and TLS [RFC2246], are rarely, if ever, used



Bellovin & Zinin             Informational                      [Page 1]

RFC 4278    Standards Maturity Variance: RFC 2385 and BGP-4 January 2006


  for this purpose.  Given the long-standing requirement for security
  features in protocols, it is not possible to advance BGP-4 without a
  mandated security mechanism.

  The conflict of maturity levels between specifications would normally
  be resolved by advancing the specification being referred to along
  the standards track, to the level of maturity that the referring
  specification needs to achieve.  However, in the particular case
  considered here, the IESG believes that [RFC2385], though adequate
  for BGP deployments at this moment, is not strong enough for general
  use, and thus should not be progressed along the standards track.  In
  this situation, the IESG believes that variance procedure should be
  used to allow the updated BGP-4 specification to be published as
  Draft Standard.

  The following sections of the document give detailed explanations of
  the statements above.

2.  Draft Standard Requirements

  The requirements for Proposed Standards and Draft Standards are given
  in [RFC2026].  For Proposed Standards, [RFC2026] warns that:

       Implementors should treat Proposed Standards as immature
       specifications.  It is desirable to implement them in order to
       gain experience and to validate, test, and clarify the
       specification.  However, since the content of Proposed Standards
       may be changed if problems are found or better solutions are
       identified, deploying implementations of such standards into a
       disruption-sensitive environment is not recommended.

  In other words, it is considered reasonable for flaws to be
  discovered in Proposed Standards.

  The requirements for Draft Standards are higher:

       A Draft Standard must be well-understood and known to be quite
       stable, both in its semantics and as a basis for developing an
       implementation.

  In other words, any document that has known deficiencies should not
  be promoted to Draft Standard.









Bellovin & Zinin             Informational                      [Page 2]

RFC 4278    Standards Maturity Variance: RFC 2385 and BGP-4 January 2006


3.  The TCP MD5 Signature Option

  [RFC2385], despite its 1998 publication date, describes a Message
  Authentication Code (MAC) that is considerably older.  It utilizes a
  technique known as a "keyed hash function", using MD5 [RFC1321] as
  the hash function.  When the original code was developed, this was
  believed to be a reasonable technique, especially if the key was
  appended (rather than prepended) to the data being protected.  But
  cryptographic hash functions were never intended for use as MACs, and
  later cryptanalytic results showed that the construct was not as
  strong as originally believed [PV1, PV2].  Worse yet, the underlying
  hash function, MD5, has shown signs of weakness [Dobbertin, Wang].
  Accordingly, the IETF community has adopted Hashed Message
  Authentication Code (HMAC) [RFC2104], a scheme with provable security
  properties, as its standard MAC.

  Beyond that, [RFC2385] does not include any sort of key management
  technique.  Common practice is to use a password as a shared secret
  between pairs of sites, but this is not a good idea [RFC3562].

  Other problems are documented in [RFC2385] itself, including the lack
  of a type code or version number, and the inability of systems using
  this scheme to accept certain TCP resets.

  Despite the widespread deployment of [RFC2385] in BGP deployments,
  the IESG has thus concluded that it is not appropriate for use in
  other contexts.  [RFC2385] is not suitable for advancement to Draft
  Standard.

4.  Usage Patterns for RFC 2385

  Given the above analysis, it is reasonable to ask why [RFC2385] is
  still used for BGP.  The answer lies in the deployment patterns
  peculiar to BGP.

  BGP connections inherently tend to travel over short paths.  Indeed,
  most external BGP links are one hop.  Although internal BGP sessions
  are usually multi-hop, the links involved are generally inhabited
  only by routers rather than general-purpose computers; general-
  purpose computers are easier for attackers to use as TCP hijacking
  tools [Joncheray].

  Also, BGP peering associations tend to be long-lived and static.  By
  contrast, many other security situations are more dynamic.

  This is not to say that such attacks cannot happen.  (If they
  couldn't happen at all, there would be no point to any security
  measures.)  Attackers could divert links at layers 1 or 2, or they



Bellovin & Zinin             Informational                      [Page 3]

RFC 4278    Standards Maturity Variance: RFC 2385 and BGP-4 January 2006


  could (in some situations) use Address Resolution Protocol (ARP)
  spoofing at Ethernet-based exchange points.  Still, on balance, BGP
  is employed in an environment that is less susceptible to this sort
  of attack.

  There is another class of attack against which BGP is extremely
  vulnerable:  false route advertisements from more than one autonomous
  system (AS) hop away.  However, neither [RFC2385] nor any other
  transmission security mechanism can block such attacks.  Rather, a
  scheme such as S-BGP [Kent] would be needed.

5.  LDP

  The Label Distribution Protocol (LDP) [RFC3036] also uses [RFC2385].
  Deployment practices for LDP are very similar to those of BGP: LDP
  connections are usually confined within a single autonomous system
  and most frequently span a single link between two routers.  This
  makes the LDP threat environment very similar to BGP's.  Given this,
  and a considerable installed base of LDP in service provider
  networks, we are not deprecating [RFC2385] for use with LDP.

6.  Security Considerations

  The IESG believes that the variance described here will not adversely
  affect the security of the Internet.

7.  Conclusions

  Given the above analysis, the IESG is persuaded that waiving the
  prerequisite requirement is the appropriate thing to do.  [RFC2385]
  is clearly not suitable for Draft Standard.  Other existing
  mechanisms, such as IPsec, would do its job better.  However, given
  the current operational practices in service provider networks at the
  moment -- and in particular the common use of long-lived standard
  keys, [RFC3562] notwithstanding --  the marginal benefit of such
  schemes in this situation would be low, and not worth the transition
  effort.  We would prefer to wait for a security mechanism tailored to
  the major threat environment for BGP.

8.  Informative References

  [Dobbertin]  H. Dobbertin, "The Status of MD5 After a Recent Attack",
               RSA Labs' CryptoBytes, Vol. 2 No. 2, Summer 1996.

  [Joncheray]  Joncheray, L.  "A Simple Active Attack Against TCP."
               Proceedings of the Fifth Usenix Unix Security Symposium,
               1995.




Bellovin & Zinin             Informational                      [Page 4]

RFC 4278    Standards Maturity Variance: RFC 2385 and BGP-4 January 2006


  [Kent]       Kent, S., C. Lynn, and K. Seo.  "Secure Border Gateway
               Protocol (Secure-BGP)."  IEEE Journal on Selected Areas
               in Communications, vol. 18, no. 4, April, 2000, pp.
               582-592.

  [RFC3562]    Leech, M., "Key Management Considerations for the TCP
               MD5 Signature Option", RFC 3562, July 2003.

  [PV1]        B. Preneel and P. van Oorschot, "MD-x MAC and building
               fast MACs from hash functions," Advances in Cryptology
               --- Crypto 95 Proceedings, Lecture Notes in Computer
               Science Vol. 963, D. Coppersmith, ed., Springer-Verlag,
               1995.

  [PV2]        B. Preneel and P. van Oorschot, "On the security of two
               MAC algorithms," Advances in Cryptology --- Eurocrypt 96
               Proceedings, Lecture Notes in Computer Science, U.
               Maurer, ed., Springer-Verlag, 1996.

  [RFC1321]    Rivest, R., "The MD5 Message-Digest Algorithm ", RFC
               1321, April 1992.

  [RFC2026]    Bradner, S., "The Internet Standards Process -- Revision
               3", BCP 9, RFC 2026, October 1996.

  [RFC2104]    Krawczyk, H., Bellare, M., and R. Canetti, "HMAC:
               Keyed-Hashing for Message Authentication", RFC 2104,
               February 1997.

  [RFC2246]    Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
               RFC 2246, January 1999.

  [RFC2385]    Heffernan, A., "Protection of BGP Sessions via the TCP
               MD5 Signature Option", RFC 2385, August 1998.

  [RFC2401]    Kent, S. and R. Atkinson, "Security Architecture for the
               Internet Protocol", RFC 2401, November 1998.

  [RFC3036]    Andersson, L., Doolan, P., Feldman, N., Fredette, A.,
               and B. Thomas, "LDP Specification", RFC 3036, January
               2001.

  [RFC4271]    Rekhter, Y., Li, T., and S. Hares, Eds., "A Border
               Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.

  [Wang]       Wang, X. and H. Yu, "How to Break MD5 and Other Hash
               Functions."  Proceedings of Eurocrypt '05, 2005.




Bellovin & Zinin             Informational                      [Page 5]

RFC 4278    Standards Maturity Variance: RFC 2385 and BGP-4 January 2006


Authors' Addresses

  Steven M. Bellovin
  Department of Computer Science
  Columbia University
  1214 Amsterdam Avenue, M.C. 0401
  New York, NY 10027-7003

  Phone: +1 212-939-7149
  EMail: [email protected]


  Alex Zinin
  Alcatel
  701 E Middlefield Rd
  Mountain View, CA 94043

  EMail: [email protected]

































Bellovin & Zinin             Informational                      [Page 6]

RFC 4278    Standards Maturity Variance: RFC 2385 and BGP-4 January 2006


Full Copyright Statement

  Copyright (C) The Internet Society (2006).

  This document is subject to the rights, licenses and restrictions
  contained in BCP 78, and except as set forth therein, the authors
  retain all their rights.

  This document and the information contained herein are provided on an
  "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
  OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
  ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
  INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
  INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
  WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

  The IETF takes no position regarding the validity or scope of any
  Intellectual Property Rights or other rights that might be claimed to
  pertain to the implementation or use of the technology described in
  this document or the extent to which any license under such rights
  might or might not be available; nor does it represent that it has
  made any independent effort to identify any such rights.  Information
  on the procedures with respect to rights in RFC documents can be
  found in BCP 78 and BCP 79.

  Copies of IPR disclosures made to the IETF Secretariat and any
  assurances of licenses to be made available, or the result of an
  attempt made to obtain a general license or permission for the use of
  such proprietary rights by implementers or users of this
  specification can be obtained from the IETF on-line IPR repository at
  http://www.ietf.org/ipr.

  The IETF invites any interested party to bring to its attention any
  copyrights, patents or patent applications, or other proprietary
  rights that may cover technology that may be required to implement
  this standard.  Please address the information to the IETF at
  [email protected].

Acknowledgement

  Funding for the RFC Editor function is provided by the IETF
  Administrative Support Activity (IASA).







Bellovin & Zinin             Informational                      [Page 7]


You are viewing proxied material from gopher.fnord.one. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.