Network Working Group D. McPherson Internet-Draft JJ. Puig Expires: March 22, 2004 September 22, 2003 Security Requirements for Routing Protocols draft-puig-rpsec-generic-requirements-00 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 March 22, 2004. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract Routing protocols are subject to attacks that can harm individual users or the network as a whole. This document provides a description of basic security requirements for routing protocols and routing systems. McPherson & Puig Expires March 22, 2004 [Page 1] Internet-Draft Routing Protocols Security Requirements September 2003 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 2. General Considerations . . . . . . . . . . . . . . . . . . . 5 2.1 What MUST / SHOULD be protected ? . . . . . . . . . . . . . 5 2.2 Transport Layer Considerations . . . . . . . . . . . . . . . 5 3. Cryptographic Requirements . . . . . . . . . . . . . . . . . 8 3.1 Basic Cryptographic Requirements . . . . . . . . . . . . . . 8 3.2 Cryptographic Keys Requirements . . . . . . . . . . . . . . 9 3.2.1 Public Key Cryptography . . . . . . . . . . . . . . . . . . 9 3.2.2 Crypto-hygiene . . . . . . . . . . . . . . . . . . . . . . . 10 3.2.3 Key Strength . . . . . . . . . . . . . . . . . . . . . . . . 10 3.3 Performances . . . . . . . . . . . . . . . . . . . . . . . . 10 3.4 Use of Cryptography . . . . . . . . . . . . . . . . . . . . 11 3.5 Specific Considerations for External Gateway Protocols . . . 12 3.6 Specific Considerations for Link State Protocols . . . . . . 12 3.7 Specific Considerations for Distance Vectors Protocols . . . 13 4. Neighbors . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.1 Use of TTL . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.2 The TTL Hack . . . . . . . . . . . . . . . . . . . . . . . . 14 4.3 Link Layer . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.4 Limited Broadcast . . . . . . . . . . . . . . . . . . . . . 15 5. The Byzantine Problem . . . . . . . . . . . . . . . . . . . 16 5.1 General Requirements . . . . . . . . . . . . . . . . . . . . 16 5.2 Detection of the Occurence of a Byzantine Failure . . . . . 17 5.3 Byzantine Detection . . . . . . . . . . . . . . . . . . . . 17 5.4 Byzantine Robustness . . . . . . . . . . . . . . . . . . . . 17 6. Local Considerations . . . . . . . . . . . . . . . . . . . . 19 6.1 Priorities and Traffic Control . . . . . . . . . . . . . . . 19 6.2 Extra checks . . . . . . . . . . . . . . . . . . . . . . . . 19 6.3 Filtering . . . . . . . . . . . . . . . . . . . . . . . . . 19 6.4 Fail-back Procedures . . . . . . . . . . . . . . . . . . . . 19 6.5 Auditable Events . . . . . . . . . . . . . . . . . . . . . . 20 7. Agreements Requirements . . . . . . . . . . . . . . . . . . 21 7.1 Authenticating Public Keys . . . . . . . . . . . . . . . . . 21 7.2 Announcing Routes . . . . . . . . . . . . . . . . . . . . . 21 7.3 Originating a Prefix . . . . . . . . . . . . . . . . . . . . 21 8. Security Considerations . . . . . . . . . . . . . . . . . . 22 Normative References . . . . . . . . . . . . . . . . . . . . 23 Informative References . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 24 A. Protection from Threat Sources . . . . . . . . . . . . . . . 26 A.1 Subverted Links . . . . . . . . . . . . . . . . . . . . . . 26 A.2 Subverted Devices . . . . . . . . . . . . . . . . . . . . . 26 B. Protection from Threat Actions . . . . . . . . . . . . . . . 27 B.1 Deliberate Exposure . . . . . . . . . . . . . . . . . . . . 27 B.2 Sniffing . . . . . . . . . . . . . . . . . . . . . . . . . . 27 B.3 Traffic Analysis . . . . . . . . . . . . . . . . . . . . . . 27 McPherson & Puig Expires March 22, 2004 [Page 2] Internet-Draft Routing Protocols Security Requirements September 2003 B.4 Spoofing . . . . . . . . . . . . . . . . . . . . . . . . . . 27 B.5 Falsification . . . . . . . . . . . . . . . . . . . . . . . 27 B.6 Interference . . . . . . . . . . . . . . . . . . . . . . . . 27 B.7 Overload . . . . . . . . . . . . . . . . . . . . . . . . . . 27 C. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . 28 D. Requirements Summary . . . . . . . . . . . . . . . . . . . . 29 Intellectual Property and Copyright Statements . . . . . . . 30 McPherson & Puig Expires March 22, 2004 [Page 3] Internet-Draft Routing Protocols Security Requirements September 2003 1. Introduction Routing protocols are subject to threats and attacks that can harm individual users or the network as a whole [THREATS]. This document provides a description of basic security requirements for routing protocols and routing systems. This work is designed to serve as reference material for current routing protocols analysis, for extensions design, and as a guidance for designing new, more secure, routing protocols and routing systems. 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]. Information about security terms is provided 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''. Additional terms are defined in acronyms section (Appendix C). This document is organized as follows: o Section 2 presents general considerations relative to the security of routing protocols and routing systems. o Section 3 defines cryptographic requirements for routing operations. o Section 4 presents the neighbors issue. o Section 5 provides guidance for tackling Byzantine failures. o Considerations on local decisions are given Section 6. o Agreements requirements and operations involving network operators responsibility are presented Section 7. McPherson & Puig Expires March 22, 2004 [Page 4] Internet-Draft Routing Protocols Security Requirements September 2003 2. General Considerations This section provides general considerations on the design of secure routing protocols. 2.1 What MUST / SHOULD be protected ? [old] Distribution of destination reachability information with the required policy considerations (QoS, trusted route, etc.) is what is expected from a routing protocol. Routing protocols act as managers of a distributed database with very quick synchronization times. They are responsible for distributing information about reachability to destinations attached to the network, and the distribution of policies about the available paths. Reachability MUST be protected against unauthorized route deletions and route additions. Note that these are high level operations; aggregation, for instance, may result in the same consequences as announcing new routes; so may the removal of some routing information, and the policies attending that routing information. Route attributes (path information, metrics, trusted entity for the forwarding of specific traffics) SHOULD also be protected. From an attacker perspective, modifying attributes in order to achieve a precise goal may be more difficult than injecting an additional route. Besides, routing protocols may benefit from protection of routes and lack of protection of route attributes. [TBD] We have to decide if route attributes require as much protection as route existence, probably yes. Note that manipulation of routes associated attributes may achieve the same effects as those resulting from addition / deletion. May be we should insert the final requirement decision in an appropriate section (likely, specific considerations to LSPs and DVPs). 2.2 Transport Layer Considerations The choice of the Transport Layer for the routing protocol may ease the requirements presented in the following sections. Any routing protocol designed to run on a specific Transport Layer MUST document or provide appropriate references to the security properties provided by the Transport Layer. [TBD] A MUST sounds reasonable, yet we can move to a SHOULD. A routing protocol designed to be, within a certain extent, Transport Layer independent, may provide options to activate built-in security McPherson & Puig Expires March 22, 2004 [Page 5] Internet-Draft Routing Protocols Security Requirements September 2003 features on-demand when security provided by a Transport Layer is insufficient. Though such a flexibility would help avoiding potential redundancy of functions with the Transport Layer and adjusting performance requirements, such an approach is usually not desirable because of it's added complexity and hazards and because such a protocol can no longer be ``bridged'' between two different Transport Layers without further processing. [TBD] I realize the above is complicated a bit. Who would do that anyway ? Do we remove this ? The Transport Layer may already provide the following properties: o [OLD VERSION] - I think the alternate version below (from Russ) is well formulated - Neighborhood: a technology may provide a way to address adjacent neighbors. The neighborhood range in this kind of technology is typically of one system away and relies on direct mapping over functions available from the Link Layer. o Neighbors discovery and maintenance: A given Transport Layer technology may provide a way to discover and communicate with adjacent devices participating in the routing domain (neighbors). o [OLD VERSION] - Integrity: the Transport Layer may provide data integrity. This is insufficient to achieve security without proper means of authenticating the system which provided the integrity proof in the first place. o Integrity: While the Transport Layer 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 Layer may also provide data integrity which will still be useless from a security perspective if the proof is hop-by-hop or 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 states which security properties are provided by the Transport Layer, which are provided by the routing protocol design and eventually how they interact. 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 McPherson & Puig Expires March 22, 2004 [Page 6] Internet-Draft Routing Protocols Security Requirements September 2003 channels may be provided via the same Link Layer infrastructure, or perhaps via a distinct network. McPherson & Puig Expires March 22, 2004 [Page 7] Internet-Draft Routing Protocols Security Requirements September 2003 3. Cryptographic Requirements This section presents cryptographic requirements for routing protocols. 3.1 Basic Cryptographic Requirements The following requirements are understood on a producer / consumer of the routing information basis. Relays which modify the content of routing messages are considered both consumers and producers. Relays which do not modify the content of routing messages act as forwarders, are then considered neither producers nor consumers and SHOULD NOT need to provide any of the following while acting as forwarders. o Integrity: data integrity between the producer and the consumer is an obvious requirement. A checksum is not an integrity evidence. Means to have data integrity are signed-hash and keyed-hash. Data integrity is always closely related to authenticity (see below). o Anti-replay: this comes here mainly for protection against active attacks from subverted Links, though this feature will also provide added protection against natural duplication of packets. 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 at the pouting protocol layer. Authentication of routing exchanges sequence numbers may bring this protection to the protocol. o Authentication: the above features are of no use without authentication of the producer. Authenticating correctly the messages sent from neighbors is the most important security requirement for a routing protocol. Authentication techniques that should be considered currently are: digital signature, keyed hash. o [TBD] Is it also important to authenticate the consumer ? In some protocols, peers may establish sessions in which both are alternatively producer and consumer. In the case such a `symmetric' rule does not apply, is there a need to authenticate the consumer or to make sure that only he can access the information ? Should the consumer acknowledge the reception ? Should the acknowledgement be authenticated ? There have been considerations of confidentiality as a mean to counter disclosure of network topology. The gains from such a feature are not obvious, especially because traffic analysis of forwarded data may provide the topology disclosure, and also because McPherson & Puig Expires March 22, 2004 [Page 8] Internet-Draft Routing Protocols Security Requirements September 2003 public information may be required in order to prove the legitimacy of routers for announcing or owning routes or prefixes. Besides, this involves additional performance issues and negotiations which are not particularly desirable. Providing confidentiality is NOT REQUIRED. If such a feature is available, it SHOULD be possible to enable / disable it. [TBD] Although perhaps confidentiality is more important than supposed here. Comments ? Topology disclosure may be a more significant threat for applications than for routing. Should the routing protocol protect an information that could be used to attack another protocol ? Is topology disclosure eventually a significant threat for the routing protocol itself ? 3.2 Cryptographic Keys Requirements Key management involves several considerations, and routing protocols involve several interconnected devices, which may be the properties of distinct organizations. A routing protocol design should analyze scaling issues; within this context, Public key cryptography is currently the most appropriate paradigm. 3.2.1 Public Key Cryptography [TBD] Disclaimer: I'm not sure this section is useful at all, unless we go in further details ? How far can we go in this specification ? e.g., Is it suitable to name protocol fields, and to set specific protection to these ? Public key cryptography is traditionally associated with drawbacks such as administration, deployment, reachability, caching. o Administration cannot be avoided. Because routing devices may not belong to the same organizations, a kind of trusted third party must exist to tie identities, public keys and possibly other contents like suitable addresses or legitimacy to advertise routes or originate prefixes. o Deployment is mainly a scaling issue. Temptation is great to rely upon a mechanism that (almost) succeeded in scaling (DNS, or the routing network itself). On the other hand, care should be taken not to misuse or overload these mechanisms. Correlation of such a mechanism with the routing protocol may lead to easy denials of service or other attacks that MUST be studied. o Reachability of the public key information is REQUIRED. This may be done in-band within the routing protocol, or through a stand-alone protocol. In the latter case, specific consideration McPherson & Puig Expires March 22, 2004 [Page 9] Internet-Draft Routing Protocols Security Requirements September 2003 occurs regarding availability of the service under high traffic or when either forwarding or relaying are severed. Reachability is useful in order to retrieve keys, but also for revocation checking or roll-overs. o Caching should be considered for deployment, reachability and performance. On the other hand, it jeopardizes revocation of keys or roll-over. Eventually, authorizations or public material of the same kind may be kept in a non-volatile storage. 3.2.2 Crypto-hygiene Limiting key 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. 3.2.3 Key Strength [TBD] Give correct lifetime for keys, in years against mips ? Is there a reference document on this topic ? What about: "m years after the standardization of the routing protocol, the keying material should resist n years against p top performance key cracking devices" ? Strength of public keys should be high. Changing these keys may be administratively heavy if they are used in EGPs. Besides, a third party may not emerge if keys have a short lifetime. In IGPs, strength of these keys should not be that high, though this mainly depends on internal administration tasks scheduling. It is acceptable to tear down sessions between routing protocol participants when the public material is changed. Strength of symmetric keys does not require to be high: refresh may happen during low traffic periods (if they exist; if they do not, a suitable heuristic SHOULD enforce the refresh at an appropriate time), and verification must be fast. These keys SHOULD be used only as a fast authentication schemes and the refresh SHOULD NOT result in torn down sessions. 3.3 Performances Device resources (CPU, memory) might be overloaded by cryptographic operations, especially by public key computations. These performance McPherson & Puig Expires March 22, 2004 [Page 10] Internet-Draft Routing Protocols Security Requirements September 2003 issues should be taken into account when designing a routing protocol, otherwise they would open the device to other forms of attacks (denials / degradations of service) that will result in the same consequences as attacks against routing operations. Performance evaluation often requires hypothesis on the underlying hardware, which is somewhat restricting. 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. There had been several discussions on the use of a token based fast rejection scheme, which could be embedded on interfaces of the 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. [TBD] Should we develop on other token-based schemes ? How about building interface dependent token chains when packets / frames are unicast ? This seems a bit tricky to achieve and would grow in square(n interfaces). How about a less efficient approach where the tokens would be checked by the core CPU ? This would infer a little delay during normal service, but under attack this may avoid computation of HMAC or DSIG. Is it acceptable to derive a token chain seed and a session key from only one shared secret material ? BTW, can the token provide the anti-replay feature if it is added within an HMAC computation (this, to save space) ? If so, is it still applicable when the tokens seed and the HMAC secret are derived from the same material ? Lastly, how about a 'reject with a cookie / re-request with cookie approach ? Neighbors authorizations and public materials may be stored in non-volatile storage. Note that there may exist no route to get this material after a reboot. However, the routing protocol itself may also assume inline provisioning of public material. [TBD] Does inline provisioning open a path for resources exhaustion ? Considerations of which other data should be stored in non-volatile storage ? Considerations regarding caching are presented in Section 3.2.1. 3.4 Use of Cryptography [TBD] This section should explain how the above cryptography McPherson & Puig Expires March 22, 2004 [Page 11] Internet-Draft Routing Protocols Security Requirements September 2003 considerations will help countering common threats. It may be wise to wait for the next version of the threat draft before going further. Details are currently rejected in appendix. Correct use of anti-replay, integrity and authentication should suffice to protect against deception or usurpation damages resulting from subverted links or devices (as long as the secret materials are unavailable to the attacker). This will be insufficient to prevent disclosure or disruption. [TBD] Do we need to prevent disclosure anyway ? Subverted routers which are still authorized participants (that is: subverted routers owning the suitable material) in the routing protocol, will be able to process with attacks resulting in all of these damages. Further protection requires a registry stating authorizations for the routing devices to be available, in order to enforce least privileges to the subverted device. This information would be authenticated by an adequate entity. Appendix A and Appendix B details which and how threats mentioned in [THREATS] are thwarted by the requirements presented in this document. The following sections present additional guidance for the specific classes a routing protocol belongs to. 3.5 Specific Considerations for External Gateway Protocols [TBD] Extract from Russ comments: I think you can mention this, but it's actually going to be difficult to impossible to find any way of securing policies within an EGP. Since each administrative domain can add policies to a given route, anyone can essentially insert any policy. The question: "Who's policy are we honoring" has to be answered before we can begin to think about this. The originator's policy? Or the AS we received the route from? Or the AS that currently has the route? Or some other AS? Related considerations: 3.6 Specific Considerations for Link State Protocols [TBD] Are there such considerations ? May be we should design dummy protocols to be more explicit or set up a high level division of RPs features. McPherson & Puig Expires March 22, 2004 [Page 12] Internet-Draft Routing Protocols Security Requirements September 2003 3.7 Specific Considerations for Distance Vectors Protocols Distance vector routing protocols are specific because participants are required to adjust the properties of routes announced by other participants. [TBD] Present appropriate protection of attributes. The originator may authenticate the initial information, and relays may stack in authenticated costs adjustments, route characteristics updates, etc. [SMITH]. We have to decide whether trace-ability of distance adjustments is critical security feature or not. McPherson & Puig Expires March 22, 2004 [Page 13] Internet-Draft Routing Protocols Security Requirements September 2003 4. Neighbors Neighbors are the peers involved in routing operations which can be reached within a maximum number of hops (according to the routing protocol itself). Often, neighbors definition is limited to the systems that are directly reachable through with the Link Layer, regardless of the technology actually used for the Transport Layer of the routing protocol. There are several ways to ensure that the routing information actually comes from a system within a max range. Note that this does not prove that the message itself has been sent by the legitimate system (for instance, it may be a replay from subverted link). It is also possible to provide such a feature within the routing protocol. From a service point of view, it is the original sender's goal to limit the range of it's messages. From a security point of view, it is the recipient's responsibility to CHECK that the message does not come from outside the neighbors zone (e.g. : check use of limited broadcast in destination address field). Use of the following recipes should mirror both these concerns. Lastly, all of this only provides topological protection if used alone. 4.1 Use of TTL In IP packets, the TTL field being decreased by forwarders provides an easy way in order to limit packets propagation. However, this does not protect against outsiders, unless forwarders also act as relays, check origin authenticity of old TTL and authenticate the newly decreased value. 4.2 The TTL Hack The TTL hack [BTSH] is a way to limit the range effect of routing messages and to prevent intrusion in the neighborhood in IP networks. By setting TTL to max value (255), neighbors can check that the message comes from direct neighbors. Spoofed routing messages coming from outside the neighborhood range will get their TTL decreased and be rejected by the routing protocol participants. This does not protect against insiders, nor against outsiders using tunnels to carry engineered packets. 4.3 Link Layer Direct use of the Link Layer instead of Network (IP) Layer for communications of the routing protocol limits neighborhood implicitly. In some cases (VLAN frame hopping, Wireless LANs), an outsider may still break in the neighbors zone. McPherson & Puig Expires March 22, 2004 [Page 14] Internet-Draft Routing Protocols Security Requirements September 2003 4.4 Limited Broadcast Limited broadcast is a simple way to ensure contact with neighbors on the local network when using a Transport Layer layered over IP. McPherson & Puig Expires March 22, 2004 [Page 15] Internet-Draft Routing Protocols Security Requirements September 2003 5. The Byzantine Problem TBD: presentation of the pb [BYZANTINE]. cf. the threats doc. Wait until new threats doc evolution. The following considerations should help in the design of a Byzantine resistant (either through detection or through robustness) routing protocol: Never rely to correct operation of a particular neighbor, always apply least privilege. Only traffic source and destination are trustworthy. Authenticate sent messages, check authenticity of received messages. Note that detection and robustness properties are not necessarily correlated. 5.1 General Requirements TBD: explain here how hypothesis needed for tackling correctly the pb (synchronization, topology considerations...) may be mapped on the specific context of routing protocols. Classical hypothesis for Byzantine failure resolution are: o devices are fully connected, o the decision that must be agreed upon is binary (yes/no), o the network is synchronous, o strictly less than a third of the devices are faulty. Under these hypothesis, 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 [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 (c.f. Section 4) 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 5.4 and [BYZANTINE]. McPherson & Puig Expires March 22, 2004 [Page 16] Internet-Draft Routing Protocols Security Requirements September 2003 5.2 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. 5.3 Byzantine Detection Byzantine detection is much more precise than just detecting a Byzantine failure and consist 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. Automatic responses following a Byzantine detection MUST NOT prevent the subverted devices from participating again when they cease to behave incorrectly. Forwarding options when dealing with a detected subverted device are forwarding along an alternate route if available (Detour), or forwarding anyway if not (Send & Hope). If only a part of non faulty participants can achieve the detection then care should be taken that detection's responses do not deceive non-detector non-faulty devices (the former would appear faulty to the latter and the situation would get worse). Simulating a link shutdown with a subverted device can be investigated. Collaborative approach between detectors to limit the influence of some subverted devices may be quite hazardous. 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 an authentication mechanism). 5.4 Byzantine Robustness Purpose of Byzantine robustness, in the general problem context, is for any given device to achieve algorithm termination, agreement and -naturally- validity. Routing protocols does NOT REQUIRE to achieve neither agreement nor termination. What matters here is validity, with regard to the requirements concerning reachability presented Section 2.1. This manages opportunities for ``severed configurations'' in which some policy requirements for a traffic could not be enforced though McPherson & Puig Expires March 22, 2004 [Page 17] Internet-Draft Routing Protocols Security Requirements September 2003 reachability is still possible / probable. McPherson & Puig Expires March 22, 2004 [Page 18] Internet-Draft Routing Protocols Security Requirements September 2003 6. Local Considerations 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. 6.1 Priorities and Traffic Control Route lookup function SHOULD have higher priority than route maintenance function. Traffic overload may provoke DOS of routing negotiations, while these would precisely help in balancing the high traffic. Forwarding is usually the principal purpose of devices running routing protocols. In order to achieve correctness of forwarding tables, means to enforce availability of the medium to the routing protocol SHOULD be provided (e.g. through the use of an adequate queue policy). For the same reasons, routing traffic SHOULD also be rate limited, so that a routing exchange overload does not jeopardize forwarding of current user traffic (which is likely to carry routing device administration traffic under such circumstances). 6.2 Extra checks 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. 6.3 Filtering 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. 6.4 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 McPherson & Puig Expires March 22, 2004 [Page 19] Internet-Draft Routing Protocols Security Requirements September 2003 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. Network management must be able to install unalterable (static) routes to allow debugging network problems without interference from routing protocols. 6.5 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 ? McPherson & Puig Expires March 22, 2004 [Page 20] Internet-Draft Routing Protocols Security Requirements September 2003 7. Agreements Requirements 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. [TBD] Currently, signed tuples carrying /identity (WRT to RP), address(es), public key, authorization on prefixes and adequate lifetimes/ should be discussed. 7.1 Authenticating Public Keys [Note] It should be clear that a light paradigm would better fit in most cases, so we should avoid the acronym PKI as much as possible, though we have to deal with the problem of the trusted party at some point. 7.2 Announcing Routes [TBD] Legitimacy for advertising routes / updating information. Using authorization paradigms should be sufficient. 7.3 Originating a Prefix [TBD] Ways to prove the right to advertise a prefix. Where will we find the appropriate victim for the administration of these pieces of information ? McPherson & Puig Expires March 22, 2004 [Page 21] Internet-Draft Routing Protocols Security Requirements September 2003 8. Security Considerations This entire informational draft RFC is security related. Specifically it addresses security of routing protocols as associated with requirements to those protocols. 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 can be considered part of that signaling and control plane, may be the most important. However, to date, routing protocols have largely remained unprotected and opened to malicious attacks. This document discusses inter and intra domain routing protocol security requirements as we know them today and lays the foundation for the design of new, more secure, routing protocols. McPherson & Puig Expires March 22, 2004 [Page 22] Internet-Draft Routing Protocols Security Requirements September 2003 Normative References [SEC-GLOSS] Shirey, R., "Internet Security Glossary", RFC 2828, May 2000, . McPherson & Puig Expires March 22, 2004 [Page 23] Internet-Draft Routing Protocols Security Requirements September 2003 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. [KEYWORDS] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, . [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 00, August 2003, . Authors' Addresses Danny McPherson Arbor Networks EMail: danny@arbor.net McPherson & Puig Expires March 22, 2004 [Page 24] Internet-Draft Routing Protocols Security Requirements September 2003 Jean-Jacques Puig INT / LoR / 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/ McPherson & Puig Expires March 22, 2004 [Page 25] Internet-Draft Routing Protocols Security Requirements September 2003 Appendix A. Protection from Threat Sources A.1 Subverted Links Partial protection against subverted links is gained with authenticated integrity proof and anti-replay. These links can still eavesdrop, delay, drop messages. A.2 Subverted Devices McPherson & Puig Expires March 22, 2004 [Page 26] Internet-Draft Routing Protocols Security Requirements September 2003 Appendix B. Protection from Threat Actions B.1 Deliberate Exposure Unless there is some odd use of assigned numbers (part of the public address space, etc.) required by local configuration, deliberate exposure will only mostly result in disclosure of local routing information. If ciphers are used between peers, the disclosure will be limited to participants sharing the key material. Note however that the value of the disclosed information may not be high. If an entity makes fun use of assigned numbers (we are above all concerned about address spaces and AS numbers here), then the deliberate exposure also becomes a falsification (refer to the adequate section). B.2 Sniffing Measure against sniffing may be encryption of routing exchanges. It is not obvious that the intrinsic value of routing information justify an additional resources investment. On the other hand, use of steganography or illusions may be investigated though chances that this provides a powerful alternative are low, even on high bandwidth links. B.3 Traffic Analysis B.4 Spoofing B.5 Falsification Authentication of sources should help here (care of anti-replay). Special considerations apply to DVPs. B.6 Interference B.7 Overload McPherson & Puig Expires March 22, 2004 [Page 27] Internet-Draft Routing Protocols Security Requirements September 2003 Appendix C. Acronyms DVP - Distance Vector Protocol. Routing protocol within which participants maintain distance vectors to destinations, these vectors being updated in a distributed algorithm fashion by inter-participants and participants-destinations distances. EGP - External Gateway Protocol. Routing protocol used between different ASs. IGP - Internal Gateway Protocol. Routing protocol used within a single AS. LSP - Link State Protocol. Routing protocol within which local routing information is broadcast to other participants. McPherson & Puig Expires March 22, 2004 [Page 28] Internet-Draft Routing Protocols Security Requirements September 2003 Appendix D. Requirements Summary McPherson & Puig Expires March 22, 2004 [Page 29] Internet-Draft Routing Protocols Security Requirements September 2003 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 (2003). 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 McPherson & Puig Expires March 22, 2004 [Page 30] Internet-Draft Routing Protocols Security Requirements September 2003 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. McPherson & Puig Expires March 22, 2004 [Page 31]