Network Working Group JJ. Puig Internet-Draft E. Jones Expires: April 23, 2004 D. McPherson October 24, 2003 Security Requirements for Routing Protocols draft-puig-rpsec-generic-requirements-01 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 April 23, 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. Puig, et al. Expires April 23, 2004 [Page 1] Internet-Draft Routing Protocols Security Requirements October 2003 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 2. General Considerations . . . . . . . . . . . . . . . . . . . 6 2.1 High Level Requirements . . . . . . . . . . . . . . . . . . 6 2.2 Routing Protocols within Scope . . . . . . . . . . . . . . . 6 3. Threats Mitigation Rationale . . . . . . . . . . . . . . . . 7 3.1 Threats Elected for Mitigation . . . . . . . . . . . . . . . 7 3.2 Threats Put Aside . . . . . . . . . . . . . . . . . . . . . 7 4. Routing Functions Overview . . . . . . . . . . . . . . . . . 9 4.1 Routing Protocols Components . . . . . . . . . . . . . . . . 10 4.2 Routing Devices Components . . . . . . . . . . . . . . . . . 11 5. Routes Descriptions . . . . . . . . . . . . . . . . . . . . 12 6. Security Requirements . . . . . . . . . . . . . . . . . . . 13 6.1 Routing Control Plane . . . . . . . . . . . . . . . . . . . 13 6.2 Data Control Plane . . . . . . . . . . . . . . . . . . . . . 15 6.3 Transport Subsystem . . . . . . . . . . . . . . . . . . . . 16 6.4 Addressability . . . . . . . . . . . . . . . . . . . . . . . 17 6.5 Neighbors . . . . . . . . . . . . . . . . . . . . . . . . . 18 7. Cryptographic Considerations . . . . . . . . . . . . . . . . 20 7.1 Basic Cryptographic Requirements . . . . . . . . . . . . . . 20 7.2 Cryptographic Keys Requirements . . . . . . . . . . . . . . 21 7.3 Performances . . . . . . . . . . . . . . . . . . . . . . . . 22 7.4 Use of Cryptography . . . . . . . . . . . . . . . . . . . . 23 7.5 Specific Considerations for External Gateway Protocols . . . 24 7.6 Specific Considerations for Link State Protocols . . . . . . 24 7.7 Specific Considerations for Distance Vectors Protocols . . . 25 7.8 Best Common Practices . . . . . . . . . . . . . . . . . . . 25 7.9 Currently Available Solutions . . . . . . . . . . . . . . . 25 8. Active Participation to Security . . . . . . . . . . . . . . 26 8.1 Checking . . . . . . . . . . . . . . . . . . . . . . . . . . 26 8.2 Reporting . . . . . . . . . . . . . . . . . . . . . . . . . 26 8.3 Reacting . . . . . . . . . . . . . . . . . . . . . . . . . . 26 9. Local Resources Considerations . . . . . . . . . . . . . . . 28 9.1 Denial of Service Attakcks . . . . . . . . . . . . . . . . . 28 9.2 Hardware Resources . . . . . . . . . . . . . . . . . . . . . 28 9.3 Logic (Software) Resources . . . . . . . . . . . . . . . . . 30 10. Inter domain routing issues . . . . . . . . . . . . . . . . 32 10.1 Legitimacy . . . . . . . . . . . . . . . . . . . . . . . . . 32 10.2 Policies . . . . . . . . . . . . . . . . . . . . . . . . . . 32 10.3 Agreements involving operators . . . . . . . . . . . . . . . 32 11. Security Considerations . . . . . . . . . . . . . . . . . . 33 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34 Normative References . . . . . . . . . . . . . . . . . . . . 35 Informative References . . . . . . . . . . . . . . . . . . . 36 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 37 A. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . 38 B. Protection achieved by the requirements . . . . . . . . . . 39 Puig, et al. Expires April 23, 2004 [Page 2] Internet-Draft Routing Protocols Security Requirements October 2003 B.1 Protection from Threat Sources . . . . . . . . . . . . . . . 39 B.2 Protection from Threat Actions . . . . . . . . . . . . . . . 39 C. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 41 D. Requirements Summary . . . . . . . . . . . . . . . . . . . . 42 E. Revision History . . . . . . . . . . . . . . . . . . . . . . 43 E.1 changes from draft-ietf-rpsec-routing-security-requirements-00 . . . . . 43 Intellectual Property and Copyright Statements . . . . . . . 44 Puig, et al. Expires April 23, 2004 [Page 3] Internet-Draft Routing Protocols Security Requirements October 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 A). This document is organized as follows: o Section 2 presents general considerations relative to the security of routing protocols and routing systems, and routing protocols categories within scope. o Some threats defined in [THREATS] can be mitigated, others can not. Section 3 is a rationale about threats elected for mitigation. o Section 4 presents a routing functions overview. o Section 5 presents an overview of routes descriptions. o Actual routing protocols security requirements are defined in Section 6. o Section 7 describes cryptographic considerations for routing operations. o Section 8 provides considerations regarding active behaviors of routing devices in the overall security of the routing negotiations. Puig, et al. Expires April 23, 2004 [Page 4] Internet-Draft Routing Protocols Security Requirements October 2003 o Section 9 addresses problems related to local resource exhaustion. o Section 10 introduces the inter-domain puzzle. o Appendix B explains how threats elected in Section 3 are actually mitigated by requirements presented in Section 6. o Appendix C gives examples. o Appendix D is a summary of the requirements. Puig, et al. Expires April 23, 2004 [Page 5] Internet-Draft Routing Protocols Security Requirements October 2003 2. General Considerations This section provides general considerations on the design of secure routing protocols. 2.1 High Level Requirements [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 Routing Protocols within Scope Currently, routing protocols addressed in this document are those limited by the rpsec WG 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. [TBD] We may need to add some verbosity level off the above ? Puig, et al. Expires April 23, 2004 [Page 6] Internet-Draft Routing Protocols Security Requirements October 2003 3. Threats Mitigation Rationale This section describes which threats extracted from [THREATS] were considered in establishing these security requirements. Some threats were put aside because they were considered either not tractable or not worthing an additional performance / complexity trade-off. Knowledge of the limits of the requirements presented in this document is essential. 3.1 Threats Elected for Mitigation o Spoofing should be mitigated, and this was considered. However, spoofing is closely tied to the concept of identity and this identity is often also an address. Protection against address spoofing requires extra care. [AH] may be seen as an instance of a protocol with built-in address spoofing protection. o Falsification is one of the most significant threats against routing protocols. It is the main target of the requirements presented in this document. o Interference is only partly tractable: protection against replay of out-dated packets, reaction to suspect slowdowns are possible. However, there is little to nothing that can be done against a subverted link or router which drop packets or receipts; only fail-back procedures / redundant paths are applicable here. o Overload protection requires appropriate design of both the routing protocol and the routing device. Several sections of this document bring further information about resources consumption and exhaustion. o Byzantine failure occurs when at least one authorized device get subverted. Thus, many threats are also Byzantine failures. The Byzantine general problem resolution is limited by hypotheses which are reminded in this document. 3.2 Threats Put Aside o Deliberate Exposure, provided that it is NOT also a falsification, is put aside in this version of the document because it is currently unclear under which circumstances such a threat may happen and what is actually the value of the information exposed. Lastly, it seems that there is little that can be done against this. o Sniffing is put aside because protection against it would involve Puig, et al. Expires April 23, 2004 [Page 7] Internet-Draft Routing Protocols Security Requirements October 2003 additional resources requirements on routing devices and additional complexity, whether this would be built directly within the routing protocol or not. For this version of the document, authenticity and integrity of routing information got more concern than it's confidentiality (confidentiality is a MAY). o Traffic Analysis protection is difficult to achieve and requires a general approach which cannot be limited to routing protocols only. Note that an effective protection against traffic analysis not only involves headers addresses camouflage, but also size and intermediate times scrambling. [TBD] Think about setting the confidentiality service as a MAY requirement; confidentiality thwarts partly interest of exposing / sniffing / analyzing traffic. Puig, et al. Expires April 23, 2004 [Page 8] Internet-Draft Routing Protocols Security Requirements October 2003 4. Routing Functions Overview [TBD] For the very moment, what you can find here is merely a cut and paste from the threat doc. The question is: do we really need this section ? if yes, should we add / change things in the following ? I suggest we start from this and specialize the description for specific classes of routing protocols. This section provides an overview of functions which can be found in various routing protocols. Following sections may refer to this description for the sake of an accurate description of some considerations. In general, routing protocols share the following functions: o 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. o Neighbor State Maintenance: neighboring relationship formation is the first step for topology determination. For this reason, routing protocols may need to maintain the state of their neighbors. Each routing protocol may use a different mechanism for determining its neighbors in the routing topology. Some protocols have distinct exchange through which they establish neighboring relationships, e.g., Hello exchanges in OSPF. o 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. A router's functions can be divided into control and data plane (protocol traffic vs. data traffic). In a similar fashion, a routing protocol has a control and a data plane. A routing protocol has a control plane that exchanges messages that are intended only for control of the protocol state. Routing protocol data plane uses messages to exchange information that is intended to be used in the forwarding function. For example, the information can be used to establish a forwarding table in each router or to return a description of the route to be used. Routing functions may affect the control and the data planes. However, there may be an emphasis on one of the planes as opposed to the other. For example, neighbor maintenance is likely to focus on the routing protocol control plane, while database maintenance may Puig, et al. Expires April 23, 2004 [Page 9] Internet-Draft Routing Protocols Security Requirements October 2003 focus on the data plane. [TBD] We should introduce the management plane somewhere !!! 4.1 Routing Protocols Components [TBD] Honestly, I doubt the following is useful. Comments are welcome on whether it actually is. If yes, we need advises on actual content. 4.1.1 IGP IGPs functions are summarized by the above statements. Database construction is achieved thanks to ``classical'' versions of route computation algorithms. 4.1.2 EGP Exterior gateway protocols historically embeds functional features related to Neighbor Reachability and Network Reachability. These are almost directly mapped to Neighbor State and Database Maintenance. Other common functions may include: o Decision: the process through which local network reachability information is built from inbound updates received from peers. The decision function is more specific than a simple route computation algorithm in that it includes policies configuration expressed through the management plane. o Coherence: a EGP may implement a specific mechanism in order to assert that external gateways from the same AS export coherent pieces of information. 4.1.3 Link State Link state protocols functions are achieved through periodic flooding on unicast or multicast addresses. 4.1.4 Distance Vectors Database Maintenance function of distance vectors protocols relies on distributed algorithms. Communication with neighbors is commonly achieved through broadcast. 4.1.5 Ad-Hoc Routing protocols for Ad-Hoc Networks implement very specific approaches of neighbors state and database maintenance. A significant Puig, et al. Expires April 23, 2004 [Page 10] Internet-Draft Routing Protocols Security Requirements October 2003 amount of topology knowledge may be acquired in a reactive fashion. Updates at both control plane level and data plane level may require either flooding on short periods or active demand. Routing decisions may eventually be the result of a heuristic on orthogonal requirements involving also QoS and power management. Sometimes, multiple path to the same destination are recorded in the database. 4.1.6 Multicast [TBD] Is-it really useful a section ? Why did we put it in the first place ? Multicast provides an alternate way to address neighbors. Group membership management relies on specific functions. 4.2 Routing Devices Components [TBD] Puig, et al. Expires April 23, 2004 [Page 11] Internet-Draft Routing Protocols Security Requirements October 2003 5. Routes Descriptions [TBD] The way routes are presented affects the overall security of the routing protocol. We should develop on this. E.g. full path description vs next hop. Puig, et al. Expires April 23, 2004 [Page 12] Internet-Draft Routing Protocols Security Requirements October 2003 6. Security Requirements 6.1 Routing Control Plane 6.1.1 Adjacency Creation of an adjacency relation with a node SHOULD be completed with the evidence that the peer actually owns the identifier he uses. Protection of keep-alive messages against falsification and replay MUST be provided. [TBD] We need to develop on this !!! 6.1.2 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: o Local instance of the protocol SHOULD NOT rely on correct operation of a particular neighbor, and SHOULD always apply least privilege. Only traffic source and destination should be considered trustworthy. o Messages MUST be authenticated when sent and checked for their authenticity when received. Note that detection and robustness properties are not necessarily correlated. 6.1.2.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, Puig, et al. Expires April 23, 2004 [Page 13] Internet-Draft Routing Protocols Security Requirements October 2003 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 6.5) 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.1.2.4 and [BYZANTINE]. 6.1.2.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. 6.1.2.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 Puig, et al. Expires April 23, 2004 [Page 14] Internet-Draft Routing Protocols Security Requirements October 2003 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). 6.1.2.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 reachability is still possible / probable. 6.2 Data Control Plane 6.2.1 Data Integrity / Source Authenticity Messages at the data control plane MUST be protected agaisnt unauthorized modifications. This implies that exchanges are protected by a combination of authenticity, integrity and anti-replay properties. 6.2.2 Legitimacy Inbound data SHOULD be checked for it's legitimacy. [TBD] One may investigate use of authorization tokens to do this. Aggregation will certainly jeopardize such a property. Depending on the bandwidth available, it may be possible to do without aggregation for the exchanges (this does not imply that local forwarding table may not aggregate entries). 6.2.3 Dampening mechanisms for DOS mitigation The rates at which updates are accepted and probably unstable routes are propagated MUST be limited. Further information is available in [DAMPING]. 6.2.4 Paths for addressing underclaiming/overclaiming [TBD] We should remove this section. Protection against overclaiming is partly addressed through legitimacy control (unless events like Puig, et al. Expires April 23, 2004 [Page 15] Internet-Draft Routing Protocols Security Requirements October 2003 aggregation happen). Underclaiming was discarded in the threat doc. 6.3 Transport Subsystem The Transport Subsystem may already provide the following properties: o [OLD] (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 Subsystem technology may provide a way to discover and communicate with adjacent devices participating in the routing domain (neighbors). o [OLD] Integrity: the Transport Subsystem 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 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 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 state 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 channels may be provided via the same Link Layer infrastructure, or perhaps via a distinct network. Puig, et al. Expires April 23, 2004 [Page 16] Internet-Draft Routing Protocols Security Requirements October 2003 6.3.1 Generic Requirements / Expectation The choice of the Transport Subsystem for the routing protocol may ease the requirements. Any routing protocol designed to run on a specific Transport Subsystem MUST document or provide appropriate references to the security properties provided by the Transport Subsystem. [TBD] A MUST sounds reasonable ? A routing protocol designed to be, within a certain extent, Transport Subsystem independent, may provide options to activate built-in security features on-demand when security provided by a Transport Subsystem is insufficient. Though such a flexibility would help avoiding potential redundancy of functions with the Transport Subsystem 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 Subsystems without further processing. [TBD] The above is complicated a bit. Who would do that anyway ? Do we remove this ? 6.3.2 Layer 2 Layer two is limited to one (IP) system away. Addressing is available in anycast, multicast and broadcast. Some Layer 2 technologies are bundled with built-in cryptographic protections. However, these are often unused because they require extra management. It is highly restrictive to build a routing protocol security upon the use of a specific layer 2 technology. This greatly limits the interest of deploying an instance of the protocol. 6.3.3 Layer 3 6.3.4 Layer 4 6.4 Addressability 6.4.1 Broadcast / Multicast 6.4.2 Ad-Hoc / Anycast Puig, et al. Expires April 23, 2004 [Page 17] Internet-Draft Routing Protocols Security Requirements October 2003 6.4.3 Unicast 6.5 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. 6.5.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. 6.5.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. 6.5.3 Link Layer Direct use of the Link Layer instead of Network (IP) Layer for communications of the routing protocol limits neighborhood Puig, et al. Expires April 23, 2004 [Page 18] Internet-Draft Routing Protocols Security Requirements October 2003 implicitly. In some cases (VLAN frame hopping, Wireless LANs), an outsider may still break in the neighbors zone. 6.5.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. Puig, et al. Expires April 23, 2004 [Page 19] Internet-Draft Routing Protocols Security Requirements October 2003 7. Cryptographic Considerations This section presents cryptographic requirements for routing protocols. 7.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 Puig, et al. Expires April 23, 2004 [Page 20] Internet-Draft Routing Protocols Security Requirements October 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 ? 7.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. 7.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 Puig, et al. Expires April 23, 2004 [Page 21] Internet-Draft Routing Protocols Security Requirements October 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. 7.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. 7.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. 7.3 Performances Device resources (CPU, memory) might be overloaded by cryptographic operations, especially by public key computations. These performance Puig, et al. Expires April 23, 2004 [Page 22] Internet-Draft Routing Protocols Security Requirements October 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 in-band provisioning of public material. [TBD] Does in-band 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 7.2.1. 7.4 Use of Cryptography [TBD] This section should explain how the above cryptography Puig, et al. Expires April 23, 2004 [Page 23] Internet-Draft Routing Protocols Security Requirements October 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 B.1 and Appendix B.2 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. 7.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: 7.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. Puig, et al. Expires April 23, 2004 [Page 24] Internet-Draft Routing Protocols Security Requirements October 2003 7.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. 7.8 Best Common Practices 7.9 Currently Available Solutions Puig, et al. Expires April 23, 2004 [Page 25] Internet-Draft Routing Protocols Security Requirements October 2003 8. 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 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.1 Passively 8.1.2 Actively (quantity a/o quality) 8.2 Reporting 8.2.1 Error Messages 8.2.2 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.3 Reacting Puig, et al. Expires April 23, 2004 [Page 26] Internet-Draft Routing Protocols Security Requirements October 2003 8.3.1 Routing Databases 8.3.1.1 Graceful degradation 8.3.1.2 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 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. 8.3.2 Filtering Ingress Filtering, participant exclusion. A routing device MAY be set to drop/reject routing messages if these are incorrect with current configuration of the network, e.g. if 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.3.3 Correcting Correcting wrong / malicious routing info Puig, et al. Expires April 23, 2004 [Page 27] Internet-Draft Routing Protocols Security Requirements October 2003 9. 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. 9.1 Denial of Service Attacks The Computer Emergency Response Team (CERT) [http://www.cert.org/tech_tips/denial_of_service.html] defines 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 paragraph 2.1. 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. 9.2 Hardware Resources Almost every hardware component in a router is essential to the correct functioning of the local instances of the various routing protocols that run on it, for example - trivially speaking - without power no packets will be routed. Among others buffers/queues and CPU cycles are two of the less obvious resources that are critical for routing protocols. 9.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 Puig, et al. Expires April 23, 2004 [Page 28] Internet-Draft Routing Protocols Security Requirements October 2003 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. 9.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. 9.2.3 Buffer/Queues and CPU Cycles Requirements Routing messages SHOULD be identifiable as coming from legitimate participants in their routing session before being directed towards the control-plane. If any rate limiting mechanism is intended by the routing protocol to mitigate congestion of control-plane links, said solution MUST be designed ensuring that an attacker cannot directly exploit it in the attempt to block a legitimate routing peer from exchanging routing messages. Puig, et al. Expires April 23, 2004 [Page 29] Internet-Draft Routing Protocols Security Requirements October 2003 9.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. 9.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 RFC 2827 [FILTERING], and solutions that relay on Quality of Service mandating that the highest priority and availability be assigned to routing messages. 9.2.5 Bandwidth Requirements Routing protocols MUST be designed to easily inter-work with lower layers Quality of Service mechanisms. 9.3 Logic (Software) Resources Similarly to hardware resources, logic resources can be finite and therefore exhausted thus affording attackers with the possibility of launching Denial of Service attacks. Databases are critical resources for every routing protocol and they may contain information about link-state, direct neighbors, active peers, external routes database, etc... Routing databases have a maximum number of entries that can be stored in them and this is generally not defined by the routing protocols. This upper bound can be set by an administrator through a configuration parameter or can be restricted only by the hardware memory available to the routing platform. Either way, when this limit is approaching, for any of the databases maintained by a routing protocol, some action must be taken. 9.3.1 Logic (Software) Requirements Routing protocols MUST mandate verification of every piece of information that can be verified before committing it to any Puig, et al. Expires April 23, 2004 [Page 30] Internet-Draft Routing Protocols Security Requirements October 2003 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 April 23, 2004 [Page 31] Internet-Draft Routing Protocols Security Requirements October 2003 10. Inter domain routing issues 10.1 Legitimacy Availability of the required material (caching/storing) [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. 10.2 Policies Note that 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. 10.3 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. [TBD] Currently, signed tuples carrying /identity (WRT to RP), address(es), public key, authorization on prefixes and adequate lifetimes/ should be discussed. 10.3.1 Announcing Routes [TBD] Legitimacy for advertising routes / updating information. Using authorization paradigms should be sufficient. 10.3.2 Originating a Prefix / Ownership [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 ? Puig, et al. Expires April 23, 2004 [Page 32] Internet-Draft Routing Protocols Security Requirements October 2003 11. 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. Puig, et al. Expires April 23, 2004 [Page 33] Internet-Draft Routing Protocols Security Requirements October 2003 12. Acknowledgements Mohammed Achemlal, France Telecom R&D, provided feedback and corrections which will be incorporated in the next version of this document. Puig, et al. Expires April 23, 2004 [Page 34] Internet-Draft Routing Protocols Security Requirements October 2003 Normative References [SEC-GLOSS] Shirey, R., "Internet Security Glossary", RFC 2828, May 2000, . Puig, et al. Expires April 23, 2004 [Page 35] Internet-Draft Routing Protocols Security Requirements October 2003 Informative References [AH] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998, . [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. [DAMPING] Villamizar, C., Chandra, R. and R. Govindan, "BGP Route Flap Damping", RFC 2439, November 1998, . [FILTERING] P.Ferguson, 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, . [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, . Puig, et al. Expires April 23, 2004 [Page 36] Internet-Draft Routing Protocols Security Requirements October 2003 Authors' Addresses 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/ 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 April 23, 2004 [Page 37] Internet-Draft Routing Protocols Security Requirements October 2003 Appendix A. 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. Puig, et al. Expires April 23, 2004 [Page 38] Internet-Draft Routing Protocols Security Requirements October 2003 Appendix B. Protection achieved by the requirements B.1 Protection from Threat Sources B.1.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. B.1.2 Subverted Devices B.2 Protection from Threat Actions B.2.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.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.2.3 Traffic Analysis B.2.4 Spoofing B.2.5 Falsification Authentication of sources should help here (care of anti-replay). Special considerations apply to DVPs. Puig, et al. Expires April 23, 2004 [Page 39] Internet-Draft Routing Protocols Security Requirements October 2003 B.2.6 Interference B.2.7 Overload Puig, et al. Expires April 23, 2004 [Page 40] Internet-Draft Routing Protocols Security Requirements October 2003 Appendix C. Examples Puig, et al. Expires April 23, 2004 [Page 41] Internet-Draft Routing Protocols Security Requirements October 2003 Appendix D. Requirements Summary Puig, et al. Expires April 23, 2004 [Page 42] Internet-Draft Routing Protocols Security Requirements October 2003 Appendix E. Revision History E.1 changes from draft-ietf-rpsec-routing-security-requirements-00 Full TOC change. Puig, et al. Expires April 23, 2004 [Page 43] Internet-Draft Routing Protocols Security Requirements October 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 Puig, et al. Expires April 23, 2004 [Page 44] Internet-Draft Routing Protocols Security Requirements October 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. Puig, et al. Expires April 23, 2004 [Page 45]