< draft-acee-ospf-rfc6506bis-02.txt   draft-acee-ospf-rfc6506bis-03.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: November 10, 2013 A. Lindem Expires: December 25, 2013 A. Lindem
Ericsson Ericsson
May 9, 2013 June 23, 2013
Supporting Authentication Trailer for OSPFv3 Supporting Authentication Trailer for OSPFv3
draft-acee-ospf-rfc6506bis-02.txt draft-acee-ospf-rfc6506bis-03.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 November 10, 2013. This Internet-Draft will expire on December 25, 2013.
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 6, line 5 skipping to change at page 5, line 44
3. Section 4.5 also includes a discussion of the choice of key 3. 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 4. 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. from RFC 6506.
5. Section 5 includes guidance on precisely the actions required for
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 20, line 25 skipping to change at page 20, line 25
result in sub-optimal routing as well as added complexity and is only result in sub-optimal routing as well as added complexity and is only
recommended in cases where authentication is desired on the link and recommended in cases where authentication is desired on the link and
migrating all the routers on the link at the same time isn't migrating all the routers on the link at the same time isn't
feasible. feasible.
In support of uninterrupted deployment, an OSPFv3 router implementing In support of uninterrupted deployment, an OSPFv3 router implementing
this specification MAY implement a transition mode where it includes this specification MAY implement a transition mode where it includes
the Authentication Trailer in transmitted packets but does not verify the Authentication Trailer in transmitted packets but does not verify
this information in received packets. This is provided as a this information in received packets. This is provided as a
transition aid for networks in the process of migrating to the transition aid for networks in the process of migrating to the
authentication mechanism described in this specification. authentication mechanism described in this specification. More
specifically:
1. OSPFv3 routers in transition mode will include the OSPFv3
authentication trailer in transmitted packets and set the AT-Bit
in the options field of transmitted Hello and Database
Description packets. OSPFv3 routers receiving these packets and
not having authentication configured will ignore the
authentication trailer and AT-bit.
2. OSPFv3 routers in transition mode will also calculate and set the
OSPFv3 header checksum and the LLS block checksum in transmitted
packets so that they will not be dropped by OSPFv3 routers
without authentication configured.
3. OSPFv3 routers in transition mode will authenticate received
packets that have the AT-Bit set in the options field of Hello
and Database Description packets or are from a neighbor that
previously set the AT-Bit in the options field in Hello and
Database Description packets.
4. OSPFv3 routers in transition mode will also accept packets
without the options field AT-Bit set in Hello and Database
Description packets. These packets will be assumed to be from
OSPFv3 routers without authentication configured and they will
not be authenticated. Additionally, the OSPFv3 header checksum
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].
skipping to change at page 25, line 30 skipping to change at page 25, line 30
and submission of RFC 6506 errata. and submission of RFC 6506 errata.
Thanks to Sam Hartman for discussions on replay mitigation and the Thanks to Sam Hartman for discussions on replay mitigation and the
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
backward compatible transition mode.
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. 7 change blocks. 
5 lines changed or deleted 37 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/