Authentication/Confidentiality for OSPFv3
RFC 4552

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 08

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.