Authentication/Confidentiality for OSPFv3
RFC 4552
Document | Type | RFC - Proposed Standard (June 2006; No errata) | |
---|---|---|---|
Authors | Mukesh Gupta , Nagavenkata Melam | ||
Last updated | 2020-07-29 | ||
Stream | Internent Engineering Task Force (IETF) | ||
Formats | plain text html pdf htmlized (tools) htmlized bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 4552 (Proposed Standard) | |
Action Holders |
(None)
|
||
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 packets. They MAY also support tunnel mode SA to provide required IPsec security to OSPFv3 packets. 3. Authentication Implementations conforming to this specification MUST support authentication for OSPFv3. In order to provide authentication to OSPFv3, implementations MUST support ESP and MAY support AH.Show full document text