< draft-ietf-ospf-rfc6506bis-03.txt   draft-ietf-ospf-rfc6506bis-04.txt >
OSPF Working Group M. Bhatia OSPF Working Group M. Bhatia
Internet-Draft Alcatel-Lucent Internet-Draft Alcatel-Lucent
Obsoletes: 6506 (if approved) V. Manral Obsoletes: 6506 (if approved) V. Manral
Intended status: Standards Track Hewlett Packard Intended status: Standards Track Hewlett Packard
Expires: May 30, 2014 A. Lindem Expires: June 11, 2014 A. Lindem
Ericsson Ericsson
November 26, 2013 December 8, 2013
Supporting Authentication Trailer for OSPFv3 Supporting Authentication Trailer for OSPFv3
draft-ietf-ospf-rfc6506bis-03.txt draft-ietf-ospf-rfc6506bis-04.txt
Abstract Abstract
Currently, OSPF for IPv6 (OSPFv3) uses IPsec as the only mechanism Currently, OSPF for IPv6 (OSPFv3) uses IPsec as the only mechanism
for authenticating protocol packets. This behavior is different from for authenticating protocol packets. This behavior is different from
authentication mechanisms present in other routing protocols (OSPFv2, authentication mechanisms present in other routing protocols (OSPFv2,
Intermediate System to Intermediate System (IS-IS), RIP, and Routing Intermediate System to Intermediate System (IS-IS), RIP, and Routing
Information Protocol Next Generation (RIPng)). In some environments, Information Protocol Next Generation (RIPng)). In some environments,
it has been found that IPsec is difficult to configure and maintain it has been found that IPsec is difficult to configure and maintain
and thus cannot be used. This document defines an alternative and thus cannot be used. This document defines an alternative
mechanism to authenticate OSPFv3 protocol packets so that OSPFv3 does mechanism to authenticate OSPFv3 protocol packets so that OSPFv3 does
not only depend upon IPsec for authentication. This document not only depend upon IPsec for authentication.
obsoletes RFC 6506.
The OSPFv3 Authentication Trailer was originally defined in RFC 6506.
This document obsoletes RFC 6506 by providing a revised definition
including clarifications and refinements of the procedures.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on May 30, 2014. This Internet-Draft will expire on June 11, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 41 skipping to change at page 3, line 41
Regarding replay protection, [RFC4552] states that: Regarding replay protection, [RFC4552] states that:
Since it is not possible using the current standards to provide Since it is not possible using the current standards to provide
complete replay protection while using manual keying, the proposed complete replay protection while using manual keying, the proposed
solution will not provide protection against replay attacks. solution will not provide protection against replay attacks.
Since there is no replay protection provided there are a number of Since there is no replay protection provided there are a number of
vulnerabilities in OSPFv3 that have been discussed in [RFC6039]. vulnerabilities in OSPFv3 that have been discussed in [RFC6039].
Since there is no deterministic way to differentiate between While techniques exist to identify ESP Null packets [RFC5879], these
encrypted and unencrypted ESP packets by simply examining the packet, techniques are generally not implemented in the data planes of OSPFv3
it could be difficult for some implementations to prioritize certain routers. This makes it very difficult for implementations to examine
OSPFv3 packet types, e.g., Hello packets, over the other types. OSPFv3 packet and prioritize certain OSPFv3 packet types, e.g., Hello
packets, over the other types.
This document defines a new mechanism that works similarly to OSPFv2 This document defines a new mechanism that works similarly to OSPFv2
[RFC5709] to provide authentication to the OSPFv3 packets and [RFC5709] to provide authentication to the OSPFv3 packets and
attempts to solve the problems related to replay protection and attempts to solve the problems related to replay protection and
deterministically disambiguating different OSPFv3 packets as deterministically disambiguating different OSPFv3 packets as
described above. described above.
This document adds support for the Secure Hash Algorithms (SHAs) This document adds support for the Secure Hash Algorithms (SHAs)
defined in the US NIST Secure Hash Standard (SHS), which is specified defined in the US NIST Secure Hash Standard (SHS), which is specified
by NIST FIPS 180-3. [FIPS-180-3] includes SHA-1, SHA-224, SHA-256, by NIST FIPS 180-3. [FIPS-180-3] includes SHA-1, SHA-224, SHA-256,
skipping to change at page 23, line 19 skipping to change at page 23, line 19
[RFC4822] Atkinson, R. and M. Fanto, "RIPv2 Cryptographic [RFC4822] Atkinson, R. and M. Fanto, "RIPv2 Cryptographic
Authentication", RFC 4822, February 2007. Authentication", RFC 4822, February 2007.
[RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R.,
and M. Fanto, "IS-IS Generic Cryptographic and M. Fanto, "IS-IS Generic Cryptographic
Authentication", RFC 5310, February 2009. Authentication", RFC 5310, February 2009.
[RFC5613] Zinin, A., Roy, A., Nguyen, L., Friedman, B., and D. [RFC5613] Zinin, A., Roy, A., Nguyen, L., Friedman, B., and D.
Yeung, "OSPF Link-Local Signaling", RFC 5613, August 2009. Yeung, "OSPF Link-Local Signaling", RFC 5613, August 2009.
[RFC5879] Kivinen, T. and D. McDonald, "Heuristics for Detecting
ESP-NULL Packets", RFC 5879, May 2010.
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
"Internet Key Exchange Protocol Version 2 (IKEv2)", "Internet Key Exchange Protocol Version 2 (IKEv2)",
RFC 5996, September 2010. RFC 5996, September 2010.
[RFC6039] Manral, V., Bhatia, M., Jaeggli, J., and R. White, "Issues [RFC6039] Manral, V., Bhatia, M., Jaeggli, J., and R. White, "Issues
with Existing Cryptographic Protection Methods for Routing with Existing Cryptographic Protection Methods for Routing
Protocols", RFC 6039, October 2010. Protocols", RFC 6039, October 2010.
[RFC6234] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms [RFC6234] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011. (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011.
skipping to change at page 26, line 5 skipping to change at page 25, line 9
Routing Directorate review. Routing Directorate review.
Thanks to Stephen Farrell for comments during the IESG review. Thanks to Stephen Farrell for comments during the IESG review.
Stephen was also involved in the discussion of cross-protocol Stephen was also involved in the discussion of cross-protocol
attacks. attacks.
Thanks to Brian Carpenter for comments made during Gen-ART review. Thanks to Brian Carpenter for comments made during Gen-ART review.
Thanks to Victor Kuarsingh for the OPS-DIR review. Thanks to Victor Kuarsingh for the OPS-DIR review.
Thanks to Brian Weis for the SEC-DIR review.
Authors' Addresses Authors' Addresses
Manav Bhatia Manav Bhatia
Alcatel-Lucent Alcatel-Lucent
Bangalore Bangalore
India India
Email: manav.bhatia@alcatel-lucent.com Email: manav.bhatia@alcatel-lucent.com
Vishwas Manral Vishwas Manral
 End of changes. 8 change blocks. 
10 lines changed or deleted 19 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/