Network Working Group JJ. Puig Internet-Draft M. Achemlal Expires: January 6, 2005 E. Jones D. McPherson July 8, 2004 Generic Security Requirements for Routing Protocols draft-ietf-rpsec-generic-requirements-00 Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. 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 January 6, 2005. 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 January 6, 2005 [Page 1] Internet-Draft Routing Protocols Security Requirements July 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1 Path . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2 Destination . . . . . . . . . . . . . . . . . . . . . . . 5 2.3 Route Property / Route Attribute (RP / RA) . . . . . . . . 5 2.4 Forwarders . . . . . . . . . . . . . . . . . . . . . . . . 5 2.5 Neighbors / Peers / Adjacent Routers . . . . . . . . . . . 5 2.6 Propagators . . . . . . . . . . . . . . . . . . . . . . . 5 2.7 Route / Routing Information (RI) . . . . . . . . . . . . . 6 2.8 Route correctness . . . . . . . . . . . . . . . . . . . . 6 2.9 Route validity . . . . . . . . . . . . . . . . . . . . . . 6 2.10 Routing Function . . . . . . . . . . . . . . . . . . . . 7 2.11 Routing Decision Process . . . . . . . . . . . . . . . . 7 2.12 Forwarding Function . . . . . . . . . . . . . . . . . . 7 3. General Requirements . . . . . . . . . . . . . . . . . . . . 8 4. Threats Importance . . . . . . . . . . . . . . . . . . . . . 9 4.1 Threats Consequences . . . . . . . . . . . . . . . . . . . 9 5. Security Requirements . . . . . . . . . . . . . . . . . . . 11 5.1 Requirements Against Overclaiming . . . . . . . . . . . . 11 5.2 Requirements Against Misclaiming . . . . . . . . . . . . . 13 5.3 Requirements Against Misstatement . . . . . . . . . . . . 14 5.4 Requirements Against Spoofing . . . . . . . . . . . . . . 17 5.5 Requirements Against Overload . . . . . . . . . . . . . . 18 5.6 Requirements Against Interference . . . . . . . . . . . . 19 5.7 Requirements Against Deliberate Exposure . . . . . . . . . 21 5.8 Requirements Against Sniffing . . . . . . . . . . . . . . 21 5.9 Requirements Against Traffic Analysis . . . . . . . . . . 22 6. Living with Byzantine Failures . . . . . . . . . . . . . . . 24 6.1 The Byzantine Problem . . . . . . . . . . . . . . . . . . 24 6.2 Byzantine General Requirements . . . . . . . . . . . . . . 24 6.3 Detection of the Occurrence of a Byzantine Failure . . . . 25 6.4 Byzantine Detection . . . . . . . . . . . . . . . . . . . 25 6.5 Byzantine Robustness . . . . . . . . . . . . . . . . . . . 26 7. Security Techniques for Routing . . . . . . . . . . . . . . 27 7.1 Techniques when Originating . . . . . . . . . . . . . . . 27 7.2 Techniques when Propagating . . . . . . . . . . . . . . . 29 7.3 Security of the Functional Parts . . . . . . . . . . . . . 31 7.4 Date and Time Issues . . . . . . . . . . . . . . . . . . . 34 8. Local Security . . . . . . . . . . . . . . . . . . . . . . . 35 Puig, et al. Expires January 6, 2005 [Page 2] Internet-Draft Routing Protocols Security Requirements July 2004 8.1 Active Participation to Security . . . . . . . . . . . . . 35 8.2 Local Resources Considerations . . . . . . . . . . . . . . 36 9. Inter-Domain Routing Issues . . . . . . . . . . . . . . . . 40 9.1 Legitimacy . . . . . . . . . . . . . . . . . . . . . . . . 40 9.2 Propagating policies . . . . . . . . . . . . . . . . . . . 41 9.3 Coherence . . . . . . . . . . . . . . . . . . . . . . . . 41 9.4 Confidentiality . . . . . . . . . . . . . . . . . . . . . 41 9.5 Agreements involving operators . . . . . . . . . . . . . . 41 10. Security Considerations . . . . . . . . . . . . . . . . . . 43 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 44 11.1 Normative References . . . . . . . . . . . . . . . . . . . 44 11.2 Informative References . . . . . . . . . . . . . . . . . . 44 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 45 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 46 B. Revision History . . . . . . . . . . . . . . . . . . . . . . 47 B.1 Changes from draft-puig-rpsec-generic-requirements-02 . . 47 B.2 Changes from draft-puig-rpsec-generic-requirements-01 . . 47 B.3 Changes from draft-puig-rpsec-generic-requirements-00 . . 47 Intellectual Property and Copyright Statements . . . . . . . 48 Puig, et al. Expires January 6, 2005 [Page 3] Internet-Draft Routing Protocols Security Requirements July 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. This document discusses generic requirements for routing protocols, used for both interdomain and intradomain routing. Host to router and multicast routing protocols, specifically, are out of scope. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "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]. This document has the following layout: o Section 2 defines terms used within this document. o Section 3 presents general requirements to the security of routing protocols and routing systems. o Section 4 sorts by importance threats defined in [THREATS]. o Section 5 defines generic security requirements. o Section 6 provides guidance for tackling the Byzantine problem. o Section 7 describes techniques for routing security. o Section 8 presents security considerations for the routing device. o Section 9 introduces the inter-domain puzzle. Puig, et al. Expires January 6, 2005 [Page 4] Internet-Draft Routing Protocols Security Requirements July 2004 2. Terminology The following terms will be used in this document: 2.1 Path A path is a list of successive forwarders through which a destination may be reached. 2.2 Destination Destination refers here either to a physical network or to a prefix, as announced in the routing protocol. Thus destination is only a 'hint' about eventual destination of user's traffic. 2.3 Route Property / Route Attribute (RP / RA) Routing protocols also distribute information associated with the destination (ex: number of hops). A minimum set of such properties may be mandatory in order to avoid loops within the routing system. Any router, while propagating routing information, may add, remove or update route attributes. 2.4 Forwarders Forwarders are either mentioned as a route attribute, or assumed to be the peers through which the routes were acquired. Forwarders are expected to be the first elements of paths providing packet forwarding to the destination mentioned in the route, with the associated properties. 2.5 Neighbors / Peers / Adjacent Routers The terms "neighbors", "peers", "adjacent routers" all refer to routers which can communicate directly over the transport subsystem. 2.6 Propagators Propagators are participants to the routing protocol. They relay the routing information between networks. They may also modify the routing information before relaying ( / flooding / re-advertising) it. Propagators are usually set on transit networks, not on stub networks. Puig, et al. Expires January 6, 2005 [Page 5] Internet-Draft Routing Protocols Security Requirements July 2004 2.7 Route / Routing Information (RI) Routing protocols enable routers to exchange routes or routing information. Routes include at least the description of a destination and associated route properties. At least one forwarder is mentioned in -or associated with- the route. 2.8 Route correctness A "correct" route is such that: 1. it exists at least one path to the destination from each system listed as a suitable forwarder. 2. (locally known) route properties are compatible with local mandatory policy requirements for the destination. Note: This definition of correctness is local to this document; a minimal definition would only address the 2nd issue, while a stronger one would also require knowledge that route properties are consistent with actual paths properties. According to this definition, there is no way to be sure a route is correct or not when routing decision must be taken. Thus, we will consider that a route is correct when the router has been 'convinced' of this correctness. This 'conviction' should result from a trust measure on the way the route was acquired (ex: route signed by a business partner, static input from the management plane). 2.9 Route validity A "valid" route is such that: o packets forwarded to any adequate forwarder follow a path up to destination. o (locally known) route properties are honored on the path and compatible with local mandatory policy requirements. Note: According to this definition of route validity, there is no way to know a route is valid when routing decision is taken. There is also no certainty of knowing afterward that a route was valid or not. This definition underlines the uncertain nature of any communication though it should not be considered as `petitio principii'. Puig, et al. Expires January 6, 2005 [Page 6] Internet-Draft Routing Protocols Security Requirements July 2004 2.10 Routing Function In this document, the routing function is a process which returns the available routes for a packet destination. 2.11 Routing Decision Process In this document, the routing decision process selects a route from the set returned by the routing function or cancels forwarding. Many criteria may influence selection (ex: packets source). In the field, respective rules of the routing function and of the routing decision process may be less strict. 2.12 Forwarding Function The forwarding function performs actual forwarding according to data installed by the routing decision process. Puig, et al. Expires January 6, 2005 [Page 7] Internet-Draft Routing Protocols Security Requirements July 2004 3. General Requirements Routing protocols are responsible for distributing information about reachability to destinations attached to the network. First main requirement is: MR(1) Correct routes SHOULD be made available for the routing function. MR(1.a) When a route is unavailable or incorrect, the first main requirement means that a correct route SHOULD be made available, either through the use of the routing protocol or from the management plane. MR(1.b) When a route is available and correct, the first main requirement means that misuse of the routing protocol SHOULD NOT jeopardize the route availability or correctness, as this would also compromise correct routing. Note: the first main requirement does not preclude acquisition of routes whose correctness cannot be established, if available. It only sets a priority to both availability and correctness of routes. Second main requirement is: MR(2) The routing function MUST recognize and select correct routes if available for the packet properties. If such routes are unavailable or partly incorrect, severed routing processing MAY be investigated, according to a heuristic learnt from the management plane. Eventually, if it is decided that no forwarding will be achieved, the packet MUST be discarded or rejected according to local policy (this SHOULD be configurable). MR(2.a) Packet properties analyzed by the decision process MAY include other information than destination address. Note: the second main requirement does not preclude forwarding when full correctness or availability of routes cannot be achieved. It also focuses more on the eventual forwarding than on routing. Routing protocols functions and misuses are documented in [THREATS]. Most (but not all) subsequent requirements are meant to raise the confidence that correct routes are available when required by the routing function. Puig, et al. Expires January 6, 2005 [Page 8] Internet-Draft Routing Protocols Security Requirements July 2004 4. Threats Importance In the [THREATS] document, threats are described according to their sources, their consequences, and eventually the behaviors -referred as "actions"- which enable sources to trigger consequences. 4.1 Threats Consequences In an economical perspective, primary concern is about the consequences and their potentiality for damages. We will elaborate requirements according to the following classification of consequences, sorted by importance order: i - Usurpation. Damages cost resulting from usurpation may be extreme and may only be roughly estimated. Besides, usurpation often enables the attacker to proceed with subsequent consequences. For these reasons, usurpation is the top issue. ii - Deception. Deception will partly result in the same damages as usurpation and is thus an important consequence. iii - Disruption. Disruption is a significant consequence, but its range and period are usually limited and damages cost can be evaluated more accurately than for previous consequences. However, actions leading to disruption should be difficult enough to achieve so that disruption does not become a common event. Beyond a certain threshold (depending on frequency, duration, range and overall context), disruption may become more significant than usurpation or deception. iv - Disclosure. The above consequences directly jeopardize the services expected to be provided by the routing system. Reliability and availability of the routing system is usually considered more important than confidentiality of the routing information (which is not `user data' per se and may be learnt by other means). In current protocols, it is unlikely that disclosure of routing information will lead to direct damages on routing services as a result of the information leak. In this context, concealing the services properties in order to protect against disclosure is not a priority. However, it is worth preventing against disclosure of information which would enable the attacker to trigger usurpation, deception or disruption (in-band plain text passwords are likely to be such pieces of 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 January 6, 2005 [Page 9] Internet-Draft Routing Protocols Security Requirements July 2004 Subversion of the routing system may be very easy if an attacker has the ability to attack the physical link between two routers, or individual routers. Techniques that harden any of these points of attack can make attacking the routing system harder, but we consider these outside the scope of this document. We are thus primarily interested in the threat actions that result in usurpation, secondarily in those that result in deception, thirdly in disruption, lastly in disclosure. Puig, et al. Expires January 6, 2005 [Page 10] Internet-Draft Routing Protocols Security Requirements July 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. Main issue with overclaiming is checking resources control or advertisement authorization. Several models may be designed to counter overclaiming; these models address the delegation and the authorization of network resources ownership, control and 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 some network resources ownership, control and advertisement may exist. Overclaiming is a violation of the logic stated in this chain for these specific resources. However, such a logic is also limited: o In specific contexts (ex: inter-domain routing, ad-hoc routing), giving birth to such a chain for any network resource may be much too complex (it may yet be possible on a limited basis). Puig, et al. Expires January 6, 2005 [Page 11] Internet-Draft Routing Protocols Security Requirements July 2004 o The destination announced may get modified by routers during normal routing operations (ex: re-advertising with a shorter prefix); this allows for reducing the overall amount of routing information and to lessen its impact on bandwidth, storage and on routing function algorithms. On the other hand, this also legitimates overclaiming, and once original information is lost, it gets far harder to provide any trust measure regarding the new routing information. In such a situation, the usefulness of the chain is unclear because it may or may not state anything about the new super-set of network resources. For these reasons, subsequent requirements are limited to the case in which the chain exists. The nature (hierarchical, relational, etc.) of the architectural scheme from which the chain is extracted is outside the scope of this documentation. Furthermore, the following requirements DO NOT make any statement about what should be done with -out of the chain- unauthenticated information (discard, install with lower preference, use it for the sake of the routing protocol but not for user traffic... cf. Section 7.3.3). R(1.1) Integrity, data origin authenticity, validity at current date and availability of nodes of the chain of delegation and authorization of a specific resource ownership, control and advertisement MUST be provided when such a chain exists. This expands to: R(1.1.a) It MUST be possible to check that a routing device is currently authorized to advertise some network resources. R(1.1.b) It MUST be possible to check that the entity which (directly or indirectly) granted the right of advertisement actually and currently controls the corresponding network resources. R(1.1.c) It MUST be possible to check that the entity which (directly or indirectly) granted the control actually and currently owns the corresponding network resources. R(1.1.d) It MUST be possible to check that delegation between entities is actually and currently valid. R(1.2) Consumers and propagators of routing information MUST check backward the chain of delegation and authorization of resource advertisement, control and ownership. R(1.2.a) Check depth MUST be sufficient according to the context in which the routing protocol instance is in use and to the locally available information. Puig, et al. Expires January 6, 2005 [Page 12] Internet-Draft Routing Protocols Security Requirements July 2004 Requirement R(1.1.c) MAY be limited to the scope in which the routing protocol instance is in use. Requirements R(1.1*) imply the use of a time scale for date validity. Further discussion on this topic is presented in Section 7.4 Requirement R(1.2.a) allows for using the same chain at different scales. In internal routing operations, a router will check the chain up to the routing system controller (of which it should already be aware), while in external routing operations, a router will check the entire chain or rely on the knowledge that the check was done by another edge router of the same system. It is also possible to establish several steps of "internal" and "external" routing with regard to this specific topic. When convergence is achieved, - if verifiable information is available, overclaiming can be thwarted by the requirement of checking that the routing device is authorized to advertise by an administrative entity which was given control of the according network resources by their owner; in such a context, authenticated information should take precedence over any unauthenticated information. - if no verifiable information is available, then overclaimed information is all what the device can get. What to do with it is a local policy matter. Practical considerations related to these requirements are presented in Section 7.1. Further elements regarding this topic are presented in Section 9. 5.2 Requirements Against Misclaiming "A misclaiming threat is defined as an action where an attacker is advertising its authorized control of some network resources in a way that is not intended by the authoritative network administrator" [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 applying to the resources as intended by their controller (cf. Section 5.1 for further information regarding this Puig, et al. Expires January 6, 2005 [Page 13] Internet-Draft Routing Protocols Security Requirements July 2004 chain). R(2.1) Integrity, data origin authenticity, validity at current date and availability of the properties applying to the advertised resources MUST be provided. R(2.2) Consumers and propagators of routing information MUST check that properties applying to the advertised resources are effectively related to the resources and as intended by the resources controllers. Requirements R(1.*) also apply. Misclaiming is thwarted by the requirement of checking that the properties are tied to the advertised resources and are intended by their controller. Practical considerations related to these requirements are presented in Section 7.1. 5.3 Requirements Against Misstatement Misstatement "is defined as an action whereby the attacker describes route attributes in an incorrect manner" [THREATS]. The attacker acts on attributes through deletion, insertion and substitution of data. He may also replay out-dated data. Misstatement is a threat from subverted links and subverted forwarding devices; it affects the data plane of the routing protocol. However, a message replay may also be considered as a control plane violation. There is an additional difficulty in cases in which correct operation of the routing protocol requires updates of a set of route attributes. This is a common situation in vector protocols. We thus define the following classification of route attributes (where route attributes are defined in Section 2): o Route attributes intended by their originator to be consumed by and to reach adjacent nodes unmodified: "constant, not propagated route attributes". o Route attributes intended by their originator to keep constant values and to be propagated by adjacent nodes: "constant, propagated route attributes". o Route attributes intended by their originator to reach adjacent Puig, et al. Expires January 6, 2005 [Page 14] Internet-Draft Routing Protocols Security Requirements July 2004 nodes unmodified and to be propagated after an update: "updateable, propagated route attributes". Lastly, any router can add or delete route attributes. 5.3.1 Constant, not propagated route attributes These route attributes must reach adjacent nodes unmodified. Possible attackers are: compromised links, subverted forwarding devices, masquerading routers. This threat results from a lack of data integrity, data origin authentication and replay protection. Protection of data between adjacent nodes, especially anti-replay, has a tendency to focus on session management and on control plane. The following requirements CAN be addressed either: o at the control plane level, o by the transport subsystem (the preferred way), o at the data plane level. A routing protocol design SHOULD mention at which level these requirements are fulfilled: R(3.1) Evidence of integrity and authenticity of data exchanged between neighbors SHOULD be provided; this evidence SHOULD be dependant on data destination. When the evidence applies on data description (as opposed to applying on a per-message basis), it SHOULD also be dependant on the resource the route attributes apply to. R(3.1.a) It SHOULD NOT be possible to impersonate a neighbor. That is: authentication of neighbors SHOULD depend on a a-priori knowledge (a public key, a shared secret, knowledge of a direct connection in a common technical room, etc). This dependency MUST be documented in the protocol design. R(3.2) Upon reception, data integrity and authenticity SHOULD be checked. This check SHOULD also include data destination and, when the check applies directly on data description (as opposed to applying on a per-message basis), that route attributes apply to appropriate resources. Puig, et al. Expires January 6, 2005 [Page 15] Internet-Draft Routing Protocols Security Requirements July 2004 R(3.3) The routing protocol SHOULD be protected against the damages resulting from data replay. This CAN be done either by preventing replays effectiveness (ex: through integrity protected sequence numbers) or by reducing replays incidence on data (ex: through lifetime limitation of data). Practical considerations related to these requirements are presented in Section 7.2. 5.3.2 Constant, propagated route attributes These route attributes must be propagated but not updated. Given requirements R(3.[1-3]) above, possible remaining attackers are: subverted propagating devices. The threat here results from a lack of route attributes integrity, origin authentication and lifetime limitation. When propagated, information protection has a tendency to apply directly at the data plane level. R(3.4) Integrity, data origin authenticity and validity at current date of constant, propagated route attributes MUST be provided. The evidence MUST depend on the resource the route attributes apply to and on the identity of the node which add these specific route attributes. R(3.4.a) This CAN be done in such a way that deletion, insertion or substitution of route attributes will invalidate the whole routing information or a set of route attributes when checked. R(3.5) Consumers and propagators of routing information MUST check that constant, propagated route attributes apply to the resources and are the ones intended by the entity which set them. R(3.6) Route attributes validity MUST be lifetime limited. Requirement R(3.4) addresses protection against unauthenticated insertion and substitution, and against partial deletion of a route attribute. However, full protection against deletion further depends on how route attributes and resources are related, and if propagators are allowed to delete route attributes: this is the scope of requirement R(3.4.a). A design may apply different treatments on route attributes which "must" be propagated and on route attributes which "can" be propagated or discarded along the routing protocol' propagation path. The latter must not invalidate routing information when deleted. In a sense, requirement R(3.4.a) manages a way for Puig, et al. Expires January 6, 2005 [Page 16] Internet-Draft Routing Protocols Security Requirements July 2004 more complex route attributes propagation management. Further considerations regarding this topic are not addressed in this document. Requirement R(3.6) set a lifetime on the evidences, not on route attributes themselves. Practical considerations related to these requirements are presented in Section 7.1. 5.3.3 Updateable, propagated route attributes These route attributes must be propagated and updated. Given requirements R(3.[1-3]) above, possible remaining attackers are: subverted propagating devices. The threat here results from the absence of any verifiable history of route attributes updates. In the absence of any data trace-ability, it is difficult to figure out if a misstatement occurred. For this reason, unless route attributes are expanded in such an history and each update meets requirements for constant, propagated route attributes, we can reach to no strong requirement here. However, depending on the semantic of specific route attributes, routers MAY evaluate whether values are realistic or not. 5.4 Requirements Against Spoofing "Spoofing occurs when an illegitimate device assumes the identity of a legitimate one" [THREATS]. Spoofing is possible because of a lack of combined integrity and data origin authentication. When considered an attack per se, spoofing is a threat on routing protocol control plane operations. It threatens neighbor relationship formation and state maintenance. R(4.1) Requirements R(1.*) and R(3.[1-3]) also address spoofing. R(4.1.a) In the context of spoofing, an emphasis SHOULD be made on the transport subsystem or on the control plane when interpreting requirements R(3.[1-3]). It is often adequate to elect an appropriate transport subsystem which would provide functionalities against spoofing (cf. Section 7.3.1). Requirements R(1.*) through R(4.*) aim at preventing against Puig, et al. Expires January 6, 2005 [Page 17] Internet-Draft Routing Protocols Security Requirements July 2004 usurpation and deception. Following requirements address disruption and usurpation. 5.5 Requirements Against Overload "Overload is defined as a threat action whereby attackers place excess burden on legitimate routers" [THREATS]. Overload is a threat from subverted links or devices. It may affect the data plane of the routing device, eg. as the result of link overload. It may also affect the control plane of the routing device, eg. by leading the victim router to use all its computational resources. It is unlikely that the design of the routing protocol will suffice to prevent against this threat. However, the routing device may also include some functions which would limit the negative consequences of this threat (cf. Section 8). At the routing protocol control plane, the following options are 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 neighbors authentication may result in expensive computational checks at the control plane, even though authentication may also be of great help against data plane overload resulting from malicious messages injected on the link. A design SHOULD consider and document opportunities of overloads resulting from protection against usurpation and deception. R(5.3) The routing protocol operations SHOULD NOT suppose the full-time availability of material (eg: a registry) whose reachability depends on the forwarding service achieved by other routers. R(5.4) The routing protocol design SHOULD limit the amount of traffic needed for correct operation. This is greatly dependant on the context in which the protocol operates. This also implies rate control of messages sent for session setup (or recovery) when starting-up (or rebooting). Requirements R(5.[1-2]) suppose that authorized neighbors messages can be authenticated, which helps rejecting attackers solicitations. Further cautions are nonetheless required against neighbors acting in a Byzantine manner. Puig, et al. Expires January 6, 2005 [Page 18] Internet-Draft Routing Protocols Security Requirements July 2004 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 messages, or of lower level datagrams, packets or frames) cannot be countered. However, it can be detected if the emitter expects an evidence of correct reception (eg: reliable transport), though it is difficult in such a case to make the difference with a denial of receipt (cf. R(6.1.*) below). Denial of receipts can be detected; even if it may prove to be difficult to figure out the cause of the threat. R(6.1.a) An implementation SHOULD revise the level of confidence (preference, trust, stability... whatever) associated with destinations whose first hop is a neighbor with which has been detected occurrence of denial of forwarding or denial of receipt. Puig, et al. Expires January 6, 2005 [Page 19] Internet-Draft Routing Protocols Security Requirements July 2004 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) Denial of forwarding or of receipts may result in breaking the states associated with neighbors sessions. Active mechanisms (ex: an in-band echo) MAY be used in order to detect such an anomaly and to set a threshold for an automatic state hygiene maintenance and for confidence revision. Section 8.2 presents resources consumption in details. Delaying responses beyond a certain threshold is likely to break neighboring relationship, because a routing protocol implementation should time out a neighboring relationship beyond such a threshold (cf. synchronization breaks, R(6.2)). Behind the threshold, delaying may result in the same consequences as a slow down of exchanges (cf. R(6.3)). There are no way of preventing against breaks of synchronization from subverted links or routers. However: R(6.2) Protocol design MUST take into account possible breaks of synchronization, even when the threat may only be accidental and improbable. State hygiene and computation of confidence level SHOULD be affected by the detection of such breaks. Slow down of exchanges may be subjective. It is likely to affect pace to convergence (either in a positive or a negative way), but slow down may also be a 'natural event', when traffic or processing is high, when queues are filling up, etc. R(6.3) 'Reactivity' of neighbors, possibly with knowledge of the traffic load on the link, MAY be a variable of the heuristic function which computes confidence associated with a neighbor or a particular piece of routing information. Flapping of routing information is a significant source of instabilities on global routing. It may be difficult to prevent against flapping which results from a subverted routing device. However, a routing device SHOULD lower the disturbance from this event on the network. R(6.4) Routing information flapping SHOULD be detected through routing databases survey. Propagation of possibly flapping information SHOULD be dampened through appropriate rate control of routing information propagation. Instabilities of particular pieces of routing information may get Puig, et al. Expires January 6, 2005 [Page 20] Internet-Draft Routing Protocols Security Requirements July 2004 absorbed through information reduction; as an instance, announcing a shorter prefix may hide the flapping on a particular route with a longer prefix. Information reduction, on the other hand, reduces traceability of information (cf. Section 5.1, Section 5.3.3). With the general threat of interference, the routing decision process is deemed to make choices based on a heuristic evaluation of the confidence associated with a particular neighbor or piece of routing information. Requirements R(6.[1-3]) DO NOT prevent against threats actions, but aim at evaluating the cost of trust as associated with a link or a neighbor. The device may then allocate resources, invalidate routing information, etc., according to the confidence measure. This is not conditions prevention; this is consequences 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 January 6, 2005 [Page 21] Internet-Draft Routing Protocols Security Requirements July 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 paths properties. R(9.1) When user traffic is protected against traffic analysis, the routing protocol operations SHOULD investigate the use of a TFC & anonymity enabled transport subsystem shared with user traffic. Design of the routing protocol SHOULD be independent of this operational consideration, unless goal of the protocol is to set up the traffic flow concealing and 'anonymizing' network used by the transport subsystem. Puig, et al. Expires January 6, 2005 [Page 22] Internet-Draft Routing Protocols Security Requirements July 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 January 6, 2005 [Page 23] Internet-Draft Routing Protocols Security Requirements July 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]; as a consequence, many threats are also Byzantine failures. The Byzantine general problem resolution is limited by hypotheses which are reminded here. Byzantine resistance includes detection of Byzantine failures, Byzantine detection and Byzantine robustness, where the two latter are not necessarily correlated. Next section gives a thorough description of these forms of resistance. The following main requirements aim at helping in the design of a Byzantine resistant routing protocol: MR(3.1.a) Local instance of the protocol SHOULD NOT rely on correct operation of any particular neighbor. MR(3.1.b) Operations associated with a particular neighbor SHOULD always apply a least privilege policy. MR(3.1.c) Only traffic source and destination SHOULD be considered 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. Puig, et al. Expires January 6, 2005 [Page 24] Internet-Draft Routing Protocols Security Requirements July 2004 Further information about distributed agreement can be found in [CONSENSUS]. In the following, we will only focus on what makes the problem tractable in IP networks. The ability to send messages to all neighbors simultaneously allow for simulation of both full connectivity and synchronization. The fact that routing information is not a agreeable binary decision has little consequences because agreement is not an absolute requirement; see Section 6.5 and [BYZANTINE]. 6.3 Detection of the Occurrence of a Byzantine Failure The protocol algorithm may detect incoherences within the correlated routing information upon algorithm termination, abnormal attractive cycles within routes computations, etc. These events may be symptoms of a Byzantine failure occurring. More trivial evidences of a possible Byzantine failure is when agreement, termination or validity of the consensus cannot be achieved. R(10.1) It SHOULD be possible to derive from a routing protocol design a set of coherence and sanity checks. The routing protocol documentation SHOULD mention directions when incoherence occurs, and describes reactions which are of direct impact on the protocol 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. Puig, et al. Expires January 6, 2005 [Page 25] Internet-Draft Routing Protocols Security Requirements July 2004 Possible automatic responses that may be investigated are the simulation of a link shutdown, setup of adequate local policies, quarantine cell. Collaborative approach between detectors to limit the influence of some subverted devices may be quite hazardous. Either at the database maintenance level or at the routing decision process level, the following SHOULD be configurable when dealing with a detected subverted device: R(11.2.a) "Detour": Allow or deny forwarding along an alternate route (if available), possibly on a path for which a "lower quality" (much many hops, longer delay, etc) is probable. The routing protocol instance MAY also seek actively after an alternate route. R(11.2.b) "Send & Hope": Allow forwarding to the subverted device anyway or, R(11.2.c) "Discard": Treat destination as unreachable. Eventually, note that sharing symmetric material for partial authentication between more than two devices would make Byzantine detection impossible to achieve in most cases (and so would do the absence of any authentication mechanism). 6.5 Byzantine Robustness Purpose of Byzantine robustness, in the general problem context, is for any given device to achieve algorithm termination, agreement and -naturally- validity. This does not imply Byzantine detection. However, in the routing context, what matters really is routing information correctness (cf. Section 3): R(12.1) Routing protocols do NOT REQUIRE to achieve agreement. R(12.2) Routing protocols do NOT REQUIRE to terminate; in fact, it is generally expected that they will not terminate during normal operation. Some routing protocols operates in context for which reachability is more important than attributes associated with the destination. In such scenarii, Byzantine robustness aims at protecting reachability. This manages opportunities for "severed configurations" in which some local policy requirements for a traffic could not be enforced though reachability is still possible / probable (Remember that what is often expected on the Internet is a high probability of packet delivery). Puig, et al. Expires January 6, 2005 [Page 26] Internet-Draft Routing Protocols Security Requirements July 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 propagated through the network, out of originator's control. Security mechanisms addressing the control side will have no control on the way data are eventually propagated. Moreover, believing that other devices will propagate the information unmodified is naive. As an instance, aggregation or filtering may be threats against resources' properties. As a consequence, it is important to know whether the originated information is authentic or not. Even though trusting unauthenticated information may appear to be a necessity in some scenarios, it is useful to set such a distinction on information so as to derive a confidence level associated with it. In order to allow for origin authentication, information may be considered as a kind of 'record', composed of sections of the kind: o Network resources description o Related properties set by resources' controller. o Integrity and data-origin authenticity evidence of information, provided by the controller of the resources. This evidence should be lifetime limited. o Properties set by propagators of routing information (possibly with a time-limited authenticity evidence). If propagators discard authenticity evidence, then the information should acquire a lower preference level. The division presented in Section 5.1 between the controller and the advertiser allows for granting the advertising device with a very limited control on what is advertised; this is an interesting protection against potential damages resulting from possible advertiser's subversion. The concept of an authorization chain linking ownership, control and advertisement is nonetheless necessary in order to build confidence between neighbors from different organizations. An issue with this kind of model is the need for a definition (or furthermore: a specification and an allocation scheme) of identities. Obviously, on a large scale, this kind of data protection requires public key operations, regardless of the actual technology eventually Puig, et al. Expires January 6, 2005 [Page 27] Internet-Draft Routing Protocols Security Requirements July 2004 used (authorization tokens, digital signature). There are quite a lot of drawbacks associated with cryptography in general and with public key cryptography in particular. Where these drawbacks affect devices, an increase amount of memory is needed for buffering cryptographic information and for caching (cf. next paragraph). Besides, public key operations are also quite CPU consuming. A performance study SHOULD be pursued when designing a routing protocol using cryptography; threats opened because of crypto processing SHOULD NOT nullify the interest of tackling routing threats which would result in comparable consequences (eg. disruption). A performance study often requires hypotheses on the underlying hardware, which is somewhat restricting but necessary. Where these drawbacks concern the overall architecture, they involve deployment, administration and public information reachability issues. Regarding this latter topic, in-band or stand-alone channels are necessary for the provision of public data, for revocation and for key roll-over. A routing protocol may find itself in a dead-end if such a channel is needed for authenticity check of data which are necessary to enable access to the ad-hoc channel. This is a tricky point, which may claim for a distributed caching mechanism. Caching is all the more important when scalability is a significant issue and when centralization of data creates bottleneck; on the other hand, the whole architecture is less reactive in case revocation or key roll-overs are required, even though soft key transitions should not be necessary in this context. Further in this direction, neighbors' public material may be kept in non-volatile storage for recovery. There may be no routes available in order to retrieve this material after a reboot, though in-band provisioning within the routing protocol is also a possibility. Whatever the path taken by an architecture specification, it's resistance against trivial denial of services must be evaluated. Requirements related to this section are R(1.*), R(2.*), R(3.[4-6]). All cryptographic material MUST have their lifetime limited, and both evaluated in terms of time and in terms of amount of data. Public keys strength is a matter of context: in inter-domain operations, one may expect that public material will not change very often, and then such a material should be significantly strong. Locally, the rate of public material updates may depend on administrator's decision; he alone evaluates the risks for the network and the administrative cost. In a conference, people may build a ephemeral network by exchanging public material on an direct Puig, et al. Expires January 6, 2005 [Page 28] Internet-Draft Routing Protocols Security Requirements July 2004 IR link before roaming and participating in ad-hoc routing through wireless links; public material is such a case would only be used a few hours and may be kept voluntarily weak. 7.2 Techniques when Propagating When propagating, security requirements have a tendency to focus on the control plane. Propagation security is that of entities communicating in a direct fashion (and perhaps interactively) over the transport subsystem. In such a situation, we're concerned with: o Integrity: data integrity between neighbors is an obvious requirement. Note that error detection and correction codes are not integrity evidences. Means to achieve integrity are signed-hash and keyed-hash. Data integrity is always closely related to authenticity. o Authenticity: the above feature is of no use without authentication of the information producer. Authenticating correctly the messages sent from neighbors is one of the most important security requirement. Authentication techniques that can be considered are: digital signature, keyed hash. o Anti-replay: comes here mainly for protection against active attacks from subverted Links, though this feature will also provide protection against 'natural' packets duplication. Note that underlying layers may provide an unauthenticated anti-replay feature, which would be of no use from a security point of view unless it gets also authenticated. Authentication of routing exchanges sequence numbers may bring this kind of protection to the protocol. Other features include confidentiality and traffic flow confidentiality, which are generally out of scope in routing protocols (cf. R(8.*) and R(9.*)). Main differences with origin-based security practices presented in the previous section include: o message oriented protection (as opposed to data protection), o messages are addressed (to one or many peers), o messages are limited in time through anti-replay techniques (as opposed to limited lifetime), o neighbors may use symmetric cryptography. Puig, et al. Expires January 6, 2005 [Page 29] Internet-Draft Routing Protocols Security Requirements July 2004 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. Requirements related to this section are R(1.*), R(3.[1-3]) and R(4.*). Section 5.3.3 is also related to this section. When possible, methods to derive a symmetric key from public exponents should be used, given that the symmetric cryptography operations considered are less computationally expensive. Caution should be taken if the number of devices sharing the same symmetric key is greater than two. Puig, et al. Expires January 6, 2005 [Page 30] Internet-Draft Routing Protocols Security Requirements July 2004 Limiting keys lifetime and refreshing them is merely cryptographic hygiene. Therefore, a refresh mechanism is REQUIRED both for public keys and for session keys; Public keys may not require a soft transition, while refreshing session keys may require to move from the old key to the new one with no session interruption. For session keys, lifetime SHOULD be evaluated both in terms of time and of amount of data. Actual mechanisms used to limit key lifetime MAY either be based on an explicit lifetime associated with key (ex: public key bundled with a validity date) or on roll-over. Both MAY be used simultaneously for different purposes within a single system. 7.3 Security of the Functional Parts The threats document [THREATS] introduces a set of functions commonly shared by routing protocols: the transport subsystem, the neighbor state maintenance function and the database maintenance function. Each of these functions may contain inner security weaknesses and simultaneously a potential for providing adequate security services for the interest of operation of the whole system. In the following sections, the security related parts of these functions are explored. 7.3.1 Transport Subsystem "The routing protocol transmits messages to its neighbors using some underlying protocol. For example, OSPF uses IP, while other protocols may run over TCP" [THREATS]. One may design a routing protocol independent -to a certain extent- from a specific transport subsystem, by requiring the availability of a minimal set of capabilities from this subsystem. Yet, relevant, specific capabilities of a transport subsystem SHOULD be exploited by a routing protocol. An adequate transport subsystem provides capabilities which would be cumbersome if included in the routing protocol itself and have been -ideally- thoroughly tested. This is a net gain in complexity, even though at the expense of added complexity on protocol interactions and addresses resolution mechanisms. FR(T.1) A routing protocol specification SHOULD document which capabilities of the transport subsystem are exploited by the routing protocol. Puig, et al. Expires January 6, 2005 [Page 31] Internet-Draft Routing Protocols Security Requirements July 2004 FR(T.2) Where issues may arise from interactions between the transport subsystem and the routing protocol, the specification MUST mention these issues (The "Security Considerations" section may be the appropriate place for IETF/IRTF documents). The transport subsystem may already provide the following properties: o Neighbors discovery and maintenance: A given Transport Subsystem technology may provide a way to discover and communicate with adjacent devices participating in the routing domain (neighbors). This is a critical property. o Range limitation: the subsystem may provide a way to limit propagation of messages outside a certain range and in the same way limit intrusions from outsiders in the neighborhood. This may be achieved either through the use of an appropriate layer (likely, link layer), through special addresses (limited broadcast, multicast, link-local, site-link, etc.), through conditions expressed on TTL (see also [BTSH]). This provides a limited access control to neighborhood (yet, there are ways around these limitations: VLAN frames hopping, tunneling). o Separate control channel: if the underlying technology provides separated channels for control traffic and user data traffic, this may help against DOS against the routing protocol. Such control channels may be provided via the same Link Layer infrastructure, or perhaps via a distinct network. o Integrity: While the Transport Subsystem chosen by the routing protocol designer may provide error detection code, this does not provide data integrity from a security point of view. The Transport Subsystem may also provide data integrity which will still be useless from a security perspective if the secret material used by the data integrity service cannot be tied to the routing protocol participant identity. o Authenticity: if the underlying layer both provides authenticity and integrity, many routing threats may be thwarted. Further investigations are required though, among which are studies of resistance to replay, performance, Byzantine detection and robustness, etc. In such a case, the documentation of the routing protocol MUST state which security properties are provided by the Transport Layer, which are provided by the routing protocol design and eventually how they interact (cf. FR(T.2)). o Address spoofing protection: the subsystem is protected against address spoofing if integrity and authenticity evidence covers also the address. Puig, et al. Expires January 6, 2005 [Page 32] Internet-Draft Routing Protocols Security Requirements July 2004 7.3.2 Neighbor State Maintenance "Neighboring relationship formation is the first step for topology determination. For this reason, routing protocols may need to maintain state information. Each routing protocol may use a different mechanism for determining its neighbors in the routing topology. Some protocols have distinct exchanges through which they establish neighboring relationships, e.g., Hello exchanges in OSPF" [THREATS]. Specifications MAY document the use of cookies or damping mechanisms in order to protect this function from trivial denial of services. 7.3.3 Database Maintenance "Routing protocols exchange network topology and reachability information. The routers collect this information in routing databases with varying detail. The maintenance of these databases is a significant portion of the function of a routing protocol" [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. Such mechanisms MAY affect gently resources flags, according to the reliability of information acquired in this way. In some cases, it may prove advisable to consider these hints as bonus for the information preference (as an instance, when destinations are overclaimed, detecting dead networks behind the large prefix should not result in depreciating the overclaimed information [this is open to discussion, of course]). 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, fail-back procedures MAY be attempted, based on previous recorded states, fail-safe states or heuristics on the routing information and on trust. Degradation of the service should often be better than no service at all, thus the device may adjust local route costs information when such events occur. The routing protocol design may document guidelines and requirements on such procedures. Puig, et al. Expires January 6, 2005 [Page 33] Internet-Draft Routing Protocols Security Requirements July 2004 Network management MUST be able to install unalterable (static) routes to allow debugging network problems without interference from routing protocols. Such routes may be pre-configured and loaded upon detection of abnormal behaviors (flapping...). 7.4 Date and Time Issues Puig, et al. Expires January 6, 2005 [Page 34] Internet-Draft Routing Protocols Security Requirements July 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, possibly involving device's 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 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. A routing device MAY be set to drop/reject routing messages if these are incorrect with current configuration of the network, e.g. if Puig, et al. Expires January 6, 2005 [Page 35] Internet-Draft Routing Protocols Security Requirements July 2004 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 8.2 Local Resources Considerations Even though this document addresses routing protocols, these cannot operate without a platform of hardware and software to support them. All the resources belonging to this platform form what is generally referred to as a router. Thus, routers comprise all local resources of a routing daemon participating in a routing session. This section will first highlight critical underlying components and their security issues regarding Denial of Service (DoS) vulnerabilities and then suggest suitable routing protocols' requirements addressing these issues. 8.2.1 Denial of Service Attacks The Computer Emergency Response Team (CERT) defines in [DOS] Denial of Service attacks as being explicit attempts by attackers to prevent legitimate users of a service from using that service. Denial of Service attacks can be launched against a target for the mere purpose of preventing the victim from using a resource or can be a component of a greater attack that may ultimately aim at stealing information. A modern router is a complex system made of several hardware and software components that interact in the effort to serve the general purpose of routing as defined in Section 3. All of these components are finite resources and therefore intrinsically prone to Denial of Service. The impact of Denial of Service attacks on certain local resources can be critical for the routing protocols running on them. 8.2.2 Hardware Resources Almost every hardware component in a router is essential to the correct functioning of the local instances of the various routing protocols that run on it, for example - trivially speaking - without power no packets will be routed. Among others buffers/queues and CPU cycles are two of the less obvious resources that are critical for routing protocols. 8.2.2.1 Buffers/Queues Buffers are widely used in hardware to store information that needs Puig, et al. Expires January 6, 2005 [Page 36] Internet-Draft Routing Protocols Security Requirements July 2004 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 easier it will be for an attacker (or a faulty router) to find a single service/process that will exhaust a significant portion of the available CPU cycles, denying service to other processes, such as routing. 8.2.2.3 Buffer/Queues and CPU Cycles Requirements Routing messages SHOULD be identifiable as coming from legitimate participants in their routing session before being directed towards the control-plane. If any rate limiting mechanism is intended by the routing protocol to mitigate congestion of control-plane links, said solution MUST be Puig, et al. Expires January 6, 2005 [Page 37] Internet-Draft Routing Protocols Security Requirements July 2004 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 rely 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 configuration parameter or can be restricted only by the hardware memory available to the routing platform. Either way, when this limit is approaching, for any of the databases maintained by a routing protocol, some action must be taken. Puig, et al. Expires January 6, 2005 [Page 38] Internet-Draft Routing Protocols Security Requirements July 2004 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 January 6, 2005 [Page 39] Internet-Draft Routing Protocols Security Requirements July 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 routing tables; this reduces tables size and improve general performances, even though this may threaten performances on a specific path. When preferred (eg. for confidentiality reasons), some specific routes may appear in the table. A problem with hierarchical addressing is that, when used as such in the routing protocol, it may generate resources masking. This is especially obvious with operations like aggregations of destinations or removal of a specific destination: both these operations will result in the generic entry taking over the specific one. These operations may be considered as a violation of ownership, though it is also unclear whether a shorter prefix ownership should -administratively speaking- involve authority on a corresponding longer prefix. On the other hand, if care is taken within the routing protocol to protect specific routes against overclaiming resulting from aggregations or removal, then this involves extra architecture requirements and more bandwidth get consumed in routing protocol exchanges. Besides, this will not prevent routing tables from aggregating or removing entries, and this kind of decorrelation between routing information and the way packets get actually forwarded may not be desirable, even though loose relation between local routing tables and routing information is common. Another part of the problem is public information reachability. When public material may help in establishing right to claim resources, availability of the required material is problematic. Section 7.1 presents this in further details. With regard to public cryptography, it should be clear that a light paradigm (authorizations ?) would better fit in most cases, though third parties also appear to be a necessity at this point. Puig, et al. Expires January 6, 2005 [Page 40] Internet-Draft Routing Protocols Security Requirements July 2004 9.2 Propagating policies Policy propagation within a routing protocol which operates between administrative routing domains, exterior gateway protocols, is very difficult. This particular area of security is fraught with difficulties making it next to impossible to actually secure policy across multiple administrative domains. Since each administrative domain can add policies to a given route, anyone can essentially insert any policy. Even if a full history of policies is available, the question: "Who's policy are we honoring ?" has to be answered. The originator's policy ? Or the AS we received the route from ? Or the AS that currently has the route ? Or some other AS ? 9.3 Coherence Where domains are multi-homed, should operations of the edge routers be coherent ? In a nutshell: should a domain be considered as a stand-alone, non-schizophrenic, entity ? Note that coherence does not preclude edge routers from behaving differently. 9.4 Confidentiality As was mentioned several times previously, confidentiality is usually not a design goal of routing protocols. In inter-domain operations, enabling confidentiality would require finding a balance between information that is required to be publicly available and information whose concealing is desirable. May be a possible path is not to care about concealing destination info, but about properties applying to resources. Yet, the value of a route without knowledge of according properties is certainly dubious. 9.5 Agreements involving operators Secure EGPs operations will require kind of agreements between the involved parties. Though operators may achieve these agreements on a case by case basis, this is unlikely to be effective in the field. Emergence of trusted third parties upon which would rely the diffusion of public key material and relations to prefix ownership would fit better. Another question is whether these pieces of information must be tied with public information related to the system ownership, such as the organization name. This may lead to specific routing policies or abuses that would introduce more complexity. Access control also imply agreements: who's granted right to Puig, et al. Expires January 6, 2005 [Page 41] Internet-Draft Routing Protocols Security Requirements July 2004 participate to the protocol ? Puig, et al. Expires January 6, 2005 [Page 42] Internet-Draft Routing Protocols Security Requirements July 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 January 6, 2005 [Page 43] Internet-Draft Routing Protocols Security Requirements July 2004 11. References 11.1 Normative References [AH] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998, . [DAMPING] Villamizar, C., Chandra, R. and R. Govindan, "BGP Route Flap Damping", RFC 2439, November 1998, . [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, . [KEYWORDS] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, . [SEC-GLOSS] Shirey, R., "Internet Security Glossary", RFC 2828, May 2000, . 11.2 Informative References [BTSH] Vijay, G., Heasley, J. and D. Meyer, "The BGP TTL Security Hack (BTSH)", Internet Draft; version 02, May 2003, . [BYZANTINE] Perlman, R., "Network Layer Protocols with Byzantine Robustness", , August 1988, . [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, . [SMITH] Smith, R. and al., "Securing Distance-Vector Routing Protocols", Symposium on Network and Distributed System Security , February 1997, . [THREATS] Barbir, A., Murphy, S. and Y. Yang, "Generic Threats to Routing Protocols", Internet Draft; version 06, April 2004, . 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/ 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 January 6, 2005 [Page 45] Internet-Draft Routing Protocols Security Requirements July 2004 Appendix A. Acknowledgments The authors would like to acknowledge the suggestions and contributions of: o Russ White - CISCO Puig, et al. Expires January 6, 2005 [Page 46] Internet-Draft Routing Protocols Security Requirements July 2004 Appendix B. Revision History B.1 Changes from draft-puig-rpsec-generic-requirements-02 Further development on requirements. Incorporation of off-list comments. Deletion of solution space paragraphs. B.2 Changes from draft-puig-rpsec-generic-requirements-01 TOC tweaking. Phrasing simplifications. Development of the requirements. B.3 Changes from draft-puig-rpsec-generic-requirements-00 Full TOC change. Puig, et al. Expires January 6, 2005 [Page 47] Internet-Draft Routing Protocols Security Requirements July 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Puig, et al. Expires January 6, 2005 [Page 48]