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

Versions: 00 01 02 03

saag                                                         G. Lebovitz
Internet-Draft                                                   Juniper
Intended status: Informational                            March 10, 2009
Expires: September 11, 2009

Roadmap for Cryptographic Authentication of Routing Protocol Packets on
                                the Wire

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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on September 11, 2009.

Copyright Notice

   Copyright (c) 2009 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 in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.


   In the March of 2006 the IAB held a workshop on the topic of
   "Unwanted Internet Traffic".  The report from that workshop is

Lebovitz &             Expires September 11, 2009               [Page 1]

Internet-Draft                KMART Roadmap                   March 2009

   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
   creates a roadmap of protocol specification work for the use of
   modern cryptogrpahic mechanisms and algorithms for message
   authentication in routing protocols.  It also defines the framework
   for a key management protocol that may be used to create and manage
   session keys for message authentication and integrity.  This 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

Lebovitz &             Expires September 11, 2009               [Page 2]

Internet-Draft                KMART Roadmap                   March 2009

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
     1.2.  Requirements Language  . . . . . . . . . . . . . . . . . .  4
     1.3.  Scope  . . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.4.  Goals  . . . . . . . . . . . . . . . . . . . . . . . . . .  6
     1.5.  Non-Goals  . . . . . . . . . . . . . . . . . . . . . . . .  9
     1.6.  Audience . . . . . . . . . . . . . . . . . . . . . . . . .  9
   2.  Threats  . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     2.1.  Threats In Scope . . . . . . . . . . . . . . . . . . . . . 10
     2.2.  Threats Out of Scope . . . . . . . . . . . . . . . . . . . 12
   3.  Categorizing Routing Protocols . . . . . . . . . . . . . . . . 13
     3.1.  Category: Messaging Transaction Type . . . . . . . . . . . 13
     3.2.  Category: Peer vs. Group Keying  . . . . . . . . . . . . . 14
     3.3.  Security Characterization Vectors  . . . . . . . . . . . . 14
       3.3.1.  Internal vs. External Operation  . . . . . . . . . . . 15
       3.3.2.  Unique versus Shared Keys  . . . . . . . . . . . . . . 15
       3.3.3.  Out-of-Band vs. In-line Key Management . . . . . . . . 17
   4.  The Roadmap  . . . . . . . . . . . . . . . . . . . . . . . . . 18
     4.1.  Work Phases on any Particular Protocol . . . . . . . . . . 18
     4.2.  Requirements for Phase 1 BaseRPs' Security Update  . . . . 20
     4.3.  Common Framework . . . . . . . . . . . . . . . . . . . . . 21
     4.4.  Work Items Per Routing Protocol  . . . . . . . . . . . . . 26
     4.5.  Protocols in Categories  . . . . . . . . . . . . . . . . . 27
     4.6.  Priorites  . . . . . . . . . . . . . . . . . . . . . . . . 29
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 29
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 30
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30
   8.  Change History (RFC Editor: Delete Before Publishing)  . . . . 30
   9.  Needs Work in Next Draft (RFC Editor: Delete Before
       Publishing)  . . . . . . . . . . . . . . . . . . . . . . . . . 32
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 32
     10.2. Informative References . . . . . . . . . . . . . . . . . . 32
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34

Lebovitz &             Expires September 11, 2009               [Page 3]

Internet-Draft                KMART Roadmap                   March 2009

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 is being conducted through
      liaisons with the RIR's globally.
   o  Specifications for cryptographic validation of routing message
      content.  This work is being done 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.

1.1.  Terminology

   [to be filled out later]

   Base RP



   session keys

1.2.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119 [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 roadmap document, will be

Lebovitz &             Expires September 11, 2009               [Page 4]

Internet-Draft                KMART Roadmap                   March 2009

   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 roque
   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,
   routing products have been fine tuned over the years for the specific
   processing necessary for these routing protocols non-encapsulated
   formats.  Operators are, therefore, quite unwilling 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 this roadmap, and for any BaseRP
   work undertaken as part of this roadmap (discussed further in the
   Work Phases (Section 4.1) section).  The first is to enhance the Base
   RP's current authentication mechanism, ensuring it employs modern
   cryptographic algorithms and methods for its basic operational model,
   fulfillling the requirements defined in the Requirements
   (Section 4.2) section, and protecting against as many of the threats
   as possible as defined in the Threats (Section 2.1)section.  Many of
   the BaseRPs' current mechanisms use manual keys, so the first phase
   updates will focus on shoring up the manual key mechanisms that

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

Lebovitz &             Expires September 11, 2009               [Page 5]

Internet-Draft                KMART Roadmap                   March 2009

   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-
   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 2)
   section below.

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 is a great deal of deployed routing devices in operating
      networks that will not be able to run the most modern
      cryptographic mechanisms without significant and unacceptable

Lebovitz &             Expires September 11, 2009               [Page 6]

Internet-Draft                KMART Roadmap                   March 2009

      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 like cryptographic algorithm agility, 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 - A solutions acceptability 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.

Lebovitz &             Expires September 11, 2009               [Page 7]

Internet-Draft                KMART Roadmap                   March 2009

      Interviews with operators show several points about routing
      security.  First, only about 25% of operators have deployed
      security in their routing protocols [REF???, Danny, you got one?].
      Of those who have deployed, only about [25% ??] of their routers
      are deployed with the authentication enabled.  Most 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:

      A.  Changing the keys brings down the links/adjacencies,
          undermining Service Level Agreements (SLAs).
      B.  For external peers, difficulty of coordination with the other
          organization.  They often don't know who the contact is at the
          other organization, so they don't know where to start, and
          doing so takes a lot of time in research.
      C.  Keys must be changed at precisely the same time in order to
          limit connectivity outage duration.  This is incredibly
          difficult to do, operationally, especially between different
      D.  Relatively low priority compared to other operatoinal issues.
      E.  Lack of staff to implement the changes device by device.
      F.  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.

Lebovitz &             Expires September 11, 2009               [Page 8]

Internet-Draft                KMART Roadmap                   March 2009

   5. Address the threats enumerated above in the "Threats" section
      (Section 2) 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. Reuse common mechanisms across routing protocols whenever possible
      - 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

   7. Bridge any gaps between routing and security engineers by
      recording agreements on work items, roadmaps, and guidance from
      the Area leads and Internet Architecture Board (IAB, www.iab.org).

   8. Create a re-usable architecture and guidelines for various IETF
      working teams who will address these security improvements for
      various protocols

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 deal with in other
      areas, like SIDR.

1.6.  Audience

   The audience for this roadmap includes:

   o  Routing Area working group chairs and members -   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.

   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
        corresponding security mechanisms for the routing protocols.
        They will ensure that incremental security improvements are

Lebovitz &             Expires September 11, 2009               [Page 9]

Internet-Draft                KMART Roadmap                   March 2009

        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.

   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.

2.  Threats

   In RFC4949[RFC4949], a threat is defined as a potential for violation
   of security, which exists when there is a circumstance, capability,
   action, or event that could breach security and cause harm.  This
   section defines the threats that are in scope for this roadmap, and
   those that are explicitly out of scope.  This document leverages the
   "Generic Threats to Routing Protocols" model, RFC 4593 [RFC4593] ,
   capitalizes terms from that document, and offers a terse definition
   of those terms.  (More thorough description of routing protocol
   threats sources, motivations, consequences and actions can be found
   in RFC 4593 [RFC4593] itself).  The threat listings below expand upon
   these threat definitions.

2.1.  Threats In Scope

   The threats that will be addressed in this roadmap are those from
   OUTSIDERS, attackers that may reside anywhere in the Internet, have
   the ability to send IP traffic to the router, may be able to observe
   the router's replies, and may even control the path for a legitimate
   peer's traffic.  These are not legitimate participants in the routing
   protocol.  Message authentication and integrity protection
   specifically aims to identify messages originating from OUTSIDERS.

   The concept of OUTSIDERS can be further refined to include attackers
   who are terminated employees, and those sitting on-path.

Lebovitz &             Expires September 11, 2009              [Page 10]

Internet-Draft                KMART Roadmap                   March 2009

   o  On-Path - attackers with control of a network resource or a tap
      along the path of packets between two routers.  An on-path
      outsider can attempt a man-in-the-middle attack, in addition to
      several other attack actions.  A man-in-the-middle (MitM) attack
      occurs when an attacker who has access to packets flowing between
      two peers tampers with those packets in such a way that both peers
      think they are talking to each other directly, when in fact they
      are actually talking to the attacker only.  Protocols conforming
      to this roadmap will use cryptographic mechanisms to prevent a
      man-in-the-middle attacker from situating himself undetected.

   o  Terminated Employees - in this context, those who had access
      router configuration that included keys or keying material like
      pre-shared keys used in securing the routing protocol.  Using this
      material, the attacker could attempt to impersonate a legitimate
      router.  The goal of addressing this source specifically is to
      call out the case where new keys or keying material becomes
      necessary very quickly, with little operational expense, upon the
      termination of such an employee.  This grouping could also refer
      to any attacker who somehow managed to gain access to keying
      material, and said access had been detected by the operators such
      that the operators have an opportunity to move to new keys in
      order to prevent attack.

   These ATTACK ACTIONS are in scope for this roadmap:

   o  SPOOFING - when an illegitimate device assumes the identity of a
      legitimate one.  Spoofing can be used, for example, to inject
      unrealistic routing information that causes the disruption of
      network services.  Spoofing can also be used to cause a neighbor
      relationship to form that subsequently denies the formation of the
      relationship with the legitimate router.

   o  FALSIFICATION - an action whereby an attacker sends false routing
      information.  To falsify the routing information, an attacker has
      to be either the originator or a forwarder of the routing
      information.  Falsification may occur by an ORIGINATOR, or a
      MISTATEMENT of network resource reachability.  We must be careful
      to remember that in this work we are only targeting falsification
      from outsiders as may occur from tampering with packets in flight.
      Falsification from BYZANTINES (see the Threats Out of Scope
      section (Section 2.2) below) are not addressed by this roadmap,
      but by other work in the IETF.

Lebovitz &             Expires September 11, 2009              [Page 11]

Internet-Draft                KMART Roadmap                   March 2009

   o  INTERFERENCE - when an attacker inhibits the exchanges by
      legitimate routers.  The types of interference addressed by this
      work include:
      *  Changing message content

   o  DoS attacks on transport sub-systems - This includes any other DoS
      attacks specifically based on the above attack types.  This is
      when an attacker sends packets aimed at halting or preventing the
      underlying protocol over which the routing protocol runs, for
      example halting a BGP session by sending a TCP FIN packet.
      Another example is sending packets which confuse or overwhelm a
      security mechanism itself, for example initiating an overwhelming
      load of keying protocol initiations from bogus sources.  All other
      possible DoS attacks are out of scope (see next section).

2.2.  Threats Out of Scope

   Threats from BYZANTINE sources -- faulty, misconfigured, or subverted
   routers, i.e., legitimate participants in the routing protocol -- are
   out of scope for this roadmap.  Any of the attacks described in the
   above section (Section 2.1) that may be levied by a BYZANTINE source
   are therefore also out of scope.

   In addition, these other attack actions are out of scope for this

   o  SNIFFING - passive observation of route message contents in flight
   o  FALSIFICATION by BYZANTINE sources - unauthorized message content
      by a legitimate source.
   o  INTERFERENCE due to:
      *  NOT FORWARDING PACKETS - cannot be prevented with cryptographic
      *  DELAYING MESSAGES - cannot be prevented with cryptographic
      *  DENIAL OF RECEIPT - cannot be prevented with cryptographic
         working group
      *  Any other type of DoS attack.  For example, a flood of traffic
         that fills the link ahead of the router, so that the router is
         rendered unusable and unreachable by valid packets is NOT an

Lebovitz &             Expires September 11, 2009              [Page 12]

Internet-Draft                KMART Roadmap                   March 2009

         attack that this work will address.  Many other such examples
         could be contrived.

3.  Categorizing Routing Protocols

   For the purpose of this security roadmap definition, we will
   categorize the routing protocols into groups and have design teams
   focus on the specification work within those groupings.  It is
   believed that the groupings will have like requirements for their
   authentication mechanisms, and that reuse of authentication
   mechanisms will be greatest within these grouping.  The work items
   placed on the roadmap will be defined and assigned based on these
   categorizations.  It is also hoped that, down the road in the Phase 2
   work, we can create one KMP per category (if not for several
   categories) so that the work can be easily leveraged by the various
   RP teams.  KMPs are useful for allowing simple, automated updates of
   the traffic keys used in a base protocol.  KMPs replace the need for
   humans, or OSS routines, to periodically replace keys on running
   systems.  It also removes the need for a chain of manual keys to be
   chosen or configured.  When configured properly, a KMP will enforce
   the key freshness policy of two peers by keeping track of the key
   lifetime and negotiating a new key at the defined interval.

3.1.  Category: Messaging Transaction Type

   The first categorization defines four types of messaging transactions
   used on the wire by the base routing protocol, the Base RP.  They

   One-to-One     One peer router directly and intentionally delivers a
                  route update specifically to one other peer router.
                  Examples are BGP and LDP. [question to reviewers:
                  Should we list all protocols into these categories
                  right here, or just give a few examples?]

   One-to-Many    A router peers with multiple other routers on a single
                  network segment -- i.e. on link local -- such that it
                  creates and sends one route update message which is
                  intended for consumption by multiple peers.  Examples
                  would be OSPF and IS-IS.

   Client-Server  A client-server routing protocol is one where one
                  router initiates a request for route information from
                  another router, who then formulates a response to that
                  request, and replies with the requested data.
                  Examples are a BGP Route Reflector and [????  Are

Lebovitz &             Expires September 11, 2009              [Page 13]

Internet-Draft                KMART Roadmap                   March 2009

                  there other examples?  Is this the right example?].

   Multicast      Multicast protocols have unique security properties
                  because of the fact that they are inherently group-
                  based protocols and thus have group keying
                  requirements at the routing level where link-local
                  routing messages are multicasted.  Also, at least in
                  the case of PIM-SM, some messages are are sent unicast
                  to a given peer(s), as is the case with router-close-
                  to-sender and the "Rendezvous Point".  Some work for
                  application layer message security has been done in
                  the Multicast Security working group (MSEC,
                  and may be helpful to review, but is not directly

   [author's note: I think the above definitions need clean up.  Routing
   area folks, especially ADs, PLEASE suggest new text.]

3.2.  Category: Peer vs. Group Keying

   The second axis of categorization groups protocols by the keying
   mechanism that will be necessary for distributing session keys to the
   actual routing protocol transports.  They are:

   Peer keying    One router sends the keying messages directly and only
                  to one other router, such that a one-to-one, unique
                  keying security association (SA) is established
                  between the two routers

   Group Keying   One router creates and distributes a single keying
                  message to multiple peers.  In this case an group SA
                  will be established and used between multiple peers
                  simultaneously.  Group keying exists for protocols
                  like OSPF [RFC2328] , and also for multicast protocols
                  like PIM-SM [RFC4601].

3.3.  Security Characterization Vectors

   A few more considerations must be made about the protocol and its use
   when initially categorizing the protocol and scoping the
   authentication work.

Lebovitz &             Expires September 11, 2009              [Page 14]

Internet-Draft                KMART Roadmap                   March 2009

3.3.1.  Internal vs. External Operation

   The designers must consider whether the protocol is an internal
   routing protocol or an external one, i.e.  Does it primarily run
   between peers within a single domain of control or between two
   different domains of control?  Some protocols may be used in both
   cases, internally and externally, and as such various modes of
   authentication operation may be required for the same protocol.
   While it is preferred that all routing exchanges run with the utmost
   security mechanisms enabled in all deployments, the exhortation is
   greater for those protocols running at a peering point between two
   domains of control, and greatest for those on public exchange point
   links, because the volume of attackers are greater from the outside.
   Note however that the consequences of internal attacks maybe no less
   severe -- in fact they may be quite a bit more sever -- than an
   external attack.  An example of this internal versus external
   consideration is BGP which has both EBGP and IBGP modes.  Another
   example is a multicast protocol where the neighbors are sometimes
   within a domain of control and sometimes external, like at an
   exchange link.  It would be more acceptable to give up some security
   to get some convenience by using a group key on large broadcast
   networks within your domain, whereas operators may favor security
   over convenience and use unique keying on peering links.  In this
   case again, designers must consider both modes of operation and
   ensure the authentication mechanisms fit both.

   Operators are encouraged to run cryptographic authentication on all
   their adjacencies, but to work from the outside in, i.e.  The EBGP
   links are a higher priority than the IBGP links because they are
   externally facing.

3.3.2.  Unique versus Shared Keys

   This section discusses security considerations of when it is
   appropriate to use the same authentication key inputs for multiple
   peers and when it is not.  This is largely a debate of convenience
   versus security.  It is often the case that the best secured
   mechanism is also the least convenient mechanism.  For example, an
   air gap between a host and the network absolutely prevents remote
   attacks on the host, but having to copy and carry files using the
   "sneaker net" is quite inconvenient and unscalable.

   Operators have erred on the side of convenience when it comes to
   securing routing protocols with cryptographic authentication.  Many
   do not use it at all.  Some use it only on external links, but not on
   internal links.  Those that do use it often use the same key for all
   peers across their entire network.  It is common to see the same key
   in use for years, and that being the same key that was entered when

Lebovitz &             Expires September 11, 2009              [Page 15]

Internet-Draft                KMART Roadmap                   March 2009

   authentication was originally configured.

   The goal for designers is to create authentication mechanisms that
   are easy for the operators to deploy, and still use unique keys.
   Operators have the impression that they NEED shared keys, when in
   fact they do not.  What they need is the relative convenience they
   experience from deploying cryptographic authentication with shared
   keys, compared to the inconvenience they would experience if they
   deployed the same authentication mechanism using unique keys per
   pair.  An example is BGP Route Reflectors.  Here operators often use
   the same authentication key between each client and the route
   reflector.  The roadmaps defined from this guidance document will
   allow for unique keys to be used between each client and the peer,
   without sacrificing much convenience.  Designers should strive to
   deliver unique keying mechanisms with similar ease-of-deployment
   properties as today's shared keys.

   Operators must understand the consequences of using shared keys
   across many peers.  Unique keys are more secure than shared keys
   because the reduce both the attack target size and the attack
   consequence size.  In this context, the attack target size represents
   the number of unique routing exchanges across a network that an
   attacker may be able to observe in order to gain security association
   credentials, i.e.  Crack the keys.  If a shared key is used across
   the entire internal domain of control, then the attack target size is
   very large.  The larger the attack target, the easier it is for the
   attacker to gain access to analysis data, and greater the volume of
   analysis data he can access, both of which make his job easier.  In
   this context, the attack consequence size represents the amount of
   routing adjacencies that can be negatively affected once a breach has
   occurred, i.e.  Once the keys have been acquired by the attacker.
   Again, if a shared key is used across the internal domain, then the
   consequence size is the whole network.  Ideally, unique key pairs
   would be used for each adjacency.

   In some cases designers may need to use shared keys in order to solve
   the given problem space.  For example, a multicast packet is sent
   once but then observed and consumed by several routing neighbors.  If
   unique keys were used per neighbor, the benefit of multicast would be
   erased because the casting peer would have to create a different
   announcement packet/stream for each listening peer.  Though this may
   be desired and acceptable in some small amount of use cases, it is
   not the norm.  Shared group keys are an acceptable solution here, and
   much work has been done already in this area (see MSEC working

Lebovitz &             Expires September 11, 2009              [Page 16]

Internet-Draft                KMART Roadmap                   March 2009

3.3.3.  Out-of-Band vs. In-line Key Management

   This section discusses the security and use case considerations for
   keys placed on devices through out-of-band configurations versus
   through one routing peer-to-peer key management protocol exchanges.
   Note, when we say here "Peer-to-Peer KMP" we do not mean in-band to
   the RP.  Instead, we mean that the exchange occurs in-line, over IP,
   between the two routing peers directly.  In in-line KMP the peers
   themselves handle the key and security association negotiation
   between themselves directly, whereas in an out-of-band system the
   keys are placed onto the device through some other configuration or
   management method or interface.

   An example of an out-of-band mechanism could be an administrator who
   makes a remote management connection (e.g. using SSH) to a router and
   manually enters the keying information -- like the algorithm, the
   key(s), the lifetimes, etc.  Another example could be an OSS system
   which inputs the same information via a script over an SSH
   connection, or by pushing configuration through some other management
   connection, standard (Netconf-based) or proprietary.

   The drawbacks of an out-of-band mechanism include: lack of scale-
   ability, complexity and speed of changing if breech is suspected.
   For example, if an employee who had access to keys was was
   terminated, or if a machine holding those keys was belived
   compromised, then the system would be considered insecure and
   vulnerable until new keys were defined by a human.  Those keys then
   need to be placed into the OSS system, manually, and the OSS system
   then needs to push the change -- often during a very limited change
   window -- into the relevant devices.  If there are multiple
   organizations involved in these connections, this process is greatly

   The benefits of out-of-band mechanism is that once the new keys/
   parameters are set in OSS system they can be pushed automatically to
   all devices within the OSS's domain of control.  Operators have
   mechanisms in place for this already.  In small environments with few
   routers, a manual system is not difficult to employ.

   We further define an in-line key exchange as using cryptographicly
   protected identity verification, session key negotiation, and
   security association parameter negotiation between the two routing
   peers.  The KMP between the two peers may also include the
   negotiation of parameters, like algorithms, cryptographic inputs
   (e.g. initialization vectors), key life-times, etc.

   The benefits an in-line KMP are several.  An in-line KMP results in
   key(s) that are privately generated, and not recorded permanently

Lebovitz &             Expires September 11, 2009              [Page 17]

Internet-Draft                KMART Roadmap                   March 2009

   anywhere.  Since the traffic keys used in a particular connection are
   not a fixed part of a device configuration no steal-able data exists
   anywhere else in the operator's systems which can be stolen, e.g. in
   the case of a terminated or turned employee.  If a server or other
   data store is stolen or compromised, the thieves gain no access to
   current traffic keys.  They may gain access to key derivation
   material, like a PSK, but not current traffic keys in use.  In this
   example, these PSKs can be updated into the device configurations
   (either manually or through an OSS) without bouncing or impacting the
   existing session at all.  In the case of using raw assymetric keys or
   certificates, instead of PSKs, the data theft would likely not even
   result in any compromise, as the key pairs would have been generated
   on the routers, and never leave those routers.  In such a case no
   changes are needed on the routers; the connections will continue to
   be secure, non-compromised.  Additoinally, with a KMP regular re-keys
   operations occur without any operator involvement or oversight.  This
   keeps keys fresh.

   The drawbacks to using a KMP are few.  First, a KMP requires more
   cryptographic processing for the router at the very beginning of a
   connection.  This will add some minor start-up time to connection
   establishment versus a purely manual key approach.  Once a connection
   with traffic keys have been established via a KMP, the performance is
   the same in the KMP and the out-of-band case.  KMPs also add another
   layer of protocol and configuration complexity which can fail or be
   misconfigured.  This was more of an issue when these KMPs were first
   deployed, but less so as these implementaitons and operational
   experience with them has matured.

   The desired end goal is in-line KMPs.

4.  The Roadmap

4.1.  Work Phases on any Particular Protocol

   The desired endstate for the KMART work contains several items.
   First, the people desiring to deploy securely authenticated and
   integrity validated packets between routing peers have the tools
   specified, implemented and shipping in order to deploy.  These tools
   should be fairly simple to implement, and not more complex than the
   security mechanisms to which the operators are already accustomed.
   (Examples of security mechanisms to which router operators are
   accustomed include: the use of assymetric keys for authentication in
   SSH for router configuration, the use of pre-shared keys (PSKs) in
   TCP MD5 for BGP protection, the use of self-signed certificates for
   HTTPS access to device Web-based user interfaces, the use of strongly
   constructed passwords and/or identity tokens for user identification

Lebovitz &             Expires September 11, 2009              [Page 18]

Internet-Draft                KMART Roadmap                   March 2009

   when logging into routers and management systems.)  While the tools
   that we intend to specify may not be able to stop a deployment from
   using "foobar" as an input key for every device across their entire
   routing domain, we intend to make a solid, modern security system
   that is not too much more difficult than that.  In other words,
   simplicity and deployability are keys to success.  The Base RP's will
   specify modern cryptographic algorithms and security mechanisms.
   Routing peers will be able to employ unique, pair-wise keys per
   peering instance, with reasonable key lifetimes, and updating those
   keys on a somewhat regular basis will be operationally easy, causing
   no service interruption.

   The reach the above described end-state using manual keys may only be
   pragmatic in very small deployments.  In larger deployments, this end
   state will be much more operationally difficult to reach with only
   manual keys.  Thus, there will be a need for key lifecycle
   management, in the form of a key management protocol, or KMP.  We
   expect that the two forms, manual key usage and KMP usage, will co-
   exist in the real world.  For example, a provider's edge router at a
   public exchange peering point will want to use a KMP for ensuring
   unique and fresh keys with external peers, while a manual key may be
   used between a provider's access edge router and each of the same
   provider's customer premise routers with which it peers.

   In accordance with the desired end state just described, we define
   two main work phases for each Base RP:

   1.  Enhance the Base RP's current authentication mechanism.  This
       work involves enhancing a Base RP's current security mechanisms
       in order to achieve a consistent, modern level of security
       functionality within its existing keying framework.  It is
       understood and accepted that the existing keying frameworks are
       largely based on manual keys.  Since many operators have already
       built operational support systems (OSS) around these manual key
       implementations, there is some automation available for an
       operator to leverage in that way, if the underlying mechanisms
       are themselves secure.  In this phase, we explicitly exclude
       embedding or creating a KMP.  A list of the requirements for
       Phase 1 work are below in the section "Requirements for Phase 1
       BaseRPs' Security Updates (Section 4.2).

   2.  Develop an automated keying framework.  The second phase will
       focus on the development of an automated keying framework to
       faciliate unique pair-wise (or perhaps group-wise, where
       applicable) keys per peering isntance.  This involves the use of
       a KMP.  A KMP is helpful because [will add a more full
       description here, sorry, ran out of time].  The framework for any
       one BaseRP will fall under, and be able to leverage, the generic

Lebovitz &             Expires September 11, 2009              [Page 19]

Internet-Draft                KMART Roadmap                   March 2009

       framework described below in section Section 4.3.

4.2.  Requirements for Phase 1 BaseRPs' Security Update

   Here is a proposed list of requirements that SHOULD be addressed by
   Phase 1 (according to "1." above) security updates to Base RPs [to be
   reviewed after -01 is released]:

   1.   Clear definitions of which elements of the transmission (frame,
        packet, segment, etc.) are protected by the authentication
   2.   Strong algorithms, and defined and accepted by the security
        community, MUST be specified.  The option should use algorithms
        considered accepted by the security community, which are
        considered appropriately safe.  The use of non-standard or
        unpublished algorithms SHOULD BE avoided.
   3.   Algorithm agility for the cryptograhpic algorithms used in the
        authentication MUST be specified, i.e. more than one algorithm
        MUST be specified and it is clear how new algorithms MAY be
        specified and used.
   4.   Secure use of simple PSKs, offering both operational convenience
        as well as building something of a fence around stupidity, MUST
        be specified.
   5.   Inter-connection replay protection.  Packets captured from one
        connection MUST NOT be able to be re-sent and accepted during a
        later connection.
   6.   Intra-connection replay protection.  Packets captured during a
        connection MUST NOT be able to be re-sent and accepted during
        that same connection, to deal with long-lived connections.
   7.   A change of security parameters REQUIRES, and even forces, a
        change of session traffic keys
   8.   Intra-connection re-keying which occurs without a break or
        interruption to the current peering session, and, if possible,
        without data loss, MUST be specified.
   9.   Efficient re-keying SHOULD be provided.  The specificaion SHOULD
        support rekeying during a connection without the need to expend
        undue computational resources.  In particular, the specification
        SHOULD avoid the need to try/compute multiple keys on a given
   10.  Prevent DoS attacks as those described as in-scope in the
        threats section Section 2.1above
   11.  Default mechanisms and algorithms specified and defined as
        REQUIRED for all implementations
   12.  Manual keying MUST be supported.
   13.  Architecture of the specification MUST consider and allows for
        future use of a KMP.

Lebovitz &             Expires September 11, 2009              [Page 20]

Internet-Draft                KMART Roadmap                   March 2009

4.3.  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 Base RP needed to define
   it's own key management protocol this would balloon the total amount
   of different sockets that needed to be opened and processes that
   needed to be simultaneously running on an implementation.  It would
   also significantly increase the run-time complexity and memory
   requirements of such systems running multiple Base RPs, 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 Base RP's 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 Base RPs that will provide better threat protection.

   The components for the framework are listed here, and described

   o  BaseRP security mechanism
   o  KMP
   o  KeyStore
   o  BaseRP-to-KMP API
   o  BaseRP-to-KeyStore API
   o  KMP-to-KeyStore API
   o  Common Base RP mechanisms
   o  Identifiers
   o  Proof of identity
   o  Profiles

   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.

Lebovitz &             Expires September 11, 2009              [Page 21]

Internet-Draft                KMART Roadmap                   March 2009

      +------------+   +--------------------+
      |            |   |                    | Check     +-----------+
      | Identifier +-->|                    +---------->|           |
      |            |   |    KMP Function    |           |  Identity |
      +----------- +   |                    |<----------+   Proof   |
                       |                    |  Approve  |           |
                       +-+--------------+---+           +-----------+
                         |              |
         KMP-to-KeyStore |              |
            API          |              |
                        \|/             |
                 +-------+-------+      |
                 |               |      | KMP-to-BaseRP
                 |    Session    |      |  API
                 |    KeyStore   |      |
                 |               |      |
                 +-------+-------+      |
                         |              |
                         |              |
           KeyStore-to-  |              |
            BaseRP API   |              |
                         |             \|/
             |           |                            |
             |          \|/          Common BaseRP    |
             |   +-------+-------+   Authentication   |
             |   |               |   Mechanisms       |
             +---|  Transport    |-----+--------------+
             |   |   Key(s)      |                    |
             |   |               |                    |
             |   +---------------+   Specific BaseRP  |
             |                       Authentication   |
             |                       Security         |
             |                       Mechanism        |
             |                                        |

               Figure 1: Automatic Key Management Framework

   Each element of the framework is described here:

   o  Base RP -  Base RP security mechanism - In each case, the Base RP
           will contain a mechanism for using session keys in their
           security option.

Lebovitz &             Expires September 11, 2009              [Page 22]

Internet-Draft                KMART Roadmap                   March 2009

   o  KeyStore -   Each implementation will also contain a protocol
           independent mechanism for storing keys, called KeyStore.  The
           key_store will have multiple different logical containers,
           one container for each session key that any given Base RP
           will need.

   o  RP-KeyStore API -   There will be an API for Base RP to retrieve
           the keys from the KeyStore.  This will enable implementers to
           reuse the same API calls for all their Base RPs.  The API
           will necessarily include facility to retrieve other
           parameters required for the construction of the BaseRP's
           packets, like key IDs or key lifetimes, etc.

   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 Base RP, say BGP and LDP, are analogous
           to ESP and AH, while the KMP is analogous to IKEv2 itself.

   o  RP-KMP API -   There will be an API for the Base RP 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 Base RP 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 Base RPs
           and each of their unique parameters that need to be
           negotiated and returned.

   o  KMP-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 RPs as
           described in the section definingcategories (Section 3).

Lebovitz &             Expires September 11, 2009              [Page 23]

Internet-Draft                KMART Roadmap                   March 2009

   [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 RP to any KMP, then there can be a generic hand-down
   function from the KMP to the RP 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 RP teams to use
   them.  Need to get this team going asap.]

   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, 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 it's format --
           must be agreed upon by the two endpoints.  Further, the
           string can be used as an identifier in this context, even if
           the string is not actually provisioned in it's 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.

Lebovitz &             Expires September 11, 2009              [Page 24]

Internet-Draft                KMART Roadmap                   March 2009

   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, like 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 contant.
           Certificate management can be made more simple and scalable
           with the use 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 Base
           RP, 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

   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 Base RP and Base RP to KMP, but also between
   Base RP 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.

Lebovitz &             Expires September 11, 2009              [Page 25]

Internet-Draft                KMART Roadmap                   March 2009

4.4.  Work Items Per Routing Protocol

   Each Base RP will have a team (the [RP]-KMART team) working on
   incrementally improving their Base RP's security, These teams will
   have the following main work items:

   PHASE 1:

   Characterize the RP
      Assess the Base RP to see what authentication mechanisms it has
      today.  Does it needs significant improvement to its existing
      mechanisms or not?  This will include determining if modern,
      strong security algorithms and parameters are present.

   Define Optimal State
      List the requirements for the Base RP's session key usage and
      format to contain to modern, strong security algorithms and
      mechanisms, per the Requirements (Section 4.2)section above.  The
      goal here is to determine what is needed for they BaseRP alone to
      be used securely with at least manual keys.

   Gap Analysis
      Enumerate the requirements for this protocol to move from its
      current security state, the first bullet, to its optimal state,
      bullet two above.

   Define, Assign, Design
      Create a deliverables list of the design and specification work,
      with milestones.  Define owners.  Release a document(s)

   PHASE 2:

   KMP Analysis
      Review requirements for KMPs [RFC????].  Identify any nuances for
      this particular protocol's needs and its use cases for KMP.  List
      the requirements that this RP has for being able to be use in
      conjunctions with a KMP.  Define the optimal state.

   Gap Analysis
      Enumerate the requirements for this protocol to move from its
      current security state to its optimal state.

   Define, Assign, Design

Lebovitz &             Expires September 11, 2009              [Page 26]

Internet-Draft                KMART Roadmap                   March 2009

      Create a deliverabels list of the design and specification work,
      with miletsones.  Define owners.  Do the design and document work
      for a KMP to be able to generate the Base RP's session keys for
      the packets on the wire.  These will be the arguments passed in
      the API to the KMP in order to bootstrap the session keys to the
      Base RP.

   There will also be a team formed to work on the base framework
   mechanisms for each of the main categories, i.e. the blocks and API's
   represented in figure 1 (Figure 1).

4.5.  Protocols in Categories

   This section groups the Base RPs into like categories, according to
   attributes set forth in Categories Section (Section 3).  Each group
   will have a design team tasked with improving the security of the
   Base RP mechanisms and defining the KMP requirements for their group,
   then rolling both into a roadmap document upon which they will

   BGP, LDP and MSDP
       The Base RP's that fall into the category of the one-to-one
       peering messages, and will use peer keying protocols, AND are all
       transmitted over TCP include BGP RFC 4271 [RFC4271], LDP
       [RFC5036] and MSDP [RFC3618].  A team will work on one mechanism
       to cover these three protocols.  Much of the work on the BaseRP
       update for its existing authentication mechanism is already
       occuring in the TCPM Working Group, on the TCP-AO
       [I-D.ietf-tcpm-tcp-auth-opt] document, as well as its
       cryptography-helper document, TCP-AO-CRYPTO [I-D.ao-crypto].  The
       exception is the mode where LDP is used directly on the LAN
       [RFC????].  The work for this may go into the Group keying
       category (w/ OSPF) mentioned below.

   OSPF, ISIS, and RIP
       The Base RPs that fall into the category Group keying with one-
       to-many peering messages includes OSPF [RFC2328], ISIS [RFC1195]
       and RIP [RFC2453].  Not surprisingly, all these routing protocols
       have two other things in common.  First, they are run on a
       combination of the OSI datalink layer 2, and the OSI network
       layer 3.  Second, they are all internal gateway protocols, or
       IGPs.  The keying mechanisms and use will be much more
       complicated to define for these.

Lebovitz &             Expires September 11, 2009              [Page 27]

Internet-Draft                KMART Roadmap                   March 2009

       Because it is less of a routing protocol, per se, and more of a
       peer aliveness detection mechanism, Bidirectional Forwarding
       Detection (BFD) [RFC????] will have its own team.

   RSVP [RFC????], RSVP-TE [RFC????], and PCE
       These three protocols will be handled together. [what more
       characterisation should we give here?  Routing AD's, provide text

   PIM-SM and PIM-DM
       Finally, the multicast protocols of PIM-SM [RFC4601] and PIM-DM
       [RFC3973] will be handled together.  PIM-SM multicasts routing
       information (Hello, Join/Prune, Assert) on a link-local basis,
       using a defined multicast address.  In addition, it specifies
       unicast communication for exchange of information (Register,
       Register-Stop) between the router closest to a group sender and
       the "rendezvous point" (RP).  The RP is typically not "on-link"
       for a particular router.  While much work has been done on
       multicast security for application-layer groups, little has been
       done to address the problem of managing hundreds or thousands of
       small one-to-many groups with link-local scope.  This will be
       necessary if we are to have unique keys per speaking router in a
       PIM chain.  Such an authentication mechanism should be considered
       along with the router-to-Rendezvous Point authentication
       mechanism.  The most important issue is ensuring that only the
       "legitimate neighbors" get the keys for (S,G), so that rogue
       routers cannot participate in the exchanges.  Another issue is
       that some of the communication may occur intra-domain, e.g. the
       link-local messages in an enterprise, while others for the same
       (*,G) may occur inter-domain, e.g. the router-to-Rendezvous Point
       messges may be from one enterprise's router to another.  One
       possible solution proposes a region-wide "master" key server
       (possibly replicated), and one "local" key server per speaking
       router.  There is no issue with propagating the messages outside
       the link, because link-local messages, by definition, are not
       forwarded.  This solution is offered only as an example of how
       work may progress; further discussion should occur in this work
       team.  Specification of a link-local protection mechanism for
       PIM-SM occurred in RFC 4601 [RFC4601], and this work is being
       updated in PIM-SM-LINKLOCAL [I-D.ietf-pim-sm-linklocal].
       However, the KMP part is completely unspecified, and will require
       work outside the expertise of the PIM working group to
       accomplish, which is why this roadmap is being created.

Lebovitz &             Expires September 11, 2009              [Page 28]

Internet-Draft                KMART Roadmap                   March 2009

   These protocols are deemed out-of-scope for this current iteration of
   the work roadmap.  Once all of the protocols listed above have had
   their work completed, or are clearly within site of completion, then
   the community will revisit the need and interest for working on

   o  MANET
   o  FORCES

   [need text from routing ADs on why these are out of scope]

4.6.  Priorites

   Resources from both the routing area and the security area will be
   applied to work on these problem spaces as quickly as possible.
   Realizing that such resources are far from unlimited, a rank order
   priority for addressing the work of incrementally securing these
   groups of routing protocols is provided:

   o  Priority 1 - BGP / LDP / MSDP
   o  Priority 2 - BFD
   o  Priority 3 - OSPF / ISIS / RIP
   o  Priority 4 - RSVP and RSVP-TE

   By far the most important group is the Priority 1 group as these are
   the protocols used on the most public and exposed segments of the
   networks, at the peering points between operators and between
   operators and their customers.  BFD, as a detection mechanism
   underlying the Priority 1 protocols is therefore second.

5.  Security Considerations

   This entire document focuses on improving the security of routing
   protocols by improving or implementing cryptographic authentication
   for each routing protocol.  Security considerations are largely
   contained within the body text of the document.

   The mechanisms that will be defined under this roadmap aim to improve
   the security, better protect against more threats, and provider far
   greater operational efficiencies than the state of things at the time
   of this writing.  However, none of these changes will improve
   Internet security unless they are implemented and deployed.  Other
   influences must be brought to bare upon operators and organizations
   to create incentives for deployment.  Such incentives may take the
   form of PCI-like industry compliance/certifications, well advertised
   BCPs profiling the use of this roadmap's output, end-user demand or

Lebovitz &             Expires September 11, 2009              [Page 29]

Internet-Draft                KMART Roadmap                   March 2009


   [we can pull pieces out of body and place here, if people think it
   more appropriate].

6.  IANA Considerations

   This document has no actions for IANA.

7.  Acknowledgements

   The outline for this draft was created from discussions and
   agreements with Routing AD's Ross Callon and Dave Ward, Security AD's
   Tim Polk and Pasi Eronen, and IAB members Danny McPherson and Gregory

   Mat Ford and Bill Atwood provided reviews to -00.

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

   -00-00 original rough rough rough draft for review by routing and
   security AD's

   -00- original submission

   o  adds new category = multicast protocols in category section and
      mentions mcast in group keying category description.
   o  add a lot of references where they did not exist before, or where
      there were only place holders.  Still more work needed on this.
   o  abstract filled in
   o  changed from standards track to informational (this was an
      oversight in last draft).
   o  filled out threats section with detailed descriptions, and linked
      to RPsec threats RFC
   o  made ascii art for the basic KMP framework
   o  added section on internal versus external peering and the
      requirements decisions for them
   o  added security characterization section in sect 2, added sections
      discussing internal vs external protocols, shared vs unique keys,
      oob vs in-band keying

Lebovitz &             Expires September 11, 2009              [Page 30]

Internet-Draft                KMART Roadmap                   March 2009

   o  incorporates all D Ward's feedback from his initial skim of the


   o  Updated framework (Figure 1) diagram to include all listed and
      described elements.  Needs review and honing.  Gregory Lebovitz
   o  Added comment in protocols (Section 4.5) section that much of the
      BGP/LDP Phase 1 work is already being done in tcp-ao and ao-
      crypto.  GL.
   o  Updated Scope making the 2 work phases more clear earlier in the
      document.  GL.
   o  Broke work items (Section 4.4) section into two Phases, 1 for
      manual key update, and second for KMP work.  GL.
   o  Re-org'd doc.  Brought Threats (Section 2) section out into its
      own top-level section.  Did same with Categorization (Section 3)
      section, leaving Roadmap section more focused.  Moved ToDo list
      and Change History to end of doc, after Acknowledgements.  GL.
   o  added new sect 2.3 (Section 4.1) on main roadmap phases.  Previous
      section Common Framework (Section 4.3) moved to 2.4.  Tim Polk
   o  Added Section 2.3.1 Requirements for Phase 1 BaseRPs' Security
      Update (Section 4.2).  This provides a nice starter set of
      requirements for any work team.  GL.
   o  Filled out text for Out vs In-band Key Mgmt (Section 3.3.3)
      section, significantly.  Changed the term from "in-band" to "in-
   o  Section Threats (Section 2) Clarified DoS threats in and out of
      scope better.  We are not preventing all DoS attacks.  Just those
      we can reasonably via authentication.  TP.
   o  Sect In-band vs Out-of-Band (Section 3.3.3)clarified that In-band
      does not mean in-band to RP, but rather over IP between the RPs,
      rather than pushed down by some external management entity.  TP.
   o  In roadmap (Section 3) section, added "it is also hoped that we
      can create one kmp per category..."  Also explained value of a
      KMP.  TP.
   o  Added "operators" to audience (Section 1.6) list.  Matt Ford (MF).
   o  Described why BGP (and LDP) security is not deployed very often.
      Added this Scope (Section 1.3) section, point 4.  If mechanisms
      aren't being deployed, why is that?  What, if anything, could be
      done to improve deployment?  Tried to address these.  Need
      references (see To Do list below).  MF.
   o  Added some text to security section to address this from MF: say
      something here about the limitations of this approach, if any -
      and refer back to the need for other pieces of the puzzle.  May
      need more work.

Lebovitz &             Expires September 11, 2009              [Page 31]

Internet-Draft                KMART Roadmap                   March 2009

   o  Cleaned up text for multicast part of Message Type (Section 3.1)
      section and Protocols (Section 4.5) section, clarifying PIM's two
      message types, mcast and unicast, in both places.  Bill Atwood
   o  In section Protocols (Section 4.5), added references to 4601 and
   o  Editorial changes pointed out various folks.

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  RTG AD's or delegates: clean up the three definitions of route
      message type categories.  Need RTG Area folks input on this.
   o  More clarity on the work items for those defining and specifying
      the framework elements and API's themselves.
   o  RTG AD's or delegates: text justifying RSVP and RSVP-TE and what
      we thing solving that problem may look like
   o  RTG AD's or delegates: more justification for why MANET and FORCES
      are out of scope.  Need ref for those RFCs.
   o  Danny McPherson: Get reference for BGP auth usage stats in Scope
      (Section 1.3) section, item 4.
   o  Get RFC references and insert where not done yet
   o  security section?  Still nees more there, I think?

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.

   [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

              Lebovitz, G., "Cryptographic Algorithms, Use and

Lebovitz &             Expires September 11, 2009              [Page 32]

Internet-Draft                KMART Roadmap                   March 2009

              Implementation Requirements for TCP Authentication
              Option", March 2009, <http://tools.ietf.org/html/

              Atwood, W., Islam, S., and M. Siami, "Authentication and
              Confidentiality in PIM-SM Link-local Messages",
              draft-ietf-pim-sm-linklocal-07 (work in progress),
              February 2009.

              Touch, J., Mankin, A., and R. Bonica, "The TCP
              Authentication Option", draft-ietf-tcpm-tcp-auth-opt-04
              (work in progress), March 2009.

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

   [RFC3552]  Rescorla, E. and B. Korver, "Guidelines for Writing RFC
              Text on Security Considerations", BCP 72, RFC 3552,
              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.

   [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):

Lebovitz &             Expires September 11, 2009              [Page 33]

Internet-Draft                KMART Roadmap                   March 2009

              Protocol Specification (Revised)", RFC 4601, 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

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

   Email: gregory.ietf@gmail.com


Lebovitz &             Expires September 11, 2009              [Page 34]

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