[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06

Network Working Group                                    M. Jethanandani
Internet-Draft                                               Independent
Intended status: Standards Track                                 B. Weis
Expires: September 9, 2012                                      K. Patel
                                                           Cisco Systems
                                                                D. Zhang
                                                                  Huawei
                                                              S. Hartman
                                                       Painless Security
                                                          March 08, 2012


              Key Management for Pairwise Routing Protocol
                       draft-mahesh-karp-rkmp-01

Abstract

   When running routing protocols such as BGP or RSVP-TE, two routers
   need to exchange routing messages in a unicast (one-to-one) fashion.
   In order to authenticate these messages using symmetric cryptography,
   a secret key needs to be established.  This document defines a Router
   Key Management Protocol for establishing and managing such keys for
   routing protocols.

Requirements Language

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

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on September 9, 2012.

Copyright Notice



Jethanandani, et al.    Expires September 9, 2012               [Page 1]


Internet-Draft                    RKMP                        March 2012


   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  3
     1.2.  Acronyms and Abbreviations . . . . . . . . . . . . . . . .  3
   2.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
     2.1.  Types of Keys  . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Protocol Exchanges . . . . . . . . . . . . . . . . . . . . . .  5
     3.1.  IKE_SA_INIT  . . . . . . . . . . . . . . . . . . . . . . .  6
     3.2.  IKE_AUTH . . . . . . . . . . . . . . . . . . . . . . . . .  6
     3.3.  CREATE_CHILD_SA  . . . . . . . . . . . . . . . . . . . . .  7
     3.4.  INFORMATIONAL  . . . . . . . . . . . . . . . . . . . . . .  7
   4.  Header and Payload Formats . . . . . . . . . . . . . . . . . .  8
     4.1.  Security Association Payload . . . . . . . . . . . . . . .  8
       4.1.1.  Transforms Substructures . . . . . . . . . . . . . . .  9
         4.1.1.1.  TCP-AO . . . . . . . . . . . . . . . . . . . . . .  9
         4.1.1.2.  LDP Discovery Key  . . . . . . . . . . . . . . . . 11
     4.2.  Traffic Selector Payload . . . . . . . . . . . . . . . . . 11
   5.  Operation Details  . . . . . . . . . . . . . . . . . . . . . . 12
     5.1.  General  . . . . . . . . . . . . . . . . . . . . . . . . . 12
     5.2.  Initial Key Specific Data Exchange . . . . . . . . . . . . 13
     5.3.  Key Selection, Rollover and Protocol Interaction . . . . . 13
   6.  Key Management Database (KMDB) . . . . . . . . . . . . . . . . 13
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 14
     10.2. Informative References . . . . . . . . . . . . . . . . . . 14
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15







Jethanandani, et al.    Expires September 9, 2012               [Page 2]


Internet-Draft                    RKMP                        March 2012


1.  Introduction

   Existing routing protocols using unicast communication model (e.g.,
   BGP, LDP, RSVP-TE) have cryptographic authentication mechanisms that
   use a key shared between the routers on the both sides of the model
   to protect routing message exchanges between the routers.  Unicast
   key management today is limited to statically configuring master keys
   in individual routers.  This document defines a Router Key Management
   Protocol (RKMP) that largely makes use of currently defined IKEv2
   [RFC5996] protocol and extends it to allow network devices to
   automatically exchange key material related information between the
   network devices.

   RKMP assumes that routers need to be provisioned with some
   credentials for a one-to-one authentication protocol.  Pre-shared
   keys or asymmetric keys and an authorization list are expected to be
   common deployments.

   If two routers running a routing protocol have not authenticated each
   other yet, and before sending out any routing protocol packets the
   two routers need to perform mutual authentication using their
   provisioned credentials.  If successful, two routers negotiate the
   key material to secure the routing protocol execution.

1.1.  Terminology

   Here are some terms that we will be using throughout the document.

   SKEYSEED: When a TCP-AO transform is chosen, keying material for the
   TCP-AO master key is generated as follows, where Ni and Nr are unique
   to this exchange.  The value SK_d is defined in Section 1.2 of IKEv2
   [RFC5996], and refers to the value derived from SKEYSEED (defined in
   Section 2.14 of IKEv2 [RFC5996]).  SK_d is used to derive new keys
   (e.g., for TCP-AO) as follows:

   <TCP-AO master key> = prf+(SK_d, Ni | Nr)

1.2.  Acronyms and Abbreviations

   The following acronyms and abbreviations are used throughout this
   document.

   IKE   Internet Key Exchange Protocol

   IKEv2 Internet Key Exchange Protocol Version 2






Jethanandani, et al.    Expires September 9, 2012               [Page 3]


Internet-Draft                    RKMP                        March 2012


   RP    Routing Protocol

   SA    Security Association


2.  Overview




                      -----------------------
           =======> |   Not Authenticated   |==========
          ||        |   No RP Keys          |          ||
          ||         -----------------------       IKE_SA_INIT
          ||                                           ||
          ||                                           ||
          ||                                           ||
     INFORMATIONAL                                     VV
          ||                                 --------------------------
          ||                                 | Privacy Keys Exchanged |
          ||                                 | No RP Keys             |
          ||                                 --------------------------
          ||                                           ||
          ||         |--------------------          IKE_AUTH
            =========| Authenticated     | <============
                     | RP Keys Derived   | ====
                      --------------------   ||
                              ^^             ||
                              ||        CREATE_CHILD_SA
                              ||             ||
                               ===============

                          Figure 1: State Diagram

2.1.  Types of Keys

   The keys adopted in RKMP are listed as follows:

   o  PSK (Pre-Shared Key) : PSKs are pair-wise unique keys used for
      authenticating one router to the other one during the initial
      exchange.  These keys are configured by some mechanism such as
      manual configuration or a management application outside of the
      scope of RKMP.

   o  Seed key: Refers to value derived from SKEYSEED that is used to
      derive new keys (e.g., for TCP-AO).





Jethanandani, et al.    Expires September 9, 2012               [Page 4]


Internet-Draft                    RKMP                        March 2012


   o  Protocol master key: A protocol master key is the key exported by
      RKMP for use by a routing protocol such as BGP.  This is the key
      that is shared in the key table between the routing protocol and
      RKMP.

   o  Transport key: A transport key is the key used to integrity
      protect routing messages in a protocol such as BGP.  In today's
      routing protocol cryptographic authentication mechanisms the
      transport key can be the same as the protocol master key.


3.  Protocol Exchanges

   The exchange of private keying material between two network devices
   using a dedicated key management protocol is a requirement as
   articulated in [I-D.ietf-karp-routing-tcp-analysis].  There is no
   need to define an entirely new protocol for this purpose, when
   existing mature protocol exchanges and methods have been vetted.
   This draft makes use of the IKEv2 protocol exchanges, state machine,
   and policy definitions to define a dedicated key management protocol.

   In the following figures, the notations contained in the message are
   defined as follows.

                +----------+------------------------------+
                | Notation | Payload                      |
                +----------+------------------------------+
                | AUTH     | Authentication               |
                | CERT     | Certificate                  |
                | CERTREQ  | Certificate Request          |
                | D        | Delete                       |
                | HDR      | IKEv2 Header (not a payload) |
                | IDi      | Identification - Initiator   |
                | IDr      | Identification - Responder   |
                | KE       | Key Exchange                 |
                | Ni, Nr   | Nonce                        |
                | N        | Notify                       |
                | SA       | Security Association         |
                | SK       | Encrypted and Authenticated  |
                | TSi      | Traffic Selector - Initiator |
                | TSr      | Traffic Selector - Responder |
                +----------+------------------------------+

                    Acronyms Used in Protocol Exchange







Jethanandani, et al.    Expires September 9, 2012               [Page 5]


Internet-Draft                    RKMP                        March 2012


3.1.  IKE_SA_INIT

   The IKE_SA_INIT exchange defined in Internet Key Exchange Protocol
   Version 2 [RFC5996] is used in RKMP.  The IKE_SA_INIT exchange is a
   two-message exchange that allows the network devices to negotiate
   cryptographic algorithms, exchange nonces, and do a Diffe-Hellman
   (DH) [DH] exchange, for their routing protocols, after which
   protocols on these network devices can communicate privately.  Note
   that at this point the network devices have not identified their
   peer.  For the details of this exchange, refer to IKE_SA_INIT in
   Internet Key Exchange Protocol Version 2 [RFC5996].

      Peer (Initiator)                   Peer (Responder)
      --------------------               ------------------
      HDR, SAi1, KEi, Ni        -->
                                <--      HDR, SAr1, KEr, Nr, [CERTREQ,]

                                IKE_SA_INIT

3.2.  IKE_AUTH

   Next, the network devices perform an IKE_AUTH exchange defined in RFC
   5996.  However, the SA payloads contain the routing protocol specific
   security policies rather than IPsec policies (SAi2, SAr2 defined in
   RFC 5996), and the TS payloads contains routing protocol specific
   traffic selectors.  Policy definitions for routing protocols is
   described in Section 3; for the details of the rest of the exchange
   please refer to IKE_AUTH in RFC 5996.

    Peer (Initiator)                         Peer (Responder)
    --------------------                     ------------------
    HDR, SK {IDi, [CERT,] [CERTREQ,]
    [IDr,] AUTH, SAi2, TSi, TSr}     -->
                                     <--     HDR, SK {IDr, [CERT,] AUTH,
                                             SAr2, TSi, TSr}


                                 IKE_AUTH

   In the IKE_AUTH exchange, the Initiator proposes one or more sets of
   policies for one routing protocol in the SAi2.  The Responder returns
   the one policy contained in SAr2 that it accepts.  Based on this
   policy, appropriate keying material is derived from the existing
   shared keying material.  At the successful conclusion of the IKE_AUTH
   exchange, the initiator and responder have agreed upon a single set
   of policy and keying material for a particular routing protocol.





Jethanandani, et al.    Expires September 9, 2012               [Page 6]


Internet-Draft                    RKMP                        March 2012


3.3.  CREATE_CHILD_SA

   The network devices may then destroy the state associated with the
   IKEv2 SA, continuing to use the RP policy and keying material, or
   they may choose to retain them for the further use.  Note that this
   policy differs from IKEv2/IPsec, where the deletion of the IKEv2 SA
   necessitates the deletion of the IPsec SAs.  If both the network
   devices choose to retain them, they may use the IKEv2 SA to
   subsequently agree upon replacement policy for the same RP, or agree
   upon policy and keying material for another routing protocol.  Either
   case will require the use of the IKEv2 CREATE_CHILD_SA exchange as
   defined in RFC 5996.

   A CREATE_CHILD_SA exchange therefore can be triggered in order to

   1.  Rekey an antique RP master key and establish a new equivalent one

   2.  Generate needed key material for a newly executed routing
       protocol based on an existing SA

   3.  Rekey an IKEv2 SA and establish a new equivalent IKEv2 SA.

        Peer (Initiator)                      Peer (Responder)
        --------------------                  ------------------
        HDR, SK {[N], SA, Ni, [KEi],
        [TSi, TSr]}                   -->
                                      <--    HDR, SK {SA, Nr, [KEr],
                                             [TSi, TSr]}

                              CREATE_CHILD_SA

   A CREATE_CHILD_SA exchange MAY be initiated by either end of the SA
   after the initial exchanges are completed.  All messages in a
   CREATE_CHILD_SA exchange are cryptographically protected using the
   cryptographic algorithms and keys negotiated in the initial exchange.

   For details on the exchange, refer to the CREATE_CHILD_SA exchange as
   defined in RFC 5996.

3.4.  INFORMATIONAL

   The IKEv2 INFORMATIONAL exchange is also useful for deleting specific
   IKEv2 SAs or sending status information.  The Notify (N) and Delete
   (D) payloads are as those defined by IKEv2 [IKEV2-PARAMS].  For
   example, if the Responder refused to accept one of Proposals sent by
   the Initiator, it would return an INFORMATIONAL exchange of type
   NO_PROPOSAL_CHOSEN instead of the response to CREATE_CHILD_SA.




Jethanandani, et al.    Expires September 9, 2012               [Page 7]


Internet-Draft                    RKMP                        March 2012


        Peer (Initiator)                   Peer (Responder)
        -------------------                ------------------
        HDR, SK {[N,] [D,] ... }    -->
                                    <--    HDR, SK {[N,] [D,] ... }

                               INFORMATIONAL


4.  Header and Payload Formats

   The protocol defined in this memo uses IKEv2 payload definitions.
   However, new security policy definitions are described to support
   security transforms and policy defined by routing protocol documents.

4.1.  Security Association Payload

   The Security Association (SA) payload contains a list of Proposals,
   which describe one or more sets of policy that a router is willing to
   use to protect a routing protocol.  In the Initiator's message, the
   SAi2 payload contains a list of Proposal payloads (as defined in the
   next section), each of which contains a single set of policy that can
   b applied to the packets described in the Traffic Selector (TS)
   payloads in the same exchange.  Each set of policy is given a
   particular "Proposal Number" uniquely identifying this set of policy.

   The responder includes a single Proposal payload in it's SA policy,
   which denotes the choice it has made amongst the initiator's list of
   Proposals.  Any attributes of a selected transform MUST be returned
   unmodified as explained in IKEv2 [RFC5996] section 3.3.6.  The
   initiator of an exchange MUST check that the accepted offer is
   consistent with one of its proposals, and if not MUST terminate the
   exchange.

   This memo defines new Proposal substructure definitions, which allow
   protocol participants to exchange proposals for routing protocol
   policy.  Figure 2 defines new Protocol IDs that can be negotiated
   within an IKEv2 SA payload.

              Protocol                Protocol ID   Reference
              ----------------------------------------------
              TCP-AO                  TBD-1        RFC 5925
              LDP Discovery Key       TBD-2

                          Figure 2: Protocol IDs

   The following section describes the SA Payload Transforms
   Substructures that are to be used with these Protocol IDs.




Jethanandani, et al.    Expires September 9, 2012               [Page 8]


Internet-Draft                    RKMP                        March 2012


4.1.1.  Transforms Substructures

   Each Proposal has a list of Transform (T) substructures, each of
   which describe a particular set of cryptographic policy choices.
   This is useful for an initiator to propose multiple cryptographic
   choices for the same policy described in its associated Proposal
   payload.

4.1.1.1.  TCP-AO

   The TCP-AO [RFC5925] transform payload is specified to negotiate the
   TCP-AO policies and contains the following fields.

                          1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | 0 (last) or 3 |   RESERVED    |        Transform Length       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    SendID     |Auth Alg       |     KDF       |     Flags     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        Figure 3: TCP-AO Transforms

   o 0 (last) or 3 (more) (1 octet) - Specifies whether this is the last
   Transform Substructure in the Proposal.

   o RESERVED (1 octet) - MUST be sent as zero; MUST be ignored on
   receipt.

   o Transform Length (2 octets) - The length (in octets) of the
   Transform Substructure including Header and Attributes.

   o SendID (1 octet) - The TCP-AO KeyID that the sender will use to
   represent this Transform.  The KeyID will be used to generate the
   keys independently on each network device at the end of the exchange.

   o Auth Alg (1 octet) - The Authentication algorithm defined as a part
   of this Transform.  Initial values are defined in Cryptographic
   Algorithms for the TCP Authentication Option [RFC5926].
   Parenthetical names in Figure 4 refer to the values assigned in the
   Cryptographic Algorithms for TCP-AO Registration [TCP-AO-REG].










Jethanandani, et al.    Expires September 9, 2012               [Page 9]


Internet-Draft                    RKMP                        March 2012


                      Auth Alg                   ID
                      ------------------------------
                      Reserved                   0
                      HMAC-SHA-1-96 (SHA1)       1
                      AES-128-CMAC-96 (AES128)   2
                      Standards Action          3-140
                      Private Use             241-255

                 Figure 4: TCP-AO Authentication Algorithm

   o KDF (1 octet) - The KDF defined as a part of this Transform.
   Values are defined in Cryptographic Algorithms for the TCP
   Authentication Option [RFC5926].

                      KDF                        ID
                      ------------------------------
                      Reserved                   0
                      KDF_HMAC_SHA1              1
                      KDF_AES_128_CMAC           2
                      Standards Action          3-240
                      Private Use             241-255

                 Figure 5: TCP-AO Key Derivation Functions

   o Flags (1 octet) - Indicates specific options for TCP-AO.  The bits
   are as follows:

                             +-+-+-+-+-+-+-+-+
                             |O|X|X|X|X|X|X|X|
                             +-+-+-+-+-+-+-+-+

   In the description below, a bit being 'set' means its value is '1',
   while 'cleared' means its value is '0'.  'X' bits MUST be cleared
   when sending and MUST be ignored on receipt.

   o  O (Options) - This bit indicates whether or not TCP Options are to
      be included in the bytes protected by the authentication
      calculation.  This bit is set to indicate that TCP Options are to
      be ignored and cleared to indicate that TCP Options are protected.

   When a TCP-AO transform is chosen, keying material for the TCP-AO
   master key is generated as follows, where Ni and Nr are unique to
   this exchange.  The value SK_D is defined in RFC 5996, and refers to
   the value derived from SKEYSEED that is used to derive new keys
   (e.g., for TCP-AO).

                 <TCP-AO master key> = prf+(SK_d, Ni | Nr)




Jethanandani, et al.    Expires September 9, 2012              [Page 10]


Internet-Draft                    RKMP                        March 2012


4.1.1.2.  LDP Discovery Key

   TBD

4.2.  Traffic Selector Payload

   The Traffic Selector (TS) payload allows an RP peer to identify
   packet flows that are to be protected with the policy in the SA
   payload.  Unlike IPsec, routing protocols have well-defined flows,
   and there is no need to specify them to the specificity of IPsec
   policy.  The document defines a new TS type for routing protocols as
   shown in Figure 6.  The TS payload defined in this document includes
   only the routing protocol identifier that is to be protected.

                          1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   TS Type     | Rtg. Prot. ID |       Selector Length         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Figure 6

   o TS Type (1 octet) - TBD-3 for all routing protocols

   o Rtg. Prot.  ID (1 octet) - Specifies the routing protocol
   identifier for the current negotiation.

              Routing (RT) Protocol  Protocol ID    Reference
              -----------------------------------------------
              Reserved                    0
              BGP                         1         RFC 4271
              LDP                         2         RFC 5036
              MSDP                        3         RFC 3618
              PIM PORT                    4
              PCEP                        5         RFC 5440
              Unassigned                 6-240
              Private Use              240-255

                      Figure 7: Routing Protocol IDs

   Exchanges including traffic selectors (i.e., IKE_AUTH,
   CREATE_CHILD_SA) include two TS payloads, one for the initiator
   policy and one for the responder policy.  In the case of RPs the
   policy is symmetric and both payloads contain the same routing
   protocol ID value.






Jethanandani, et al.    Expires September 9, 2012              [Page 11]


Internet-Draft                    RKMP                        March 2012


5.  Operation Details

5.1.  General

   RKMP is used to dynamically derive key material information between
   the two network devices trying to establish or maintain a routing
   protocol neighbor adjacency.  Typically network devices running the
   routing protocols establish neighbor adjacencies at the routing
   protocol level.  These routing protocols may run different security
   algorithms that provide transport level security for the protocol
   neighbor adjacencies.  Depending on the security algorithm used, the
   routing protocols are configured with security algorithm specific
   keys that are either long term keys or short term session keys.
   These keys are specific to the security algorithms used to enforce
   transport level security for the routing protocols.

   A routing protocol causes RKMP to execute when it needs key material
   to establish neighbor adjacency.  This can be as a result of the
   routing protocol neighbor being configured, neighbor changed or
   updated, a local rekey policy decision, or some other event dictated
   by the implementation.  The key material would allow the network
   devices to then independently generate the same key and establish a
   RKMP neighbor adjacency between them.  This is typically done by the
   Initiator (RKMP speaker) initiating a RKMP RP_INIT exchange mentioned
   in the section 2.1 towards its RKMP peer.  As part of RP_INIT
   exchange, RKMP will send a message to the RKMP peer's IKEv2 port.
   The format of the message is explained in section 3.  The procedure
   to exchange key information is explained in section 3.  Once the key
   material information is successfully exchanged by both the RKMP
   speaker, the RKMP neighbor adjacency may be torn down or kept around
   as explained in section 3.

   The master key data received from RKMP peers are stored in the
   separate Key Management Database known as KMDB.  KMDB follows the
   guidelines inDatabase of Long Lived Symmetric Cryptographic Keys
   [I-D.ietf-karp-crypto-key-table], and each entry consists of Key
   specific information, Security algorithm to which the Key is
   applicable to, Routing Protocol Clients of interest, and the
   announcing RKMP Peer.  KMDB is also used to notify the routing
   protocols about the key updates.  Typically key material information
   is exchanged whenever a routing protocol is about to create a new
   neighbor adjacency.  This is considered as an Initial Key exchange
   mode.  Key material information is also exchanged to refresh existing
   key data on an already existing neighbor adjacency.  This is
   considered as Key rollover exchange mode.  The following sections
   describes their detail behavior.





Jethanandani, et al.    Expires September 9, 2012              [Page 12]


Internet-Draft                    RKMP                        March 2012


5.2.  Initial Key Specific Data Exchange

   Routing protocols informs RKMP of its new neighbor adjacency.  It
   does so by creating a local entry in KMDB which consists of a
   Security algorithm, Key specific information, routing protocol client
   and the routing protocol neighbor.  Upon a successful creation of
   such an entry RKMP initiates RKMP peering with the neighbor and
   starts initial RKMP RP_INIT exchange explained in section 2.1
   followed by the RP_AUTH exchanged explained in section 2.2.  Once the
   key related information is successfully exchanged, KMDB may invoke
   the routing protocol client to provide key specific information
   updates if any.

5.3.  Key Selection, Rollover and Protocol Interaction

   The procedure for key selection and rollover exchange has been
   described in Section 3 of Database of Long-Lived Symmetric
   Cryptographic Keys [I-D.ietf-karp-crypto-key-table].  Details of how
   RP interact with KMDB and deals with multiple keys during rollover
   are also described in that section.


6.  Key Management Database (KMDB)

   Protocol interaction between RKMP and its client routing protocols is
   typically done using KMDB.  Routing protocols update KMDB by
   installing a new Key related information or purging an existing Key
   specific information.  As part of the KMDB update, RKMP initiates
   peering connections with its appropriate RKMP peers to announce the
   updated key related information.  RKMP may also receive an updated
   key related information from its peers which gets installed in KMDB.
   Whenever RKMP updates KMDB with updated key information from its
   peers, it notifies client routing protocols of its updates.


7.  IANA Considerations

   New Protocol-IDs (as described in Figure 2) are to be allocated in
   the IKEv2 Security Protocol Identifiers registry.

   A new Traffic Selector Type (as described in Figure 7) is to be
   allocated in the IKEv2 Traffic Selector Types registry.

   Several new registries are to be defined as part of a new RKMP
   Protocol Registry.  These are described in Figure 4, Figure 5, and
   Figure 7.





Jethanandani, et al.    Expires September 9, 2012              [Page 13]


Internet-Draft                    RKMP                        March 2012


8.  Security Considerations

   TBD


9.  Acknowledgements

   During the development of TCP-AO, Gregory Lebovitz noted that a
   protocol based on an IKEv2 exchange would be a good automated key
   management method for deriving a TCP-AO master key.


10.  References

10.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.

   [RFC5925]  Touch, J., Mankin, A., and R. Bonica, "The TCP
              Authentication Option", RFC 5925, June 2010.

   [RFC5926]  Lebovitz, G. and E. Rescorla, "Cryptographic Algorithms
              for the TCP Authentication Option (TCP-AO)", RFC 5926,
              June 2010.

   [RFC5996]  Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
              "Internet Key Exchange Protocol Version 2 (IKEv2)",
              RFC 5996, September 2010.

10.2.  Informative References

   [DH]       Diffie, W. and M. Hellman, "New Directions in
              Cryptography", IEEE Transactions on Information
              Theory, V.IT-22 n. 6, June 1977.

   [I-D.ietf-karp-crypto-key-table]
              Housley, R. and T. Polk, "Database of Long-Lived Symmetric
              Cryptographic Keys", draft-ietf-karp-crypto-key-table-02
              (work in progress), October 2011.

   [I-D.ietf-karp-routing-tcp-analysis]
              Jethanandani, M., Patel, K., and L. Zheng, "Analysis of
              BGP, LDP, PCEP, and MSDP Security According to KARP Design



Jethanandani, et al.    Expires September 9, 2012              [Page 14]


Internet-Draft                    RKMP                        March 2012


              Guide", draft-ietf-karp-routing-tcp-analysis-00 (work in
              progress), June 2011.

   [IKEV2-PARAMS]
              "Internet Key Exchange Version 2 (IKEv2) Parameters", <htt
              p://www.iana.org/assignments/ikev2-parameters/
              ikev2-parameters.xml>.

   [TCP-AO-REG]
              "Internet Key Exchange Version 2 (IKEv2) Parameters", <htt
              p://www.iana.org/assignments/tcp-parameters/
              tcp-parameters.xml>.


Authors' Addresses

   Mahesh Jethanandani
   Independent


   Phone:
   Fax:
   Email: mjethanandani@gmail.com
   URI:


   Brian Weis
   Cisco Systems
   170 W. Tasman Drive
   San Jose, California  95134
   USA

   Phone: +1 (408) 526-4796
   Fax:
   Email: bew@cisco.com
   URI:















Jethanandani, et al.    Expires September 9, 2012              [Page 15]


Internet-Draft                    RKMP                        March 2012


   Keyur Patel
   Cisco Systems
   170 Tasman Drive
   San Jose, California  95134
   USA

   Phone: +1 (408) 526-7183
   Fax:
   Email: keyupate@cisco.com
   URI:


   Dacheng Zhang
   Huawei
   Beijing,
   China

   Phone:
   Fax:
   Email: zhangdacheng@huawei.com
   URI:


   Sam Hartman
   Painless Security


   Phone:
   Fax:
   Email: hartmans@painless-security.com
   URI:




















Jethanandani, et al.    Expires September 9, 2012              [Page 16]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/