< draft-ietf-ospf-rfc6506bis-00.txt   draft-ietf-ospf-rfc6506bis-01.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: February 14, 2014 A. Lindem Expires: April 11, 2014 A. Lindem
Ericsson Ericsson
August 13, 2013 October 8, 2013
Supporting Authentication Trailer for OSPFv3 Supporting Authentication Trailer for OSPFv3
draft-ietf-ospf-rfc6506bis-00.txt draft-ietf-ospf-rfc6506bis-01.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
skipping to change at page 1, line 42 skipping to change at page 1, line 42
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 February 14, 2014. This Internet-Draft will expire on April 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 10 skipping to change at page 3, line 10
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 5
1.2. Summary of Changes from RFC 6506 . . . . . . . . . . . . . 5 1.2. Summary of Changes from RFC 6506 . . . . . . . . . . . . . 5
2. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . 6 2. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . 7
2.1. AT-Bit in Options Field . . . . . . . . . . . . . . . . . 6 2.1. AT-Bit in Options Field . . . . . . . . . . . . . . . . . 7
2.2. Basic Operation . . . . . . . . . . . . . . . . . . . . . 7 2.2. Basic Operation . . . . . . . . . . . . . . . . . . . . . 8
2.3. IPv6 Source Address Protection . . . . . . . . . . . . . . 7 2.3. IPv6 Source Address Protection . . . . . . . . . . . . . . 8
3. OSPFv3 Security Association . . . . . . . . . . . . . . . . . 9 3. OSPFv3 Security Association . . . . . . . . . . . . . . . . . 10
4. Authentication Procedure . . . . . . . . . . . . . . . . . . . 12 4. Authentication Procedure . . . . . . . . . . . . . . . . . . . 13
4.1. Authentication Trailer . . . . . . . . . . . . . . . . . . 12 4.1. Authentication Trailer . . . . . . . . . . . . . . . . . . 13
4.1.1. Sequence Number Wrap . . . . . . . . . . . . . . . . . 13 4.1.1. Sequence Number Wrap . . . . . . . . . . . . . . . . . 14
4.2. OSPFv3 Header Checksum and LLS Data Block Checksum . . . . 14 4.2. OSPFv3 Header Checksum and LLS Data Block Checksum . . . . 15
4.3. Cryptographic Authentication Procedure . . . . . . . . . . 14 4.3. Cryptographic Authentication Procedure . . . . . . . . . . 15
4.4. Cross-Protocol Attack Mitigation . . . . . . . . . . . . . 15 4.4. Cross-Protocol Attack Mitigation . . . . . . . . . . . . . 16
4.5. Cryptographic Aspects . . . . . . . . . . . . . . . . . . 15 4.5. Cryptographic Aspects . . . . . . . . . . . . . . . . . . 16
4.6. Message Verification . . . . . . . . . . . . . . . . . . . 17 4.6. Message Verification . . . . . . . . . . . . . . . . . . . 18
5. Migration and Backward Compatibility . . . . . . . . . . . . . 20 5. Migration and Backward Compatibility . . . . . . . . . . . . . 21
6. Security Considerations . . . . . . . . . . . . . . . . . . . 21 6. Security Considerations . . . . . . . . . . . . . . . . . . . 22
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
8.1. Normative References . . . . . . . . . . . . . . . . . . . 23 8.1. Normative References . . . . . . . . . . . . . . . . . . . 24
8.2. Informative References . . . . . . . . . . . . . . . . . . 23 8.2. Informative References . . . . . . . . . . . . . . . . . . 24
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 25 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27
1. Introduction 1. Introduction
Unlike Open Shortest Path First version 2 (OSPFv2) [RFC2328], OSPF Unlike Open Shortest Path First version 2 (OSPFv2) [RFC2328], OSPF
for IPv6 (OSPFv3) [RFC5340] does not include the AuType and for IPv6 (OSPFv3) [RFC5340] does not include the AuType and
Authentication fields in its headers for authenticating protocol Authentication fields in its headers for authenticating protocol
packets. Instead, OSPFv3 relies on the IPsec protocols packets. Instead, OSPFv3 relies on the IPsec protocols
Authentication Header (AH) [RFC4302] and Encapsulating Security Authentication Header (AH) [RFC4302] and Encapsulating Security
Payload (ESP) [RFC4303] to provide integrity, authentication, and/or Payload (ESP) [RFC4303] to provide integrity, authentication, and/or
confidentiality. confidentiality.
skipping to change at page 5, line 30 skipping to change at page 5, line 30
This document includes the following changes from RFC 6506 [RFC6506]: This document includes the following changes from RFC 6506 [RFC6506]:
1. Sections 2.2 and 4.2 explicitly state that the Link-Local 1. Sections 2.2 and 4.2 explicitly state that the Link-Local
Signaling (LLS) block checksum calculation is omitted when an Signaling (LLS) block checksum calculation is omitted when an
OSPFv3 authentication trailer is used for OSPFv3 authentication. OSPFv3 authentication trailer is used for OSPFv3 authentication.
The LLS block is included in the authentication digest The LLS block is included in the authentication digest
calculation and computation of a checksum is unnecessary. calculation and computation of a checksum is unnecessary.
Clarification of this issue was documented in an errata. Clarification of this issue was documented in an errata.
2. Section 4.5 includes a correction to the key preparation to use 2. Section 3 previously advocated usage of an expired key for
transmitted OSPFv3 packets when no valid keys existed. This
statement has been removed.
3. Section 4.5 includes a correction to the key preparation to use
the protocol specific key (Ks) rather than the key (K) as the the protocol specific key (Ks) rather than the key (K) as the
initial key (Ko). This problem was also documented in an errata. initial key (Ko). This problem was also documented in an errata.
3. Section 4.5 also includes a discussion of the choice of key 4. Section 4.5 also includes a discussion of the choice of key
length to be the hash length (L) rather than the block size (B). length to be the hash length (L) rather than the block size (B).
The discussion of this choice was included to clarify an issue The discussion of this choice was included to clarify an issue
raised in a rejected errata. raised in a rejected errata.
4. Section 4.1 and 4.6 indicate that sequence number checking is 5. Section 4.1 and 4.6 indicate that sequence number checking is
dependent on OSPFv3 packet type in order to account for packet dependent on OSPFv3 packet type in order to account for packet
prioritization as specified in [RFC4222]. This was an omission prioritization as specified in [RFC4222]. This was an omission
from RFC 6506 [RFC6506]. from RFC 6506 [RFC6506].
5. Section 5 includes guidance on precisely the actions required for 6. Section 4.6 explicitly states that OSPFv3 packets with a non-
existent or expired Security Association (SA) will be dropped.
7. Section 5 includes guidance on precisely the actions required for
an OSPFv3 router providing a backward compatible transition mode. an OSPFv3 router providing a backward compatible transition mode.
2. Proposed Solution 2. Proposed Solution
To perform non-IPsec Cryptographic Authentication, OSPFv3 routers To perform non-IPsec Cryptographic Authentication, OSPFv3 routers
append a special data block, henceforth referred to as the append a special data block, henceforth referred to as the
Authentication Trailer, to the end of the OSPFv3 packets. The length Authentication Trailer, to the end of the OSPFv3 packets. The length
of the Authentication Trailer is not included in the length of the of the Authentication Trailer is not included in the length of the
OSPFv3 packet but is included in the IPv6 payload length, as shown in OSPFv3 packet but is included in the IPv6 payload length, as shown in
Figure 1. Figure 1.
skipping to change at page 18, line 27 skipping to change at page 19, line 27
the AT. It is RECOMMENDED that OSPFv3 routers supporting this the AT. It is RECOMMENDED that OSPFv3 routers supporting this
specification fully support OSPFv3 Link-Local Signaling [RFC5613]. specification fully support OSPFv3 Link-Local Signaling [RFC5613].
If usage of the Authentication Trailer (AT), as specified herein, is If usage of the Authentication Trailer (AT), as specified herein, is
configured for an OSPFv3 link, OSPFv3 Hello and Database Description configured for an OSPFv3 link, OSPFv3 Hello and Database Description
packets with the AT-bit clear in the options will be dropped. All packets with the AT-bit clear in the options will be dropped. All
OSPFv3 packet types will be dropped if AT is configured for the link OSPFv3 packet types will be dropped if AT is configured for the link
and the IPv6 header length is less than the amount necessary to and the IPv6 header length is less than the amount necessary to
include an Authentication Trailer. include an Authentication Trailer.
Locate the receiving interface's OSPFv3 SA using the SA ID in the
received AT. If the SA is not found, or if the SA is not valid for
reception (i.e., current time < KeyStartAccept or current time >=
KeyStopAccept), the OSPFv3 packet is dropped.
If the cryptographic sequence number in the AT is less than or equal If the cryptographic sequence number in the AT is less than or equal
to the last sequence number in the last OSPFv3 packet of the same to the last sequence number in the last OSPFv3 packet of the same
OSPFv3 type successfully received from the neighbor, the OSPFv3 OSPFv3 type successfully received from the neighbor, the OSPFv3
packet MUST be dropped, and an error event SHOULD be logged. OSPFv3 packet MUST be dropped, and an error event SHOULD be logged. OSPFv3
packets of different types may arrive out of order if they are packets of different types may arrive out of order if they are
prioritized as recommended in [RFC4222]. prioritized as recommended in [RFC4222].
Authentication-algorithm-dependent processing needs to be performed, Authentication-algorithm-dependent processing needs to be performed,
using the algorithm specified by the appropriate OSPFv3 SA for the using the algorithm specified by the appropriate OSPFv3 SA for the
received packet. received packet.
skipping to change at page 25, line 33 skipping to change at page 26, line 33
use of a 64-bit strictly increasing sequence number. Also, thanks to use of a 64-bit strictly increasing sequence number. Also, thanks to
Sam for comments during IETF last call with respect to the OSPFv3 SA Sam for comments during IETF last call with respect to the OSPFv3 SA
and sharing of key between protocols. and sharing of key between protocols.
Thanks to Michael Barnes for numerous comments and strong input on Thanks to Michael Barnes for numerous comments and strong input on
the coverage of LLS by the Authentication Trailer (AT). the coverage of LLS by the Authentication Trailer (AT).
Thanks to Marek Karasek for providing the specifics with respect to Thanks to Marek Karasek for providing the specifics with respect to
backward compatible transition mode. backward compatible transition mode.
Thanks to Michael Dubrovskiy and Anton Smirnov for comments on draft
revisions.
Thanks to Rajesh Shetty for numerous comments, including the Thanks to Rajesh Shetty for numerous comments, including the
suggestion to include an Authentication Type field in the suggestion to include an Authentication Type field in the
Authentication Trailer for extendibility. Authentication Trailer for extendibility.
Thanks to Uma Chunduri for suggesting that we may want to protect the Thanks to Uma Chunduri for suggesting that we may want to protect the
IPv6 source address even though OSPFv3 uses the Router ID for IPv6 source address even though OSPFv3 uses the Router ID for
neighbor identification. neighbor identification.
Thanks to Srinivasan KL, Shraddha H, Alan Davey, Russ White, Stan Thanks to Srinivasan KL, Shraddha H, Alan Davey, Russ White, Stan
Ratliff, and Glen Kent for their support and review comments. Ratliff, and Glen Kent for their support and review comments.
 End of changes. 11 change blocks. 
29 lines changed or deleted 44 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/