diff options
Diffstat (limited to 'doc/rfc/rfc6952.txt')
| -rw-r--r-- | doc/rfc/rfc6952.txt | 955 |
1 files changed, 955 insertions, 0 deletions
diff --git a/doc/rfc/rfc6952.txt b/doc/rfc/rfc6952.txt new file mode 100644 index 0000000..a990f9e --- /dev/null +++ b/doc/rfc/rfc6952.txt @@ -0,0 +1,955 @@ + + + + + + +Internet Engineering Task Force (IETF) M. Jethanandani +Request for Comments: 6952 Ciena Corporation +Category: Informational K. Patel +ISSN: 2070-1721 Cisco Systems, Inc + L. Zheng + Huawei Technologies + May 2013 + + + + Analysis of BGP, LDP, PCEP, and MSDP Issues According to the + Keying and Authentication for Routing Protocols (KARP) Design Guide + +Abstract + + This document analyzes TCP-based routing protocols, the Border + Gateway Protocol (BGP), the Label Distribution Protocol (LDP), the + Path Computation Element Communication Protocol (PCEP), and the + Multicast Source Distribution Protocol (MSDP), according to + guidelines set forth in Section 4.2 of "Keying and Authentication for + Routing Protocols Design Guidelines", RFC 6518. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Not all documents + approved by the IESG are a candidate for any level of Internet + Standard; see Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6952. + + + + + + + + + + + + + + +Jethanandani, et al. Informational [Page 1] + +RFC 6952 BGP, LDP, PCEP, and MSDP Analysis May 2013 + + +Copyright Notice + + Copyright (c) 2013 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4 + 2. Current Assessment of BGP, LDP, PCEP, and MSDP . . . . . . . 5 + 2.1. Transport Layer . . . . . . . . . . . . . . . . . . . . . 5 + 2.2. Keying Mechanisms . . . . . . . . . . . . . . . . . . . . 6 + 2.3. BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 2.4. LDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 2.4.1. Spoofing Attacks . . . . . . . . . . . . . . . . . . 7 + 2.4.2. Denial-of-Service Attacks . . . . . . . . . . . . . . 8 + 2.5. PCEP . . . . . . . . . . . . . . . . . . . . . . . . . . 8 + 2.6. MSDP . . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 3. Optimal State for BGP, LDP, PCEP, and MSDP . . . . . . . . . 10 + 3.1. LDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 4. Gap Analysis for BGP, LDP, PCEP, and MSDP . . . . . . . . . . 11 + 4.1. LDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 4.2. PCEP . . . . . . . . . . . . . . . . . . . . . . . . . . 13 + 5. Transition and Deployment Considerations . . . . . . . . . . 13 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 + 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 + 8.1. Normative References . . . . . . . . . . . . . . . . . . 14 + 8.2. Informative References . . . . . . . . . . . . . . . . . 14 + + + + + + + + + + + + +Jethanandani, et al. Informational [Page 2] + +RFC 6952 BGP, LDP, PCEP, and MSDP Analysis May 2013 + + +1. Introduction + + In their "Report from the IAB Workshop on Unwanted Traffic March + 9-10, 2006" [RFC4948], the Internet Architecture Board (IAB) + described an attack on core routing infrastructure as an ideal attack + that would inflict the greatest amount of damage and suggested steps + to tighten the infrastructure against the attack. Four main steps + were identified for that tightening: + + 1. Create secure mechanisms and practices for operating routers. + + 2. Clean up the Internet Routing Registry (IRR) repository, and + secure both the database and the access, so that it can be used + for routing verifications. + + 3. Create specifications for cryptographic validation of routing + message content. + + 4. Secure the routing protocols' packets on the wire. + + In order to secure the routing protocols, this document performs an + initial analysis of the current state of four TCP-based protocols -- + BGP [RFC4271], LDP [RFC5036], PCEP [RFC5440], and MSDP [RFC3618] -- + according to the requirements of the KARP Design Guidelines + [RFC6518]. Section 4.2 of that document uses the term "state", which + will be referred to as the "state of the security method". Thus, a + term like "Define Optimal State" would be referred to as "Define + Optimal State of the Security Method". + + This document builds on several previous efforts into routing + security: + + o "Issues with Existing Cryptographic Protection Methods for Routing + Protocols" [RFC6039], describes issues with existing cryptographic + protection methods for routing protocols. + + o Analysis of OSPF Security According to the KARP Design Guide + [RFC6863] analyzes Open Shortest Path First (OSPF) security + according to the KARP Design Guide. + + Section 2 of this document looks at the current state of the security + method for the four routing protocols: BGP, LDP, PCEP, and MSDP. + Section 3 examines what the optimal state of the security method + would be for the four routing protocols according to the KARP Design + Guidelines [RFC6518], and Section 4 does an analysis of the gap + between the existing state of the security method and the optimal + state of the security method for the protocols and suggests some + areas where improvement is needed. + + + +Jethanandani, et al. Informational [Page 3] + +RFC 6952 BGP, LDP, PCEP, and MSDP Analysis May 2013 + + +1.1. Abbreviations + + AES - Advanced Encryption Standard + + AO - Authentication Option + + AS - Autonomous System + + BGP - Border Gateway Protocol + + CMAC - Cipher-Based Message Authentication Code + + DoS - Denial of Service + + GTSM - Generalized Time-to-Live (TTL) Security Mechanism + + HMAC - Hash-Based MAC + + KARP - Key and Authentication for Routing Protocols + + KDF - Key Derivation Function + + KEK - Key Encrypting Key + + KMP - Key Management Protocol + + LDP - Label Distribution Protocol + + LSR - Label Switching Routers + + MAC - Message Authentication Code + + MKT - Master Key Table + + MSDP - Multicast Source Distribution Protocol + + MD5 - Message Digest Algorithm 5 + + OSPF - Open Shortest Path First + + PCEP - Path Computation Element Communication Protocol + + PCC - Path Computation Client + + PCE - Path Computation Element + + SHA - Secure Hash Algorithm + + + + +Jethanandani, et al. Informational [Page 4] + +RFC 6952 BGP, LDP, PCEP, and MSDP Analysis May 2013 + + + TCP - Transmission Control Protocol + + TTL - Time-to-Live + + UDP - User Datagram Protocol + + WG - Working Group + +2. Current Assessment of BGP, LDP, PCEP, and MSDP + + This section assesses the transport protocols for any authentication + or integrity mechanisms used by the protocol. It describes the + current security mechanisms, if any, used by BGP, LDP, PCEP, and + MSDP. + +2.1. Transport Layer + + At the transport layer, routing protocols are subject to a variety of + DoS attacks, as outlined in "Internet Denial-of-Service + Considerations" [RFC4732]. Such attacks can cause the routing + protocol to become congested, resulting in the routing updates being + supplied too slowly to be useful. In extreme cases, these attacks + prevent routers from converging after a change. + + Routing protocols use several methods to protect themselves. Those + that use TCP as a transport protocol use access lists to accept + packets only from known sources. These access lists also help + protect edge routers from attacks originating outside the protected + domain. In addition, for edge routers running the External Border + Gateway Protocol (eBGP), TCP LISTEN is run only on interfaces on + which its peers have been discovered or via which routing sessions + are expected (as specified in router configuration databases). + + "Generalized TTL Security Mechanism (GTSM)" [RFC5082] describes a + generalized Time-to-Live (TTL) security mechanism to protect a + protocol stack from CPU-utilization-based attacks. TCP Robustness + [RFC5961] recommends some TCP-level mitigations against spoofing + attacks targeted towards long-lived routing protocol sessions. + + Even when BGP, LDP, PCEP, and MSDP sessions use access lists, they + are vulnerable to spoofing and man-in-the-middle attacks. + Authentication and integrity checks allow the receiver of a routing + protocol update to know that the message genuinely comes from the + node that claims to have sent it and to know whether the message has + been modified. Sometimes routers can be subjected to a large number + of authentication and integrity requests, exhausting connection + resources on the router in a way that could lead to the denial of + genuine requests. + + + +Jethanandani, et al. Informational [Page 5] + +RFC 6952 BGP, LDP, PCEP, and MSDP Analysis May 2013 + + + TCP MD5 [RFC2385] has been obsoleted by TCP-AO [RFC5925]. However, + it is still widely used to authenticate TCP-based routing protocols + such as BGP. It provides a way for carrying a MD5 digest in a TCP + segment. This digest is computed using information known only to the + endpoints, and this ensures authenticity and integrity of messages. + The MD5 key used to compute the digest is stored locally on the + router. This option is used by routing protocols to provide for + session-level protection against the introduction of spoofed TCP + segments into any existing TCP streams, in particular, TCP Reset + segments. TCP MD5 does not provide a generic mechanism to support + key rollover. It also does not support algorithm agility. + + The Message Authentication Codes (MACs) used by TCP MD5 are + considered too weak both because of the use of the hash function and + because of the way the secret key used by TCP MD5 is managed. + Furthermore, TCP MD5 does not support any algorithm agility. TCP-AO + [RFC5925] and its companion document Cryptographic Algorithms for + TCP-AO [RFC5926], describe steps towards correcting both the MAC + weakness and the management of secret keys. Those steps require that + two MAC algorithms be supported. They are HMAC-SHA-1-96, as + specified in HMAC [RFC2104], and AES-128-CMAC-96, as specified in + NIST-SP800-38B [NIST-SP800-38B]. Cryptographic research suggests + that both these MAC algorithms are fairly secure. By supporting + multiple MAC algorithms, TCP-AO supports algorithm agility. TCP-AO + also allows additional MACs to be added in the future. + +2.2. Keying Mechanisms + + For TCP-AO [RFC5925], there is no Key Management Protocol (KMP) used + to manage the keys that are employed to generate the MAC. TCP-AO + talks about coordinating keys derived from the Master Key Table (MKT) + between endpoints and allows for a master key to be configured + manually or for it to be managed via an out-of-band mechanism. + + It should be noted that most routers configured with static keys have + not seen the key changed ever. The common reason given for not + changing the key is the difficulty in coordinating the change between + pairs of routers when using TCP MD5. It is well known that the + longer the same key is used, the greater the chance that it can be + guessed or exposed, e.g., when an administrator with knowledge of the + keys leaves the company. + + For point-to-point key management, the IKEv2 protocol [RFC5996] + provides for automated key exchange under a Security Association (SA) + and can be used for a comprehensive KMP solution for routers. IKEv2 + can be used for both IPsec SAs [RFC4301] and other types of SAs. For + example, Fibre Channel SAs [RFC4595] are currently negotiated with + IKEv2. Using IKEv2 to negotiate TCP-AO is a possible option. + + + +Jethanandani, et al. Informational [Page 6] + +RFC 6952 BGP, LDP, PCEP, and MSDP Analysis May 2013 + + +2.3. BGP + + All BGP communications take place over TCP. Therefore, all security + vulnerabilities for BGP can be categorized as relating to the + security of the transport protocol itself, or to the compromising of + individual routers and the data they handle. This document examines + the issues for the transport protocol, while the SIDR Working Group + (WG) looks at ways to sign and secure the data exchanged in BGP as + described in "An Infrastructure to Support Secure Internet Protocol" + [RFC6480]. + +2.4. LDP + + "Security Framework for MPLS and GMPLS Networks" [RFC5920] outlines + security aspects that are relevant in the context of MPLS and GMPLS. + It describes the security threats, the related defensive techniques, + and the mechanism for detection and reporting. + + Section 5 of LDP [RFC5036] states that LDP is subject to two + different types of attacks: spoofing and denial-of-service attacks. + +2.4.1. Spoofing Attacks + + A spoofing attack against LDP can occur both during the discovery + phase and during the session communication phase. + +2.4.1.1. Discovery Exchanges using UDP + + Label Switching Routers (LSRs) indicate their willingness to + establish and maintain LDP sessions by periodically sending Hello + messages. Reception of a Hello message serves to create a new "Hello + adjacency", if one does not already exist, or to refresh an existing + one. + + There are two variants of the discovery mechanism. A Basic Discovery + mechanism is used to discover LSR neighbors that are directly + connected at the link level, and an Extended Discovery mechanism is + used by LSRs that are more than one hop away. + + Unlike all other LDP messages, the Hello messages are sent using UDP. + This means that they cannot benefit from the security mechanisms + available with TCP. LDP [RFC5036] does not provide any security + mechanisms for use with Hello messages except for some configuration + that may help protect against bogus discovery events. These + configurations include directly connected links and interfaces. + Routers that do not use directly connected links have to use the + Extended Discovery mechanism and will not be able to use + configuration to protect against bogus discovery events. + + + +Jethanandani, et al. Informational [Page 7] + +RFC 6952 BGP, LDP, PCEP, and MSDP Analysis May 2013 + + + Spoofing a Hello packet for an existing adjacency can cause the + adjacency to time out and result in termination of the associated + session. This can occur when the spoofed Hello message specifies a + small Hold Time, causing the receiver to expect Hello messages within + this interval, while the true neighbor continues sending Hello + messages at the lower, previously agreed to frequency. + + Spoofing a Hello packet can also cause the LDP session to be + terminated. This can occur when the spoofed Hello specifies a + different Transport Address from the previously agreed one between + neighbors. Spoofed Hello messages are observed and reported as a + real problem in production networks. + +2.4.1.2. Session Communication using TCP + + LDP, like other TCP-based routing protocols, specifies use of the TCP + MD5 Signature Option to provide for the authenticity and integrity of + session messages. As stated in Section 2.1 of this document and in + Section 2.9 of LDP [RFC5036], MD5 authentication is considered too + weak for this application as outlined in MD5 and HMAC-MD5 Security + Considerations [RFC6151]. It also does not support algorithm + agility. A stronger hashing algorithm, e.g., SHA1, which is + supported by TCP-AO [RFC5925], could be deployed to take care of the + weakness. + + Alternatively, one could move to using TCP-AO, which provides for + stronger MAC algorithms, makes it easier to set up manual keys, and + protects against replay attacks. + +2.4.2. Denial-of-Service Attacks + + LDP is subject to Denial-of-Service (DoS) attacks both in discovery + mode and session mode. The potential targets are documented in + Section 5.3 of LDP [RFC5036]. + +2.5. PCEP + + For effective selection by Path Computation Clients (PCCs), a PCC + needs to know the location of Path Computation Elements (PCEs) in its + domain along with some information relevant for PCE selection. Such + PCE information could be learned through manual configuration, on + each PCC, along with the capabilities of the PCE or automatically + through a PCE discovery mechanism as outlined in Requirements for PCE + Discovery [RFC4674]. + + Attacks on PCEP [RFC5440] may result in damage to active networks. + These include computation responses, which if changed can cause + protocols like RSVP-TE [RFC3209] to set up suboptimal or + + + +Jethanandani, et al. Informational [Page 8] + +RFC 6952 BGP, LDP, PCEP, and MSDP Analysis May 2013 + + + inappropriate LSPs. In addition, PCE itself can be a target for a + variety of DoS attacks. Such attacks can cause path computations to + be supplied too slowly to be of any value, particularly as it relates + to recovery or establishment of LSPs. + + Finally, PCE discovery, as outlined in OSPF Protocol Extensions for + PCE Discovery [RFC5088] and IS-IS Protocol Extensions for PCE + Discovery [RFC5089], is a significant feature for the successful + deployment of PCEP in large networks. These mechanisms allow PCC to + discover the existence of PCEs within the network. If the discovery + mechanism is compromised, it will impair the ability of the nodes to + function as described below. + + As RFC 5440 states, PCEP (which makes use of TCP as a transport) + could be the target of the following attacks: + + o Spoofing (PCC or PCE implementation) + + o Snooping (message interception) + + o Falsification + + o Denial of Service + + In inter-Autonomous System (inter-AS) scenarios where PCE-to-PCE + communication is required, attacks may be particularly significant + with commercial implications as well as service-level agreement + implications. + + Additionally, snooping of PCEP requests and responses may give an + attacker information about the operation of the network. By viewing + the PCEP messages, an attacker can determine the pattern of service + establishment in the network and can know where traffic is being + routed, thereby making the network susceptible to targeted attacks + and the data within specific LSPs vulnerable. + + Ensuring PCEP communication privacy is of key importance, especially + in an inter-AS context, where PCEP communication endpoints do not + reside in the same AS. An attacker that intercepts a PCE message + could obtain sensitive information related to computed paths and + resources. + + At the time PCEP was documented in [RFC5440], TCP-AO had not been + fully specified. Therefore, [RFC5440] mandates that PCEP + implementations include support for TCP MD5 and that use of the + function should be configurable by the operator. [RFC5440] also + describes the vulnerabilities and weaknesses of TCP MD5 as noted in + this document. [RFC5440] goes on to state that PCEP implementations + + + +Jethanandani, et al. Informational [Page 9] + +RFC 6952 BGP, LDP, PCEP, and MSDP Analysis May 2013 + + + should include support for TCP-AO as soon as that specification is + complete. Since TCP-AO [RFC5925] has now been published, new PCEP + implementations should fully support TCP-AO. + +2.6. MSDP + + Similar to BGP and LDP, the Multicast Source Distribution Protocol + (MSDP) uses TCP MD5 [RFC2385] to protect TCP sessions via the TCP MD5 + option. But with a weak MD5 authentication, TCP MD5 is not + considered strong enough for this application. It also does not + support algorithm agility. + + MSDP advocates imposing a limit on the number of source address and + group addresses (S,G) that can be cached within the protocol in order + to mitigate state explosion due to any denial of service and other + attacks. + +3. Optimal State for BGP, LDP, PCEP, and MSDP + + The ideal state of the security method for BGP, LDP, PCEP, and MSDP + protocols is when they can withstand any of the known types of + attacks. The protocols also need to support algorithm agility, i.e., + they must not hardwire themselves to one algorithm. + + Additionally, the KMP for the routing sessions should help negotiate + unique, pair-wise random keys without administrator involvement. It + should also negotiate Security Association (SA) parameters required + for the session connection, including key lifetimes. It should keep + track of those lifetimes and negotiate new keys and parameters before + they expire and do so without administrator involvement. In the + event of a breach, including when an administrator with knowledge of + the keys leaves the company, the keys should be changed immediately. + + The DoS attacks for BGP, LDP, PCEP, and MSDP are attacks to the + transport protocol -- TCP for the most part, and UDP in case of the + discovery phase of LDP. TCP and UDP should be able to withstand any + of the DoS scenarios by dropping packets that are attack packets in a + way that does not impact legitimate packets. + + The routing protocols should provide a mechanism to authenticate the + routing information carried within the payload, and administrators + should enable it. + +3.1. LDP + + To mitigate LDP's current vulnerability to spoofing attacks, LDP + needs to be upgraded such that an implementation is able to determine + the authenticity of the neighbors sending the Hello message. + + + +Jethanandani, et al. Informational [Page 10] + +RFC 6952 BGP, LDP, PCEP, and MSDP Analysis May 2013 + + + Labels are similar to routing information, which is distributed in + the clear. However, there is currently no requirement that the + labels be encrypted. Such a requirement is out of scope for this + document. + + Similarly, it is important to ensure that routers exchanging labels + are mutually authenticated, and that there are no rogue peers or + unauthenticated peers that can compromise the stability of the + network. + +4. Gap Analysis for BGP, LDP, PCEP, and MSDP + + This section outlines the differences between the current state of + the security methods for routing protocols and the desired state of + the security methods as outlined in Section 4.2 of the KARP Design + Guidelines [RFC6518]. As that document states, these routing + protocols fall into the category of one-to-one peering messages and + will use peer keying protocols. This section covers issues that are + common to the four protocols, leaving protocol-specific issues to + sub-sections. + + At a transport level, these routing protocols are subject to some of + the same attacks that TCP applications are subject to. These include + DoS and spoofing attacks. "Internet Denial-of-Service + Considerations" [RFC4732] outlines some solutions. "Defending TCP + Against Spoofing Attacks" [RFC4953] recommends ways to prevent + spoofing attacks. In addition, the recommendations in [RFC5961] + should also be followed and implemented to strengthen TCP. + + Routers lack comprehensive key management and keys derived that they + can use to authenticate data. As an example, TCP-AO [RFC5925], talks + about coordinating keys derived from the Master Key Table (MKT) + between endpoints, but the MKT itself has to be configured manually + or through an out-of-band mechanism. Also, TCP-AO does not address + the issue of connectionless reset, as it applies to routers that do + not store MKT across reboots. + + Authentication, integrity protection, and encryption all require the + use of keys by sender and receiver. An automated KMP, therefore has + to include a way to distribute key material between two endpoints + with little or no administrative overhead. It has to cover automatic + key rollover. It is expected that authentication will cover the + packet, i.e., the payload and the TCP header, and will not cover the + frame, i.e., the layer 2 header. + + There are two methods of automatic key rollover. Implicit key + rollover can be initiated after a certain volume of data gets + exchanged or when a certain time has elapsed. This does not require + + + +Jethanandani, et al. Informational [Page 11] + +RFC 6952 BGP, LDP, PCEP, and MSDP Analysis May 2013 + + + explicit signaling nor should it result in a reset of the TCP + connection in a way that the links/adjacencies are affected. On the + other hand, explicit key rollover requires an out-of-band key + signaling mechanism. It can be triggered by either side and can be + done anytime a security parameter changes, e.g., an attack has + happened, or a system administrator with access to the keys has left + the company. An example of this is IKEv2 [RFC5996], but it could be + any other new mechanisms also. + + As stated earlier, TCP-AO [RFC5925] and its accompanying document, + Cryptographic Algorithms for TCP-AO [RFC5926], require that two MAC + algorithms be supported, and they are HMAC-SHA-1-96, as specified in + HMAC [RFC2104], and AES-128-CMAC-96, as specified in NIST-SP800-38B + [NIST-SP800-38B]. Therefore, TCP-AO meets the algorithm agility + requirement. + + There is a need to protect authenticity and validity of the routing/ + label information that is carried in the payload of the sessions. + However, that is outside the scope of this document and is being + addressed by the SIDR WG. Similar mechanisms could be used for + intra-domain protocols. + + Finally, replay protection is required. The replay mechanism needs + to be sufficient to prevent an attacker from creating a denial of + service or disrupting the integrity of the routing protocol by + replaying packets. It is important that an attacker not be able to + disrupt service by capturing packets and waiting for replay state to + be lost. + +4.1. LDP + + As described in LDP [RFC5036], the threat of spoofed Basic Hellos can + be reduced by only accepting Basic Hellos on interfaces that LSRs + trust, employing GTSM [RFC5082], and ignoring Basic Hellos not + addressed to the "all routers on this subnet" multicast group. + Spoofing attacks via Targeted Hellos are potentially a more serious + threat. An LSR can reduce the threat of spoofed Extended Hellos by + filtering them and accepting Hellos from sources permitted by access + lists. However, performing the filtering using access lists requires + LSR resources, and the LSR is still vulnerable to the IP source + address spoofing. Spoofing attacks can be solved by being able to + authenticate the Hello messages, and an LSR can be configured to only + accept Hello messages from specific peers when authentication is in + use. + + LDP Hello Cryptographic Authentication [HELLO-CRYPTO] suggest a new + Cryptographic Authentication TLV that can be used as an + authentication mechanism to secure Hello messages. + + + +Jethanandani, et al. Informational [Page 12] + +RFC 6952 BGP, LDP, PCEP, and MSDP Analysis May 2013 + + +4.2. PCEP + + Path Computation Element (PCE) discovery, according to [RFC5440], is + a significant feature for the successful deployment of PCEP in large + networks. This mechanism allows a Path Computation Client (PCC) to + discover the existence of suitable PCEs within the network without + the necessity of configuration. It should be obvious that, where + PCEs are discovered and not configured, the PCC cannot know the + correct key to use. There are different approaches to retain some + aspect of security, but all of them require use of a keys and a + keying mechanism, the need for which has been discussed above. + +5. Transition and Deployment Considerations + + As stated in the KARP Design Guidelines [RFC6518], it is imperative + that the new authentication, security mechanisms, and key management + protocol support incremental deployment, as it is not feasible to + deploy the new routing protocol authentication mechanism overnight. + + Typically, authentication and security in a peer-to-peer protocol + requires that both parties agree to the mechanisms that will be used. + If an agreement is not reached, the setup of the new mechanism will + fail or will be deferred. Upon failure, the routing protocols can + fall back to the mechanisms that were already in place, e.g., use + static keys if that was the mechanism in place. The fallback should + be configurable on a per-node or per-interface basis. It is usually + not possible for one end to use the new mechanism while the other end + uses the old. Policies can be put in place to retry upgrading after + a said period of time, so that manual coordination is not required. + + If the automatic KMP requires use of Public Key Infrastructure + Certificates [RFC5280] to exchange key material, the required + Certificate Authority (CA) root certificates may need to be installed + to verify the authenticity of requests initiated by a peer. Such a + step does not require coordination with the peer, except to decide + which CA authority will be used. + +6. Security Considerations + + This section describes security considerations that BGP, LDP, PCEP, + and MSDP should try to meet. + + As with all routing protocols, they need protection from both on-path + and off-path blind attacks. A better way to protect them would be + with per-packet protection using a cryptographic MAC. In order to + provide for the MAC, keys are needed. + + + + + +Jethanandani, et al. Informational [Page 13] + +RFC 6952 BGP, LDP, PCEP, and MSDP Analysis May 2013 + + + The routing protocols need to support algorithm agility, i.e., they + must not hardwire themselves to one algorithm. + + Once keys are used, mechanisms are required to support key rollover. + They should cover both manual and automatic key rollover. Multiple + approaches could be used. However, since the existing mechanisms + provide a protocol field to identify the key as well as management + mechanisms to introduce and retire new keys, focusing on the existing + mechanism as a starting point is prudent. + + Furthermore, it is strongly suggested that these routing protocols + support algorithm agility. It has been proven that algorithms weaken + over time. Supporting algorithm agility assists in smooth + transitions from old to new algorithms. + +7. Acknowledgements + + We would like to thank Brian Weis for encouraging us to write this + document, and thanks to Anantha Ramaiah and Mach Chen for providing + comments on it. + +8. References + +8.1. Normative References + + [RFC5926] Lebovitz, G. and E. Rescorla, "Cryptographic Algorithms + for the TCP Authentication Option (TCP-AO)", RFC 5926, + June 2010. + + [RFC6518] Lebovitz, G. and M. Bhatia, "Keying and Authentication for + Routing Protocols (KARP) Design Guidelines", RFC 6518, + February 2012. + + [RFC6863] Hartman, S. and D. Zhang, "Analysis of OSPF Security + According to the Keying and Authentication for Routing + Protocols (KARP) Design Guide", RFC 6863, March 2013. + +8.2. Informative References + + [HELLO-CRYPTO] + Zheng, L., Chen, M., and M. Bhatia, "LDP Hello + Cryptographic Authentication", Work in Progress, January + 2013. + + [NIST-SP800-38B] + Dworking, , "Recommendation for Block Cipher Modes of + Operation: The CMAC Mode for Authentication", May 2005. + + + + +Jethanandani, et al. Informational [Page 14] + +RFC 6952 BGP, LDP, PCEP, and MSDP Analysis May 2013 + + + [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- + Hashing for Message Authentication", RFC 2104, February + 1997. + + [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 + Signature Option", RFC 2385, August 1998. + + [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., + and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP + Tunnels", RFC 3209, December 2001. + + [RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery + Protocol (MSDP)", RFC 3618, October 2003. + + [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway + Protocol 4 (BGP-4)", RFC 4271, January 2006. + + [RFC4301] Kent, S. and K. Seo, "Security Architecture for the + Internet Protocol", RFC 4301, December 2005. + + [RFC4595] Maino, F. and D. Black, "Use of IKEv2 in the Fibre Channel + Security Association Management Protocol", RFC 4595, July + 2006. + + [RFC4674] Le Roux, J.L., "Requirements for Path Computation Element + (PCE) Discovery", RFC 4674, October 2006. + + [RFC4732] Handley, M., Rescorla, E., IAB, "Internet Denial-of- + Service Considerations", RFC 4732, December 2006. + + [RFC4948] Andersson, L., Davies, E., and L. Zhang, "Report from the + IAB workshop on Unwanted Traffic March 9-10, 2006", RFC + 4948, August 2007. + + [RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks", RFC + 4953, July 2007. + + [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP + Specification", RFC 5036, October 2007. + + [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C. + Pignataro, "The Generalized TTL Security Mechanism + (GTSM)", RFC 5082, October 2007. + + [RFC5088] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, + "OSPF Protocol Extensions for Path Computation Element + (PCE) Discovery", RFC 5088, January 2008. + + + + +Jethanandani, et al. Informational [Page 15] + +RFC 6952 BGP, LDP, PCEP, and MSDP Analysis May 2013 + + + [RFC5089] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, + "IS-IS Protocol Extensions for Path Computation Element + (PCE) Discovery", RFC 5089, January 2008. + + [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., + Housley, R., and W. Polk, "Internet X.509 Public Key + Infrastructure Certificate and Certificate Revocation List + (CRL) Profile", RFC 5280, May 2008. + + [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element + (PCE) Communication Protocol (PCEP)", RFC 5440, March + 2009. + + [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS + Networks", RFC 5920, July 2010. + + [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP + Authentication Option", RFC 5925, June 2010. + + [RFC5961] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's + Robustness to Blind In-Window Attacks", RFC 5961, August + 2010. + + [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, + "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC + 5996, September 2010. + + [RFC6039] Manral, V., Bhatia, M., Jaeggli, J., and R. White, "Issues + with Existing Cryptographic Protection Methods for Routing + Protocols", RFC 6039, October 2010. + + [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations + for the MD5 Message-Digest and the HMAC-MD5 Algorithms", + RFC 6151, March 2011. + + [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support + Secure Internet Routing", RFC 6480, February 2012. + + + + + + + + + + + + + + +Jethanandani, et al. Informational [Page 16] + +RFC 6952 BGP, LDP, PCEP, and MSDP Analysis May 2013 + + +Authors' Addresses + + Mahesh Jethanandani + Ciena Corporation + 1741 Technology Drive + San Jose, CA 95110 + USA + + Phone: +1 (408) 436-3313 + EMail: mjethanandani@gmail.com + + + Keyur Patel + Cisco Systems, Inc + 170 Tasman Drive + San Jose, CA 95134 + USA + + Phone: +1 (408) 526-7183 + EMail: keyupate@cisco.com + + + Lianshu Zheng + Huawei Technologies + China + + Phone: +86 (10) 82882008 + EMail: vero.zheng@huawei.com + + + + + + + + + + + + + + + + + + + + + + + +Jethanandani, et al. Informational [Page 17] + |