396 lines
14 KiB
Plaintext
396 lines
14 KiB
Plaintext
|
||
|
||
|
||
|
||
|
||
|
||
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: bellovin@acm.org
|
||
|
||
|
||
Alex Zinin
|
||
Alcatel
|
||
701 E Middlefield Rd
|
||
Mountain View, CA 94043
|
||
|
||
EMail: zinin@psg.com
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
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
|
||
ietf-ipr@ietf.org.
|
||
|
||
Acknowledgement
|
||
|
||
Funding for the RFC Editor function is provided by the IETF
|
||
Administrative Support Activity (IASA).
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Bellovin & Zinin Informational [Page 7]
|
||
|