Internet DRAFT - draft-wei-karp-rsvp-te-analysis

draft-wei-karp-rsvp-te-analysis






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]