[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01                                                         
Network Working Group                                           JJ. Puig
Internet-Draft                                               M. Achemlal
Expires: July 2, 2005                                           E. Jones
                                                            D. McPherson
                                                            January 2005

          Generic Security Requirements for Routing Protocols

Status of this Memo

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   and any of which I become aware will be disclosed, in accordance with
   RFC 3668.

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

   Internet-Drafts 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 July 2, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2005).  All Rights Reserved.


   Routing protocols are subject to threats and attacks that can harm
   individual users or network operations as a whole.  This document
   describes a generic set of security requirements for routing
   protocols and routing systems.

Puig, et al.              Expires July 2, 2005                  [Page 1]

Internet-Draft    Routing Protocols Security Requirements   January 2005

Table of Contents

   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   4

   2.   Terminology  . . . . . . . . . . . . . . . . . . . . . . . .   5
     2.1  Path . . . . . . . . . . . . . . . . . . . . . . . . . . .   5
     2.2  Destination  . . . . . . . . . . . . . . . . . . . . . . .   5
     2.3  Route Property / Route Attribute (RP / RA) . . . . . . . .   5
     2.4  Forwarders . . . . . . . . . . . . . . . . . . . . . . . .   5
     2.5  Neighbors / Peers / Adjacent Routers . . . . . . . . . . .   5
     2.6  Propagators  . . . . . . . . . . . . . . . . . . . . . . .   5
     2.7  Route / Routing Information (RI) . . . . . . . . . . . . .   6
     2.8  Route correctness  . . . . . . . . . . . . . . . . . . . .   6
     2.9  Route validity . . . . . . . . . . . . . . . . . . . . . .   6
     2.10   Routing Function . . . . . . . . . . . . . . . . . . . .   7
     2.11   Routing Decision Process . . . . . . . . . . . . . . . .   7
     2.12   Forwarding Function  . . . . . . . . . . . . . . . . . .   7

   3.   General Requirements . . . . . . . . . . . . . . . . . . . .   8

   4.   Threats Importance . . . . . . . . . . . . . . . . . . . . .   9
     4.1  Threats Consequences . . . . . . . . . . . . . . . . . . .   9

   5.   Security Requirements  . . . . . . . . . . . . . . . . . . .  11
     5.1  Requirements Against Overclaiming  . . . . . . . . . . . .  11
     5.2  Requirements Against Misclaiming . . . . . . . . . . . . .  13
     5.3  Requirements Against Misstatement  . . . . . . . . . . . .  14
     5.4  Requirements Against Spoofing  . . . . . . . . . . . . . .  17
     5.5  Requirements Against Overload  . . . . . . . . . . . . . .  18
     5.6  Requirements Against Interference  . . . . . . . . . . . .  19
     5.7  Requirements Against Deliberate Exposure . . . . . . . . .  21
     5.8  Requirements Against Sniffing  . . . . . . . . . . . . . .  21
     5.9  Requirements Against Traffic Analysis  . . . . . . . . . .  22

   6.   Living with Byzantine Failures . . . . . . . . . . . . . . .  24
     6.1  The Byzantine Problem  . . . . . . . . . . . . . . . . . .  24
     6.2  Byzantine General Requirements . . . . . . . . . . . . . .  24
     6.3  Detection of the Occurrence of a Byzantine Failure . . . .  25
     6.4  Byzantine Detection  . . . . . . . . . . . . . . . . . . .  25
     6.5  Byzantine Robustness . . . . . . . . . . . . . . . . . . .  26

   7.   Security Techniques for Routing  . . . . . . . . . . . . . .  27
     7.1  Techniques when Originating  . . . . . . . . . . . . . . .  27
     7.2  Techniques when Propagating  . . . . . . . . . . . . . . .  29
     7.3  Security of the Functional Parts . . . . . . . . . . . . .  31
     7.4  Date and Time Issues . . . . . . . . . . . . . . . . . . .  34

   8.   Local Security . . . . . . . . . . . . . . . . . . . . . . .  35

Puig, et al.              Expires July 2, 2005                  [Page 2]

Internet-Draft    Routing Protocols Security Requirements   January 2005

     8.1  Active Participation to Security . . . . . . . . . . . . .  35
     8.2  Local Resources Considerations . . . . . . . . . . . . . .  36

   9.   Inter-Domain Routing Issues  . . . . . . . . . . . . . . . .  40
     9.1  Legitimacy . . . . . . . . . . . . . . . . . . . . . . . .  40
     9.2  Propagating policies . . . . . . . . . . . . . . . . . . .  41
     9.3  Coherence  . . . . . . . . . . . . . . . . . . . . . . . .  41
     9.4  Confidentiality  . . . . . . . . . . . . . . . . . . . . .  41
     9.5  Agreements involving operators . . . . . . . . . . . . . .  41

   10.  Security Considerations  . . . . . . . . . . . . . . . . . .  43

   11.  References . . . . . . . . . . . . . . . . . . . . . . . . .  44
   11.1   Normative References . . . . . . . . . . . . . . . . . . .  44
   11.2   Informative References . . . . . . . . . . . . . . . . . .  44

        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  45

   A.   Acknowledgments  . . . . . . . . . . . . . . . . . . . . . .  46

   B.   Revision History . . . . . . . . . . . . . . . . . . . . . .  47
     B.1  Changes from draft-puig-rpsec-generic-requirements-02  . .  47
     B.2  Changes from draft-puig-rpsec-generic-requirements-01  . .  47
     B.3  Changes from draft-puig-rpsec-generic-requirements-00  . .  47

        Intellectual Property and Copyright Statements . . . . . . .  48

Puig, et al.              Expires July 2, 2005                  [Page 3]

Internet-Draft    Routing Protocols Security Requirements   January 2005

1.  Introduction

   Routing protocols are subject to threats and attacks that can harm
   individual users or network operations as a whole.  This document
   describes a generic set of security requirements for routing
   protocols and routing systems.

   Along with the "Generic Threats to Routing Protocols" document
   [THREATS], this work is designed to serve as a reference material for
   current routing protocols and routing systems analysis, for
   extensions design, and as a guidance for designing new, more secure,
   routing protocols and routing systems.

   This document discusses generic requirements for routing protocols,
   used for both interdomain and intradomain routing.  Host to router
   and multicast routing protocols, specifically, are out of scope.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in [KEYWORDS].

   Security terms are explained in [SEC-GLOSS].

   This document has the following layout:

   o  Section 2 defines terms used within this document.

   o  Section 3 presents general requirements to the security of routing
      protocols and routing systems.

   o  Section 4 sorts by importance threats defined in [THREATS].

   o  Section 5 defines generic security requirements.

   o  Section 6 provides guidance for tackling the Byzantine problem.

   o  Section 7 describes techniques for routing security.

   o  Section 8 presents security considerations for the routing device.

   o  Section 9 introduces the inter-domain puzzle.

Puig, et al.              Expires July 2, 2005                  [Page 4]

Internet-Draft    Routing Protocols Security Requirements   January 2005

2.  Terminology

   The following terms will be used in this document:

2.1  Path

   A path is a list of successive forwarders through which a destination
   may be reached.

2.2  Destination

   Destination refers here either to a physical network or to a prefix,
   as announced in the routing protocol.  Thus destination is only a
   'hint' about eventual destination of user's traffic.

2.3  Route Property / Route Attribute (RP / RA)

   Routing protocols also distribute information associated with the
   destination (ex: number of hops).  A minimum set of such properties
   may be mandatory in order to avoid loops within the routing system.

   Any router, while propagating routing information, may add, remove or
   update route attributes.

2.4  Forwarders

   Forwarders are either mentioned as a route attribute, or assumed to
   be the peers through which the routes were acquired.

   Forwarders are expected to be the first elements of paths providing
   packet forwarding to the destination mentioned in the route, with the
   associated properties.

2.5  Neighbors / Peers / Adjacent Routers

   The terms "neighbors", "peers", "adjacent routers" all refer to
   routers which can communicate directly over the transport subsystem.

2.6  Propagators

   Propagators are participants to the routing protocol.  They relay the
   routing information between networks.  They may also modify the
   routing information before relaying ( / flooding / re-advertising)

   Propagators are usually set on transit networks, not on stub

Puig, et al.              Expires July 2, 2005                  [Page 5]

Internet-Draft    Routing Protocols Security Requirements   January 2005

2.7  Route / Routing Information (RI)

   Routing protocols enable routers to exchange routes or routing

   Routes include at least the description of a destination and
   associated route properties.  At least one forwarder is mentioned in
   -or associated with- the route.

2.8  Route correctness

   A "correct" route is such that:

   1.  it exists at least one path to the destination from each system
       listed as a suitable forwarder.

   2.  (locally known) route properties are compatible with local
       mandatory policy requirements for the destination.

   Note: This definition of correctness is local to this document; a
   minimal definition would only address the 2nd issue, while a stronger
   one would also require knowledge that route properties are consistent
   with actual paths properties.

   According to this definition, there is no way to be sure a route is
   correct or not when routing decision must be taken.  Thus, we will
   consider that a route is correct when the router has been 'convinced'
   of this correctness.

   This 'conviction' should result from a trust measure on the way the
   route was acquired (ex: route signed by a business partner, static
   input from the management plane).

2.9  Route validity

   A "valid" route is such that:

   o  packets forwarded to any adequate forwarder follow a path up to

   o  (locally known) route properties are honored on the path and
      compatible with local mandatory policy requirements.

   Note: According to this definition of route validity, there is no way
   to know a route is valid when routing decision is taken.  There is
   also no certainty of knowing afterward that a route was valid or not.
   This definition underlines the uncertain nature of any communication
   though it should not be considered as `petitio principii'.

Puig, et al.              Expires July 2, 2005                  [Page 6]

Internet-Draft    Routing Protocols Security Requirements   January 2005

2.10  Routing Function

   In this document, the routing function is a process which returns the
   available routes for a packet destination.

2.11  Routing Decision Process

   In this document, the routing decision process selects a route from
   the set returned by the routing function or cancels forwarding.

   Many criteria may influence selection (ex: packets source).  In the
   field, respective rules of the routing function and of the routing
   decision process may be less strict.

2.12  Forwarding Function

   The forwarding function performs actual forwarding according to data
   installed by the routing decision process.

Puig, et al.              Expires July 2, 2005                  [Page 7]

Internet-Draft    Routing Protocols Security Requirements   January 2005

3.  General Requirements

   Routing protocols are responsible for distributing information about
   reachability to destinations attached to the network.

   First main requirement is:

   MR(1) Correct routes SHOULD be made available for the routing

   MR(1.a) When a route is unavailable or incorrect, the first main
      requirement means that a correct route SHOULD be made available,
      either through the use of the routing protocol or from the
      management plane.

   MR(1.b) When a route is available and correct, the first main
      requirement means that misuse of the routing protocol SHOULD NOT
      jeopardize the route availability or correctness, as this would
      also compromise correct routing.

   Note: the first main requirement does not preclude acquisition of
   routes whose correctness cannot be established, if available.  It
   only sets a priority to both availability and correctness of routes.

   Second main requirement is:

   MR(2) The routing function MUST recognize and select correct routes
      if available for the packet properties.  If such routes are
      unavailable or partly incorrect, severed routing processing MAY be
      investigated, according to a heuristic learnt from the management
      plane.  Eventually, if it is decided that no forwarding will be
      achieved, the packet MUST be discarded or rejected according to
      local policy (this SHOULD be configurable).

   MR(2.a) Packet properties analyzed by the decision process MAY
      include other information than destination address.

   Note: the second main requirement does not preclude forwarding when
   full correctness or availability of routes cannot be achieved.  It
   also focuses more on the eventual forwarding than on routing.

   Routing protocols functions and misuses are documented in [THREATS].

   Most (but not all) subsequent requirements are meant to raise the
   confidence that correct routes are available when required by the
   routing function.

Puig, et al.              Expires July 2, 2005                  [Page 8]

Internet-Draft    Routing Protocols Security Requirements   January 2005

4.  Threats Importance

   In the [THREATS] document, threats are described according to their
   sources, their consequences, and eventually the behaviors -referred
   as "actions"- which enable sources to trigger consequences.

4.1  Threats Consequences

   In an economical perspective, primary concern is about the
   consequences and their potentiality for damages.  We will elaborate
   requirements according to the following classification of
   consequences, sorted by importance order:

   i - Usurpation.  Damages cost resulting from usurpation may be
      extreme and may only be roughly estimated.  Besides, usurpation
      often enables the attacker to proceed with subsequent
      consequences.  For these reasons, usurpation is the top issue.

   ii - Deception.  Deception will partly result in the same damages as
      usurpation and is thus an important consequence.

   iii - Disruption.  Disruption is a significant consequence, but its
      range and period are usually limited and damages cost can be
      evaluated more accurately than for previous consequences.
      However, actions leading to disruption should be difficult enough
      to achieve so that disruption does not become a common event.
      Beyond a certain threshold (depending on frequency, duration,
      range and overall context), disruption may become more significant
      than usurpation or deception.

   iv - Disclosure.  The above consequences directly jeopardize the
      services expected to be provided by the routing system.
      Reliability and availability of the routing system is usually
      considered more important than confidentiality of the routing
      information (which is not `user data' per se and may be learnt by
      other means).  In current protocols, it is unlikely that
      disclosure of routing information will lead to direct damages on
      routing services as a result of the information leak.  In this
      context, concealing the services properties in order to protect
      against disclosure is not a priority.  However, it is worth
      preventing against disclosure of information which would enable
      the attacker to trigger usurpation, deception or disruption
      (in-band plain text passwords are likely to be such pieces of

   Security requirements deal with prevention against the conditions of
   consequences.  This prevention may be against the existence of threat
   sources or against the occurrence of threat actions (attacks).

Puig, et al.              Expires July 2, 2005                  [Page 9]

Internet-Draft    Routing Protocols Security Requirements   January 2005

   Subversion of the routing system may be very easy if an attacker has
   the ability to attack the physical link between two routers, or
   individual routers.  Techniques that harden any of these points of
   attack can make attacking the routing system harder, but we consider
   these outside the scope of this document.

   We are thus primarily interested in the threat actions that result in
   usurpation, secondarily in those that result in deception, thirdly in
   disruption, lastly in disclosure.

Puig, et al.              Expires July 2, 2005                 [Page 10]

Internet-Draft    Routing Protocols Security Requirements   January 2005

5.  Security Requirements

   In this section, we explore the requirements which will help in
   tackling the actions leading to the consequences of concern.  First
   set of requirements addresses prevention against usurpation.

5.1  Requirements Against Overclaiming

   "Overclaiming occurs when a subverted router advertises its control
   of some network resources, while in reality it does not, or the
   advertisement is not authorized" [THREATS].

   Overclaiming is a threat from an originating router; it affects the
   data plane of the routing protocol.

   Main issue with overclaiming is checking resources control or
   advertisement authorization.  Several models may be designed to
   counter overclaiming; these models address the delegation and the
   authorization of network resources ownership, control and

   Delegation allows for an entity to delegate a property in part or
   entirely to another entity (ex: owner of some network resources
   delegates ownership of a part of resources to another entity, which
   in turn becomes owner of this part).

   Authorization allows for an entity to grant rights on network
   resources.  An owner of some network resources grants control of
   resources to a controller; A controller of some network resources
   grants authorization of advertisement to an advertiser.

   In the field, depending on the context and on the instance of the
   routing protocol, status of owner, controller and advertiser does not
   necessarily imply separate entities.  The same entity may own and
   control the resources; the same device may have been granted control
   and advertisement.

   Whatever the model representation, a chain of variable length
   involving delegation and authorization of some network resources
   ownership, control and advertisement may exist.  Overclaiming is a
   violation of the logic stated in this chain for these specific

   However, such a logic is also limited:

   o  In specific contexts (ex: inter-domain routing, ad-hoc routing),
      giving birth to such a chain for any network resource may be much
      too complex (it may yet be possible on a limited basis).

Puig, et al.              Expires July 2, 2005                 [Page 11]

Internet-Draft    Routing Protocols Security Requirements   January 2005

   o  The destination announced may get modified by routers during
      normal routing operations (ex: re-advertising with a shorter
      prefix); this allows for reducing the overall amount of routing
      information and to lessen its impact on bandwidth, storage and on
      routing function algorithms.  On the other hand, this also
      legitimates overclaiming, and once original information is lost,
      it gets far harder to provide any trust measure regarding the new
      routing information.  In such a situation, the usefulness of the
      chain is unclear because it may or may not state anything about
      the new super-set of network resources.

   For these reasons, subsequent requirements are limited to the case in
   which the chain exists.  The nature (hierarchical, relational, etc.)
   of the architectural scheme from which the chain is extracted is
   outside the scope of this documentation.  Furthermore, the following
   requirements DO NOT make any statement about what should be done with
   -out of the chain- unauthenticated information (discard, install with
   lower preference, use it for the sake of the routing protocol but not
   for user traffic...  cf.  Section 7.3.3).

   R(1.1) Integrity, data origin authenticity, validity at current date
      and availability of nodes of the chain of delegation and
      authorization of a specific resource ownership, control and
      advertisement MUST be provided when such a chain exists.

      This expands to:

   R(1.1.a) It MUST be possible to check that a routing device is
      currently authorized to advertise some network resources.

   R(1.1.b) It MUST be possible to check that the entity which (directly
      or indirectly) granted the right of advertisement actually and
      currently controls the corresponding network resources.

   R(1.1.c) It MUST be possible to check that the entity which (directly
      or indirectly) granted the control actually and currently owns the
      corresponding network resources.

   R(1.1.d) It MUST be possible to check that delegation between
      entities is actually and currently valid.

   R(1.2) Consumers and propagators of routing information MUST check
      backward the chain of delegation and authorization of resource
      advertisement, control and ownership.

   R(1.2.a) Check depth MUST be sufficient according to the context in
      which the routing protocol instance is in use and to the locally
      available information.

Puig, et al.              Expires July 2, 2005                 [Page 12]

Internet-Draft    Routing Protocols Security Requirements   January 2005

   Requirement R(1.1.c) MAY be limited to the scope in which the routing
   protocol instance is in use.

   Requirements R(1.1*) imply the use of a time scale for date validity.
   Further discussion on this topic is presented in Section 7.4

   Requirement R(1.2.a) allows for using the same chain at different
   scales.  In internal routing operations, a router will check the
   chain up to the routing system controller (of which it should already
   be aware), while in external routing operations, a router will check
   the entire chain or rely on the knowledge that the check was done by
   another edge router of the same system.  It is also possible to
   establish several steps of "internal" and "external" routing with
   regard to this specific topic.

   When convergence is achieved,

   -  if verifiable information is available, overclaiming can be
      thwarted by the requirement of checking that the routing device is
      authorized to advertise by an administrative entity which was
      given control of the according network resources by their owner;
      in such a context, authenticated information should take
      precedence over any unauthenticated information.

   -  if no verifiable information is available, then overclaimed
      information is all what the device can get.  What to do with it is
      a local policy matter.

   Practical considerations related to these requirements are presented
   in Section 7.1.

   Further elements regarding this topic are presented in Section 9.

5.2  Requirements Against Misclaiming

   "A misclaiming threat is defined as an action where an attacker is
   advertising its authorized control of some network resources in a way
   that is not intended by the authoritative network administrator"

   Misclaiming is a threat from an originating router; it affects the
   data plane of the routing protocol.

   In our approach, the authoritative network administrator is a
   resource controller, higher in the chain of delegation and
   authorization than the routing device.  Misclaiming is a corruption
   of properties applying to the resources as intended by their
   controller (cf.  Section 5.1 for further information regarding this

Puig, et al.              Expires July 2, 2005                 [Page 13]

Internet-Draft    Routing Protocols Security Requirements   January 2005


   R(2.1) Integrity, data origin authenticity, validity at current date
      and availability of the properties applying to the advertised
      resources MUST be provided.

   R(2.2) Consumers and propagators of routing information MUST check
      that properties applying to the advertised resources are
      effectively related to the resources and as intended by the
      resources controllers.

      Requirements R(1.*) also apply.

   Misclaiming is thwarted by the requirement of checking that the
   properties are tied to the advertised resources and are intended by
   their controller.

   Practical considerations related to these requirements are presented
   in Section 7.1.

5.3  Requirements Against Misstatement

   Misstatement "is defined as an action whereby the attacker describes
   route attributes in an incorrect manner" [THREATS].  The attacker
   acts on attributes through deletion, insertion and substitution of
   data.  He may also replay out-dated data.

   Misstatement is a threat from subverted links and subverted
   forwarding devices; it affects the data plane of the routing
   protocol.  However, a message replay may also be considered as a
   control plane violation.

   There is an additional difficulty in cases in which correct operation
   of the routing protocol requires updates of a set of route
   attributes.  This is a common situation in vector protocols.

   We thus define the following classification of route attributes
   (where route attributes are defined in Section 2):

   o  Route attributes intended by their originator to be consumed by
      and to reach adjacent nodes unmodified: "constant, not propagated
      route attributes".

   o  Route attributes intended by their originator to keep constant
      values and to be propagated by adjacent nodes: "constant,
      propagated route attributes".

   o  Route attributes intended by their originator to reach adjacent

Puig, et al.              Expires July 2, 2005                 [Page 14]

Internet-Draft    Routing Protocols Security Requirements   January 2005

      nodes unmodified and to be propagated after an update:
      "updateable, propagated route attributes".

   Lastly, any router can add or delete route attributes.

5.3.1  Constant, not propagated route attributes

   These route attributes must reach adjacent nodes unmodified.
   Possible attackers are: compromised links, subverted forwarding
   devices, masquerading routers.

   This threat results from a lack of data integrity, data origin
   authentication and replay protection.  Protection of data between
   adjacent nodes, especially anti-replay, has a tendency to focus on
   session management and on control plane.

   The following requirements CAN be addressed either:

   o  at the control plane level,

   o  by the transport subsystem (the preferred way),

   o  at the data plane level.

   A routing protocol design SHOULD mention at which level these
   requirements are fulfilled:

   R(3.1) Evidence of integrity and authenticity of data exchanged
      between neighbors SHOULD be provided; this evidence SHOULD be
      dependant on data destination.  When the evidence applies on data
      description (as opposed to applying on a per-message basis), it
      SHOULD also be dependant on the resource the route attributes
      apply to.

   R(3.1.a) It SHOULD NOT be possible to impersonate a neighbor.  That
      is: authentication of neighbors SHOULD depend on a a-priori
      knowledge (a public key, a shared secret, knowledge of a direct
      connection in a common technical room, etc).  This dependency MUST
      be documented in the protocol design.

   R(3.2) Upon reception, data integrity and authenticity SHOULD be
      checked.  This check SHOULD also include data destination and,
      when the check applies directly on data description (as opposed to
      applying on a per-message basis), that route attributes apply to
      appropriate resources.

Puig, et al.              Expires July 2, 2005                 [Page 15]

Internet-Draft    Routing Protocols Security Requirements   January 2005

   R(3.3) The routing protocol SHOULD be protected against the damages
      resulting from data replay.  This CAN be done either by preventing
      replays effectiveness (ex: through integrity protected sequence
      numbers) or by reducing replays incidence on data (ex: through
      lifetime limitation of data).

   Practical considerations related to these requirements are presented
   in Section 7.2.

5.3.2  Constant, propagated route attributes

   These route attributes must be propagated but not updated.  Given
   requirements R(3.[1-3]) above, possible remaining attackers are:
   subverted propagating devices.

   The threat here results from a lack of route attributes integrity,
   origin authentication and lifetime limitation.  When propagated,
   information protection has a tendency to apply directly at the data
   plane level.

   R(3.4) Integrity, data origin authenticity and validity at current
      date of constant, propagated route attributes MUST be provided.
      The evidence MUST depend on the resource the route attributes
      apply to and on the identity of the node which add these specific
      route attributes.

   R(3.4.a) This CAN be done in such a way that deletion, insertion or
      substitution of route attributes will invalidate the whole routing
      information or a set of route attributes when checked.

   R(3.5) Consumers and propagators of routing information MUST check
      that constant, propagated route attributes apply to the resources
      and are the ones intended by the entity which set them.

   R(3.6) Route attributes validity MUST be lifetime limited.

   Requirement R(3.4) addresses protection against unauthenticated
   insertion and substitution, and against partial deletion of a route

   However, full protection against deletion further depends on how
   route attributes and resources are related, and if propagators are
   allowed to delete route attributes: this is the scope of requirement
   R(3.4.a).  A design may apply different treatments on route
   attributes which "must" be propagated and on route attributes which
   "can" be propagated or discarded along the routing protocol'
   propagation path.  The latter must not invalidate routing information
   when deleted.  In a sense, requirement R(3.4.a) manages a way for

Puig, et al.              Expires July 2, 2005                 [Page 16]

Internet-Draft    Routing Protocols Security Requirements   January 2005

   more complex route attributes propagation management.  Further
   considerations regarding this topic are not addressed in this

   Requirement R(3.6) set a lifetime on the evidences, not on route
   attributes themselves.

   Practical considerations related to these requirements are presented
   in Section 7.1.

5.3.3  Updateable, propagated route attributes

   These route attributes must be propagated and updated.  Given
   requirements R(3.[1-3]) above, possible remaining attackers are:
   subverted propagating devices.

   The threat here results from the absence of any verifiable history of
   route attributes updates.  In the absence of any data trace-ability,
   it is difficult to figure out if a misstatement occurred.

   For this reason, unless route attributes are expanded in such an
   history and each update meets requirements for constant, propagated
   route attributes, we can reach to no strong requirement here.

   However, depending on the semantic of specific route attributes,
   routers MAY evaluate whether values are realistic or not.

5.4  Requirements Against Spoofing

   "Spoofing occurs when an illegitimate device assumes the identity of
   a legitimate one" [THREATS].

   Spoofing is possible because of a lack of combined integrity and data
   origin authentication.  When considered an attack per se, spoofing is
   a threat on routing protocol control plane operations.  It threatens
   neighbor relationship formation and state maintenance.

   R(4.1) Requirements R(1.*) and R(3.[1-3]) also address spoofing.

   R(4.1.a) In the context of spoofing, an emphasis SHOULD be made on
      the transport subsystem or on the control plane when interpreting
      requirements R(3.[1-3]).

   It is often adequate to elect an appropriate transport subsystem
   which would provide functionalities against spoofing (cf.  Section

   Requirements R(1.*) through R(4.*) aim at preventing against

Puig, et al.              Expires July 2, 2005                 [Page 17]

Internet-Draft    Routing Protocols Security Requirements   January 2005

   usurpation and deception.  Following requirements address disruption
   and usurpation.

5.5  Requirements Against Overload

   "Overload is defined as a threat action whereby attackers place
   excess burden on legitimate routers" [THREATS].

   Overload is a threat from subverted links or devices.  It may affect
   the data plane of the routing device, eg.  as the result of link
   overload.  It may also affect the control plane of the routing
   device, eg.  by leading the victim router to use all its
   computational resources.

   It is unlikely that the design of the routing protocol will suffice
   to prevent against this threat.  However, the routing device may also
   include some functions which would limit the negative consequences of
   this threat (cf.  Section 8).

   At the routing protocol control plane, the following options are

   R(5.1) Fast rejection schemes based on tokens or cookies MAY be used.
      Such functionalities MAY be provided by the transport subsystem.

   R(5.2) Above requirements regarding neighbors authentication may
      result in expensive computational checks at the control plane,
      even though authentication may also be of great help against data
      plane overload resulting from malicious messages injected on the
      link.  A design SHOULD consider and document opportunities of
      overloads resulting from protection against usurpation and

   R(5.3) The routing protocol operations SHOULD NOT suppose the
      full-time availability of material (eg: a registry) whose
      reachability depends on the forwarding service achieved by other

   R(5.4) The routing protocol design SHOULD limit the amount of traffic
      needed for correct operation.  This is greatly dependant on the
      context in which the protocol operates.  This also implies rate
      control of messages sent for session setup (or recovery) when
      starting-up (or rebooting).

   Requirements R(5.[1-2]) suppose that authorized neighbors messages
   can be authenticated, which helps rejecting attackers solicitations.
   Further cautions are nonetheless required against neighbors acting in
   a Byzantine manner.

Puig, et al.              Expires July 2, 2005                 [Page 18]

Internet-Draft    Routing Protocols Security Requirements   January 2005

5.6  Requirements Against Interference

   "Interference is a threat action where an attacker uses a subverted
   link or router to inhibit the exchanges by legitimate routers"

   Interference is a general threat which can be perpetrated through:

   -  Noise addition

   -  Packets replay

   -  Denial of forwarding

   -  Denial of receipts

   -  Delay of responses

   -  Break of synchronization

   -  Slow down of exchanges

   -  Flapping

   Noise addition, where it affects integrity of routing exchanges, is
   addressed by requirements against misstatements R(3.*).  Where it
   affects the link layer or other traffic, the nature of the threat
   changes to break of synchronization, overload, etc.

   Packets replay is addressed by requirements against misstatements

   Denial of forwarding (of routing protocol messages, or of lower level
   datagrams, packets or frames) cannot be countered.  However, it can
   be detected if the emitter expects an evidence of correct reception
   (eg: reliable transport), though it is difficult in such a case to
   make the difference with a denial of receipt (cf.  R(6.1.*) below).

   Denial of receipts can be detected; even if it may prove to be
   difficult to figure out the cause of the threat.

   R(6.1.a) An implementation SHOULD revise the level of confidence
      (preference, trust, stability...  whatever) associated with
      destinations whose first hop is a neighbor with which has been
      detected occurrence of denial of forwarding or denial of receipt.

Puig, et al.              Expires July 2, 2005                 [Page 19]

Internet-Draft    Routing Protocols Security Requirements   January 2005

   R(6.1.b) The protocol design MAY affect the way these data are
      represented, and allow for signaling / sharing stability / trust

   R(6.1.c) Denial of forwarding or of receipts may result in breaking
      the states associated with neighbors sessions.  Active mechanisms
      (ex: an in-band echo) MAY be used in order to detect such an
      anomaly and to set a threshold for an automatic state hygiene
      maintenance and for confidence revision.  Section 8.2 presents
      resources consumption in details.

   Delaying responses beyond a certain threshold is likely to break
   neighboring relationship, because a routing protocol implementation
   should time out a neighboring relationship beyond such a threshold
   (cf.  synchronization breaks, R(6.2)).  Behind the threshold,
   delaying may result in the same consequences as a slow down of
   exchanges (cf.  R(6.3)).

   There are no way of preventing against breaks of synchronization from
   subverted links or routers.  However:

   R(6.2) Protocol design MUST take into account possible breaks of
      synchronization, even when the threat may only be accidental and
      improbable.  State hygiene and computation of confidence level
      SHOULD be affected by the detection of such breaks.

   Slow down of exchanges may be subjective.  It is likely to affect
   pace to convergence (either in a positive or a negative way), but
   slow down may also be a 'natural event', when traffic or processing
   is high, when queues are filling up, etc.

   R(6.3) 'Reactivity' of neighbors, possibly with knowledge of the
      traffic load on the link, MAY be a variable of the heuristic
      function which computes confidence associated with a neighbor or a
      particular piece of routing information.

   Flapping of routing information is a significant source of
   instabilities on global routing.  It may be difficult to prevent
   against flapping which results from a subverted routing device.
   However, a routing device SHOULD lower the disturbance from this
   event on the network.

   R(6.4) Routing information flapping SHOULD be detected through
      routing databases survey.  Propagation of possibly flapping
      information SHOULD be dampened through appropriate rate control of
      routing information propagation.

   Instabilities of particular pieces of routing information may get

Puig, et al.              Expires July 2, 2005                 [Page 20]

Internet-Draft    Routing Protocols Security Requirements   January 2005

   absorbed through information reduction; as an instance, announcing a
   shorter prefix may hide the flapping on a particular route with a
   longer prefix.  Information reduction, on the other hand, reduces
   traceability of information (cf.  Section 5.1, Section 5.3.3).

   With the general threat of interference, the routing decision process
   is deemed to make choices based on a heuristic evaluation of the
   confidence associated with a particular neighbor or piece of routing
   information.  Requirements R(6.[1-3]) DO NOT prevent against threats
   actions, but aim at evaluating the cost of trust as associated with a
   link or a neighbor.  The device may then allocate resources,
   invalidate routing information, etc., according to the confidence
   measure.  This is not conditions prevention; this is consequences

   Last sections address requirements against disclosure.

5.7  Requirements Against Deliberate Exposure

   "Deliberate Exposure occurs when an attacker takes control of a
   router and intentionally releases routing information directly to
   devices that, otherwise, should not receive the exposed information"

   Deliberate exposure is an information leak about the routing system.
   Yet, it is unclear to which extend it affects the routing protocol.
   If neighbors take the exposure into account, then it turns to
   actually be a spoofing threat, and actual consequence is deception.

   There is no way a local instance of the routing protocol may protect
   against this action if the attacker achieves full control of the

   This threat may be limited by hardening access to the router,
   enforcing privilege separations, validating through external devices
   on the link, etc.  This is not directly related to the routing

5.8  Requirements Against Sniffing

   "Sniffing is an action whereby attackers monitor and/or record the
   routing exchanges between authorized routers.  Attackers can use
   subverted links to sniff for routing information" [THREATS].

   As mentioned in the threat document, confidentiality is not generally
   a design goal of routing protocols.  However, confidentiality may be
   desirable when collecting votes (Byzantine participants may observe
   others votes and set their alignment so that majority is impossible

Puig, et al.              Expires July 2, 2005                 [Page 21]

Internet-Draft    Routing Protocols Security Requirements   January 2005

   or lead to future consequences; on the other hand, clear text
   communications may also help detecting failures).

   R(8.1) A routing protocol design process SHOULD investigate the needs
      for confidentiality.  Conclusions from this process MAY be

   R(8.2) A routing protocol CAN optionally provide confidentiality.
      This SHOULD be implemented on the transport subsystem unless
      otherwise justified (eg.  it is also possible to provide optional
      and partial confidentiality at the data plane level, or to conceal
      only a subset of messages).

   R(8.3) When confidentiality is in scope, deployment, scalability and
      performance issues related to it's use SHOULD be studied and the
      conclusions documented.

5.9  Requirements Against Traffic Analysis

   "Traffic analysis is an action whereby attackers gain routing
   information by analyzing the characteristics of the data traffic on a
   subverted link" [THREATS].

   Even if the confidentiality of the routing traffic is activated, the
   attacker may access some routing information by analyzing the
   characteristics of data traffic.

   Protections against traffic analysis include traffic flow
   confidentiality (TFC) (inter-times padding, data padding &
   compression, generation of dummy packets) and anonymity.  Currently,
   these functionalities are scarcely used on the Internet and often
   oppose provision of quality of service.

   Protecting only the routing protocol against traffic analysis is
   insufficient because analysis of user traffic will also leak
   information about the topology and paths properties.

   R(9.1) When user traffic is protected against traffic analysis, the
      routing protocol operations SHOULD investigate the use of a TFC &
      anonymity enabled transport subsystem shared with user traffic.
      Design of the routing protocol SHOULD be independent of this
      operational consideration, unless goal of the protocol is to set
      up the traffic flow concealing and 'anonymizing' network used by
      the transport subsystem.

Puig, et al.              Expires July 2, 2005                 [Page 22]

Internet-Draft    Routing Protocols Security Requirements   January 2005

   R(9.2) When TFC & anonymity are among the design goals of the routing
      protocol, their effects on performance and correct operations of
      the routing system MUST be documented.

Puig, et al.              Expires July 2, 2005                 [Page 23]

Internet-Draft    Routing Protocols Security Requirements   January 2005

6.  Living with Byzantine Failures

6.1  The Byzantine Problem

   "A node with a Byzantine failure may corrupt messages, forge
   messages, delay messages, or send conflicting messages to different
   nodes" [BYZANTINE].  These faults may arise from routers which have
   been subverted by an attacker or which have faulty hardware or
   software [THREATS]; as a consequence, many threats are also Byzantine
   failures.  The Byzantine general problem resolution is limited by
   hypotheses which are reminded here.

   Byzantine resistance includes detection of Byzantine failures,
   Byzantine detection and Byzantine robustness, where the two latter
   are not necessarily correlated.  Next section gives a thorough
   description of these forms of resistance.

   The following main requirements aim at helping in the design of a
   Byzantine resistant routing protocol:

   MR(3.1.a) Local instance of the protocol SHOULD NOT rely on correct
      operation of any particular neighbor.

   MR(3.1.b) Operations associated with a particular neighbor SHOULD
      always apply a least privilege policy.

   MR(3.1.c) Only traffic source and destination SHOULD be considered

   MR(3.2) Messages MUST be authenticated when sent and checked for
      their authenticity when received (cf.  also R(3.[1-3]).  Use of
      cryptography simplifies the Byzantine problem.

6.2  Byzantine General Requirements

   Classical hypotheses for Byzantine failure resolution are:

   -  devices are fully connected,

   -  the decision that must be agreed upon is binary (yes/no),

   -  the network is synchronous,

   -  strictly less than a third of the devices are faulty.

   Under these hypotheses, a distributed algorithm requires as many
   rounds as the number of faults to be tolerated plus one.

Puig, et al.              Expires July 2, 2005                 [Page 24]

Internet-Draft    Routing Protocols Security Requirements   January 2005

   Further information about distributed agreement can be found in
   [CONSENSUS].  In the following, we will only focus on what makes the
   problem tractable in IP networks.

   The ability to send messages to all neighbors simultaneously allow
   for simulation of both full connectivity and synchronization.  The
   fact that routing information is not a agreeable binary decision has
   little consequences because agreement is not an absolute requirement;
   see Section 6.5 and [BYZANTINE].

6.3  Detection of the Occurrence of a Byzantine Failure

   The protocol algorithm may detect incoherences within the correlated
   routing information upon algorithm termination, abnormal attractive
   cycles within routes computations, etc.  These events may be symptoms
   of a Byzantine failure occurring.  More trivial evidences of a
   possible Byzantine failure is when agreement, termination or validity
   of the consensus cannot be achieved.

   R(10.1) It SHOULD be possible to derive from a routing protocol
      design a set of coherence and sanity checks.  The routing protocol
      documentation SHOULD mention directions when incoherence occurs,
      and describes reactions which are of direct impact on the protocol

6.4  Byzantine Detection

   Byzantine detection is much more accurate than just detecting a
   Byzantine failure and consists in the ability to find out which
   participants are subverted.  A part of inherent risk of Byzantine
   detection is that when the number of traitors grow past a limit, it
   may be difficult for a device to figure out which group is subverted.
   Sometimes, the considered device may be itself -or conclude it is
   itself- faulty.

   R(11.1) When Byzantine detection is achieved, automatic responses MAY
      be triggered in order to prevent Byzantine nodes from damaging
      operation of the routing protocol.

   R(11.1.a) Automatic responses following a Byzantine detection MUST
      NOT prevent subverted devices from participating again when they
      cease to behave incorrectly.

   R(11.1.b) Automatic responses following a Byzantine detection MUST
      NOT deceive non-faulty neighbors in concluding that responding
      devices are Byzantine nodes.

Puig, et al.              Expires July 2, 2005                 [Page 25]

Internet-Draft    Routing Protocols Security Requirements   January 2005

   Possible automatic responses that may be investigated are the
   simulation of a link shutdown, setup of adequate local policies,
   quarantine cell.  Collaborative approach between detectors to limit
   the influence of some subverted devices may be quite hazardous.

   Either at the database maintenance level or at the routing decision
   process level, the following SHOULD be configurable when dealing with
   a detected subverted device:

   R(11.2.a) "Detour": Allow or deny forwarding along an alternate route
      (if available), possibly on a path for which a "lower quality"
      (much many hops, longer delay, etc) is probable.  The routing
      protocol instance MAY also seek actively after an alternate route.

   R(11.2.b) "Send & Hope": Allow forwarding to the subverted device
      anyway or,

   R(11.2.c) "Discard": Treat destination as unreachable.

   Eventually, note that sharing symmetric material for partial
   authentication between more than two devices would make Byzantine
   detection impossible to achieve in most cases (and so would do the
   absence of any authentication mechanism).

6.5  Byzantine Robustness

   Purpose of Byzantine robustness, in the general problem context, is
   for any given device to achieve algorithm termination, agreement and
   -naturally- validity.  This does not imply Byzantine detection.

   However, in the routing context, what matters really is routing
   information correctness (cf.  Section 3):

   R(12.1) Routing protocols do NOT REQUIRE to achieve agreement.

   R(12.2) Routing protocols do NOT REQUIRE to terminate; in fact, it is
      generally expected that they will not terminate during normal

   Some routing protocols operates in context for which reachability is
   more important than attributes associated with the destination.  In
   such scenarii, Byzantine robustness aims at protecting reachability.
   This manages opportunities for "severed configurations" in which some
   local policy requirements for a traffic could not be enforced though
   reachability is still possible / probable (Remember that what is
   often expected on the Internet is a high probability of packet

Puig, et al.              Expires July 2, 2005                 [Page 26]

Internet-Draft    Routing Protocols Security Requirements   January 2005

7.  Security Techniques for Routing

7.1  Techniques when Originating

   When originating, security requirements have a tendency to focus on
   the data plane.  Indeed, data will further get propagated through the
   network, out of originator's control.  Security mechanisms addressing
   the control side will have no control on the way data are eventually
   propagated.  Moreover, believing that other devices will propagate
   the information unmodified is naive.  As an instance, aggregation or
   filtering may be threats against resources' properties.

   As a consequence, it is important to know whether the originated
   information is authentic or not.  Even though trusting
   unauthenticated information may appear to be a necessity in some
   scenarios, it is useful to set such a distinction on information so
   as to derive a confidence level associated with it.  In order to
   allow for origin authentication, information may be considered as a
   kind of 'record', composed of sections of the kind:

   o  Network resources description

   o  Related properties set by resources' controller.

   o  Integrity and data-origin authenticity evidence of information,
      provided by the controller of the resources.  This evidence should
      be lifetime limited.

   o  Properties set by propagators of routing information (possibly
      with a time-limited authenticity evidence).

   If propagators discard authenticity evidence, then the information
   should acquire a lower preference level.

   The division presented in Section 5.1 between the controller and the
   advertiser allows for granting the advertising device with a very
   limited control on what is advertised; this is an interesting
   protection against potential damages resulting from possible
   advertiser's subversion.

   The concept of an authorization chain linking ownership, control and
   advertisement is nonetheless necessary in order to build confidence
   between neighbors from different organizations.  An issue with this
   kind of model is the need for a definition (or furthermore: a
   specification and an allocation scheme) of identities.

   Obviously, on a large scale, this kind of data protection requires
   public key operations, regardless of the actual technology eventually

Puig, et al.              Expires July 2, 2005                 [Page 27]

Internet-Draft    Routing Protocols Security Requirements   January 2005

   used (authorization tokens, digital signature).  There are quite a
   lot of drawbacks associated with cryptography in general and with
   public key cryptography in particular.

   Where these drawbacks affect devices, an increase amount of memory is
   needed for buffering cryptographic information and for caching (cf.
   next paragraph).  Besides, public key operations are also quite CPU
   consuming.  A performance study SHOULD be pursued when designing a
   routing protocol using cryptography; threats opened because of crypto
   processing SHOULD NOT nullify the interest of tackling routing
   threats which would result in comparable consequences (eg.
   disruption).  A performance study often requires hypotheses on the
   underlying hardware, which is somewhat restricting but necessary.

   Where these drawbacks concern the overall architecture, they involve
   deployment, administration and public information reachability
   issues.  Regarding this latter topic, in-band or stand-alone channels
   are necessary for the provision of public data, for revocation and
   for key roll-over.  A routing protocol may find itself in a dead-end
   if such a channel is needed for authenticity check of data which are
   necessary to enable access to the ad-hoc channel.  This is a tricky
   point, which may claim for a distributed caching mechanism.  Caching
   is all the more important when scalability is a significant issue and
   when centralization of data creates bottleneck; on the other hand,
   the whole architecture is less reactive in case revocation or key
   roll-overs are required, even though soft key transitions should not
   be necessary in this context.

   Further in this direction, neighbors' public material may be kept in
   non-volatile storage for recovery.  There may be no routes available
   in order to retrieve this material after a reboot, though in-band
   provisioning within the routing protocol is also a possibility.

   Whatever the path taken by an architecture specification, it's
   resistance against trivial denial of services must be evaluated.

   Requirements related to this section are R(1.*), R(2.*), R(3.[4-6]).

   All cryptographic material MUST have their lifetime limited, and both
   evaluated in terms of time and in terms of amount of data.

   Public keys strength is a matter of context: in inter-domain
   operations, one may expect that public material will not change very
   often, and then such a material should be significantly strong.
   Locally, the rate of public material updates may depend on
   administrator's decision; he alone evaluates the risks for the
   network and the administrative cost.  In a conference, people may
   build a ephemeral network by exchanging public material on an direct

Puig, et al.              Expires July 2, 2005                 [Page 28]

Internet-Draft    Routing Protocols Security Requirements   January 2005

   IR link before roaming and participating in ad-hoc routing through
   wireless links; public material is such a case would only be used a
   few hours and may be kept voluntarily weak.

7.2  Techniques when Propagating

   When propagating, security requirements have a tendency to focus on
   the control plane.  Propagation security is that of entities
   communicating in a direct fashion (and perhaps interactively) over
   the transport subsystem.  In such a situation, we're concerned with:

   o  Integrity: data integrity between neighbors is an obvious
      requirement.  Note that error detection and correction codes are
      not integrity evidences.  Means to achieve integrity are
      signed-hash and keyed-hash.  Data integrity is always closely
      related to authenticity.

   o  Authenticity: the above feature is of no use without
      authentication of the information producer.  Authenticating
      correctly the messages sent from neighbors is one of the most
      important security requirement.  Authentication techniques that
      can be considered are: digital signature, keyed hash.

   o  Anti-replay: comes here mainly for protection against active
      attacks from subverted Links, though this feature will also
      provide protection against 'natural' packets duplication.  Note
      that underlying layers may provide an unauthenticated anti-replay
      feature, which would be of no use from a security point of view
      unless it gets also authenticated.  Authentication of routing
      exchanges sequence numbers may bring this kind of protection to
      the protocol.

   Other features include confidentiality and traffic flow
   confidentiality, which are generally out of scope in routing
   protocols (cf.  R(8.*) and R(9.*)).

   Main differences with origin-based security practices presented in
   the previous section include:

   o  message oriented protection (as opposed to data protection),

   o  messages are addressed (to one or many peers),

   o  messages are limited in time through anti-replay techniques (as
      opposed to limited lifetime),

   o  neighbors may use symmetric cryptography.

Puig, et al.              Expires July 2, 2005                 [Page 29]

Internet-Draft    Routing Protocols Security Requirements   January 2005

   The above characteristics may be implemented by the routing protocol,
   or by the transport subsystem.  In this latter case, a specification
   MUST document which security properties are provided by the transport
   subsystem, which are provided by the routing protocol and,
   eventually, how they interact.

   Note that transport subsystems may experience evolutions; as a
   trivial instance, one may design a routing protocol which will run on
   wire Ethernet (802.3) with the hypothesis that physical and logical
   access to layer 2 infrastructure is under control.  Such an
   hypothesis may no longer be suitable on wireless Ethernet (802.11).

   Further protection may include range limiting features, enabled by
   the use of special addresses (link-local, limited broadcast,
   multicast) or of counter-based schemes (TTL).  Most of these features
   are provided by adequate transport subsystems.

   Specific issues for communications between neighbors include:

   o  Address protection: sometimes extra care is needed against
      transport subsystem's address spoofing, even though an identity
      has been defined at an upper layer.  Address protection requires
      inclusion of the address in the integrity and authenticity
      evidence computation.  [AH] may be seen as an instance of a
      protocol with built-in address spoofing protection.

   o  In 'one to many' communication contexts, sharing symmetric
      material opens opportunities for damages resulting from subverted

   o  Interactivity involves managing sessions and keeping states
      associated with neighbors.  For the sake of state hygiene,
      reactivity of neighbors SHOULD be evaluated.  This calls for
      setting delays threshold, using keep alive / heart beat mechanisms
      and explicitly tearing sessions down.

   o  Participants are vulnerable to direct computational harassment,
      against which DOS mitigation mechanisms are necessary.  These
      include puzzles, cookies, tokens chains.

   Requirements related to this section are R(1.*), R(3.[1-3]) and
   R(4.*).  Section 5.3.3 is also related to this section.

   When possible, methods to derive a symmetric key from public
   exponents should be used, given that the symmetric cryptography
   operations considered are less computationally expensive.  Caution
   should be taken if the number of devices sharing the same symmetric
   key is greater than two.

Puig, et al.              Expires July 2, 2005                 [Page 30]

Internet-Draft    Routing Protocols Security Requirements   January 2005

   Limiting keys lifetime and refreshing them is merely cryptographic
   hygiene.  Therefore, a refresh mechanism is REQUIRED both for public
   keys and for session keys; Public keys may not require a soft
   transition, while refreshing session keys may require to move from
   the old key to the new one with no session interruption.  For session
   keys, lifetime SHOULD be evaluated both in terms of time and of
   amount of data.

   Actual mechanisms used to limit key lifetime MAY either be based on
   an explicit lifetime associated with key (ex: public key bundled with
   a validity date) or on roll-over.  Both MAY be used simultaneously
   for different purposes within a single system.

7.3  Security of the Functional Parts

   The threats document [THREATS] introduces a set of functions commonly
   shared by routing protocols: the transport subsystem, the neighbor
   state maintenance function and the database maintenance function.

   Each of these functions may contain inner security weaknesses and
   simultaneously a potential for providing adequate security services
   for the interest of operation of the whole system.

   In the following sections, the security related parts of these
   functions are explored.

7.3.1  Transport Subsystem

   "The routing protocol transmits messages to its neighbors using some
   underlying protocol.  For example, OSPF uses IP, while other
   protocols may run over TCP" [THREATS].

   One may design a routing protocol independent -to a certain extent-
   from a specific transport subsystem, by requiring the availability of
   a minimal set of capabilities from this subsystem.

   Yet, relevant, specific capabilities of a transport subsystem SHOULD
   be exploited by a routing protocol.  An adequate transport subsystem
   provides capabilities which would be cumbersome if included in the
   routing protocol itself and have been -ideally- thoroughly tested.
   This is a net gain in complexity, even though at the expense of added
   complexity on protocol interactions and addresses resolution

   FR(T.1) A routing protocol specification SHOULD document which
      capabilities of the transport subsystem are exploited by the
      routing protocol.

Puig, et al.              Expires July 2, 2005                 [Page 31]

Internet-Draft    Routing Protocols Security Requirements   January 2005

   FR(T.2) Where issues may arise from interactions between the
      transport subsystem and the routing protocol, the specification
      MUST mention these issues (The "Security Considerations" section
      may be the appropriate place for IETF/IRTF documents).

   The transport subsystem may already provide the following properties:

   o  Neighbors discovery and maintenance: A given Transport Subsystem
      technology may provide a way to discover and communicate with
      adjacent devices participating in the routing domain (neighbors).
      This is a critical property.

   o  Range limitation: the subsystem may provide a way to limit
      propagation of messages outside a certain range and in the same
      way limit intrusions from outsiders in the neighborhood.  This may
      be achieved either through the use of an appropriate layer
      (likely, link layer), through special addresses (limited
      broadcast, multicast, link-local, site-link, etc.), through
      conditions expressed on TTL (see also [BTSH]).  This provides a
      limited access control to neighborhood (yet, there are ways around
      these limitations: VLAN frames hopping, tunneling).

   o  Separate control channel: if the underlying technology provides
      separated channels for control traffic and user data traffic, this
      may help against DOS against the routing protocol.  Such control
      channels may be provided via the same Link Layer infrastructure,
      or perhaps via a distinct network.

   o  Integrity: While the Transport Subsystem chosen by the routing
      protocol designer may provide error detection code, this does not
      provide data integrity from a security point of view.  The
      Transport Subsystem may also provide data integrity which will
      still be useless from a security perspective if the secret
      material used by the data integrity service cannot be tied to the
      routing protocol participant identity.

   o  Authenticity: if the underlying layer both provides authenticity
      and integrity, many routing threats may be thwarted.  Further
      investigations are required though, among which are studies of
      resistance to replay, performance, Byzantine detection and
      robustness, etc.  In such a case, the documentation of the routing
      protocol MUST state which security properties are provided by the
      Transport Layer, which are provided by the routing protocol design
      and eventually how they interact (cf.  FR(T.2)).

   o  Address spoofing protection: the subsystem is protected against
      address spoofing if integrity and authenticity evidence covers
      also the address.

Puig, et al.              Expires July 2, 2005                 [Page 32]

Internet-Draft    Routing Protocols Security Requirements   January 2005

7.3.2  Neighbor State Maintenance

   "Neighboring relationship formation is the first step for topology
   determination.  For this reason, routing protocols may need to
   maintain state information.  Each routing protocol may use a
   different mechanism for determining its neighbors in the routing
   topology.  Some protocols have distinct exchanges through which they
   establish neighboring relationships, e.g., Hello exchanges in OSPF"

   Specifications MAY document the use of cookies or damping mechanisms
   in order to protect this function from trivial denial of services.

7.3.3  Database Maintenance

   "Routing protocols exchange network topology and reachability
   information.  The routers collect this information in routing
   databases with varying detail.  The maintenance of these databases is
   a significant portion of the function of a routing protocol"

   From a local perspective, and with a selfish point of view, database
   maintenance is what really matters for a particular device.

   For this reason, resources SHOULD be 'flagged' according to trust,
   stability, quality...  scales.

   Coherence of information MAY be checked actively (with probes) and
   passively (observation of user traffic).  In ad-hoc contexts,
   database may also be fed reactively.  Such mechanisms MAY affect
   gently resources flags, according to the reliability of information
   acquired in this way.  In some cases, it may prove advisable to
   consider these hints as bonus for the information preference (as an
   instance, when destinations are overclaimed, detecting dead networks
   behind the large prefix should not result in depreciating the
   overclaimed information [this is open to discussion, of course]).  Fail-back Procedures

   When detecting obvious routing misbehavior which result from misuse
   of the routing protocol, but when sources responsible for this
   misbehavior cannot be identified, fail-back procedures MAY be
   attempted, based on previous recorded states, fail-safe states or
   heuristics on the routing information and on trust.  Degradation of
   the service should often be better than no service at all, thus the
   device may adjust local route costs information when such events
   occur.  The routing protocol design may document guidelines and
   requirements on such procedures.

Puig, et al.              Expires July 2, 2005                 [Page 33]

Internet-Draft    Routing Protocols Security Requirements   January 2005

   Network management MUST be able to install unalterable (static)
   routes to allow debugging network problems without interference from
   routing protocols.  Such routes may be pre-configured and loaded upon
   detection of abnormal behaviors (flapping...).

7.4  Date and Time Issues

Puig, et al.              Expires July 2, 2005                 [Page 34]

Internet-Draft    Routing Protocols Security Requirements   January 2005

8.  Local Security

8.1  Active Participation to Security

   Topics presented within this section may not be directly tied to the
   protocol design.  However, it addresses several local considerations
   that are requirements for a secure operation of the routing protocol
   and of the device it is running on.

8.1.1  Checking

   A routing device may be configured to run extra checks on the routing
   state, like checking databases against previous information.  Some
   active tests may also be triggered, possibly involving device's
   neighbors.  High caution should be taken regarding implementation of
   such features and they should not jeopardize the routing protocol

8.1.2  Reporting

   A set of error messages may be designed in order to report detection
   of failures to other participants.  Locally, a set of auditable
   events MUST be defined.  Auditable Events

   The following events should be audited:

   1.  Authentication failure

   2.  Required public information (keys, authority) is not available

   3.  Errors reported by forwarders

   4.  Detection of a Byzantine event

   5.  Detection of a rebooting peer

8.1.3  Reacting  Filtering

   Upon detection of subverted devices, a process may enforce security
   procedures such as ingress filtering or participant exclusion.

   A routing device MAY be set to drop/reject routing messages if these
   are incorrect with current configuration of the network, e.g.  if

Puig, et al.              Expires July 2, 2005                 [Page 35]

Internet-Draft    Routing Protocols Security Requirements   January 2005

   they do not belong to the correct range of the IGP, etc.

   Note that this protection is topological and partial.  Extreme care
   should be taken not to jeopardize correct behavior of the protocol.  Correcting

8.2  Local Resources Considerations

   Even though this document addresses routing protocols, these cannot
   operate without a platform of hardware and software to support them.
   All the resources belonging to this platform form what is generally
   referred to as a router.  Thus, routers comprise all local resources
   of a routing daemon participating in a routing session.

   This section will first highlight critical underlying components and
   their security issues regarding Denial of Service (DoS)
   vulnerabilities and then suggest suitable routing protocols'
   requirements addressing these issues.

8.2.1  Denial of Service Attacks

   The Computer Emergency Response Team (CERT) defines in [DOS] Denial
   of Service attacks as being explicit attempts by attackers to prevent
   legitimate users of a service from using that service.  Denial of
   Service attacks can be launched against a target for the mere purpose
   of preventing the victim from using a resource or can be a component
   of a greater attack that may ultimately aim at stealing information.

   A modern router is a complex system made of several hardware and
   software components that interact in the effort to serve the general
   purpose of routing as defined in Section 3.  All of these components
   are finite resources and therefore intrinsically prone to Denial of
   Service.  The impact of Denial of Service attacks on certain local
   resources can be critical for the routing protocols running on them.

8.2.2  Hardware Resources

   Almost every hardware component in a router is essential to the
   correct functioning of the local instances of the various routing
   protocols that run on it, for example - trivially speaking - without
   power no packets will be routed.  Among others buffers/queues and CPU
   cycles are two of the less obvious resources that are critical for
   routing protocols.  Buffers/Queues

   Buffers are widely used in hardware to store information that needs

Puig, et al.              Expires July 2, 2005                 [Page 36]

Internet-Draft    Routing Protocols Security Requirements   January 2005

   to be aggregated or delayed before being consumed.  In general once a
   buffer is full every subsequent object that needs to be stored in
   that queue will simply be discarded.  Depending on what messages are
   discarded, the consequences of dropping information for routing
   protocols can vary from negligible to critical.

   Since all messages exchanged between participants to a routing
   session need to reach the control-plane, the queues and buffers that
   support this link are critical for routing protocols.  Often people
   are deceived by thinking that the throughput of a switching fabric is
   roughly the amount of bandwidth needed to launch a DoS attack against
   a given router; in reality, routers have smaller bandwidth links
   toward the control plane.  The goal of an attacker could be easier in
   terms of resources, if he/she were to attempt to exhaust the buffers
   and queues on the link to the control plane with bogus control plane
   packets rather than trying to congest the resources serving the
   switching fabric.  The goal of such attacks would be to cause queues
   and buffers to drop legitimate routing messages together with bogus
   ones.  CPU Cycles

   Processors units, and in particular Network Processors (NPs), are a
   valuable resource that can perform predetermined sets of operations
   during a single cycle.  Generally speaking, CPU cycles are a finite
   resource that is shared among many different processes, some of these
   being instances of routing protocols.  As a consequence of
   congestion, and from an oversimplified point of view, some processes
   may be put "on hold" until more CPU cycles are available, or every
   process may be "starved a bit".  Both scenarios may cause great
   damage to interactive processes.  In particular routing protocols'
   instances may enter critical states where a timely reaction to an
   event is necessary but not available.

   In general the more a CPU serves an heterogeneous pool of processes,
   the easier it will be for an attacker (or a faulty router) to find a
   single service/process that will exhaust a significant portion of the
   available CPU cycles, denying service to other processes, such as
   routing.  Buffer/Queues and CPU Cycles Requirements

   Routing messages SHOULD be identifiable as coming from legitimate
   participants in their routing session before being directed towards
   the control-plane.

   If any rate limiting mechanism is intended by the routing protocol to
   mitigate congestion of control-plane links, said solution MUST be

Puig, et al.              Expires July 2, 2005                 [Page 37]

Internet-Draft    Routing Protocols Security Requirements   January 2005

   designed ensuring that an attacker cannot directly exploit it in the
   attempt to block a legitimate routing peer from exchanging routing
   messages.  Bandwidth

   Routing protocols are based on the exchange of information between
   the participants to a session over network links.  A link's bandwidth
   is finite critical resource that, if starved, can lead to Denial of
   Service attacks on the routing protocols.  If a link is not
   malfunctioning, and neglecting transmission errors, then DoS attacks
   on a link's bandwidth can only take place at the link's ends.  A
   router may receive an aggregate of traffic higher than it can be
   forwarded by a given output interface, or a receiving router may not
   be capable of handling the current load of traffic incoming on a
   given interface due to an internal scheduling priority problem or
   because it entered a critical or unknown state.  General Mitigation Techniques

   Some mitigation techniques can be deployed to limit the exhaustion of
   bandwidth between two routing peers; two current examples are:
   ingress filtering, as described in [FILTERING], and solutions that
   rely on Quality of Service mandating that the highest priority and
   availability be assigned to routing messages.  Bandwidth Requirements

   Routing protocols MUST be designed to easily inter-work with lower
   layers Quality of Service mechanisms.

8.2.3  Logic (Software) Resources

   Similarly to hardware resources, logic resources can be finite and
   therefore exhausted thus affording attackers with the possibility of
   launching Denial of Service attacks.  Databases are critical
   resources for every routing protocol and they may contain information
   about link-state, direct neighbors, active peers, external routes
   database, etc...

   Routing databases have a maximum number of entries that can be stored
   in them and this is generally not defined by the routing protocols.
   This upper bound can be set by an administrator through a
   configuration parameter or can be restricted only by the hardware
   memory available to the routing platform.  Either way, when this
   limit is approaching, for any of the databases maintained by a
   routing protocol, some action must be taken.

Puig, et al.              Expires July 2, 2005                 [Page 38]

Internet-Draft    Routing Protocols Security Requirements   January 2005  Logic (Software) Requirements

   Routing protocols MUST mandate verification of every piece of
   information that can be verified before committing it to any
   underlying database.

   Every piece of information that cannot be verified by the routing
   protocol immediately MUST be marked as temporary and means should be
   provided, by the routing protocol itself, to keep track of these
   entries, verify and discard them as soon as possible.

   Every piece of information that cannot be verified by the routing
   protocol MUST be installed in the apposite database with the minimum
   time to live compatible with its function.

   Routing protocols MUST provide mechanisms for routing platforms'
   databases, in overflow state, to discard information that will cause
   minimum possible disruption to the routing session.

   Routing protocols SHOULD be designed as to incorporate feed-back
   solutions from databases approaching overflow state so that
   mitigative actions can be taken.

   Routing protocols SHOULD be designed with the concept of graceful
   degradation in mind in order to better survive in case any of the
   underlying databases approaches or enters overflow state.

Puig, et al.              Expires July 2, 2005                 [Page 39]

Internet-Draft    Routing Protocols Security Requirements   January 2005

9.  Inter-Domain Routing Issues

9.1  Legitimacy

   An important issue in inter-domain routing is legitimacy for claiming
   network resources.  In fact, this is where confidence edifice starts.
   Requirements R(1.*) are related to this topic, though they do not
   address some decisions.

   Parts of these decisions regard routes specialization.

   Hierarchical addressing is necessary in order to aggregate entries in
   local routing tables; this reduces tables size and improve general
   performances, even though this may threaten performances on a
   specific path.  When preferred (eg.  for confidentiality reasons),
   some specific routes may appear in the table.  A problem with
   hierarchical addressing is that, when used as such in the routing
   protocol, it may generate resources masking.  This is especially
   obvious with operations like aggregations of destinations or removal
   of a specific destination: both these operations will result in the
   generic entry taking over the specific one.

   These operations may be considered as a violation of ownership,
   though it is also unclear whether a shorter prefix ownership should
   -administratively speaking- involve authority on a corresponding
   longer prefix.

   On the other hand, if care is taken within the routing protocol to
   protect specific routes against overclaiming resulting from
   aggregations or removal, then this involves extra architecture
   requirements and more bandwidth get consumed in routing protocol

   Besides, this will not prevent routing tables from aggregating or
   removing entries, and this kind of decorrelation between routing
   information and the way packets get actually forwarded may not be
   desirable, even though loose relation between local routing tables
   and routing information is common.

   Another part of the problem is public information reachability.

   When public material may help in establishing right to claim
   resources, availability of the required material is problematic.
   Section 7.1 presents this in further details.  With regard to public
   cryptography, it should be clear that a light paradigm
   (authorizations ?) would better fit in most cases, though third
   parties also appear to be a necessity at this point.

Puig, et al.              Expires July 2, 2005                 [Page 40]

Internet-Draft    Routing Protocols Security Requirements   January 2005

9.2  Propagating policies

   Policy propagation within a routing protocol which operates between
   administrative routing domains, exterior gateway protocols, is very
   difficult.  This particular area of security is fraught with
   difficulties making it next to impossible to actually secure policy
   across multiple administrative domains.

   Since each administrative domain can add policies to a given route,
   anyone can essentially insert any policy.  Even if a full history of
   policies is available, the question: "Who's policy are we honoring ?"
   has to be answered.  The originator's policy ? Or the AS we received
   the route from ? Or the AS that currently has the route ? Or some
   other AS ?

9.3  Coherence

   Where domains are multi-homed, should operations of the edge routers
   be coherent ? In a nutshell: should a domain be considered as a
   stand-alone, non-schizophrenic, entity ? Note that coherence does not
   preclude edge routers from behaving differently.

9.4  Confidentiality

   As was mentioned several times previously, confidentiality is usually
   not a design goal of routing protocols.  In inter-domain operations,
   enabling confidentiality would require finding a balance between
   information that is required to be publicly available and information
   whose concealing is desirable.  May be a possible path is not to care
   about concealing destination info, but about properties applying to
   resources.  Yet, the value of a route without knowledge of according
   properties is certainly dubious.

9.5  Agreements involving operators

   Secure EGPs operations will require kind of agreements between the
   involved parties.  Though operators may achieve these agreements on a
   case by case basis, this is unlikely to be effective in the field.
   Emergence of trusted third parties upon which would rely the
   diffusion of public key material and relations to prefix ownership
   would fit better.

   Another question is whether these pieces of information must be tied
   with public information related to the system ownership, such as the
   organization name.  This may lead to specific routing policies or
   abuses that would introduce more complexity.

   Access control also imply agreements: who's granted right to

Puig, et al.              Expires July 2, 2005                 [Page 41]

Internet-Draft    Routing Protocols Security Requirements   January 2005

   participate to the protocol ?

Puig, et al.              Expires July 2, 2005                 [Page 42]

Internet-Draft    Routing Protocols Security Requirements   January 2005

10.  Security Considerations

   This entire draft RFC is security related.  Specifically it addresses
   security of routing protocols and routing systems as associated with
   requirements to those protocols and systems.  In a larger context,
   this work builds upon the recognition of the IETF community that
   signaling and control/management planes of networked devices need
   strengthening.  Routing protocols and routing systems can be
   considered part of that signaling and control plane, may be the most
   important.  However, to date, these protocols and systems have
   largely remained unprotected and opened to malicious attacks.  This
   document discusses routing protocol and routing system security
   requirements as we know them today and lays the foundation for the
   design of new, more secure, routing protocols and systems.

Puig, et al.              Expires July 2, 2005                 [Page 43]

Internet-Draft    Routing Protocols Security Requirements   January 2005

11.  References

11.1  Normative References

   [AH]       Kent, S. and R. Atkinson, "IP Authentication Header", RFC
              2402, November 1998, <www.ietf.org/rfc/rfc2402.txt>.

   [DAMPING]  Villamizar, C., Chandra, R. and R. Govindan, "BGP Route
              Flap Damping", RFC 2439, November 1998, <www.ietf.org/rfc/

              Ferguson, P. and D. Senie, "Network Ingress Filtering:
              Defeating Denial of Service Attacks which employ IP Source
              Address Spoofing", BCP 38, RFC 2827, May 2000,

              Bradner, S., "Key Words for Use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997,

              Shirey, R., "Internet Security Glossary", RFC 2828, May
              2000, <www.ietf.org/rfc/rfc2828.txt>.

11.2  Informative References

   [BTSH]     Vijay, G., Heasley, J. and D. Meyer, "The BGP TTL Security
              Hack (BTSH)", Internet Draft; version 02, May 2003,

              Perlman, R., "Network Layer Protocols with Byzantine
              Robustness",  , August 1988, <www.vendian.org/mncharity/

              Coulouris, G., Kindberg, T. and J. Dollimore, "Distributed
              Systems: Concepts and Design", Addison Wesley ISBN -
              0201619180, 2000 September.

   [DOS]      CERT, "Denial of Service Attacks", June 2001,

   [SMITH]    Smith, R. and al., "Securing Distance-Vector Routing
              Protocols",  Symposium on Network and Distributed System
              Security , February 1997, <www.isoc.org/isoc/conferences/

Puig, et al.              Expires July 2, 2005                 [Page 44]

Internet-Draft    Routing Protocols Security Requirements   January 2005


   [THREATS]  Barbir, A., Murphy, S. and Y. Yang, "Generic Threats to
              Routing Protocols", Internet Draft; version 06, April
              2004, <www.ietf.org/internet-drafts/

Authors' Addresses

   Jean-Jacques Puig
   CNRS / UMR 5157 (Samovar) / Piece A-108
   9, Rue Charles Fourier
   Evry  91011

   Phone: +33 1 60 76 44 65
   Fax:   +33 1 60 76 47 11
   EMail: jean-jacques.puig@int-evry.fr
   URI:   http://www-lor.int-evry.fr/~puig/

   Mohammed Achemlal
   France Telecom R & D

   EMail: mohammed.achemlal@francetelecom.com

   Emanuele Jones
   Alcatel Canada - R&I - Security group
   600 March Road
   Kanata, ON  K2K 2E6

   Phone: +1 613 784 5977
   Fax:   +1 613 784 8944
   EMail: emanuele.jones@alcatel.com

   Danny McPherson
   Arbor Networks

   EMail: danny@arbor.net

Puig, et al.              Expires July 2, 2005                 [Page 45]

Internet-Draft    Routing Protocols Security Requirements   January 2005

Appendix A.  Acknowledgments

   The authors would like to acknowledge the suggestions and
   contributions of:

   o  Russ White - CISCO

Puig, et al.              Expires July 2, 2005                 [Page 46]

Internet-Draft    Routing Protocols Security Requirements   January 2005

Appendix B.  Revision History

B.1  Changes from draft-puig-rpsec-generic-requirements-02

   Further development on requirements.  Incorporation of off-list
   comments.  Deletion of solution space paragraphs.

B.2  Changes from draft-puig-rpsec-generic-requirements-01

   TOC tweaking.  Phrasing simplifications.  Development of the

B.3  Changes from draft-puig-rpsec-generic-requirements-00

   Full TOC change.

Puig, et al.              Expires July 2, 2005                 [Page 47]

Internet-Draft    Routing Protocols Security Requirements   January 2005

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at

Disclaimer of Validity

   This document and the information contained herein are provided on an

Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Puig, et al.              Expires July 2, 2005                 [Page 48]