< draft-ietf-ospf-rfc6506bis-01.txt   draft-ietf-ospf-rfc6506bis-02.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: April 11, 2014 A. Lindem Expires: May 16, 2014 A. Lindem
Ericsson Ericsson
October 8, 2013 November 12, 2013
Supporting Authentication Trailer for OSPFv3 Supporting Authentication Trailer for OSPFv3
draft-ietf-ospf-rfc6506bis-01.txt draft-ietf-ospf-rfc6506bis-02.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 April 11, 2014. This Internet-Draft will expire on May 16, 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Summary of Changes from RFC 6506 . . . . . . . . . . . . . 5 1.2. Summary of Changes from RFC 6506 . . . . . . . . . . . . . 4
2. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . 7 2. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . 6
2.1. AT-Bit in Options Field . . . . . . . . . . . . . . . . . 7 2.1. AT-Bit in Options Field . . . . . . . . . . . . . . . . . 6
2.2. Basic Operation . . . . . . . . . . . . . . . . . . . . . 8 2.2. Basic Operation . . . . . . . . . . . . . . . . . . . . . 7
2.3. IPv6 Source Address Protection . . . . . . . . . . . . . . 8 2.3. IPv6 Source Address Protection . . . . . . . . . . . . . . 7
3. OSPFv3 Security Association . . . . . . . . . . . . . . . . . 10 3. OSPFv3 Security Association . . . . . . . . . . . . . . . . . 9
4. Authentication Procedure . . . . . . . . . . . . . . . . . . . 13 4. Authentication Procedure . . . . . . . . . . . . . . . . . . . 11
4.1. Authentication Trailer . . . . . . . . . . . . . . . . . . 13 4.1. Authentication Trailer . . . . . . . . . . . . . . . . . . 11
4.1.1. Sequence Number Wrap . . . . . . . . . . . . . . . . . 14 4.1.1. Sequence Number Wrap . . . . . . . . . . . . . . . . . 12
4.2. OSPFv3 Header Checksum and LLS Data Block Checksum . . . . 15 4.2. OSPFv3 Header Checksum and LLS Data Block Checksum . . . . 13
4.3. Cryptographic Authentication Procedure . . . . . . . . . . 15 4.3. Cryptographic Authentication Procedure . . . . . . . . . . 13
4.4. Cross-Protocol Attack Mitigation . . . . . . . . . . . . . 16 4.4. Cross-Protocol Attack Mitigation . . . . . . . . . . . . . 14
4.5. Cryptographic Aspects . . . . . . . . . . . . . . . . . . 16 4.5. Cryptographic Aspects . . . . . . . . . . . . . . . . . . 14
4.6. Message Verification . . . . . . . . . . . . . . . . . . . 18 4.6. Message Verification . . . . . . . . . . . . . . . . . . . 16
5. Migration and Backward Compatibility . . . . . . . . . . . . . 21 5. Migration and Backward Compatibility . . . . . . . . . . . . . 19
6. Security Considerations . . . . . . . . . . . . . . . . . . . 22 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
8.1. Normative References . . . . . . . . . . . . . . . . . . . 24 8.1. Normative References . . . . . . . . . . . . . . . . . . . 22
8.2. Informative References . . . . . . . . . . . . . . . . . . 24 8.2. Informative References . . . . . . . . . . . . . . . . . . 22
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 26 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
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 28 skipping to change at page 4, line 28
1.2. Summary of Changes from RFC 6506 1.2. Summary of Changes from RFC 6506
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 erratum.
2. Section 3 previously advocated usage of an expired key for 2. Section 3 previously recommended usage of an expired key for
transmitted OSPFv3 packets when no valid keys existed. This transmitted OSPFv3 packets when no valid keys existed. This
statement has been removed. statement has been removed.
3. Section 4.5 includes a correction to the key preparation to use 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
erratum.
4. 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 erratum.
5. 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].
6. Section 4.6 explicitly states that OSPFv3 packets with a non- 6. Section 4.6 explicitly states that OSPFv3 packets with a non-
existent or expired Security Association (SA) will be dropped. existent or expired Security Association (SA) will be dropped.
7. Section 5 includes guidance on precisely the actions required for 7. Section 5 includes guidance on precisely the actions required for
skipping to change at page 11, line 49 skipping to change at page 10, line 49
KeyStopAccept. If KeyStartGenerate or KeyStartAccept are left KeyStopAccept. If KeyStartGenerate or KeyStartAccept are left
unspecified, the time will default to 0, and the key will be used unspecified, the time will default to 0, and the key will be used
immediately. If KeyStopGenerate or KeyStopAccept are left immediately. If KeyStopGenerate or KeyStopAccept are left
unspecified, the time will default to infinity, and the key's unspecified, the time will default to infinity, and the key's
lifetime will be infinite. When a new key replaces an old, the lifetime will be infinite. When a new key replaces an old, the
KeyStartGenerate time for the new key MUST be less than or equal to KeyStartGenerate time for the new key MUST be less than or equal to
the KeyStopGenerate time of the old key. the KeyStopGenerate time of the old key.
Key storage SHOULD persist across a system restart, warm or cold, to Key storage SHOULD persist across a system restart, warm or cold, to
avoid operational issues. In the event that the last key associated avoid operational issues. In the event that the last key associated
with an interface expires, it is unacceptable to revert to an with an interface expires, the network operator SHOULD be notified
unauthenticated condition and not advisable to disrupt routing. and the OSPFv3 packet MUST NOT be transmitted unauthenticated.
Therefore, the router SHOULD send a "last Authentication Key
expiration" notification to the network operator and treat the key as
having an infinite lifetime until the lifetime is extended, the key
is deleted by the network operator, or a new key is configured.
4. Authentication Procedure 4. Authentication Procedure
4.1. Authentication Trailer 4.1. Authentication Trailer
The Authentication Trailer that is appended to the OSPFv3 protocol The Authentication Trailer that is appended to the OSPFv3 protocol
packet is described below: packet is described below:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
skipping to change at page 22, line 12 skipping to change at page 20, line 12
not be authenticated. Additionally, the OSPFv3 header checksum not be authenticated. Additionally, the OSPFv3 header checksum
and LLS block checksum will be validated. and LLS block checksum will be validated.
6. Security Considerations 6. Security Considerations
The document proposes extensions to OSPFv3 that would make it more The document proposes extensions to OSPFv3 that would make it more
secure than [RFC5340]. It does not provide confidentiality as a secure than [RFC5340]. It does not provide confidentiality as a
routing protocol contains information that does not need to be kept routing protocol contains information that does not need to be kept
secret. It does, however, provide means to authenticate the sender secret. It does, however, provide means to authenticate the sender
of the packets that are of interest. It addresses all the security of the packets that are of interest. It addresses all the security
issues that have been identified in [RFC6039]. issues that have been identified in [RFC6039] and [RFC6506].
It should be noted that the authentication method described in this It should be noted that the authentication method described in this
document is not being used to authenticate the specific originator of document is not being used to authenticate the specific originator of
a packet but is rather being used to confirm that the packet has a packet but is rather being used to confirm that the packet has
indeed been issued by a router that has access to the Authentication indeed been issued by a router that has access to the Authentication
Key. Key.
Deployments SHOULD use sufficiently long and random values for the Deployments SHOULD use sufficiently long and random values for the
Authentication Key so that guessing and other cryptographic attacks Authentication Key so that guessing and other cryptographic attacks
on the key are not feasible in their environments. Furthermore, it on the key are not feasible in their environments. Furthermore, it
skipping to change at page 27, line 5 skipping to change at page 25, line 5
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.
Thanks to Alia Atlas for comments made under the purview of the Thanks to Alia Atlas for comments made under the purview of the
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.
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. 13 change blocks. 
51 lines changed or deleted 38 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/