| TOC |
|
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 (C) The Internet Society (2003). All Rights Reserved.
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.
| TOC |
| TOC |
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:
| TOC |
This section provides general considerations on the design of secure routing protocols.
[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).
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 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:
| TOC |
This section presents cryptographic requirements for routing protocols.
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.
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 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 ?
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.
[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.
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.
[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.
Device resources (CPU, memory) might be overloaded by cryptographic operations, especially by public key computations. These performance 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.
[TBD] This section should explain how the above cryptography 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.
[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:
[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.
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.
| TOC |
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.
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.
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.
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.
Limited broadcast is a simple way to ensure contact with neighbors on the local network when using a Transport Layer layered over IP.
| TOC |
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.
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:
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].
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.
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).
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.
| TOC |
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.
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).
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.
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.
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.
The following events should be audited:
[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 ?
| TOC |
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.
[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.
[TBD] Legitimacy for advertising routes / updating information. Using authorization paradigms should be sufficient.
[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 ?
| TOC |
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.
| TOC |
| [SEC-GLOSS] | Shirey, R., "Internet Security Glossary", RFC 2828, May 2000. |
| TOC |
| [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. |
| TOC |
| Danny McPherson | |
| Arbor Networks | |
| EMail: | danny@arbor.net |
| 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/ |
| TOC |
Partial protection against subverted links is gained with authenticated integrity proof and anti-replay. These links can still eavesdrop, delay, drop messages.
| TOC |
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).
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.
Authentication of sources should help here (care of anti-replay). Special considerations apply to DVPs.
| TOC |
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.
| TOC |
| TOC |
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.
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 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Funding for the RFC Editor function is currently provided by the Internet Society.