Authentication/Confidentiality for OSPFv3
RFC 4552
|
| Document |
Type |
|
RFC - Proposed Standard
(June 2006; Errata)
|
|
Last updated |
|
2015-10-14
|
|
Stream |
|
IETF
|
|
Formats |
|
plain text
pdf
html
bibtex
|
| Stream |
WG state
|
|
(None)
|
|
Document shepherd |
|
No shepherd assigned
|
| IESG |
IESG state |
|
RFC 4552 (Proposed Standard)
|
|
Consensus Boilerplate |
|
Unknown
|
|
Telechat date |
|
|
|
Responsible AD |
|
Bill Fenner
|
|
Send notices to |
|
<rohit@utstar.com>
|
Network Working Group M. Gupta
Request for Comments: 4552 Tropos Networks
Category: Standards Track N. Melam
Juniper Networks
June 2006
Authentication/Confidentiality for OSPFv3
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document describes means and mechanisms to provide
authentication/confidentiality to OSPFv3 using an IPv6 Authentication
Header/Encapsulating Security Payload (AH/ESP) extension header.
Gupta & Melam Standards Track [Page 1]
RFC 4552 Authentication/Confidentiality for OSPFv3 June 2006
Table of Contents
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................2
2. Transport Mode vs. Tunnel Mode ..................................3
3. Authentication ..................................................3
4. Confidentiality .................................................3
5. Distinguishing OSPFv3 from OSPFv2 ...............................4
6. IPsec Requirements ..............................................4
7. Key Management ..................................................5
8. SA Granularity and Selectors ....................................7
9. Virtual Links ...................................................8
10. Rekeying .......................................................9
10.1. Rekeying Procedure ........................................9
10.2. KeyRolloverInterval .......................................9
10.3. Rekeying Interval ........................................10
11. IPsec Protection Barrier and SPD ..............................10
12. Entropy of Manual Keys ........................................12
13. Replay Protection .............................................12
14. Security Considerations .......................................12
15. References ....................................................13
15.1. Normative References .....................................13
15.2. Informative References ...................................13
1. Introduction
OSPF (Open Shortest Path First) Version 2 [N1] defines the fields
AuType and Authentication in its protocol header to provide security.
In OSPF for IPv6 (OSPFv3) [N2], both of the authentication fields
were removed from OSPF headers. OSPFv3 relies on the IPv6
Authentication Header (AH) and IPv6 Encapsulating Security Payload
(ESP) to provide integrity, authentication, and/or confidentiality.
This document describes how IPv6 AH/ESP extension headers can be used
to provide authentication/confidentiality to OSPFv3.
It is assumed that the reader is familiar with OSPFv3 [N2], AH [N5],
ESP [N4], the concept of security associations, tunnel and transport
mode of IPsec, and the key management options available for AH and
ESP (manual keying [N3] and Internet Key Exchange (IKE)[I1]).
1.1. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [N7].
Gupta & Melam Standards Track [Page 2]
RFC 4552 Authentication/Confidentiality for OSPFv3 June 2006
2. Transport Mode vs. Tunnel Mode
The transport mode Security Association (SA) is generally used
between two hosts or routers/gateways when they are acting as hosts.
The SA must be a tunnel mode SA if either end of the security
association is a router/gateway. Two hosts MAY establish a tunnel
mode SA between themselves. OSPFv3 packets are exchanged between
routers. However, since the packets are locally delivered, the
routers assume the role of hosts in the context of tunnel mode SA.
All implementations conforming to this specification MUST support
transport mode SA to provide required IPsec security to OSPFv3
Show full document text