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

Versions: 00 01 02 03 04 05 06 07 RFC 6862

KARP Working Group                                           G. Lebovitz
Internet-Draft                                    Juniper Networks, Inc.
Intended status: Standards Track                               M. Bhatia
Expires: April 12, 2011                                   Alcatel-Lucent
                                                                R. White
                                                           Cisco Systems
                                                         October 9, 2010


The Threat Analysis and Requirements for Cryptographic Authentication of
                     Routing Protocols' Transports
                    draft-ietf-karp-threats-reqs-01

Abstract

   Different routing protocols exist and each employs its own mechanism
   for securing the protocol packets on the wire.  While most already
   have some method for accomplishing cryptographic message
   authentication, in many cases the existing methods are dated,
   vulnerable to attack, and employ cryptographic algorithms that have
   been deprecated.  The "Keying and Authentication for Routing
   Protocols" (KARP) effort aims to overhaul and improve these
   mechanisms.

   This document has two main parts - the first describes the threat
   analysis for attacks against routing protocols' transports and the
   second enumerates the requirements for addressing the described
   threats.  This document, along with the KARP design guide and KARP
   framework documents, will be used by KARP design teams for specific
   protocol review and overhaul.  This document reflects the input of
   both the IETF's Security Area and Routing Area in order to form a
   jointly agreed upon guidance.

Status of this Memo

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

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

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




Lebovitz, et al.         Expires April 12, 2011                 [Page 1]


Internet-Draft       KARP Threats and Reqquirements         October 2010


   This Internet-Draft will expire on April 12, 2011.

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 Simplified BSD License.



































Lebovitz, et al.         Expires April 12, 2011                 [Page 2]


Internet-Draft       KARP Threats and Reqquirements         October 2010


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
     1.2.  Requirements Language  . . . . . . . . . . . . . . . . . .  7
     1.3.  Scope  . . . . . . . . . . . . . . . . . . . . . . . . . .  7
     1.4.  Incremental Approach . . . . . . . . . . . . . . . . . . .  8
     1.5.  Goals  . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     1.6.  Non-Goals  . . . . . . . . . . . . . . . . . . . . . . . . 12
     1.7.  Audience . . . . . . . . . . . . . . . . . . . . . . . . . 12

   2.  Threats  . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
     2.1.  Threats In Scope . . . . . . . . . . . . . . . . . . . . . 14
     2.2.  Threats Out of Scope . . . . . . . . . . . . . . . . . . . 16

   3.  Requirements for Phase 1 of a Routing Protocol Transport's
       Security Update  . . . . . . . . . . . . . . . . . . . . . . . 18

   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 23

   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 24

   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25

   7.  Change History (RFC Editor: Delete Before Publishing)  . . . . 26

   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 27
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 27

   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30




















Lebovitz, et al.         Expires April 12, 2011                 [Page 3]


Internet-Draft       KARP Threats and Reqquirements         October 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 "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 item in the list above, securing the
   the transmission of routing protocol packets on the wire, or rather
   securing routing protocol transport.  This effort is referred to as
   Keying and Authentication for Routing Protocols, or "KARP".  This
   document specifically addresses the threat analysis for per packet
   routing protocol transport authentication, and the requirements for
   protocols to mitigate those threats.

   This document is one of three that together form the guidance and
   instructions for KARP design teams working to overhaul routing
   protocol transport security.  The other two are the KARP Design Guide
   [I-D.ietf-karp-design-guide] and the KARP Framework
   [I-D.ietf-karp-framework].

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.





Lebovitz, et al.         Expires April 12, 2011                 [Page 4]


Internet-Draft       KARP Threats and Reqquirements         October 2010


      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

      In cryptography, a pseudorandom function family, abbreviated PRF,
      is a collection of efficiently-computable functions which emulate
      a random oracle in the following way: No efficient algorithm can
      distinguish (with significant advantage) between a function chosen
      randomly from the PRF family and a random oracle (a function whose
      outputs are fixed completely at random).  Informally, a PRF takes
      a secret key and a set of input values and produces random-seeming
      output values for each input value.

      KDF (Key derivation function)

      A KDF is a function in which an input key and other input data is
      used to generate (or derive) keying material that can be employed
      by cryptographic algorithms.  The key that is input to a KDF is
      called a key derivation key.  KDFs can be used to generate one or
      more keys from either (i) a uniformly random or pseudorandom seed
      value or (ii) a Diffie-Hellman shared secret or (iii) a non-
      uniform random source or (iv) a passphrase.

      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

      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



Lebovitz, et al.         Expires April 12, 2011                 [Page 5]


Internet-Draft       KARP Threats and Reqquirements         October 2010


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

      SA (Security Association)

      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 for creation, distribution and
      maintenance of secret keys.  It determines how secret keys are
      generated and made available to both the parties.  If session or
      traffic keys are being used, KMP is responsible for generating
      them and determining when they should be renewed.

      A KMP is helpful because it negotiates unique, pair wise, random
      keys without administrator involvement.  It also negotiates as
      mentioned earlier several of the SA parameters required for the
      secure connection, including key life times.  It keeps track of
      those lifetimes using counters, and negotiates new keys and
      parameters before they expire, again, without administrator
      interaction.  Additionally, in the event of a breach, changing the
      KMP key will immediately cause a rekey to occur for the Traffic
      Key, and those new Traffic Keys will be installed and used in the
      current connection.

      KMP Function






Lebovitz, et al.         Expires April 12, 2011                 [Page 6]


Internet-Draft       KARP Threats and Reqquirements         October 2010


      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.  This would generally be given by the
      KMP that would later be used to derive fresh traffic keys.

      Traffic Key

      The actual key (or set of keys) used for protecting the routing
      protocol traffic.  Since the traffic keys used in a particular
      connection are not a fixed part of a device configuration no 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.

   Definitions of items specific to the general KARP framework are
   described in more detail in the KARP Framework
   [I-D.ietf-karp-framework] document.

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

   Three basic services (or techniques) may be employed in order to
   secure any piece of data as it is transmitted over the wire: privacy,
   authentication, and message integrity.  The focus for this effort,
   and the scope for this roadmap document, will be message
   authentication and packet integrity only.  This work explicitly
   excludes, at this point in time, privacy services.  Non-repudiation
   is also excluded as a goal at this time.  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



Lebovitz, et al.         Expires April 12, 2011                 [Page 7]


Internet-Draft       KARP Threats and Reqquirements         October 2010


   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.  Privacy and non-
   repudiation may be addressed in future work.

   OSPF, IS-IS, LDP, and RIP 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, this document aims to enhance them, updating them to
   modern and secure levels.

   Therefore, the scope of this roadmap of work includes:

   o  Making use of existing routing protocol transport security
      mechanisms, 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

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

   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, and a set considered out-of- scope.
   These are described in detail in the Threats (Section 2) section
   below.

1.4.  Incremental Approach

   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.  The principle of crawl, walk, run will be
   in place and routing protocol authentication mechanisms may not go
   immediately from their current state to a state containing the best
   possible, most modern security practices.  This point is important as
   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



Lebovitz, et al.         Expires April 12, 2011                 [Page 8]


Internet-Draft       KARP Threats and Reqquirements         October 2010


   out places where agreement has been reached on such trade offs.

   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 like cryptographic algorithm agility, replay attacks,
   TCP session resetting in the base TCP-AO protocol before we layer key
   management on top of it.

1.5.  Goals

   The goals and general guidance for the KARP work 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 as explained in the earlier sections.




Lebovitz, et al.         Expires April 12, 2011                 [Page 9]


Internet-Draft       KARP Threats and Reqquirements         October 2010


   3.  The deployability 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 deployability - 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.  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 is 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:

       A. Changing the keys triggers a TCP reset, and thus bounces the
          links/adjacencies, undermining Service Level Agreements
          (SLAs).






Lebovitz, et al.         Expires April 12, 2011                [Page 10]


Internet-Draft       KARP Threats and Reqquirements         October 2010


       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 operational 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-unique 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.

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

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



Lebovitz, et al.         Expires April 12, 2011                [Page 11]


Internet-Draft       KARP Threats and Reqquirements         October 2010


       threats will be addressed completely over time.

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

   8.  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.6.  Non-Goals

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

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

   o  Message content validity (routing database validity).  This work
      is being addressed in other IETF efforts, like SIDR.

1.7.  Audience

   The audience for this document 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 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



Lebovitz, et al.         Expires April 12, 2011                [Page 12]


Internet-Draft       KARP Threats and Reqquirements         October 2010


      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.






































Lebovitz, et al.         Expires April 12, 2011                [Page 13]


Internet-Draft       KARP Threats and Reqquirements         October 2010


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.

   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 classes.  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 send properly MAC'd spoofed packets
      appearing to come from router A to router B, and thus impersonate
      an authorized peer.  The attacker could then send false traffic
      that changes the network behavior from its operator's design.  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



Lebovitz, et al.         Expires April 12, 2011                [Page 14]


Internet-Draft       KARP Threats and Reqquirements         October 2010


      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 an
      attack.

   These attack actions are in scope for this roadmap:

   o  Spoofing - when an unauthorized device assumes the identity of an
      authorized one.  Spoofing can be used, for example, to inject
      malicious 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
      forwarder, and may involve overclaiming, misclaiming, or
      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 the KARP effort.

   o  Interference - when an attacker inhibits the exchanges by
      legitimate routers.  The types of interference addressed by this
      work include:

      A.  Adding noise

      B.  Replaying out-dated packets

      C.  Inserting messages

      D.  Corrupting messages

      E.  Breaking synchronization

      F.  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 spoofed 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 or
      RST packet.  Since this attack depends on spoofing, operators are



Lebovitz, et al.         Expires April 12, 2011                [Page 15]


Internet-Draft       KARP Threats and Reqquirements         October 2010


      encouraged to deploy proper authentication mechanisms to prevent
      such attacks.

   o  DoS attacks using the authentication mechanism - This includes an
      attacker sending packets which confuse or overwhelm a security
      mechanism itself.  An example is initiating an overwhelming load
      of spoofed authenticated route messages so that the receiver needs
      to process the MAC check, only to discard the packet, sending CPU
      levels rising.  Another example is when an attacker sends an
      overwhelming load of keying protocol initiations from bogus
      sources.  All other possible DoS attacks are out of scope (see
      next section).

   o  Brute Force Attacks Against Password/Keys - This includes either
      online or offline attacks where attempts are made repeatedly using
      different keys/passwords until a match is found.  While it is
      impossible to make brute force attacks on keys completely
      unsuccessful, proper design can make such attacks much harder to
      succeed.  For example, the key length should be sufficiently long
      so that covering the entire space of possible keys is improbable
      using computational power expected to be available 10 years out or
      more.  Using per session keys is another widely used method for
      reducing the number of brute force attacks as this would make it
      difficult to guess the keys.

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
   work:

   o  Sniffing - passive observation of route message contents in flight

   o  Falsification by Byzantine sources - unauthorized message content
      by a legitimate authorized source.

   o  Interference due to:

      A.  Not forwarding packets - cannot be prevented with
          cryptographic authentication

      B.  Delaying messages - cannot be prevented with cryptographic
          authentication



Lebovitz, et al.         Expires April 12, 2011                [Page 16]


Internet-Draft       KARP Threats and Reqquirements         October 2010


      C.  Denial of receipt - cannot be prevented with cryptographic
          authentication

      D.  Unauthorized message content - the work of the IETF's SIDR
          working group
          (http://www.ietf.org/html.charters/sidr-charter.html).

      E.  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
          attack that this work will address.  Many other such examples
          could be contrived.







































Lebovitz, et al.         Expires April 12, 2011                [Page 17]


Internet-Draft       KARP Threats and Reqquirements         October 2010


3.  Requirements for Phase 1 of a Routing Protocol Transport's Security
    Update

   The following list of requirements SHOULD be addressed by a KARP Work
   Phase 1 security update to any Routing Protocol (according to section
   4.1 of the KARP Design Guide [I-D.ietf-karp-design-guide] document).
   IT IS RECOMMENDED that any Phase 1 security update to a Rouing
   Protocol contain a section of the specification document that
   describes how each of these requirements are met.  It is further
   RECOMMENDED that textual justification be presented for any
   requirements that are NOT addressed.

   1.   Clear definitions of which elements of the transmission (frame,
        packet, segment, etc.) are protected by the authentication
        mechanism

   2.   Strong algorithms, and defined and accepted by the security
        community, MUST be specified.  The option should use algorithms
        considered accepted by the IETF's Security community, which are
        considered appropriately safe.  The use of non-standard or
        unpublished algorithms SHOULD BE avoided.

   3.   Algorithm agility for the cryptographic algorithms used in the
        authentication MUST be specified, i.e. more than one algorithm
        MUST be specified and it MUST be clear how new algorithms MAY be
        specified and used within the protocol.  This requirement exists
        in case one algorithm gets broken suddenly.  Research to
        identify weakness in algorithms is constant.  Breaking a cipher
        isn't a matter of if, but when it will occur.  It's highly
        unlikely that two different algorithms will be broken
        simultaneously.  So, if two are supported, and one gets broken,
        we can use the other until we get a new one in place.  Having
        the ability within the protocol specification to support such an
        event, having algorithm agility, is essential.  Mandating two
        algorithms provides both a redundancy, and a mechanism for
        enacting that redundancy when needed.  Further, the mechanism
        MUST describe the generic interface for new cryptographic
        algorithms to be used, so that implementers can use algorithms
        other than those specified, and so that new algorithms may be
        specified and supported in the future.

   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
        session MUST NOT be able to be re-sent and accepted during a
        later session.  In OSPF parlance, or other non TCP based



Lebovitz, et al.         Expires April 12, 2011                [Page 18]


Internet-Draft       KARP Threats and Reqquirements         October 2010


        protocols, two routers have a session up if they are able to
        exchange protocol packets.  In OSPF, a session between two
        routers is called an adjacency only if the neighbor FSM is in
        ExStart or a higher state.  An OSPF session between two routers
        must go through two main stages of two-way connectivity and LSDB
        synchronization before an OSPF adjacency is fully established.

   6.   Intra-connection replay protection.  Packets captured during a
        session MUST NOT be able to be re-sent and accepted during that
        same session, to deal with long-lived connections.  The design
        teams may thus want to provide a sufficiently large sequence
        number space for providing intra-connection replay protection.
        Additionally, replay mechanisms MUST work correctly even in the
        presence of Routing Protocol packet prioritization by the
        router.

   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.  Keys need to be changed
        periodically, for operational privacey (e.g. when an
        administrator who had access to the keys leaves an organization)
        and for entropy purposes, and a re-keying mechanism enables the
        deployers to execute the change without productivity loss.

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

   10.  Prevent DoS attacks as those described as in-scope in the
        threats section Section 2.1 above.

   11.  Default mechanisms and algorithms specified and defined are
        REQUIRED for all implementations.

   12.  For backward compatibilty reasons manual keying MUST be
        supported.

   13.  Architecture of the specification SHOULD consider and allow for
        future use of a KMP.

   14.  The authentication mechanism in the Routing Protocol MUST be
        decoupled from the key management system used.  It MUST be
        obvious how the keying material was obtained, and the process



Lebovitz, et al.         Expires April 12, 2011                [Page 19]


Internet-Draft       KARP Threats and Reqquirements         October 2010


        for obtaining the keying material MUST exist outside of the
        Routing Protocol.  This will allow for the various key
        generation methods, like manual keys and KMPs, to be used with
        the same Routing Protocol mechanism.

   15.  Convergence times of the Routing Protocols SHOULD NOT be
        materially affected.  Materially here is defined as anything
        greater than a 5% convergence time increase.  Note that
        convergence is different than boot time.  Also note that
        convergence time has a lot to do with the speed of processors
        used on individual routing peers, and this processing power
        increases by Moore's law over time, meaning that the same route
        calculations and table population routines will decrease in
        duration over time.  Therefore, this requirement should be
        considered only in terms of total number of messages that must
        be exchanged, and less for the computational intensity of
        processing any one message.  Alternatively this can be
        simplified by saying that the new mechanisms should only result
        in a minimal increase in the number of routing protocol messages
        passed between the peers.

   16.  The changes or addition of security mechanisms SHOULD NOT cause
        a refresh of route updates or cause additional route updates to
        be generated.

   17.  Router implementations provide prioritized treatment to certain
        protocol packets.  For example, OSPF HELLO messages and ACKs are
        prioritized for processing above other OSPF packets.  The
        authentication mechanism SHOULD NOT interfere with the ability
        to observe and enforce such prioritization.  Any effect on such
        priority mechanisms MUST be explicitly documented and
        justified.Replay mechanisms provided by the routing protocols
        MUST work even if certain protocol packets are offered
        prioritized treatment.

   18.  The authentication mechanism does not provide message
        confidentiality, but SHOULD NOT preclude the possibility of
        confidentiality support being added in the future.

   19.  Routing protocols MUST only send minimal information regarding
        the authentication mechanisms and the parameters in its protocol
        packets to avoid exposing the information to parties on the
        path.

   20.  In most routing protocols (OSPF, ISIS, BFD, RIP, etc), all
        speakers share the same key on a broadcast segment.  Possession
        of the key itself is used for identity validation and no other
        identity check is used.  This opens a window for an attack where



Lebovitz, et al.         Expires April 12, 2011                [Page 20]


Internet-Draft       KARP Threats and Reqquirements         October 2010


        the sender can masquerade as some other neighbor.  Routing
        protocols SHOULD thus use some other information besides the key
        to validate a neighbor.  One could look at
        [I-D.ietf-opsec-routing-protocols-crypto-issues] for details on
        such attacks.

   21.  Routing protocols that rely on the IP header (or information
        beyond the routing protocol payload) to identify the neighbor
        which originated the packet must either protect the IP header or
        provide some other means to identify the neighbor.
        [I-D.ietf-opsec-routing-protocols-crypto-issues] describes some
        attacks that are based on this.

   22.  The new security and authentication mechanisms MUST support
        incremental deployment.  It will not be feasible to deploy a new
        Routing Protocol authentication mechanism throughout the network
        instantaneously.  It also may not be possible to deploy such a
        mechanism to all routers in a large autonomous system (AS) at
        one time.  Proposed solutions SHOULD support an incremental
        deployment method that provides some benefit for those who
        participate.  Because of this, there are several requirements
        that any proposed KARP mechanism should consider.

        A.  The Routing Protocol security mechanism MUST enable each
            router to configure use of the security mechanism on a per-
            peer basis where the communication is one-on-one.

        B.  The new KARP mechanism MUST provide backward compatibility
            in the message formatting, transmission, and processing of
            routing information carried through a mixed security
            environment.  Message formatting in a fully secured
            environment MAY be handled in a non-backward compatible
            fashion though care must be taken to ensure that routing
            protocol packets can traverse intermediate routers which
            don't support the new format.

        C.  In an environment where both secured and non-secured systems
            are interoperating a mechanism MUST exist for secured
            systems to identify whether an originator intended the
            information to be secured.

        D.  In an environment where secured service is in the process of
            being deployed a mechanism MUST exist to support a
            transition free of service interruption (caused by the
            deployment per se).






Lebovitz, et al.         Expires April 12, 2011                [Page 21]


Internet-Draft       KARP Threats and Reqquirements         October 2010


   23.  The introduction of mechanisms to improve routing authentication
        and security may increase the processing performed by a router.
        Since most of the currently deployed routers do not have
        hardware to accelerate cryptographic operations, these
        operations could impose a significant processing burden under
        some circumstances.  Thus proposed solutions should be evaluated
        carefully with regard to the processing burden they may impose,
        since deployment may be impeded if network operators perceive
        that a solution will impose a processing burden which either
        provokes substantial capital expense, or threatens to
        destabilize routers.

   24.  Given the high number of routers that would require the new
        authentication mechanisms in a typical ISP deployment, solutions
        can increase their appeal by minimizing the burden imposed on
        all routers in favor of confining significant work loads to a
        relatively small number of devices.  Optional features or
        increased assurance that provokes more pervasive processing load
        MAY be made available for deployments where the additional
        resources are economically justifiable.

   25.  The new authentication and security mechanisms should not rely
        on systems external to the routing system (the equipment that is
        performing forwarding).  In order to ensure the rapid
        initialization and/or return to service of failed nodes it is
        important to reduce reliance on these external systems to the
        greatest extent possible.  Therefore, proposed solutions SHOULD
        NOT require connections to external systems, beyond those
        directly involved in peering relationships, in order to return
        to full service.  It is however acceptable for the proposed
        solutions to require post initialization synchronization with
        external systems in order to fully synchronize the security
        information.


















Lebovitz, et al.         Expires April 12, 2011                [Page 22]


Internet-Draft       KARP Threats and Reqquirements         October 2010


4.  Security Considerations

   This document is mostly about security considerations for the KARP
   efforts, both threats and requirements for solving those threats.
   More detailed security considerations were placed in the Security
   Considerations section of the KARP Design Guide
   [I-D.ietf-karp-design-guide] document.












































Lebovitz, et al.         Expires April 12, 2011                [Page 23]


Internet-Draft       KARP Threats and Reqquirements         October 2010


5.  IANA Considerations

   This document has no actions for IANA.
















































Lebovitz, et al.         Expires April 12, 2011                [Page 24]


Internet-Draft       KARP Threats and Reqquirements         October 2010


6.  Acknowledgements

   The majority of the text for version -00 of this document was taken
   from draft-lebovitz-karp-roadmap, authored by Gregory Lebovitz.















































Lebovitz, et al.         Expires April 12, 2011                [Page 25]


Internet-Draft       KARP Threats and Reqquirements         October 2010


7.  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-00-00 original rough rough rough draft for review by routing
   and security AD's

   karp-threats-reqs-00-

   o removed all the portions that will be covered in either
   draft-ietf-karp-design-guide or draft-ietf-karp-framework







































Lebovitz, et al.         Expires April 12, 2011                [Page 26]


Internet-Draft       KARP Threats and Reqquirements         October 2010


8.  References

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

8.2.  Informative References

   [I-D.ietf-karp-design-guide]
              Lebovitz, G. and M. Bhatia, "Keying and Authentication for
              Routing Protocols (KARP) Design Guidelines",
              draft-ietf-karp-design-guide-01 (work in progress),
              September 2010.

   [I-D.ietf-karp-framework]
              Atwood, W. and G. Lebovitz, "Framework for Cryptographic
              Authentication of Routing Protocol Packets on the Wire",
              draft-ietf-karp-framework-00 (work in progress),
              February 2010.

   [I-D.ietf-opsec-routing-protocols-crypto-issues]
              Jaeggli, J., Hares, S., Bhatia, M., Manral, V., and R.
              White, "Issues with existing Cryptographic Protection
              Methods for Routing Protocols",
              draft-ietf-opsec-routing-protocols-crypto-issues-07 (work
              in progress), August 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



Lebovitz, et al.         Expires April 12, 2011                [Page 27]


Internet-Draft       KARP Threats and Reqquirements         October 2010


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

   [RFC5796]  Atwood, W., Islam, S., and M. Siami, "Authentication and



Lebovitz, et al.         Expires April 12, 2011                [Page 28]


Internet-Draft       KARP Threats and Reqquirements         October 2010


              Confidentiality in Protocol Independent Multicast Sparse
              Mode (PIM-SM) Link-Local Messages", RFC 5796, March 2010.

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

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










































Lebovitz, et al.         Expires April 12, 2011                [Page 29]


Internet-Draft       KARP Threats and Reqquirements         October 2010


Authors' Addresses

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

   Email: gregory.ietf@gmail.com


   Manav Bhatia
   Alcatel-Lucent
   Bangalore,
   India

   Phone:
   Email: manav.bhatia@alcatel-lucent.com


   Russ White
   Cisco Systems
   USA

   Phone:
   Email: russ@cisco.com

























Lebovitz, et al.         Expires April 12, 2011                [Page 30]


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