Network Working Group                                           JJ. Puig
Internet-Draft                                               M. Achemlal
Expires: October 18, 2004                                       E. Jones
                                                            D. McPherson
                                                          April 19, 2004


          Generic Security Requirements for Routing Protocols
                draft-puig-rpsec-generic-requirements-02

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   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.

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

   The list of current Internet-Drafts can be accessed at http://
   www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on October 18, 2004.

Copyright Notice

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

Abstract

   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 October 18, 2004                [Page 1]


Internet-Draft    Routing Protocols Security Requirements     April 2004


Table of Contents

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

   2.  General Requirements . . . . . . . . . . . . . . . . . . . . .  6

   3.  Threats Importance . . . . . . . . . . . . . . . . . . . . . .  9
     3.1   Threats Consequences . . . . . . . . . . . . . . . . . . .  9
     3.2   Threats Actions  . . . . . . . . . . . . . . . . . . . . . 10
     3.3   Damages  . . . . . . . . . . . . . . . . . . . . . . . . . 11

   4.  Elements of Routing  . . . . . . . . . . . . . . . . . . . . . 12

   5.  Security Requirements  . . . . . . . . . . . . . . . . . . . . 13
     5.1   Requirements Against Overclaiming  . . . . . . . . . . . . 13
     5.2   Requirements Against Misclaiming . . . . . . . . . . . . . 14
     5.3   Requirements Against Misstatement  . . . . . . . . . . . . 15
     5.4   Requirements Against Spoofing  . . . . . . . . . . . . . . 19
     5.5   Requirements Against Overload  . . . . . . . . . . . . . . 20
     5.6   Requirements Against Interference  . . . . . . . . . . . . 21
     5.7   Requirements Against Deliberate Exposure . . . . . . . . . 23
     5.8   Requirements Against Sniffing  . . . . . . . . . . . . . . 23
     5.9   Requirements Against Traffic Analysis  . . . . . . . . . . 24

   6.  Living with Byzantine Failures . . . . . . . . . . . . . . . . 26
     6.1   The Byzantine Problem  . . . . . . . . . . . . . . . . . . 26
     6.2   Byzantine General Requirements . . . . . . . . . . . . . . 26
     6.3   Detection of the Occurence of a Byzantine Failure  . . . . 27
     6.4   Byzantine Detection  . . . . . . . . . . . . . . . . . . . 27
     6.5   Byzantine Robustness . . . . . . . . . . . . . . . . . . . 28

   7.  Security Techniques for Routing  . . . . . . . . . . . . . . . 29
     7.1   Techniques when Originating  . . . . . . . . . . . . . . . 29
     7.2   Techniques when Relaying . . . . . . . . . . . . . . . . . 31
     7.3   Security of the Functional Parts . . . . . . . . . . . . . 33

   8.  Local Security . . . . . . . . . . . . . . . . . . . . . . . . 37
     8.1   Active Participation to Security . . . . . . . . . . . . . 37
     8.2   Local Resources Considerations . . . . . . . . . . . . . . 38

   9.  Inter-Domain Routing Issues  . . . . . . . . . . . . . . . . . 42
     9.1   Legitimacy . . . . . . . . . . . . . . . . . . . . . . . . 42
     9.2   Policies . . . . . . . . . . . . . . . . . . . . . . . . . 43
     9.3   Coherence  . . . . . . . . . . . . . . . . . . . . . . . . 43
     9.4   Confidentiality  . . . . . . . . . . . . . . . . . . . . . 43
     9.5   Agreements involving operators . . . . . . . . . . . . . . 43

   10.   Security Considerations  . . . . . . . . . . . . . . . . . . 45



Puig, et al.            Expires October 18, 2004                [Page 2]


Internet-Draft    Routing Protocols Security Requirements     April 2004


       Normative References . . . . . . . . . . . . . . . . . . . . . 46

       Informative References . . . . . . . . . . . . . . . . . . . . 47

       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 47

   A.  Revision History . . . . . . . . . . . . . . . . . . . . . . . 49
     A.1   Changes from draft-puig-rpsec-generic-requirements-01  . . 49
     A.2   Changes from draft-puig-rpsec-generic-requirements-00  . . 49

       Intellectual Property and Copyright Statements . . . . . . . . 50








































Puig, et al.            Expires October 18, 2004                [Page 3]


Internet-Draft    Routing Protocols Security Requirements     April 2004


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.

   Routing protocols addressed in this document are those limited by the
   rpsec working group charter. This includes distance vectors protocols
   and link-state protocols. We are also interested in the dedicated use
   of such protocols for intra-domain and inter-domain routing.
   Host-to-routers protocols are out of scope.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [KEYWORDS].

   Security terms are explained in [SEC-GLOSS].

   In order to avoid confusion between user traffic forwarding and
   routing traffic forwarding, in this document the former is performed
   by "forwarders" and called "forwarding" while the latter is performed
   by "relays" and called "relaying".

   This document is organized as follows:

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

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

   o  Section 4 presents routing functions and protocols components
      relevant to subsequent sections.

   o  Section 5 defines actual 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.




Puig, et al.            Expires October 18, 2004                [Page 4]


Internet-Draft    Routing Protocols Security Requirements     April 2004


   o  Section 9 introduces the inter-domain puzzle.


















































Puig, et al.            Expires October 18, 2004                [Page 5]


Internet-Draft    Routing Protocols Security Requirements     April 2004


2. General Requirements

   Routing protocols are responsible for distributing information about
   reachability to destinations attached to the network. Often, routing
   protocols also distribute policies associated with the properties of
   the path(s) to destinations.

   A path is a list of successive forwarding systems through which the
   destination can eventually be reached.

   Paths properties may be obtained from the management plane
   (configuration) of the routing device or from the routing protocol.
   When available, paths properties may have several status:

   o  "trusted": devices along that path are trusted to honor these
      properties. Possible trust paradigms are: the path is set as being
      trusted from the management plane, the devices are proven to
      belong to the same organization, it exists a verified agreement
      between routing devices owners, etc. Best effort packet forwarding
      within an intranet is a commonly "trusted" path property.

   o  "evaluated": properties on that path may be evaluated. This status
      is complementary with others. Evaluation may be achieved with the
      help of the peer or through a monitoring system.

   o  "expected": devices along that path are expected to provide these
      properties, but there is no certainty. Best effort packet
      forwarding on the Internet is a commonly "expected" path property.

   o  "hazardous": there are chances that these properties are available
      along that path, however this is dubious and these properties are
      not to be relied upon. Best effort packet forwarding may be a
      "hazardous" path property in some ad-hoc contexts. Data
      confidentiality on the Internet may be considered as a "hazardous"
      path property.

   Note: It is commonly accepted that the status of a path property is
   the weakest status of a hop-by-hop (an elementary path) property
   along that path. As an instance, a path linking systems "trusted" to
   provide hop-by-hop data confidentiality and a single system
   "expected" to provide hop-by-hop data confidentiality may only be
   "expected" to provide data confidentiality up to the destination.
   However, this common acceptance is untrue in a general fashion: if a
   system is "trusted" to provide at least 1 minute delay, then a path
   through this system can still be "trusted" to have this property.
   Similarly, a path on which RFC 1149 encapsulation is used between
   some systems can still be "trusted" to provide high delay and low
   throughput. Thus, the path property status greatly depends on the



Puig, et al.            Expires October 18, 2004                [Page 6]


Internet-Draft    Routing Protocols Security Requirements     April 2004


   actual property and the way it is described.

   First main requirement is:

   MR(1) Correct destination reachability information (DRI) SHOULD be
      made available for the forwarding function.

   DRI is a set of systems and paths properties associated with the
   destination. These systems are claimed to be the first elements of a
   path providing ("trusted" / "expected" / "hazardous") packet
   forwarding.

   A "correct" DRI is such that:

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

   o  properties of such paths comply with all locally-defined mandatory
      policy requirements for the destination.

   Note: According to this definition of DRI correctness, there is no
   way to be sure a DRI is correct or not when forwarding decision must
   be taken. Thus, from now on, we will consider that a DRI is correct
   when the routing device has been /convinced/ of this correctness.
   This /conviction/ may result from a trust measure on the way the DRI
   was obtained (ex: DRI signed by a business partner, static input from
   the management plane, etc).

   We also define DRI validity. A "valid" DRI is such that:

   o  packets forwarded to any system of the set follow a path up to
      destination (assuming that range limiting features -such as TTL-
      within the packets allow for this).

   o  mandatory policy requirements for the destination are fulfilled by
      properties of the paths followed.

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

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




Puig, et al.            Expires October 18, 2004                [Page 7]


Internet-Draft    Routing Protocols Security Requirements     April 2004


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

   Second main requirement is:

   MR(2) The forwarding decision process MUST recognize and select a
      correct DRI if available for the packet properties. If such a DRI
      is unavailable or partly incorrect, the decision process MAY
      investigate severed forwarding processing, 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 policy
      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 DRI cannot be achieved. It also
   focuses more on forwarding than on routing.

   Forwarding function and misuses of the routing protocol are
   documented in [THREATS].

   Most (but not all) subsequent requirements are meant to raise the
   confidence that correct DRI is available when required by the
   forwarding decision process.






















Puig, et al.            Expires October 18, 2004                [Page 8]


Internet-Draft    Routing Protocols Security Requirements     April 2004


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

3.1 Threats Consequences

   In an economical perspective, primary concern is about the
   consequences and their potentiality for damages. We will elaborate
   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 information).

   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 October 18, 2004                [Page 9]


Internet-Draft    Routing Protocols Security Requirements     April 2004


   A part of the security strategy is hardening of links and routing
   devices so that achieving access and subversion is significantly
   difficult. This part is not addressed here. Only subversion resulting
   from misuse of the routing protocol and actions against the routing
   system are studied.

   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.

3.2 Threats Actions

   This section lists the threats actions as associated to the
   achievement of a specific consequence.

   The following actions may result in usurpation:

   o  Overclaiming (source: subverted originating router)

   o  Misclaiming (source: subverted originating router)

   o  Misstatement (source: subverted relaying or forwarding devices)

   o  Reactions from router(s) deceived through spoofing (source:
      legitimate router(s))

   The following actions may result in deception:

   o  Spoofing (source: subverted device)

   o  Overclaiming (source: subverted originating router)

   o  Misclaiming (source: subverted originating router)

   o  Misstatement (source: subverted relaying or forwarding devices)

   The following actions may result in disruption:

   o  Overload (source: subverted devices)

   o  Interference (source: subverted devices)

   o  Overclaiming (source: subverted originating router)

   o  Misclaiming (source: subverted originating router)

   o  Misstatement (source: subverted relaying or forwarding devices)




Puig, et al.            Expires October 18, 2004               [Page 10]


Internet-Draft    Routing Protocols Security Requirements     April 2004


   o  Reactions from router(s) deceived through spoofing (source:
      legitimate router(s))

   The following actions may result in disclosure:

   o  Deliberate Exposure (source: subverted router)

   o  Sniffing (source: subverted link)

   o  Traffic Analysis (source: subverted link(s))

   o  Reactions from router(s) deceived through spoofing (source:
      legitimate router(s))

   Lastly, Byzantine Failure is a special threat action, which occurs
   when at least one authorized device get subverted. Thus, many threats
   are also Byzantine failures. This threat is addressed in a section of
   its own (cf. Section 6). The Byzantine general problem resolution is
   limited by hypotheses which are reminded in this document.

3.3 Damages

   [This part will present a rationale on the damages presented in the
   threats document. The point is certain damages should be issues
   address by hosts or specialized gateways (confidentiality of user
   traffic for instance), others are related to the device, others to
   forwarding, etc.]
























Puig, et al.            Expires October 18, 2004               [Page 11]


Internet-Draft    Routing Protocols Security Requirements     April 2004


4. Elements of Routing

   [This will be updated according to the need expressed later in the
   document, or remove if unused.]















































Puig, et al.            Expires October 18, 2004               [Page 12]


Internet-Draft    Routing Protocols Security Requirements     April 2004


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.

   Several models may be designed to counter overclaiming; these models
   address the delegation and the authorization of network resources
   ownership, control and advertisement.

   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 ownership, control and
   advertisement exists. Overclaiming is a violation of the logic stated
   in the chain.

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

      This expands to:





Puig, et al.            Expires October 18, 2004               [Page 13]


Internet-Draft    Routing Protocols Security Requirements     April 2004


   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 relays of DRI MUST check backward the chain of
      delegation and authorization of 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.

   Requirement R(1.1.c) implies the existence of a "top level" or "root"
   owner. This definition MAY be limited to the scope in which the
   routing protocol instance is in use.

   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.

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

   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



Puig, et al.            Expires October 18, 2004               [Page 14]


Internet-Draft    Routing Protocols Security Requirements     April 2004


   advertising its authorized control of some network resources in a way
   that is not intended by the authoritative network administrator"
   [THREATS].

   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 and of policies applying to the resources as intended by
   their controller.

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

   R(2.2) Consumers and relays of DRI MUST check that properties and
      policies 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 and policies are tied to the advertised resources and are
   intended by their controller.

   Note: it is technically possible to bundle resources description,
   properties and policies in such a way that the routing device will
   have no choice but to advertise the resources with the correct
   properties and policies or not advertising authorized information at
   all. This may provide an interesting protection against consequences
   resulting from future subversion of the device, and it further
   propagates along the path (as far as no aggregation occurs; cf.
   Section 9).

   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 relaying



Puig, et al.            Expires October 18, 2004               [Page 15]


Internet-Draft    Routing Protocols Security Requirements     April 2004


   or 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 attributes. This
   is a common situation in distance vectors protocols.

   We thus define the following classification of attributes:

   o  Attributes intended by their originator to reach adjacent nodes
      unmodified: "constant, neighborhood-limited" attributes.

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

   o  Attributes intended by their originator to reach adjacent nodes
      unmodified and to be propagated after an update: "updateable,
      propagated" attributes.


5.3.1 Constant, neighborhood-limited attributes

   These 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 solution),

   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



Puig, et al.            Expires October 18, 2004               [Page 16]


Internet-Draft    Routing Protocols Security Requirements     April 2004


      SHOULD also be dependant on the resource the 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 attributes apply to
      appropriate resources.

   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 limited and authenticated data).

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

5.3.2 Constant, propagated attributes

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

   The threat here results from a lack of attributes integrity, origin
   authentication and lifetime limitation.

   R(3.4) Integrity, data origin authenticity and validity at current
      date of DRI propagated attributes MUST be provided. The evidence
      MUST depend on the resource the attributes apply to.

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

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

   R(3.6) Attributes validity MUST be lifetime limited.

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



Puig, et al.            Expires October 18, 2004               [Page 17]


Internet-Draft    Routing Protocols Security Requirements     April 2004


   attribute.

   However, protection against deletion further depends on how
   attributes and resources are related, and if relays are allowed to
   delete attributes: this is the scope of requirement R(3.4.a). A
   design may apply different treatments on attributes which "must" be
   propagated and on attributes which "can" be propagated or discarded
   along the path of relays. The latter must not invalidate DRI when
   deleted.

   Note: when routing entities along the path are identified, it is
   possible to achieve accurate control against early deletion of
   attributes whose range is limited. This may be done through explicit
   identification of routing entities in attributes whose deletion would
   invalidate DRI, and with the mandatory presence of a stand-alone,
   authenticated set of attributes addressed to each particular entity.
   In some cases, the identified entities may be virtual (groups).

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

5.3.3 Updateable, propagated attributes

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

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

   The following aims only at offering a way round the problem and input
   for discussion; Figure 1 presents an instance of scenario.


                    |          |          |          |          |
             ---[e(i+0)]---[e(i+1)]---[e(i+2)]---[e(i+4)]---[e(i+5)]---
                    |          |          |          |          |
                                   ---[e(i+3)]---
                                          |


                      Figure 1: Updated Attributes

   Suppose we consider updates as constant, propagated attributes
   following requirements R(3.[4-6]). These attributes, noted u(i), are
   authentic. A history is built from the succession of updates.




Puig, et al.            Expires October 18, 2004               [Page 18]


Internet-Draft    Routing Protocols Security Requirements     April 2004


   Now, if u(i) only describes an update, then e(i+2) gets the chain of
   updates [originated_value, ..., u(i), u(i+1)]. e(i+2) may discard
   u(i+1) and relay to e(i+3) the chain [originated_value, ..., u(i),
   u(i+2)]. That is: the chain integrity is unprotected. In order to
   avoid the discard, e(i) should mention that u(i) is addressed to
   e(i+1). The chain then becomes [originated_value, ..., {u(i) to
   e(i+1)}, {u(i+1) to e(i+2)}, {u(i+2) to e(i+3)}] and trivial discards
   can be detected. This requires of course more work for one-to-many
   routing protocols, building on multicast or broadcast addressing.

   Other kind of discard is when a router appears several time in the
   path (loops): [originated_value, ..., {u(i) to e(i+1)}, {u(i+1) to
   e(i+2)}, {u(i+2) to e(i+3)}, {u(i+3) to e(i+2)}, {u'(i+2) to e(i+4)},
   {u(i+4) to e(i+5)}]. e(i+5) can just discard sub-chain [{u(i+2) to
   e(i+3)}, {u(i+3) to e(i+2)}] in order to corrupt the chain. This will
   also not be countered if source is explicitly mentioned in updates
   (ex: {u(i+1) from e(i) to (e+2)}), because loops may be much more
   complex. A way out would be to have numbered updates.

   In order to avoid cut-and-paste replays of some attributes, it may be
   necessary to have a chain number which is fed to the data origin
   authenticity and integrity function when adding an update. Similarly,
   routers should be able to impose an update down the chain with a way
   to signal an attribute freshness.

   Note that in any cases, e(i+2) may forward [originated_value, ...,
   {u(i) to e(i+1)}, {u(i+1) to e(i+2)}, {u'(i+2) to e(i+4)}, {u(i+4) to
   e(i+5)}] instead of [originated_value, ..., {u(i) to e(i+1)}, {u(i+1)
   to e(i+2)}, {u(i+2) to e(i+3)}, {u(i+3) to e(i+2)}, {u'(i+2) to
   e(i+4)}, {u(i+4) to e(i+5)}] because e(i+2) owns the appropriate
   secret material. In doing so, e(i+2) would make misstatements as the
   result of being a Byzantine router, which is the topic of a later
   section.

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.






Puig, et al.            Expires October 18, 2004               [Page 19]


Internet-Draft    Routing Protocols Security Requirements     April 2004


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

   Requirements R(1.*) through R(4.*) aim at preventing against
   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 very unlikely that the design of a routing protocol will
   entirely 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
   offered:

   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 authentication of neighbors
      messages may result in limiting routing protocol data plane
      overload but at the expense of computational checks at the control
      plane. A design SHOULD consider and document opportunities of
      overloads resulting from protection against usurpation and
      deception.

   R(5.3) The routing protocol operation SHOULD NOT suppose the
      full-time availability of protocols whose correct behavior depend
      on forwarding service (eg. live authentication through EAP).

   R(5.4) The routing protocol design SHOULD limit the amount of traffic
      needed for correct operation. This is greatly dependant on the
      context the protocol addresses. This also implies slow recovery on



Puig, et al.            Expires October 18, 2004               [Page 20]


Internet-Draft    Routing Protocols Security Requirements     April 2004


      reboots.

   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.

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"
   [THREATS].

   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
   R(3.*).

   Denial of forwarding (of routing protocol packets) cannot be
   countered. However, it can be detected if the emitter expects a
   receipts, though it is difficult (yet not impossible) 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 is difficult to figure
   out the cause of the threat.





Puig, et al.            Expires October 18, 2004               [Page 21]


Internet-Draft    Routing Protocols Security Requirements     April 2004


   R(6.1.a) An implementation SHOULD revise the level of confidence
      (trust or stability) associated with paths getting through a
      neighbor with which it has been detected occurrence of denial of
      forwarding or denial of receipt.

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

   R(6.1.c) Neighbors are likely to keep states associated with
      each-others. Kind of keep alive / heart beat messages facility MAY
      periodically states that "All systems are functional, Everything
      is going extremely well." in order to set a threshold for
      triggering state hygiene functions and confidence revision (Note:
      a manual reboot should not be considered as a state hygiene
      process).

   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. breaks of synchronization, 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.

   Note: Occurrence of "break of synchronization" events may be regarded
   as a random variable whose evaluations (possibly biased) of central
   moments affect the level of confidence associated with the
   relationship.

   Slow down of exchanges may be subjective. It is likely to affect pace
   to convergence, 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
      DRI.

   Flapping can be addressed by the routing protocol through the use of
   heuristics as for previous threats; however:



Puig, et al.            Expires October 18, 2004               [Page 22]


Internet-Draft    Routing Protocols Security Requirements     April 2004


   R(6.4) Part of flapping occurrences SHOULD be thwarted through
      enabling of the routing protocol to achieve atomic updates (as an
      instance, a removal and a subsequent addition which are related to
      overlapping fields of piece of DRI SHOULD be committed as an
      atomic update).

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

   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"
   [THREATS].

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

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

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 October 18, 2004               [Page 23]


Internet-Draft    Routing Protocols Security Requirements     April 2004


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

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

   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 October 18, 2004               [Page 24]


Internet-Draft    Routing Protocols Security Requirements     April 2004


   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 October 18, 2004               [Page 25]


Internet-Draft    Routing Protocols Security Requirements     April 2004


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

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

   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.

   Further information about distributed agreement can be found in



Puig, et al.            Expires October 18, 2004               [Page 26]


Internet-Draft    Routing Protocols Security Requirements     April 2004


   [CONSENSUS]. In the following, we will only focus on what makes the
   problem tractable in IP networks.

   The ability to send messages to all participants 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 Occurence 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
      operation.


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.

   Possible automatic responses that may be investigated are the



Puig, et al.            Expires October 18, 2004               [Page 27]


Internet-Draft    Routing Protocols Security Requirements     April 2004


   simulation of a link shutdown, setup of adequate 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 forwarding
   function 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 of "lower quality" (much many
      hops, long delay, etc). The routing protocol instance MAY also
      seek actively after an alternate path.

   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 DRI
   correctness (cf. Section 2):

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

   Some routing protocols address scenarii in which reachability is more
   important than policies and attributes associated with the
   destination. In such scenarii, Byzantine robustness aims at
   protecting reachability. This manages opportunities for "severed
   configurations" in which some 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 delivery).





Puig, et al.            Expires October 18, 2004               [Page 28]


Internet-Draft    Routing Protocols Security Requirements     April 2004


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 relayed through the
   network, out of originator's catch. Security mechanisms addressing
   the control side will have no control on the way data are eventually
   propagated. Moreover, believing that other devices will relay the
   information unmodified is naive. As an instance, mere aggregation may
   be a threat against policies applying to resources.

   As a consequence, it is important to know whether the originated
   information is authentic or not. In order to allow for this,
   information may be considered as a kind of 'record', composed of
   sections of the kind:

   o  Network resources description

   o  Related policies set by resources' controller.

   o  Information Lifetime

   o  Integrity and data-origin authenticity evidence of information,
      provided by the controller of the resources.

   The division presented in Section 5.1 between the controller and the
   advertiser then 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. It also enables the controller with setting
   an authenticated registry of authorized advertisers. 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
   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



Puig, et al.            Expires October 18, 2004               [Page 29]


Internet-Draft    Routing Protocols Security Requirements     April 2004


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

   Hence, security from the originating part is the big problem of
   routing security. In effect, a trade-off must be found between
   performance (sensibility to denial of service) and heavy
   cryptographic protection, public material reachability and it's
   synchronization.

   As for setting up channels for public material diffusion: this
   requires an expensive investment in architecture. Consequently,
   temptation may be high to rely on other architectures, especially
   when large scalability is in scope: DNS and the routing and
   forwarding system itself are the architectures which (almost)
   succeeded in scaling, but care must be taken not to misuse or
   overload these.  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



Puig, et al.            Expires October 18, 2004               [Page 30]


Internet-Draft    Routing Protocols Security Requirements     April 2004


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

   According to the distinction made in Section 1, the following
   concerns relays but not forwarders.

   When relaying, security requirements have a tendency to focus on the
   control plane. Relaying 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),



Puig, et al.            Expires October 18, 2004               [Page 31]


Internet-Draft    Routing Protocols Security Requirements     April 2004


   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.

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

   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.

   Note: There had been several discussions on the use of a token based
   fast rejection scheme, which could be embedded on interfaces of the



Puig, et al.            Expires October 18, 2004               [Page 32]


Internet-Draft    Routing Protocols Security Requirements     April 2004


   devices. Such a scheme would protect against a category of denials of
   service in which malign traffic gets in at a high rate. The
   management of such a scheme may require a stand-alone protocol and
   raises issues when neighbors communicate through several interfaces.

   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.

   Limiting keys lifetime and refreshing them is good cryptographic
   hygiene. Therefore, a mechanism to roll-over keys is REQUIRED both
   for public keys and for session keys; Public keys roll-over 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.
   Lifetime MUST be evaluated both in terms of time and of amount of
   data.

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



Puig, et al.            Expires October 18, 2004               [Page 33]


Internet-Draft    Routing Protocols Security Requirements     April 2004


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

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

   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



Puig, et al.            Expires October 18, 2004               [Page 34]


Internet-Draft    Routing Protocols Security Requirements     April 2004


      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.


7.3.2 The 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" [THREATS].

   [TBD] Cookies ? Damping ?

7.3.3 The 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"
   [THREATS].

   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.

7.3.3.1 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 (no Byzantine detection), 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



Puig, et al.            Expires October 18, 2004               [Page 35]


Internet-Draft    Routing Protocols Security Requirements     April 2004


   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.

   Network management must be able to install unalterable (static)
   routes to allow debugging network problems without interference from
   routing protocols.












































Puig, et al.            Expires October 18, 2004               [Page 36]


Internet-Draft    Routing Protocols Security Requirements     April 2004


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: sending source routed ICMP
   packets, etc. Such tests may also involve the neighbors. High caution
   should be taken regarding implementation of such features and they
   should not jeopardize the routing protocol mechanisms.

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.

8.1.2.1 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

   [TBD] The above has nothing to do with routing. Or has-it ? Should
   the protocol automate detect and act according to the detection of
   these events ?

8.1.3 Reacting

8.1.3.1 Filtering

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



Puig, et al.            Expires October 18, 2004               [Page 37]


Internet-Draft    Routing Protocols Security Requirements     April 2004


   A routing device MAY be set to drop/reject routing messages if these
   are incorrect with current configuration of the network, e.g. if 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.

8.1.3.2 Correcting

   [TBD] Correcting wrong / malicious routing info; investigate
   correction resulting from the above procedures.

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



Puig, et al.            Expires October 18, 2004               [Page 38]


Internet-Draft    Routing Protocols Security Requirements     April 2004


   routing protocols.

8.2.2.1 Buffers/Queues

   Buffers are widely used in hardware to store information that needs
   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.

8.2.2.2 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 more easy 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.

8.2.2.3 Buffer/Queues and CPU Cycles Requirements

   Routing messages SHOULD be identifiable as coming from legitimate



Puig, et al.            Expires October 18, 2004               [Page 39]


Internet-Draft    Routing Protocols Security Requirements     April 2004


   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
   designed ensuring that an attacker cannot directly exploit it in the
   attempt to block a legitimate routing peer from exchanging routing
   messages.

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

8.2.2.4.1 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
   relay on Quality of Service mandating that the highest priority and
   availability be assigned to routing messages.

8.2.2.5 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



Puig, et al.            Expires October 18, 2004               [Page 40]


Internet-Draft    Routing Protocols Security Requirements     April 2004


   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.

8.2.3.1 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 October 18, 2004               [Page 41]


Internet-Draft    Routing Protocols Security Requirements     April 2004


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

   Besides, this will not prevent forwarding tables from aggregating or
   removing entries, and this kind of decorrelation between forwarding
   and routing information may not be desirable, even though loose
   relation between forwarding 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 October 18, 2004               [Page 42]


Internet-Draft    Routing Protocols Security Requirements     April 2004


9.2 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
   standalone, 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 policies. Yet, the value
   of a route without knowledge of according policies 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.

   A limited set of fields composing a signed tuple could include an



Puig, et al.            Expires October 18, 2004               [Page 43]


Internet-Draft    Routing Protocols Security Requirements     April 2004


   identity (WRT to RP), address(es), public key, authorization on
   prefixes and adequate lifetimes.

   Access control also imply agreements: who's granted right to
   participate to the protocol ?














































Puig, et al.            Expires October 18, 2004               [Page 44]


Internet-Draft    Routing Protocols Security Requirements     April 2004


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 October 18, 2004               [Page 45]


Internet-Draft    Routing Protocols Security Requirements     April 2004


Normative References

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

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

   [FILTERING]
              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, <http://
              www.ietf.org/rfc/rfc2827.txt>.

   [KEYWORDS]
              Bradner, S., "Key Words for Use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997, <http:/
              /www.ietf.org/rfc/rfc2119.txt>.

   [SEC-GLOSS]
              Shirey, R., "Internet Security Glossary", RFC 2828, May
              2000, <http://www.ietf.org/rfc/rfc2828.txt>.



























Puig, et al.            Expires October 18, 2004               [Page 46]


Internet-Draft    Routing Protocols Security Requirements     April 2004


Informative References

   [BTSH]     Vijay, G., Heasley, J. and D. Meyer, "The BGP TTL Security
              Hack (BTSH)", Internet Draft; version 02, May 2003,
              <http://www.ietf.org/internet-drafts/
              draft-gill-btsh-02.txt>.

   [BYZANTINE]
              Perlman, R., "Network Layer Protocols with Byzantine
              Robustness",  , August 1988, <http://www.vendian.org/
              mncharity/dir3/perlman_thesis/>.

   [CONSENSUS]
              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, <http://
              www.cert.org/tech_tips/denial_of_service.html>.

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

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


Authors' Addresses

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

   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/








Puig, et al.            Expires October 18, 2004               [Page 47]


Internet-Draft    Routing Protocols Security Requirements     April 2004


   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
   Canada

   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 October 18, 2004               [Page 48]


Internet-Draft    Routing Protocols Security Requirements     April 2004


Appendix A. Revision History

A.1 Changes from draft-puig-rpsec-generic-requirements-01

   TOC tweaking. Phrasing simplifications. Development of the
   requirements.

A.2 Changes from draft-puig-rpsec-generic-requirements-00

   Full TOC change.









































Puig, et al.            Expires October 18, 2004               [Page 49]


Internet-Draft    Routing Protocols Security Requirements     April 2004


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property 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; neither does it represent that it
   has made any effort to identify any such rights. Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11. Copies of
   claims of rights made available for publication 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 implementors or users of this specification can
   be obtained from the IETF Secretariat.

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


Full Copyright Statement

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

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assignees.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION



Puig, et al.            Expires October 18, 2004               [Page 50]


Internet-Draft    Routing Protocols Security Requirements     April 2004


   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Acknowledgment

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











































Puig, et al.            Expires October 18, 2004               [Page 51]