[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00 01                                                         
   Network Working Group                                       M. Gupta
   Internet Draft                                                 Nokia
   Document: draft-gupta-ospf-ospfv3-auth-00.txt               N. Melam
   Expires: October 2002                                          Nokia
                                                              June 2002


                 Authentication/Confidentiality for OSPFv3


Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
        http://www.ietf.org/ietf/1id-abstracts.txt
   The list of Internet-Draft Shadow Directories can be accessed at
        http://www.ietf.org/shadow.html.

Abstract

   This document describes means/mechanisms to provide
   authentication/confidentiality to OSPFv3 using IPv6 AH/ESP Extension
   Header.

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 [Ref5].

Table of Contents

   1. Introduction...................................................2
   2. OSPFv2 to OSPFv3...............................................2
   3. Authentication.................................................2
   4. Confidentiality................................................3
   5. Key Management.................................................3
   6. SA Granularity.................................................4


M. Gupta/N. Melam      Expires - December 2002               [Page 1]


               Authentication/Confidentiality to OSPFv3      June 2002


   7. Virtual Links..................................................5
   8. Replay Protection..............................................5
   Security Considerations...........................................5
   References........................................................5
   Acknowledgments...................................................6
   Authors Addresses................................................6


1. Introduction

   In OSPFv3 for IPv6, authentication fields have been removed from OSPF
   headers. When running over IPv6, OSPF relies on the IPv6
   Authentication Header (AH) and IPv6 Encapsulating Security Payload
   (ESP) to ensure integrity, authentication and/or confidentiality of
   routing exchanges.

   This documents 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 [Ref1], AH
   [Ref4], ESP [Ref3], the concept of security associations, tunnel and
   transport mode of IPsec and the key management options available for
   AH and ESP (manual keying and IKE) [Ref2].


2. OSPFv2 to OSPFv3

   Security concerns MUST be taken away from OSPFv3 protocol and IPv6
   stack MUST provide inherent security to OSPFv3 by using AH/ESP
   extension headers. It means OSPFv3 protocol MUST not receive any
   unauthenticated packets. As OSPFv2 has its own security mechanisms,
   no inherent security needs to be provided by the IPv4 stack. As
   OSPFv2 is only for IPv4 and OSPFv3 is only for IPv6, the distinction
   between the packets can be easily made by IP version.

   Authentication and confidentiality, if provided, MUST be provided to
   the entire OSPFv3 header and data. Authentication to the selected
   portions of IPv6 header, selected portions of extension headers and
   selected options may also be provided optionally.

3. Authentication

   Transport mode SA is the security association between two hosts or
   security gateways that are acting as hosts. SA must be tunnel mode if
   either end of the security association is a security gateway. OSPFv3
   packets are exchanged between the routers but as the packets are
   destined to the routers, the routers act like host in this case. So
   transport mode SA MUST be used in order to provide required security
   to OSPFv3.


M. Gupta/N. Melam      Expires - December 2002               [Page 2]


               Authentication/Confidentiality to OSPFv3      June 2002



   In order to support OSPFv3 authentication, ESP with NULL encryption¶
   MUST be supported in transport mode. AH¶ in transport mode SHOULD
   also be provided. AH in transport mode provides authentication to
   higher layer protocols, selected portions of IPv6 header, selected
   portions of extension headers and selected options. ESP with NULL
   encryption in transport mode will provide authentication to only
   higher layer protocol data and not to the IPv6 header, extension
   headers and options.

   OSPF packets received in clear text and OSPF received with incorrect
   AH ICV MUST be dropped when authentication is enabled.

4. Confidentiality

   Providing confidentiality to OSPFv3 in addition to authentication is
   optional. Confidentiality must be implemented using ESP extension
   header of IPv6 if it is being provided. ESP with non-null encryption
   in transport mode MUST be used for the providing confidentiality to
   OSPFv3.

5. Key Management

   OSPFv3 exchanges both multicast and unicast packets. While running
   OSPFv3 over a broadcast interface, the authentication/confidentiality
   required is one to many¶. Since IKE is based on the Diffie-Hellman
   key agreement protocol and works only for two communicating parties,
   it is not possible to use IKE for providing the required one to
   many¶ authentication/confidentiality. Manual keying MUST be used for
   this purpose. In manual keying SAs are statically installed on the
   routers and these static SAs are used to encrypt/authenticate the
   data.

   Since security associations (SAs) are directional, generally
   different security associations are used for inbound and outbound
   processing for providing higher security. Following figure explains
   that it is not possible to use different security associations for
   inbound and outbound processing in order to provide the required one
   to many¶ security.












M. Gupta/N. Melam      Expires - December 2002               [Page 3]


               Authentication/Confidentiality to OSPFv3      June 2002



       A                  |
     SAa     ------------>|
     SAb     <------------|
                          |
       B                  |
     SAb     ------------>|
     SAa     <------------|
                          |
       C                  |
     SAa/SAb ------------>|
     SAa/SAb <------------|
                      Broadcast
                       Network


   If we consider communication between A and B in the above diagram,
   everything seems to be fine. A uses security association SAa for
   outgoing packets and B uses the same for incoming packets and vice
   versa. Now if we include C in the group and C sends a packet out
   using SAa then only A will be able to understand it or if C sends the
   packets out using SAb then only B will be able to understand it.
   Since the packets are multicast packets and they are going to be
   processed by both A and B, there is no SA for C to use so that A and
   B both can understand it.

   The problem can be solved with the following figure where all of them
   use same SA for incoming and outgoing direction.

      A                   |
     SAs     ------------>|
     SAs     <------------|
                          |
      B                   |
     SAs     ------------>|
     SAs     <------------|
                          |
      C                   |
     SAs     ------------>|
     SAs     <------------|
                      Broadcast
                       Network

   So, all the adjacent routers on a broadcast medium MUST use same SA
   and the same SA MUST be used for inbound and outbound processing.

6. SA Granularity and Selectors




M. Gupta/N. Melam      Expires - December 2002               [Page 4]


               Authentication/Confidentiality to OSPFv3      June 2002


   Different SA for different interfaces MUST be supported. In the
   outgoing path, IPv6 source address, OSPF protocol and egress
   interface ID MUST be used as selectors to locate the SA to be
   applied. In the incoming path, OSPF protocol, SPI and ingress
   interface ID MUST used to locate the SA to be applied. Any incoming
   OSPF protocol packets on the given ingress interface that fail the
   confidentiality/authentication checks MUST be dropped.

7. Virtual Links

   Different SA than the SA of underlying interface MUST be provided for
   virtual links. Packets sent out on virtual links use unicast site
   local addresses as the IPv6 source address and all the other packets
   use multicast and unicast link local addresses. This difference in
   the IPv6 source address should be used in order to differentiate the
   packets sent on interfaces and virtual links.
   Note: All the details about using IPsec for providing authentication
   for virtual links are not clear yet. This area can be explored
   further for more details.

8. Replay Protection

   As it is not possible as per the current standards to provide
   complete replay protection while using manual keying, replay
   protection will not be provided for OSPFv3
   authentication/confidentiality. It is assumed that OSPFv3 protects
   itself against reply attacks. According to the current standards
   OSPFv3 has sequence number fields in the packet headers and protects
   itself against some replay attacks.

Security Considerations

   This memo discusses the use of IPsec AH and ESP headers in order to
   provide security to OSPFv3 for IPv6.

   Use of manual keying does not provide very high level of security as
   compared to IKE but the security provided should be enough for a
   routing protocol.

References


  1. Coltun, R., Ferguson, D. and Moy, J., OSPF for IPv6¶, RFC 2740,
     December 1999

  2. Kent, S. and Atkinson, R., Security Architecture for the Internet
     Protocol¶, RFC 2401, November 1998




M. Gupta/N. Melam      Expires - December 2002               [Page 5]


               Authentication/Confidentiality to OSPFv3      June 2002



  3. Kent, S. and Atkinson, R., "IP Encapsulating Security Payload
     (ESP)¶, RFC 2406, November 1998

  4. Kent, S. and Atkinson, R., "IP Authentication Header (AH)¶, RFC
     2402, November 1998

  5. Bradner, S., "Key words for use in RFCs to Indicate Requirement
     Level", BCP 14, RFC 2119, March 1997.


Acknowledgments

   Authors would like to extend sincere thanks to Marc Solsona, Janne
   Peltonen, John Cruz and Dhaval Shah for providing useful information
   and critiques in order to write this memo.

Authors Addresses

   Mukesh Gupta
   Nokia
   313 Fairchild Drive
   Mountain View, CA 94043
   Phone: 650-625-2264
   Email: Mukesh.Gupta@nokia.com

   Nagavenkata Suresh Melam
   Nokia
   313 Fairchild Drive
   Mountain View, CA 94043
   Phone: 650-625-2949
   Email: Nagavenkata.Melam@nokia.com



















M. Gupta/N. Melam      Expires - December 2002               [Page 6]