< draft-ietf-ospf-rfc6506bis-02.txt   draft-ietf-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: May 16, 2014 A. Lindem Expires: May 30, 2014 A. Lindem
Ericsson Ericsson
November 12, 2013 November 26, 2013
Supporting Authentication Trailer for OSPFv3 Supporting Authentication Trailer for OSPFv3
draft-ietf-ospf-rfc6506bis-02.txt draft-ietf-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 May 16, 2014. This Internet-Draft will expire on May 30, 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 20, line 28 skipping to change at page 20, line 28
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
is RECOMMENDED that Authentication Keys incorporate at least 128 is RECOMMENDED that Authentication Keys incorporate at least 128
pseudo-random bits to minimize the risk of such attacks. In support pseudo-random bits to minimize the risk of such attacks. In support
of these recommendations, management systems SHOULD support of these recommendations, management systems SHOULD support
hexadecimal input of Authentication Keys. hexadecimal input of Authentication Keys.
Deployments supporting a transitionary state which interoperate with
routers that do not support this authentication method may be exposed
to unauthenticated data during the transition period.
The mechanism described herein is not perfect and does not need to be The mechanism described herein is not perfect and does not need to be
perfect. Instead, this mechanism represents a significant increase perfect. Instead, this mechanism represents a significant increase
in the effort required for an adversary to successfully attack the in the effort required for an adversary to successfully attack the
OSPFv3 protocol while not causing undue implementation, deployment, OSPFv3 protocol while not causing undue implementation, deployment,
or operational complexity. or operational complexity.
Refer to [RFC4552] for additional considerations on manual keying. Refer to [RFC4552] for additional considerations on manual keying.
7. IANA Considerations 7. IANA Considerations
This document obsoletes RFC 6506 and thus IANA is requested to update
the reference for the existing registries previously created by RFC
6506 to this document. This is the only IANA action requested by
this document.
IANA has allocated the AT-bit (0x000400) in the "OSPFv3 Options (24 IANA has allocated the AT-bit (0x000400) in the "OSPFv3 Options (24
bits)" registry as described in Section 2.1. bits)" registry as described in Section 2.1.
IANA has created the "OSPFv3 Authentication Trailer Options" IANA has created the "OSPFv3 Authentication Trailer Options"
registry. This new registry initially includes the "OSPFv3 registry. This new registry initially includes the "OSPFv3
Authentication Types" registry, which defines valid values for the Authentication Types" registry, which defines valid values for the
Authentication Type field in the OSPFv3 Authentication Trailer. The Authentication Type field in the OSPFv3 Authentication Trailer. The
registration procedure is Standards Action. registration procedure is Standards Action.
+-------------+-----------------------------------+ +-------------+-----------------------------------+
skipping to change at page 26, line 5 skipping to change at page 25, line 7
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. Thanks to Brian Carpenter for comments made during Gen-ART review.
Thanks to Victor Kuarsingh for the OPS-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
Hewlett Packard Hewlett Packard
USA USA
Email: vishwas.manral@hp.com Email: vishwas.manral@hp.com
Acee Lindem Acee Lindem
Ericsson Ericsson
102 Carric Bend Court 301 Midenhall Way
Cary, NC 27519 Cary, NC 27513
USA USA
Email: acee.lindem@ericsson.com Email: acee.lindem@ericsson.com
 End of changes. 8 change blocks. 
6 lines changed or deleted 17 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/