[Docs] [txt|pdf|xml|html] [Tracker] [WG] [Email] [Nits]

Versions: 00

KARP                                                           W. Atwood
Internet-Draft                                  Concordia University/CSE
Intended status: Informational                               G. Lebovitz
Expires: August 31, 2010                                         Juniper
                                                       February 27, 2010


 Framework for Cryptographic Authentication of Routing Protocol Packets
                              on the Wire
                      draft-ietf-karp-framework-00

Abstract

   In the March of 2006 the IAB held a workshop on the topic of
   "Unwanted Internet Traffic".  The report from that workshop is
   documented in RFC 4948 [RFC4948].  Section 8.2 of RFC 4948 calls for
   "[t]ightening the security of the core routing infrastructure."  Four
   main steps were identified for improving the security of the routing
   infrastructure.  One of those steps was "securing the routing
   protocols' packets on the wire."  One mechanism for securing routing
   protocol packets on the wire is the use of per-packet cryptographic
   message authentication, providing both peer authentication and
   message integrity.  Many different routing protocols exist and they
   employ a range of different transport subsystems.  Therefore there
   must necessarily be various methods defined for applying
   cryptographic authentication to these varying protocols.  Many
   routing protocols already have some method for accomplishing
   cryptographic message authentication.  However, in many cases the
   existing methods are dated, vulnerable to attack, and/or employ
   cryptographic algorithms that have been deprecated.  This document is
   one of a series concerned with defining a roadmap of protocol
   specification work for the use of modern cryptogrpahic mechanisms and
   algorithms for message authentication in routing protocols.  In
   particular, it defines the framework for a key management protocol
   that may be used to create and manage session keys for message
   authentication and integrity.  The overall roadmap reflects the input
   of both the security area and routing area in order to form a jointly
   agreed upon and prioritized work list for the effort.

Status of this Memo

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

   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.



Atwood & Lebovitz        Expires August 31, 2010                [Page 1]


Internet-Draft               KARP Framework                February 2010


   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.

   This Internet-Draft will expire on August 31, 2010.

Copyright Notice

   Copyright (c) 2010 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 BSD License.
























Atwood & Lebovitz        Expires August 31, 2010                [Page 2]


Internet-Draft               KARP Framework                February 2010


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
     1.2.  Requirements Language  . . . . . . . . . . . . . . . . . .  6
     1.3.  Scope  . . . . . . . . . . . . . . . . . . . . . . . . . .  6
     1.4.  Goals  . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     1.5.  Non-Goals  . . . . . . . . . . . . . . . . . . . . . . . . 11
     1.6.  Audience . . . . . . . . . . . . . . . . . . . . . . . . . 11
   2.  Common Framework . . . . . . . . . . . . . . . . . . . . . . . 12
     2.1.  Framework Elements . . . . . . . . . . . . . . . . . . . . 15
   3.  Framework Components . . . . . . . . . . . . . . . . . . . . . 19
     3.1.  Key Management Protocol  . . . . . . . . . . . . . . . . . 19
     3.2.  KeyStore . . . . . . . . . . . . . . . . . . . . . . . . . 20
     3.3.  Routing Protocol Mechanisms  . . . . . . . . . . . . . . . 20
   4.  Framework APIs . . . . . . . . . . . . . . . . . . . . . . . . 21
     4.1.  KMP-to_Keystore API  . . . . . . . . . . . . . . . . . . . 21
     4.2.  KMP-to-Routing Protocol API  . . . . . . . . . . . . . . . 21
     4.3.  Keystore-to-Routing Protocl API  . . . . . . . . . . . . . 21
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 21
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 21
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
   8.  Change History (RFC Editor: Delete Before Publishing)  . . . . 22
   9.  Needs Work in Next Draft (RFC Editor: Delete Before
       Publishing)  . . . . . . . . . . . . . . . . . . . . . . . . . 22
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 23
     10.2. Informative References . . . . . . . . . . . . . . . . . . 23
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25






















Atwood & Lebovitz        Expires August 31, 2010                [Page 3]


Internet-Draft               KARP Framework                February 2010


1.  Introduction

   In March 2006 the Internet Architecture Board (IAB) held a workshop
   on the topic of "Unwanted Internet Traffic".  The report from that
   workshop is documented in RFC 4948 [RFC4948].  Section 8.1 of that
   document states that "A simple risk analysis would suggest that an
   ideal attack target of minimal cost but maximal disruption is the
   core routing infrastructure."  Section 8.2 calls for "[t]ightening
   the security of the core routing infrastructure."  Four main steps
   were identified for that tightening:

   o  More secure mechanisms and practices for operating routers.  This
      work is being addressed in the OPSEC Working Group.
   o  Cleaning up the Internet Routing Registry repository [IRR], and
      securing both the database and the access, so that it can be used
      for routing verifications.  This work should be addressed through
      liaisons with those running the IRR's globally.
   o  Specifications for cryptographic validation of routing message
      content.  This work will likely be addressed in the SIDR Working
      Group.
   o  Securing the routing protocols' packets on the wire

   This document addresses the last bullet, securing the packets on the
   wire of the routing protocol exchanges.  The document addresses
   Keying and Authentication for Routing Protocols, aka "KARP".

1.1.  Terminology

   Within the scope of this document, the following words, when
   beginning with a capital letter, or spelled in all capitals, hold the
   meanings described to the right of each term.  If the same word is
   used uncapitalized, then it is intended to have its common english
   definition.

   PSK            Pre-Shared Key. A key used by both peers in a secure
                  configuration.  Usually exchanged out-of-band prior to
                  a first connection.

   Routing Protocol  When used with capital "R" and "P" in this document
                  the term refers the Routing Protocol for which work is
                  being done to provide or enhance its peer
                  authentication mechanisms.

   PRF            Pseudorandom number function, or sometimes called
                  pseudorandom number generator (PRNG).  An algorithm
                  for generating a sequence of numbers that approximates
                  the properties of random numbers.  The sequence is not
                  truly random, in that it is completely determined by a



Atwood & Lebovitz        Expires August 31, 2010                [Page 4]


Internet-Draft               KARP Framework                February 2010


                  relatively small set of initial values that are passed
                  into the function.  An example is SHA-256.

   KDF            Key derivation function.  A particular specified use
                  of a PRF that takes a PSK, combines it with other
                  inputs to the PRF, and produces a result that is
                  suitable for use as a Traffic Key.

   Identifier     The type and value used by one peer of an
                  authenticated message exchange to signify to the other
                  peer who they are.  The Identifier is used by the
                  receiver as a lookup index into a table containing
                  further information about the peer that is required to
                  continue processing the message, for example a
                  Security Association (SA) or keys.

   Identity Proof A cryptographic proof for an asserted identity, that
                  the peer really is who they assert themselves to be.
                  Proof of identity can be arranged between the peers in
                  a few ways, for example PSK, raw assymetric keys, or a
                  more user-friendly representation of assymetric keys,
                  such as a certificate.

   Security Association or SA  The parameters and keys that together
                  form the required information for processing secure
                  sessions between peers.  Examples of items that may
                  exist in an SA include: Identifier, PSK, Traffic Key,
                  cryptographic algorithms, key lifetimes.

   KMP            Key Management Protocol.  A protocol used between
                  peers to exchange SA parameters and Traffic Keys.
                  Examples of KMPs include IKE, TLS, and SSH.

   KMP Function   Any actual KMP used in the general KARP solution
                  framework

   Peer Key       Keys that are used between peers as the identity
                  proof.  These keys may or may not be connection
                  specific, depending on how they were established, and
                  what form of identity and identity proof is being used
                  in the system.

   Traffic Key    The actual key used on each packet of a message.

   Definitions of items specific to the general KARP framework are
   described in more detail in the Framework section Section 2.





Atwood & Lebovitz        Expires August 31, 2010                [Page 5]


Internet-Draft               KARP Framework                February 2010


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

   When used in lower case, these words convey their typical use in
   common language, and are not to be interpreted as described in
   RFC2119 [RFC2119].

1.3.  Scope

   Four basic tactics may be employed in order to secure any piece of
   data as it is transmitted over the wire: privacy (or encryption),
   authentication, message integrity, and non-repudiation.  The focus
   for this effort, and the scope for this framework document, will be
   message authentication and packet integrity only.  This work
   explicitly excludes, at this point in time, the other two tactics:
   privacy and non-repudiation.  Since the objective of most routing
   protocols is to broadly advertise the routing topology, routing
   messages are commonly sent in the clear; confidentiality is not
   normally required for routing protocols.  However, ensuring that
   routing peers truly are the trusted peers expected, and that no rogue
   peers or messages can compromise the stability of the routing
   environment is critical, and thus our focus.  The other two
   explicitly excluded tactics, privacy and non-repudiation, may be
   addressed in future work.

   It is possible for routing protocol packets to be transmitted
   employing all four security tactics mentioned above using existing
   standards.  For example, one could run unicast, layer 3 or above
   routing protocol packets through IPsec ESP [RFC4303].  This would
   provide the added benefit of privacy, and non-repudiation.  However,
   router platforms and systems have been fine tuned over the years for
   the specific processing necessary for routing protocols' non-
   encapsulated formats.  Operators are, therefore, quite reluctant to
   explore new packet encapsulations for these tried and true protocols.

   In addition, at least in the case of BGP and LDP, these protocols
   already have existing mechanisms for cryptographically authenticating
   and integrity checking the packets on the wire.  Products with these
   mechanisms have already been produced, code has already been written
   and both have been optimized for the existing mechanisms.  Rather
   than turn away from these mechanisms, we want to enhance them,
   updating them to modern and secure levels.

   There are two main work phases for the roadmap, and for any Routing
   Protocol work undertaken as part of the roadmap.  The first is to



Atwood & Lebovitz        Expires August 31, 2010                [Page 6]


Internet-Draft               KARP Framework                February 2010


   enhance the Routing Protocol's current authentication mechanism,
   ensuring it employs modern cryptographic algorithms and methods for
   its basic operational model, fulfilling the requirements defined in
   the Requirements section of the Design Guidelines document [**need
   reference**], and protecting against as many of the threats as
   possible as defined in the Threats section of the same dcoument.
   Many of the Routing Protocols' current mechanisms use manual keys, so
   the first phase updates will focus on shoring up the manual key
   mechanisms that exist.

   The second work phase is to define the use of a key management
   protocol (KMP) for creating and managing session keys used in the
   Routing Protocols' message authentication and data integrity
   functions.  It is intended that a general KMP framework -- or a small
   number of frameworks -- can be defined and leveraged for many Routing
   Protocols.

   Therefore, the scope of this roadmap of work includes:

   o  Making use of existing routing protocol security protocols, where
      they exist, and enhancing or updating them as necessary for modern
      cryptographic best practices,

   o  Developing a framework for using automatic key management in order
      to ease deployment, lower cost of operation, and allow for rapid
      responses to security breaches, and

   o  Specifying the automated key management protocol that may be
      combined with the bits-on-the-wire mechanisms.

   The work also serves as an agreement between the Routing Area and the
   Security Area about the priorities and work plan for incrementally
   delivering the above work.  This point is important.  There will be
   times when the best-security-possible will give way to vastly-
   improved-over-current-security-but-admittedly-not-yet-best-security-
   possible, in order that incremental progress toward a more secure
   Internet may be achieved.  As such, this document will call out
   places where agreement has been reached on such trade offs.

   This document does not contain protocol specifications.  Instead, it
   defines the areas where protocol specification work is needed and
   sets a direction, a set of requirements, and a relative priority for
   addressing that specification work.

   There are a set of threats to routing protocols that are considered
   in-scope for this document/roadmap, and a set considered out-of-
   scope.  These are described in detail in the Threats section of
   [**somewhere**].



Atwood & Lebovitz        Expires August 31, 2010                [Page 7]


Internet-Draft               KARP Framework                February 2010


   NOTE: Cross-references now indicated by [** some text *]] were valid
   in the original draft by Greg.  They will be properly indicated in
   the next version, once all three companion documents are published
   and available in the repository.

1.4.  Goals

   The goals and general guidance for this work roadmap follow:

   1. Provide authentication and integrity protection for packets on the
      wire of existing routing protocols

   2. Deliver a path to incrementally improve security of the routing
      infrastructure.  The principle of crawl, walk, run will be in
      place.  Routing protocol authentication mechanisms may not go
      immediately from their current state to a state containing the
      best possible, most modern security practices.  Incremental steps
      will need to be taken for a few very practical reasons.  First,
      there are a considerable number of deployed routing devices in
      operating networks that will not be able to run the most modern
      cryptographic mechanisms without significant and unacceptable
      performance penalties.  The roadmap for any one routing protocol
      MUST allow for incremental improvements on existing operational
      devices.  Second, current routing protocol performance on deployed
      devices has been achieved over the last 20 years through extensive
      tuning of software and hardware elements, and is a constant focus
      for improvement by vendors and operators alike.  The introduction
      of new security mechanisms affects this performance balance.  The
      performance impact of any incremental step of security improvement
      will need to be weighed by the community, and introduced in such a
      way that allows the vendor and operator community a path to
      adoption that upholds reasonable performance metrics.  Therefore,
      certain specification elements may be introduced carrying the
      "SHOULD" guidance, with the intention that the same mechanism will
      carry a "MUST" in the next release of the specification.  This
      gives the vendors and implementors the guidance they need to tune
      their software and hardware appropriately over time.  Last, some
      security mechanisms require the build out of other operational
      support systems, and this will take time.  An example where these
      three reasons are at play in an incremental improvement roadmap is
      seen in the improvement of BGP's [RFC4271] security via the update
      of the TCP Authentication Option (TCP-AO)
      [I-D.ietf-tcpm-tcp-auth-opt] effort.  It would be ideal, and
      reflect best common security practice, to have a fully specified
      key management protocol for negotiating TCP-AO's authentication
      material, using certificates for peer authentication in the
      keying.  However, in the spirit of incremental deployment, we will
      first address issues such as cryptographic algorithm agility,



Atwood & Lebovitz        Expires August 31, 2010                [Page 8]


Internet-Draft               KARP Framework                February 2010


      replay attacks, TCP session resetting in the base TCP-AO protocol
      before we layer key management on top of it.

   3. The deploy-ability of the improved security solutions on currently
      running routing infrastructure equipment.  This begs the
      consideration of the current state of processing power available
      on routers in the network today.

   4. Operational deploy-ability - The acceptability of a solution will
      also be measured by how deployable the solution is by common
      operator teams using common deployment processes and
      infrastructures, i.e., we will try to make these solutions fit as
      well as possible into current operational practices or router
      deployment.  This will be heavily influenced by operator input, to
      ensure that what we specify can -- and, more importantly, will --
      be deployed once specified and implemented by vendors.  Deployment
      of incrementally more secure routing infrastructure in the
      Internet is the final measure of success.  Measurably, we would
      like to see an increase in the number of surveyed respondents who
      report deploying the updated authentication mechanisms anywhere
      across their network, as well as a sharp rise in usage for the
      total percentage of their network's routers.

      Interviews with operators show several points about routing
      security.  First, over 70% of operators have deployed transport
      connection protection via TCP-MD5 on their EBGP [ISR2008] .  Over
      55% also deploy MD5 on their IBGP connections, and 50% deploy MD5
      on some other IGP.  The survey states that "a considerable
      increase was observed over previous editions of the survey for use
      of TCP MD5 with external peers (eBGP), internal peers (iBGP) and
      MD5 extensions for IGPs."  Though the data are not captured in the
      report, the authors believe anecdotally that of those who have
      deployed MD5 somewhere in their network, only about 25-30% of the
      routers in their network are deployed with the authentication
      enabled.  None report using IPsec to protect the routing protocol,
      and this was a decline from the few that reported doing so in the
      previous year's report.
      From my personal conversations with operators, of those using MD5,
      almost all report deploying with one single manual key throughout
      the entire network.  These same operators report that the one
      single key has not been changed since it was originally installed,
      sometimes five or more years ago.  When asked why, particularly
      for the case of BGP using TCP MD5, the following reasons are often
      given:







Atwood & Lebovitz        Expires August 31, 2010                [Page 9]


Internet-Draft               KARP Framework                February 2010




      A.  Changing the keys triggers a TCP reset, and thus bounces the
          links/adjacencies, undermining Service Level Agreements
          (SLAs).
      B.  For external peers, difficulty of coordination with the other
          organization is an issue.  Once they find the correct contact
          at the other organization (not always so easy), the
          coordination function is serialized and on a per peer/AS
          basis.  The coordination is very cumbersome and tedious to
          execute in practice.
      C.  Keys must be changed at precisely the same time, or at least
          within 60 seconds (as supported by two major vendors) in order
          to limit connectivity outage duration.  This is incredibly
          difficult to do, operationally, especially between different
          organizations.
      D.  Relatively low priority compared to other operatoinal issues.
      E.  Lack of staff to implement the changes device by device.
      F.  There are three use cases for operational peering at play
          here: peers and interconnection with other operators, Internal
          BGP and other routing sessions within a single operator, and
          operator-to-customer-CPE devices.  All three have very
          different properties, and all are reported as cumbersome.  One
          operator reported that the same key is used for all customer
          premise equipment.  The same operator reported that if the
          customer mandated, a unique key could be created, although the
          last time this occurred it created such an operational
          headache that the administrators now usually tell customers
          that the option doesn't even exist, to avoid the difficulties.
          These customer-uniqe keys are never changed, unless the
          customer demands so.
      The main threat at play here is that a terminated employee from
      such an operator who had access to the one (or few) keys used for
      authentication in these environments could easily wage an attack
      -- or offer the keys to others who would wage the attack -- and
      bring down many of the adjacencies, causing destabilization to the
      routing system.

      Whatever mechanisms we specify need to be easier than the current
      methods to deploy, and should provide obvious operational
      efficiency gains along with significantly better security and
      threat protection.  This combination of value may be enough to
      drive much broader adoption.








Atwood & Lebovitz        Expires August 31, 2010               [Page 10]


Internet-Draft               KARP Framework                February 2010


   5. Address the threats enumerated above in the "Threats" section
      [**somewhere**] for each routing protocol, along a roadmap.  Not
      all threats may be able to be addressed in the first specification
      update for any one protocol.  Roadmaps will be defined so that
      both the security area and the routing area agree on how the
      threats will be addressed completely over time.

   6. Create a re-usable architecture, framework, and guidelines for
      various IETF working teams who will address these security
      improvements for various Routing Protocols.  The crux of the KARP
      work is to re-use that framework as much as possible across
      relevant Routing Protocols.  For example, designers should aim to
      re-use the key management protocol that will be defined for BGP's
      TCP-AO key establishment for as many other routing protocols as
      possible.  This is but one example.

   7. Bridge any gaps between IETF's Routing and Security Areas by
      recording agreements on work items, roadmaps, and guidance from
      the Area leads and Internet Architecture Board (IAB, www.iab.org).


1.5.  Non-Goals

   The following two goals are considered out-of-scope for this effort:

   o  Privacy of the packets on the wire, at this point in time.  Once
      this roadmap is realized, we may revisit work on privacy.

   o  Message content security.  This work is being addressed in other
      IETF efforts, such as SIDR.

1.6.  Audience

   The audience for this roadmap includes:

   o  Routing Area working group chairs and participants -   These
        people are charged with updates to the Routing Protocol
        specifications.  Any and all cryptographic authentication work
        on these specifications will occur in Routing Area working
        groups, with close partnership with the Security Area.  Co-
        advisors from Security Area may often be named for these
        partnership efforts.

   o  Security Area reviewers of routing area documents -   These people
        are delegated by the Security Area Directors to perform reviews
        on routing protocol specifications as they pass through working
        group last call or IESG review.  They will pay particular
        attention to the use of cryptographic authentication and



Atwood & Lebovitz        Expires August 31, 2010               [Page 11]


Internet-Draft               KARP Framework                February 2010


        corresponding security mechanisms for the routing protocols.
        They will ensure that incremental security improvements are
        being made, in line with this roadmap.

   o  Security Area engineers -   These people partner with routing area
        authors/designers on the security mechanisms in routing protocol
        specifications.  Some of these security area engineers will be
        assigned by the Security Area Directors, while others will be
        interested parties in the relevant working groups.

   o  Operators -   The operators are a key audience for this work, as
        the work is considered to have succeeded if the operators deploy
        the technology, presumably due to a perception of significantly
        improved security value coupled with relative similarity to
        deployment complexity and cost.  Conversely, the work will be
        considered a failure if the operators do not care to deploy it,
        either due to lack of value or perceived (or real) over-
        complexity of operations.  And as such, the GROW and OPSEC WGs
        should be kept squarely in the loop as well.




2.  Common Framework

   Each of the categories of routing protocols above will require unique
   designs for authenticating and integrity checking their protocols.
   However, a single underlying framework for delivering automatic
   keying to those solutions will be pursued.  Providing such a single
   framework will significantly reduce the complexity of each step of
   the overall roadmap.  For example, if each Routing Protocol needed to
   define its own key management protocol this would balloon the total
   number of different sockets that need to be opened and processes that
   need to be simultaneously running on an implementation.  It would
   also significantly increase the run-time complexity and memory
   requirements of such systems running multiple Routing Protocols,
   causing perhaps slower performance of such systems.  However, if we
   can land on a very small set (perhaps one or two) of automatic key
   management protocols, KMPs, that the various Routing Protocols can
   use, then we can reduce this implementation and run-time complexity.
   We can also decrease the total amount of time implementers need to
   deliver the KMPs for the Routing Protocols that will provide better
   threat protection.

   The components for the framework are listed here, and described in
   the next section:





Atwood & Lebovitz        Expires August 31, 2010               [Page 12]


Internet-Draft               KARP Framework                February 2010


   o  Common Routing Protocol security mechanisms
   o  Specific Routing Protocol security mechanisms
   o  KeyStore
   o  Peer Key
   o  Traffic Key
   o  KMP
   o  Identifiers
   o  Identity Proof
   o  Profiles
   o  RoutingProtocol-to-KMP API
   o  RoutingProtocol-to-KeyStore API
   o  KMP-to-KeyStore API

   The framework is modularized for how keys and security association
   (SA) parameters generally get passed from a KMP to a transport
   protocol.  It contains three main blocks and APIs.



































Atwood & Lebovitz        Expires August 31, 2010               [Page 13]


Internet-Draft               KARP Framework                February 2010


     +------------+   +--------------------+           +-----------+
     |            |   |                    | Check     |           |
     | Identifier +-->|                    +---------->|  Identity |
     |            |   |    KMP Function    |           |   Proof   |
     +----------- +   |                    |<----------+           |
                      |                    |  Approve  +-----------+
  +---------------+   +-------+--------+---+
  |               |          /|\      /|\
  | Manual        |           |        |
  | Configuration |           |        |
  |               |           |        |
  +-------------+-+           |        |
               /|\   KMP-to-  |        |
                |    Keystore |        |
                |    API      |        |
               \|/           \|/       |
              +-+-------------+-+      |
              |                 |      | KMP-to-
              |                 |      | RoutingProtocol
              |      KeyStore   |      | API
              |                 |      |
              +---------+-------+      |
                       /|\             |
                        |              |
          KeyStore-to-  |              |
   RoutingProtocol API  |              |
                        |             \|/
            +--------------------------+-------------+
            |           |                            |
            |           |           Common Routing   |
            |          \|/          Protocol         |
            |   +-------+-------+   Security         |
            |   |               |   Mechanisms       |
            +---|  Traffic      |----+---+---+---+---+
            |   |   Key(s)      |    |   |   |   |   |
            |   |               |    |   |   |   |   |  A, B, C, D ->
            |   +---------------+    | A | B | C | D |  Specific
            |                        |   |   |   |   |  Routing Protocol
            |                        |   |   |   |   |  Security
            |                        |   |   |   |   |  Mechanisms
            +------------------------+---+---+---+---+


               Figure 1: Automatic Key Management Framework







Atwood & Lebovitz        Expires August 31, 2010               [Page 14]


Internet-Draft               KARP Framework                February 2010


2.1.  Framework Elements

   Each element of the framework is described here:


   o  Common Routing Protocol security mechanisms -  In each case, the
           Routing Protocol will contain one or more mechanism(s) for
           using session keys in their security option.  The common
           mechanisms part will allow a routing protocol to receive
           updates from the KeyStore and to poll for updates from the
           KeyStore, including the passing of all possible required
           attributes relevant to that Routing Protocol.

   o Specific Routing Protocol security mechanisms -  These parts will
           be specific to a particular Routing Protocol.  When the
           Routing Protocol uses a transport substrate, e.g., the way
           BGP, LDP and MSDP use TCP, then this applies to the security
           mechanism the includes that substrate.
           NOTE: the point of this two-layer approach is that there will
           be one generic abstraction layer that can sit on top of any/
           all Routing Protocols.  The hope is that the Routing Protocol
           Demon development teams can write this part once, and use it
           for any routing Protocol.  There may be evolution over time
           of the abstraction layer so as to contain capabilities and
           attribute definitions as needed by routing Protocols yet-to-
           be-addressed in this architecture.  However, the new Routing
           Protocol would still leverage all that had gone into the
           abstraction layer before.

   o  KeyStore -  Each implementation will also contain a protocol
           independent mechanism for storing keys, called the KeyStore.
           The KeyStore will have multiple different logical containers,
           one container for each Session Association or Multicast
           Session Association that any given Routing Protocol will
           need.  The container will store the parameters needed for the
           SA or the MSA, for example, detalis of the authentication/
           encryption algorithms employed, the valid lifetime of the
           keys, the direction in which the key needs to be applied
           (inward/outward/both), the group SPI, a KeyID, etc.  A key
           stored here may be a Peer Key or a Traffic Key. Further
           details may be found in [I-D.polk-saag-rtg-auth-keytable] and
           [I-D.housley-saag-crypto-key-table].  Note that a specific
           Routing Protocol may utilize both communication between two
           peers and communication among groups of peers.  As an
           example, PIM-SM sends distant messages (Register and
           Register-Stop) using unicast, and "link-local" messages
           (Hello, Assert, Join/Prune) using multicast
           [I-D.ietf-pim-sm-linklocal].



Atwood & Lebovitz        Expires August 31, 2010               [Page 15]


Internet-Draft               KARP Framework                February 2010



   o  Peer Key -  A key used between peers from which a traffic key is
           derived.  An example is a Pre-Shared Key.

   o  Traffic Key -  The actual key used on each packet of a message.
           This key may be derived from the key existing in the
           KeyStore.  This will depend on whether the key in KeyStore
           was a manual PSK for the peers, or whether a connection-aware
           KMP created the key.  Further, it will be connection
           specific, so as to provide inter- and intra-connection replay
           protection.

   o  KMP -  There will be an automated key management protocol, KMP.
           This KMP will run between the peers.  The KMP serves as a
           protected channel between the peers, through which they can
           negotiate and pass important data required to exchange proof
           of key identifiers, derive session keys, determine re-keying,
           synchronize their keying state, signal various keying events,
           notify with error messages, etc.  As an analogy, in the IPsec
           protocol (RFC4301 [RFC4301], RFC4303 [RFC4303] and RFC4306
           [RFC4306]) IKEv2 is the KMP that runs between the two peers,
           while AH and ESP are two different base protocols that take
           session keys from IKEv2 and use them in their transmissions.
           In the analogy, the Routing Protocol, say BGP and LDP, are
           analogous to ESP and AH, while the KMP is analogous to IKEv2
           itself.

   o Identifiers -   A KMP is fed by identities.  The identities are
           text strings used by the peers to indicate to each other that
           each are known to the other, and authorized to establish
           connections.  Those identities must be represented in some
           standard string format, e.g. an IP address -- either v4 or
           v6, an FQDN, an RFC 822 email address, a Common Name [RFC
           PKI], etc.  Note that even though routers do not normally
           have email addresses, one could use an RFC 822 email address
           string as a formatted identifier for a router.  They would do
           so simply by putting the router's reference number or name-
           code as the "NAME" part of the address, left of the "@"
           symbol.  They would then place some locational context in the
           "DOMAIN" part of the string, to the right of the "@" symbol.
           An example would be "rtr0210@sf.ca.us.company.com".  This
           document does not suggest this string value at all.  Instead,
           the concept is used only to clarify that the type of string
           employed does not matter.  It also does not matter what
           specific text you chose to place in that string type.  It
           only matters that the type of string -- and its format --
           must be agreed upon by the two endpoints.  Further, the
           string can be used as an identifier in this context, even if



Atwood & Lebovitz        Expires August 31, 2010               [Page 16]


Internet-Draft               KARP Framework                February 2010


           the string is not actually provisioned in its source domain.
           For example, the email address "rtr0210@sf.ca.us.company.com"
           may not actually exist as an email address in that domain,
           but that string of characters may still be used as an
           identifier type(s) in the routing protocol security context.
           What is important is that the community decide on a small but
           flexible set of Identifiers they will all support, and that
           they decide on the exact format of those string.  The formats
           that will be used must be standardized and must be sensible
           for the routing infrastructure.

   o  Identity Proof -   Once the form of identity is decided, then
           there must be a cryptographic proof of that identity, that
           the peer really is who they assert themselves to be.  Proof
           of identity can be arranged between the peers in a few ways,
           for example pre-shared keys, raw assymetric keys, or a more
           user-friendly representation of assymetric keys, such as a
           certificate.  Certificates can be used in a way requiring no
           additional supporting systems -- e.g. public keys for each
           peer can be maintained locally for verification upon contact.
           Certificate management can be made more simple and scalable
           with the use of minor additional supporting systems, as is
           the case with self-signed certificates and a flat file list
           of "approved thumbprints".  Self-signed certificates will
           have somewhat lower security properties than Certificate
           Authority signed certificates [RFC Certs].  The use of these
           different identity proofs vary in ease of deployment, ease of
           ongoing management, startup effort, ongoing effort and
           management, security strength, and consequences from loss of
           secrets from one part of the system to the rest of the
           system.  For example, they differ in resistance to a security
           breach, and the effort required to remediate the whole system
           in the event of such a breach.  The point here is that there
           are options, many of which are quite simple to employ and
           deploy.

   o  Profiles -   Once the KMP, Identifiers and Proofs mechanisms are
           converged upon, they must be clearly profiled for each
           Routing Protocol, so that implementors and deployers alike
           understand the different pieces of the solution, and can have
           similar configurations and interoperability across multiple
           vendors' devices, so as to reduce management difficulty.  The
           profiles SHOULD also provide guidance on when to use which
           various combinations of options.  This will, again, simplify
           use and interoperability.






Atwood & Lebovitz        Expires August 31, 2010               [Page 17]


Internet-Draft               KARP Framework                February 2010




   [after writing this all up, I'm not sure we really need the key_store
   in the middle.  As long as we standardize fully all the calls needed
   from any Routing Protocol to any KMP, then there can be a generic
   hand-down function from the KMP to the Routing Protocol when the key
   and parameters are ready.  Let's sleep on it.]

   [will need state machines and function calls for these APIs, as one
   of the work items.  In essence, there is a need for a core team to
   develop the APIs out completely in order for the Routing Protocol
   teams to use them.  Need to get this team going asap.]


   o  KMP-to-RoutingProtocol API -   There will be an API for the
           Routing Protocol to request a session key of the KMP, and be
           notified when the keys are available for it.  The API will
           also contain a mechanism for the KMP to notify the Routing
           Protocol that there are new keys that it must now use, even
           if it didn't request those keys.  The API will also include a
           mechanism for the KMP to receive requests for session keys
           and other parameters from the routing protocol.  The KMP will
           also be aware of the various Routing Protocols and each of
           their unique parameters that need to be negotiated and
           returned.

   o  KeyStore-to-RoutingProtocol API -  There will be an API for
           Routing Protocol to retrieve (or receive; it could be a push
           or a pull) the keys from the KeyStore.  This will enable
           implementers to reuse the same API calls for all their
           Routing Protocols.  The API will necessarily include facility
           to retrieve other SA parameters required for the construction
           of the Routing Protocol's packets, such as key IDs or key
           lifetimes, etc.

   o  KMP-to-KeyStore API -  There will be an API for the KMP to place
           keys and parameters into the KeyStore after their negotiation
           and derivation with the other peer.  This will enable the
           implementers to reuse the same calls for multiple KMPs that
           may be needed to address the various categories of Routing
           Protocols as described in the section defining categories in
           the Design Guidelines document [**need reference**].

   In addition to other business, administrative, and operational terms
   they must already exchange prior to forming first adjacencies, it is
   assumed that two parties deploying message authentication on their
   routing protocol will also need to decide upon acceptable security
   parameters for the connection.  This will include the form and



Atwood & Lebovitz        Expires August 31, 2010               [Page 18]


Internet-Draft               KARP Framework                February 2010


   content of the identity each use to represent the other.  It will
   also include the type of keys to be used, e.g.  PSK, raw assymetric
   keys, certificate.  Also, it will include the acceptable
   cryptographic algorithms, or algorithm suite.  This agreement is
   necessary in order for each to properly configure the connection on
   their respective devices.  The manner in which they agree upon and
   exchange this policy information is normally via phone call or
   written exchange, and is outside the scope of the KARP effort, but
   assumed to have occured.  We take as a given that each party knows
   the identity types and values, key types and values, and acceptable
   cryptographic algorithms for both their own device and the peer that
   form the security policy for configuration on their device.

   Common Mechanisms - In as much as they exist, the framework will
   capture mechanisms that can be used commonly not only within a
   particular category of Routing Protocol and Routing Protocol to KMP,
   but also between Routing Protocol categories.  Again, the goal here
   is simplifying the implementations and runtime code and resource
   requirements.  There is also a goal here of favoring well vetted,
   reviewed, operationally proven security mechanisms over newly brewed
   mechanisms that are less well tried in the wild.


3.  Framework Components

   This section will contain additional information/commentary on the
   operation of the components.

3.1.  Key Management Protocol

   [[The following text needs a home.]]

   [[Manav]] Should there be some text on key rollover or keys expiring?
   Who takes care of these events, the KMP or the Routing Protocol?  I
   believe that it should be the former.

   [[Greg]] If there is a kmp, then the kmp can put the new SA
   parameters (including keys) into the KeyStore.  However, based on our
   experience with TCP-AO, there are several things that the base
   RoutingProtocol needs to do to handle key rollover so that no routing
   messages are dropped.  Allowing for overlapping or multiple,
   simulatneously valid KeyIDs is one requirements. polling for updates,
   or receiving updates from, KeyStore is another requirement.  For now,
   however, it would be better to capture these in the threats-
   requirements document, and then let each routing protocol category
   design team figure out the details as apporpriate for their
   protocol(s).




Atwood & Lebovitz        Expires August 31, 2010               [Page 19]


Internet-Draft               KARP Framework                February 2010


3.2.  KeyStore

   [[The following text needs a home.]]

   [[Greg]] If one continues down this thought exercise, one could
   imagine an IANA registry filled with attributes as would be required
   for any SA parameters that any KARP-following protocol would want /
   need to use, such that both the KMP-to-KeyStore API and the KeyStore-
   to-RtgProto API would reference that registry, and it would grow over
   time as new categories of RoutingProtocols find need for this or that
   attribute to make their specific SA's complete.

3.3.  Routing Protocol Mechanisms

   [[Issue to be resolved]]

   [[Manav]] I am not sure I completely understand what would get into
   Common RtgProto auth mechanisms?

   [[Manav]] Is it some infrastructure that protocols like OSPF and ISIS
   can use, or all RPs (PIM, OSPFv3, etc) using IPSec may want to use?

   [[Greg]] Probably only those protocols taking keys from IKE directly
   (assuming IKEv2 would be the KMP, whic is still up for discussion),
   and not relevant to keys created from IKE for IPsec (IKE already
   knows how to pass keys SA parameters to IPsec).

   [[Manav]] If so, then some protocols (BGP?) may want KMP to directly
   speak to them, in which case KMP-to-RoutingProtocol API should also
   have a direct connection to Specific routing protocol auth security
   mechanism.

   [[Greg]] We discussed this on the planning call for the first draft.
   We decided that there are times when, as the routing protocol kicks-
   off, it sees that the protocol config calls for authentication.  In
   this case, the routing protocol needs to tell the KMP that it needs
   keys and SA parameters.  Also, though this isn't the exchange I agree
   with, we might decide that it is the RoutingProtocol's responsibility
   to tell the KMP when active keys are approaching expiry, and ask for
   new keys.  (On this point, I favor the KMP keeping track of this, and
   negotiating new Keys for the RoutingProtocol when needed.)  But we
   aren't done with that discussion yet.  As we get into the detailed
   work on RoutingProtocol(s) categories, we may find other uses for the
   direct KMP-to-RoutingProtocol-Auth-Mechanism abstraction layer, so we
   decided to keep it.

   [[Manav]] On second thoughts, wouldnt KMP only interact with the
   KeyStore and RPs with Keystore - why would we want the RPs to speak



Atwood & Lebovitz        Expires August 31, 2010               [Page 20]


Internet-Draft               KARP Framework                February 2010


   to KMP?

   [[Greg]] See explanation directly above.

   [[Manav, later]] Would be extremely helpful if we can have a section
   with the pros and cons of having IKEv2 as the KMP as against defining
   a new KMP for RPs.

   [[Bill]] Unicast relationships may well use something such as IKEv2;
   multicast relationships will need to use a group key management
   protocol, such as GDOI some variant of GDOI.


4.  Framework APIs

   This will be new work.

4.1.  KMP-to_Keystore API

   To be written.

4.2.  KMP-to-Routing Protocol API

   To be written.

4.3.  Keystore-to-Routing Protocl API

   To be written.


5.  Security Considerations


6.  IANA Considerations

   This document has no actions for IANA.


7.  Acknowledgements

   Almost all the text for draft-00 of this document was pasted in from
   draft-lebovitz-karp-roadmap, which was written by Gregory Lebovitz.
   Bill Atwood took the role as editor for the first version of this
   framework document.







Atwood & Lebovitz        Expires August 31, 2010               [Page 21]


Internet-Draft               KARP Framework                February 2010


8.  Change History (RFC Editor: Delete Before Publishing)

   [NOTE TO RFC EDITOR: this section for use during I-D stage only.
   Please remove before publishing as RFC.]

   kmart-framework-00- (original submission, based on
   draft-lebovitz-karp-roadmap-00)

   o  removed sections of the roadmap that are not part of the
      framework.
   o  promoted subsection on "Common Framework" to section, and
      separated part of it into a subsection on "Framework Elements".
   o  added section on Framework Components and three subsections for
      specific components.  Inserted "notes" on points that need to be
      resolved.
   o  added (empty) section on Framework APIs and three (empty)
      subsections for the specific APIs.
   o  made arrows in Figure 1 bi-directional.
   o  added "Manual Configuration" in Figure 1, so that the routing
      protocol's use of keys is decoupled from the mechanism used to
      derive and place those keys.
   o  made explicit the fact that the KeyStore contains various
      parameters for Security Associations (or Multicast Security
      Associations), not just keys.
   o  broke the Routing Protocol security mechanisms into "common" and
      "specific" parts
   o  re-ordered and augmented the "list of components" and the "list of
      framework elements" so that they contained the same components
   o  marked internal references that need to become external
      references, pending creation of the external documents.
   o  general grammatical corrections.


9.  Needs Work in Next Draft (RFC Editor: Delete Before Publishing)

   [NOTE TO RFC EDITOR: this section for use during I-D stage only.
   Please remove before publishing as RFC.]

   List of stuff that still needs work
   o  text for section on Framework Components and its subsections
   o  text for section on Framework APIs and its subsections
   o  general removal of text that belongs in other companion documents
   o
   o


10.  References




Atwood & Lebovitz        Expires August 31, 2010               [Page 22]


Internet-Draft               KARP Framework                February 2010


10.1.  Normative References

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

   [RFC4593]  Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to
              Routing Protocols", RFC 4593, October 2006.

   [RFC4948]  Andersson, L., Davies, E., and L. Zhang, "Report from the
              IAB workshop on Unwanted Traffic March 9-10, 2006",
              RFC 4948, August 2007.

10.2.  Informative References

   [I-D.ao-crypto]
              Lebovitz, G., "Cryptographic Algorithms, Use and
              Implementation Requirements for TCP Authentication
              Option", March 2009, <http://tools.ietf.org/html/
              draft-lebovitz-ietf-tcpm-tcp-ao-crypto-00>.

   [I-D.housley-saag-crypto-key-table]
              Housley, R. and T. Polk, "Database of Long-Lived Symmetric
              Cryptographic Keys",
              draft-housley-saag-crypto-key-table-01 (work in progress),
              November 2009.

   [I-D.ietf-pim-sm-linklocal]
              Atwood, W., Islam, S., and M. Siami, "Authentication and
              Confidentiality in PIM-SM Link-local Messages",
              draft-ietf-pim-sm-linklocal-10 (work in progress),
              December 2009.

   [I-D.ietf-tcpm-tcp-ao-crypto]
              Lebovitz, G. and E. Rescorla, "Cryptographic Algorithms
              for TCP's Authentication Option, TCP-AO",
              draft-ietf-tcpm-tcp-ao-crypto-02 (work in progress),
              February 2010.

   [I-D.ietf-tcpm-tcp-auth-opt]
              Touch, J., Mankin, A., and R. Bonica, "The TCP
              Authentication Option", draft-ietf-tcpm-tcp-auth-opt-10
              (work in progress), January 2010.

   [I-D.polk-saag-rtg-auth-keytable]
              Polk, T. and R. Housley, "Routing Authentication Using A
              Database of Long-Lived Cryptographic Keys",
              draft-polk-saag-rtg-auth-keytable-02 (work in progress),
              December 2009.



Atwood & Lebovitz        Expires August 31, 2010               [Page 23]


Internet-Draft               KARP Framework                February 2010


   [ISR2008]  McPherson, D. and C. Labovitz, "Worldwide Infrastructure
              Security Report", October 2008,
              <http://www.arbornetworks.com/dmdocuments/ISR2008_US.pdf>.

   [RFC1195]  Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
              dual environments", RFC 1195, December 1990.

   [RFC2328]  Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.

   [RFC2453]  Malkin, G., "RIP Version 2", STD 56, RFC 2453,
              November 1998.

   [RFC3562]  Leech, M., "Key Management Considerations for the TCP MD5
              Signature Option", RFC 3562, July 2003.

   [RFC3618]  Fenner, B. and D. Meyer, "Multicast Source Discovery
              Protocol (MSDP)", RFC 3618, October 2003.

   [RFC3973]  Adams, A., Nicholas, J., and W. Siadak, "Protocol
              Independent Multicast - Dense Mode (PIM-DM): Protocol
              Specification (Revised)", RFC 3973, January 2005.

   [RFC4086]  Eastlake, D., Schiller, J., and S. Crocker, "Randomness
              Requirements for Security", BCP 106, RFC 4086, June 2005.

   [RFC4107]  Bellovin, S. and R. Housley, "Guidelines for Cryptographic
              Key Management", BCP 107, RFC 4107, June 2005.

   [RFC4271]  Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
              Protocol 4 (BGP-4)", RFC 4271, January 2006.

   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", RFC 4301, December 2005.

   [RFC4303]  Kent, S., "IP Encapsulating Security Payload (ESP)",
              RFC 4303, December 2005.

   [RFC4306]  Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
              RFC 4306, December 2005.

   [RFC4601]  Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
              "Protocol Independent Multicast - Sparse Mode (PIM-SM):
              Protocol Specification (Revised)", RFC 4601, August 2006.

   [RFC4615]  Song, J., Poovendran, R., Lee, J., and T. Iwata, "The
              Advanced Encryption Standard-Cipher-based Message
              Authentication Code-Pseudo-Random Function-128 (AES-CMAC-
              PRF-128) Algorithm for the Internet Key Exchange Protocol



Atwood & Lebovitz        Expires August 31, 2010               [Page 24]


Internet-Draft               KARP Framework                February 2010


              (IKE)", RFC 4615, August 2006.

   [RFC4949]  Shirey, R., "Internet Security Glossary, Version 2",
              RFC 4949, August 2007.

   [RFC5036]  Andersson, L., Minei, I., and B. Thomas, "LDP
              Specification", RFC 5036, October 2007.

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


Authors' Addresses

   J. William Atwood
   Concordia University/CSE
   1455 de Maisonneuve Blvd, West
   Montreal, QC  H3G 1M8
   Canada

   Phone: +1(514)848-2424 ext3046
   Email: bill@cse.concordia.ca
   URI:   http://users.encs.concordia.ca/~bill


   Gregory Lebovitz
   Juniper Networks, Inc.
   1194 North Mathilda Ave.
   Sunnyvale, CA  94089-1206
   US

   Phone:
   Email: gregory.ietf@gmail.com

















Atwood & Lebovitz        Expires August 31, 2010               [Page 25]


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