< draft-iesg-tcpmd5app-00.txt   draft-iesg-tcpmd5app-01.txt >
Network Working Group Steven M. Bellovin Network Working Group Steven M. Bellovin
Internet Draft AT&T Labs Research Internet Draft AT&T Labs Research
Expiration Date: May 2005 Alex Zinin
Alcatel
Expiration Date: September 2004 March 2004 September 2004
Standards Maturity Variance Regarding the TCP MD5 Signature Option (RFC Standards Maturity Variance Regarding the TCP MD5 Signature Option (RFC
2385) and the BGP-4 Specification 2385) and the BGP-4 Specification
draft-iesg-tcpmd5app-00.txt draft-iesg-tcpmd5app-01.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with By submitting this Internet-Draft, I certify that any applicable
all provisions of Section 10 of RFC2026. 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.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
skipping to change at page 2, line 14 skipping to change at page 2, line 25
1. Introduction 1. Introduction
The IETF Standards Process [RFC2026] requires that all normative The IETF Standards Process [RFC2026] requires that all normative
references for a document be at the same or higher level of references for a document be at the same or higher level of
standardization. RFC 2026 section 9.1 allows the IESG to grant a standardization. RFC 2026 section 9.1 allows the IESG to grant a
variance to the standard practices of the IETF. Pursuant to that, it variance to the standard practices of the IETF. Pursuant to that, it
is considering publishing the updated BGP-4 specification [RLH] as is considering publishing the updated BGP-4 specification [RLH] as
Draft Standard, despite the normative reference to [RFC2385], Draft Standard, despite the normative reference to [RFC2385],
"Protection of BGP Sessions via the TCP MD5 Signature Option"; that "Protection of BGP Sessions via the TCP MD5 Signature Option"; that
protocol will remain a Proposed Standard. protocol will remain a Proposed Standard. (Note that though 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 [RFC2385], which is widely implemented, is the only transmission
security mechanism defined for BGP-4. Other possible mechanisms, security mechanism defined for BGP-4. Other possible mechanisms,
such as IPsec [RFC2401] and TLS [RFC2246], are rarely, if ever, used such as IPsec [RFC2401] and TLS [RFC2246], are rarely, if ever, used
for this purpose. Given the long-standing requirement for security for this purpose. Given the long-standing requirement for security
features in protocols, it is not possible to advance BGP-4 with no features in protocols, it is not possible to advance BGP-4 with no
mandated security mechanism. mandated security mechanism.
The conflict of maturity levels between specifications would normally The conflict of maturity levels between specifications would normally
be resolved by advancing the specification being referred to along be resolved by advancing the specification being referred to along
skipping to change at page 4, line 38 skipping to change at page 5, line 8
There is another class of attack against which BGP is extremely There is another class of attack against which BGP is extremely
vulnerable: false route advertisements from more than one autonomous vulnerable: false route advertisements from more than one autonomous
system (AS) hop away. However, neither [RFC2385] nor any other system (AS) hop away. However, neither [RFC2385] nor any other
transmission security mechanism can block such attacks. Rather, a transmission security mechanism can block such attacks. Rather, a
scheme such as S-BGP [Kent] would be needed. scheme such as S-BGP [Kent] would be needed.
5. LDP 5. LDP
The Label Distribution Protocol (LDP) [RFC3036] also uses [RFC2385]. The Label Distribution Protocol (LDP) [RFC3036] also uses [RFC2385].
Since LDP connections are always between routers and are always one Deployment practices for LDP are very similar to those of BGP: LDP
hop long, the threat environment is similar to BGP's. Accordingly, connections are usually confined within a single autonomous system
we are not deprecating [RFC2385] for use with LDP. and most frequently span a single link between two routers. This
makes 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 6. Security Considerations
The IESG believes that the variance described here will not affect The IESG believes that the variance described here will not affect
the security of the Internet. the security of the Internet.
7. Conclusions 7. Conclusions
Given the above analysis, the IESG is persuaded that waiving the Given the above analysis, the IESG is persuaded that waiving the
prerequisite requirement is the appropriate thing to do. [RFC2385] prerequisite requirement is the appropriate thing to do. [RFC2385]
skipping to change at page 5, line 25 skipping to change at page 5, line 35
mechanisms, such as IPsec, would do its job better. However, given mechanisms, such as IPsec, would do its job better. However, given
the current operational practices in service provider networks at the the current operational practices in service provider networks at the
moment -- and in particular the common use of long-lived standard moment -- and in particular the common use of long-lived standard
keys, [RFC3562] notwithstanding -- the marginal benefit of such keys, [RFC3562] notwithstanding -- the marginal benefit of such
schemes in this situation would be low, and not worth the transition schemes in this situation would be low, and not worth the transition
effort. We would prefer to wait for a security mechanism tailored effort. We would prefer to wait for a security mechanism tailored
towards the major threat environment for BGP. towards the major threat environment for BGP.
8. References 8. References
[Dobbertin] H. Dobbertin, "The Status of MD5 After a Recent Attack", [Dobbertin] H. Dobbertin, "The Status of MD5 After a Recent
RSA Labs' CryptoBytes, Vol. 2 No. 2, Summer 1996. Attack", RSA Labs' CryptoBytes, Vol. 2 No. 2, Summer
1996.
[Joncheray] Joncheray, L. "A Simple Active Attack Against TCP." [Joncheray] Joncheray, L. "A Simple Active Attack Against TCP."
Proceedings of the Fifth Usenix Unix Security Symposium, Proceedings of the Fifth Usenix Unix Security Symposium,
1995. 1995.
[Kent] Kent, S., C. Lynn, and K. Seo. "Secure Border Gateway [Kent] Kent, S., C. Lynn, and K. Seo. "Secure Border Gateway
Protocol (Secure-BGP)." IEEE Journal on Selected Areas Protocol (Secure-BGP)." IEEE Journal on Selected Areas
in Communications, vol. 18, no. 4, April, 2000, pp. in Communications, vol. 18, no. 4, April, 2000, pp.
582-592. 582-592.
[RFC3562] Leech, M. "Key Management Considerations for the TCP MD5 [RFC3562] Leech, M. "Key Management Considerations for the TCP
Signature Option". RFC 3562. July 2003. MD5 Signature Option". RFC 3562. July 2003.
[PV1] B. Preneel and P. van Oorschot, "MD-x MAC and building [PV1] B. Preneel and P. van Oorschot, "MD-x MAC and building fast
fast MACs from hash functions," Advances in Cryptology MACs from hash functions," Advances in Cryptology ---
--- Crypto 95 Proceedings, Lecture Notes in Computer Crypto 95 Proceedings, Lecture Notes in Computer Science
Science Vol. 963, D. Coppersmith, ed., Springer-Verlag, Vol. 963, D. Coppersmith, ed., Springer-Verlag, 1995.
1995.
[PV2] B. Preneel and P. van Oorschot, "On the security of two [PV2] B. Preneel and P. van Oorschot, "On the security of two MAC
MAC algorithms," Advances in Cryptology --- Eurocrypt 96 algorithms," Advances in Cryptology --- Eurocrypt 96
Proceedings, Lecture Notes in Computer Science, U. Proceedings, Lecture Notes in Computer Science, U.
Maurer, ed., Springer-Verlag, 1996. Maurer, ed., Springer-Verlag, 1996.
[RFC1321] Rivest, R. "The MD5 Message-Digest Algorithm." RFC [RFC1321] Rivest, R. "The MD5 Message-Digest Algorithm." RFC
1321. April, 1992. 1321. April, 1992.
[RFC2026] Bradner, S. "The Internet Standards Process -- Revision [RFC2026] Bradner, S. "The Internet Standards Process --
3." RFC 2026. October 1996. Revision 3." RFC 2026. October 1996.
[RFC2104] Krawczyk, H., M. Bellare, and R. Canetti, "HMAC: Keyed- [RFC2104] Krawczyk, H., M. Bellare, and R. Canetti, "HMAC:
Hashing for Message Authentication." RFC 2104. February Keyed-Hashing for Message Authentication." RFC 2104.
1997. February 1997.
[RFC2246] Dierks, T. and C. Allen. "The TLS Protocol Version 1.0." [RFC2246] Dierks, T. and C. Allen. "The TLS Protocol Version
RFC 2246. January, 1999. 1.0." RFC 2246. January, 1999.
[RFC2385] Heffernan, A. "Protection of BGP Sessions via the TCP [RFC2385] Heffernan, A. "Protection of BGP Sessions via the
MD5 Signature Option." RFC 2385. August, 1998. TCP MD5 Signature Option." RFC 2385. August, 1998.
[RFC2401] Kent, S. and R. Atkinson. "Security Architecture for the [RFC2401] Kent, S. and R. Atkinson. "Security Architecture for
Internet Protocol." RFC 2401. November, 1998. the Internet Protocol." RFC 2401. November, 1998.
[RFC3036] Andersson, L., P. DOolan, N. Feldman, A. [RFC3036] Andersson, L., P. DOolan, N. Feldman, A.
Fredette, and B. Thomas. "LDP Specification." RFC 3036, Fredette, and B. Thomas. "LDP Specification." RFC 3036,
January 2001. January 2001.
[RLH] Rekhter, Y., T. Li, and S. Hares. "A Border Gateway [RLH] Rekhter, Y., T. Li, and S. Hares. "A Border Gateway Protocol
Protocol 4 (BGP-4)." draft-ietf-idr-bgp4, December 2003, 4 (BGP-4)." draft-ietf-idr-bgp4, December 2003, work in
work in progress. progress.
9. Author Information 9. Author Information
Steven M. Bellovin
AT&T Labs Research
Shannon Laboratory
180 Park Avenue
Florham Park, NJ 07932
Phone: +1 973-360-8656
email: bellovin@acm.org
IPR Disclosure Acknowledgement Steven M. Bellovin
AT&T Labs Research
Shannon Laboratory
180 Park Avenue
Florham Park, NJ 07932
Phone: +1 973-360-8656
email: bellovin@acm.org
By submitting this Internet-Draft, I certify that any applicable Alex Zinin
patent or other IPR claims of which I am aware have been disclosed, Alcatel
and any of which I become aware will be disclosed, in accordance with Mountain View, CA
RFC 3668. email: zinin@psg.com
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Disclaimer Disclaimer
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
 End of changes. 23 change blocks. 
49 lines changed or deleted 58 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/