than restricting it to a subset of ASCII characters (letters,
numbers, etc.). A restricted character set will reduce key entropy
significantly as discussed in [I2].
13. Replay Protection
Since it is not possible using the current standards to provide
complete replay protection while using manual keying, the proposed
solution will not provide protection against replay attacks.
Detailed analysis of various vulnerabilities of the routing protocols
and OSPF in particular is discussed in [I3] and [I2]. The conclusion
is that replay of OSPF packets can cause adjacencies to be disrupted,
which can lead to a DoS attack on the network. It can also cause
database exchange process to occur continuously thus causing CPU
overload as well as micro loops in the network.
14. Security Considerations
This memo discusses the use of IPsec AH and ESP headers to provide
security to OSPFv3 for IPv6. Hence, security permeates throughout
this document.
OSPF Security Vulnerabilities Analysis [I2] identifies OSPF
vulnerabilities in two scenarios -- one with no authentication or
simple password authentication and the other with cryptographic
authentication. The solution described in this specification
provides protection against all the vulnerabilities identified for
scenarios with cryptographic authentication with the following
exceptions:
Limitations of manual key:
This specification mandates the usage of manual keys. The following
are the known limitations of the usage of manual keys.
o As the sequence numbers cannot be negotiated, replay protection
cannot be provided. This leaves OSPF insecure against all the
attacks that can be performed by replaying OSPF packets.
o Manual keys are usually long lived (changing them often is a
tedious task). This gives an attacker enough time to discover
the keys.
o As the administrator is manually configuring the keys, there is
a chance that the configured keys are weak (there are known
weak keys for DES/3DES at least).
Impersonating attacks:
The usage of the same key on all the OSPF routers connected to a link
leaves them all insecure against impersonating attacks if any one of
the OSPF routers is compromised, malfunctioning, or misconfigured.
Detailed analysis of various vulnerabilities of routing protocols is
discussed in [I3].
15. References
15.1. Normative References
[N1] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[N2] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", RFC 2740,
December 1999.
[N3] Kent, S. and K. Seo, "Security Architecture for the Internet
Protocol", RFC 4301, December 2005.
[N4] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303,
December 2005.
[N5] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[N6] Eastlake 3rd, D., "Cryptographic Algorithm Implementation
Requirements for Encapsulating Security Payload (ESP) and
Authentication Header (AH)", RFC 4305, December 2005.
[N7] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
15.2. Informative References
[I1] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306,
December 2005.
[I2] Jones, E. and O. Moigne, "OSPF Security Vulnerabilities
Analysis", Work in Progress.
[I3] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to Routing
Protocols", Work in Progress.
[I4] Leech, M., "Key Management Considerations for the TCP MD5
Signature Option", RFC 3562, July 2003.
Acknowledgements
The authors would like to extend sincere thanks to Marc Solsona,
Janne Peltonen, John Cruz, Dhaval Shah, Abhay Roy, Paul Wells,
Vishwas Manral, and Sam Hartman for providing useful information and
critiques on this memo. The authors would like to extend special
thanks to Acee Lindem for many editorial changes.
We would also like to thank members of the IPsec and OSPF WG for
providing valuable review comments.
Authors’ Addresses
Mukesh Gupta
Tropos Networks
555 Del Rey Ave
Sunnyvale, CA 94085
Phone: 408-331-6889
EMail: mukesh.gupta@tropos.com
Nagavenkata Suresh Melam
Juniper Networks
1194 N. Mathilda Ave
Sunnyvale, CA 94089
Phone: 408-505-4392
EMail: nmelam@juniper.net
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).