KARP Working Group Y. Wei Internet-Draft ZTE Corporation Intended status: Informational C. Wan Expires: January 28, 2012 Southeast University July 27, 2011 Analysis of Resource ReSerVation Protocol-Traffic Engineering (RSVP-TE) Security According to KARP Design Guide draft-wei-karp-rsvp-te-analysis-00 Abstract This document analyzes Resource ReSerVation Protocol-Traffic Engineering (RSVP-TE) security according to the guidelines set forth in the KARP Design Guide. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on January 28, 2012. Copyright Notice Copyright (c) 2011 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. Wei & Wan Expires January 28, 2012 [Page 1] Internet-Draft RSVP-TE analysis July 2011 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions Used in This Document . . . . . . . . . . . . . . . 3 3. Current State and Gap Analysis . . . . . . . . . . . . . . . . 4 3.1. Ipsec used in RSVP-TE messages . . . . . . . . . . . . . . 4 3.2. INTEGIRTY object used in RSVP-TE messages . . . . . . . . . 4 4. Impacts of RSVP Replays . . . . . . . . . . . . . . . . . . . . 6 5. Gap Analysis and Specific Requirements . . . . . . . . . . . . 6 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . . 6 7. security considerations . . . . . . . . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 Wei & Wan Expires January 28, 2012 [Page 2] Internet-Draft RSVP-TE analysis July 2011 1. Introduction This document performs the initial analysis of the current state of Resource ReSerVation Protocol-Traffic Engineering (RSVP-TE) [RFC3209] Security according to the requirements of [ietf-karp-design-guide]. The security of RSVP-TE [RFC3209] poses no security exposures over and above that of the Resource ReSerVation Protocol (RSVP) [RFC2205]. However, there is a slight change in the trust model. Traffic sent on a normal RSVP session can be filtered according to source and destination addresses as well as port numbers. In RSVP-TE, filtering occurs only on the basis of an incoming label. For this reason an administration may wish to limit the domain over which LSP tunnels can be established. This can be accomplished by setting filters on various ports to deny action on a RSVP path message with a SESSION object of type LSP_TUNNEL_IPv4 or LSP_TUNNEL_IPv6. There are two sorts of security mechanisms for RSVP-TE (or RSVP), they are listed below: - [RFC2207]describes mechanisms to authenticate the RSVP-TE( or RSVP) messages using the IP security (IPsec) Encapsulating Security Payload (ESP) [RFC1827] or the Authentication Header (AH) [RFC1826]. -[RFC2747] describes mechanisms to authenticate the RSVP-TE messages using the INTEGRITY Object. These two mechanisms meet many of the requirements expected from a manually keyed routing protocol. Integrity protection is provided with modern cryptographic algorithms, rekeying process is discussed, although apparently some implementations have trouble with this in practice. However, some gaps remain between the current state and the requirements for manually keyed routing security expressed in the [ietf-karp-threats-req] document. This document explores these gaps and proposes directions for addressing the gaps. 2. Conventions Used in This Document 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 [RFC2119] . When used in lower case, these words convey their typical use in common language, and are not to be interpreted as described in [RFC2119]. Wei & Wan Expires January 28, 2012 [Page 3] Internet-Draft RSVP-TE analysis July 2011 3. Current State and Gap Analysis This section describes the security mechanisms built into RSVP-TE. There are two goals to this section. First, this section gives a brief explanation of the RSVP-TE security mechanisms to those familiar with connectionless integrity mechanisms but not with RSVP-TE. Second, this section explains the background necessary to understand how RSVP-TE fails to meet some of the requirements proposed for routing security. 3.1. Ipsec used in RSVP-TE messages Similar to RSVP, RSVP-TE can use Ipsec as its security mechanism. [RFC2207] describes how the authentication header and encapsulating security payload mechanism can be used to protect RSVP-TE packets. This mechanism provides per-packet integrity and optional confidentiality using a wide variety of cryptographic algorithms. So, this mechanism meets requirements related to algorithm selection and agility. Because RSVP-TE [RFC3209] uses only unicast traffic, both manual and automatic key management are supported. The Security Parameter Index (SPI) provides an identifier for the security association. This along with other IPsec facilities provides a mechanism for moving from one key to another, meeting the key rollover requirements. When manual keying is used, no replay protection is provided for RSVP-TE. Thus the intra-connection and inter-connection replay requirements are not met. There is another serious problem with the RSVP-TE security that is based on IPsec. Since the Ipsec protocol is not integrated into RSVP-TE, there are a lot of deployment problems in practices. Furthermore, the security associations in IPSEC are based on destination address. While in RSVP-TE, filtering occurs only on the basis of an incoming label. That is, RSVP-TE traffic may otherwise not follow exactly the same path as data traffic. Using either source or destination based associations would require opening a new security association among the routers for which a reservation traverses. This will complicate the deployment too. 3.2. INTEGIRTY object used in RSVP-TE messages [RFC2747] describes the basic procedure for cryptographic authentication in RSVP-TE. An INTEGRITY object in the RSVP-TE messages is defined, which contains a key identifier, a sequence number and the keyed message digest. This keyed message digest Wei & Wan Expires January 28, 2012 [Page 4] Internet-Draft RSVP-TE analysis July 2011 protects all fields of the packet including the sequence number but not the IP header. As defined in [RFC2747], the sending and receiving systems maintain a security association for each authentication key that they share. This security association includes the following parameters: Authentication algorithm and algorithm mode being used, Key used with the authentication algorithm, Lifetime of the key, Associated sending interface and other security association selection criteria, Source Address of the sending system, Latest sending sequence number used with this key identifier, List of last N sequence numbers received with this key identifier. However, [RFC2747] does not defines algorithms to be used for RSVP-TE. Thus RSVP-TE does not meet the requirement for strong algorithms. Since no algorithms are defined and no new algorithm can be selected with each key, RSVP does not meet the requirement for algorithm agility. Moreover, no mandatory algorithm is supported. These security services provide integrity protection on each packet. In addition, limited replay detection is provided. The message replay prevention algorithm is quite simple. The sender generates packets with monotonically increasing sequence numbers. In turn, the receiver only accepts packets that have a larger sequence number than the previous packet. To start this process, a receiver handshakes with the sender to get an initial sequence number. Each time a message is transmitted for a given key, the sequence number counter is incremented. The current value of this counter is continually or periodically saved to stable storage. After a restart, the counter is recovered using this stable storage. Also, because the IP header is not protected, the sequence number may not be associated with the right neighbor; this opens up opportunities for outsiders to perform replay attacks. [RFC2747] addresses this issue by adding source address and interface to the security association. In this way, the source address from the IP header is incorporated in the security association, and any change of the IP source address will be detected. [RFC2747] discusses the use of Kerberos as the key rollover mechanism. But it does not defines how to rekey using the Kerberos protocol. So, there is no real key rollover mechanism for RSVP-TE. But the support for a key rollover mechanism in RSVP-TE is quite good. There is a key identifier. Key lifetime is defined in the security association. Wei & Wan Expires January 28, 2012 [Page 5] Internet-Draft RSVP-TE analysis July 2011 The RSVP-TE replay mechanism handles the out-of-order sequence numbers using a sequence number window. So, out-of-order packets will be handled successfully. 4. Impacts of RSVP Replays Similar to that discussed in [draft-ietf-karp-ospf-analysis-01], RSVP-TE with Ipsec does not meet the requirements of inter-connection or intra-connection replay protection. So, this section mainly discusses the impacts of RSVP replays when INTEGRITY object is employed. The router periodically stores the Latest sending sequence number used with this key identifier into stable storage to avoid the inter- session replay attacks. However, there are several scenarios in which the replay attack still work: -Inter-session replay attacks: When the router collapses before the Latest sending sequence number used with this key identifier is stored into the stable storage, replay attack may occur. -Intra-session replay attacks: Since the receiver only accepts larger sequence numbers, when the sequence number reaches to 2^64, the sender can not increase it any more. In this case, sequence number may be repeated, and replay attacks may occur. 5. Gap Analysis and Specific Requirements To prevant inter-session replay attacks, [RFC2747] discusses several techniques. The routers can use the NTP based timestamp (or local clock based timestamp) instead of the stable storage. However, this sort of solution requires high resolution ratio timestamps. So, a possible solution to address this issue is to store a session counter instead of the sequence number counter. To address the intra-session issue, a possible solution is to store a extended sequence number locally. Another possible solution is to rekey before the sequence number repeats. 6. IANA considerations This document places no new request to IANA. Wei & Wan Expires January 28, 2012 [Page 6] Internet-Draft RSVP-TE analysis July 2011 7. security considerations To be completed. 8. References [RFC1826] R, Atkinson., "IP Authentication Header", August 1995. [RFC1827] R, Atkinson., "IP Encapsulating Security Payload (ESP)", August 1995. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2205] R, Braden. and Et. Al., "Resource ReSerVation Protocol (RSVP) --Version 1 Functional Specification", September 1997. [RFC2207] L, Berge. and T. Malley, "RSVP Extensions for IPSEC Data Flows", September 1997. [RFC2747] F, Baker. and Et. Al., "RSVP Cryptographic Authentication", January 2000. [RFC3209] D, Awduche. and Et. Al., "RSVP-TE: Extensions to RSVP for LSP Tunnels", December 2001. [draft-ietf-karp-ospf-analysis-01] S, Hartman. and D. Zhang, "Analysis of OSPF Security According to KARP Design Guide", June 2011. [ietf-karp-design-guide] G, Lebovitz. and M. Bhatia, "Keying and Authentication for Routing Protocols (KARP) Design Guidelines", February 2010. [ietf-karp-threats-req] G, Lebovitz., "KARP Threats and Requirements", February 2010. Wei & Wan Expires January 28, 2012 [Page 7] Internet-Draft RSVP-TE analysis July 2011 Authors' Addresses Yinxing Wei ZTE Corporation No. 6, HuashenDa Road, Yuhuatai District Nanjing, Jiangsu 210012 China Phone: +86 25 52877993 Email: wei.yinxing@zte.com.cn Changsheng Wan Southeast University No. 2, Sipailou, Radio Department, Southeast University Nanjing, Jiangsu 210096 China Phone: +86 25 83795822-866 Email: wanchangsheng@seu.edu.cn Wei & Wan Expires January 28, 2012 [Page 8]