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, . [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, . 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, . [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/ 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]