[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02

TSVWG                                                     F. Le Faucheur
Internet-Draft                                                  B. Davie
Expires: August 16, 2005                                   Cisco Systems
                                                                 P. Bose
                                                         Lockheed Martin
                                                             C. Christou
                                                             M. Christou
                                                     Booz Allen Hamilton
                                                       February 12, 2005


             Aggregate RSVP Reservations for IPsec Tunnels
                   draft-lefaucheur-rsvp-ipsec-00.txt

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of Section 3 of RFC 3667.  By submitting this Internet-Draft, each
   author represents that any applicable patent or other IPR claims of
   which he or she is aware have been or will be disclosed, and any of
   which he or she become aware will be disclosed, in accordance with
   RFC 3668.

   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 August 16, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   [RSVP-IPSEC] defines RSVP extensions for IPSec which permit support



Le Faucheur, et al.      Expires August 16, 2005                [Page 1]


Internet-Draft      Aggregate Reservations for IPsec       February 2005


   of reservations for individual IPsec flows, but it does not support
   aggregate reservations between the IPSec devices with Diffserv
   [DIFFSERV] classification and scheduling.  Conversely, [RSVP-AGG]
   defines how to aggregate individual RSVP reservations over Aggregate
   IP reservations when the aggregation region supports Diffserv, but it
   does not address the case where the aggregator and deaggregator use
   IPSec.  However, there are scenarios requiring aggregate reservations
   for IPsec tunnels.  This document specifies the incremental RSVP
   extensions beyond those defined in [RSVP-IPSEC] and [RSVP-AGG] to
   support such reservations.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3

   2.  Overview of Extensions . . . . . . . . . . . . . . . . . . . .  7

   3.  Object Definition  . . . . . . . . . . . . . . . . . . . . . .  9
     3.1   SESSION Class  . . . . . . . . . . . . . . . . . . . . . .  9
     3.2   AGGREGATION-SESSION Class  . . . . . . . . . . . . . . . .  9

   4.  Processing Rules . . . . . . . . . . . . . . . . . . . . . . . 11
     4.1   Required Changes . . . . . . . . . . . . . . . . . . . . . 11
     4.2   Merging Rules  . . . . . . . . . . . . . . . . . . . . . . 12
       4.2.1   FF and SE Styles . . . . . . . . . . . . . . . . . . . 13
       4.2.2   WF Styles  . . . . . . . . . . . . . . . . . . . . . . 13

   5.  Example Usage in Nested VPNs . . . . . . . . . . . . . . . . . 14

   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 20

   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 21

   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 23

   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
     9.1   Normative References . . . . . . . . . . . . . . . . . . . 24
     9.2   Informative References . . . . . . . . . . . . . . . . . . 24

       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 24

       Intellectual Property and Copyright Statements . . . . . . . . 27









Le Faucheur, et al.      Expires August 16, 2005                [Page 2]


Internet-Draft      Aggregate Reservations for IPsec       February 2005


1.  Introduction

   [RSVP-IPSEC] defines RSVP extensions for IPSec which permit support
   of reservations for individual IPsec flows, but it does not support
   aggregate reservations between the IPSec devices with Diffserv
   [DIFFSERV] classification and scheduling.  Conversely, [RSVP-AGG]
   defines how to aggregate individual RSVP reservations over Aggregate
   IP reservations when the aggregation region supports Diffserv, but it
   does not address the case where the aggregator and deaggregator use
   IPSec.  However, there are scenarios requiring aggregate reservations
   for IPsec tunnels.  This document specifies the incremental RSVP
   extensions beyond those defined in [RSVP-IPSEC] and [RSVP-AGG] to
   support such reservations.

   Let us consider an environment as depicted in Figure 1.  Let us
   assume that the IPsec-Routers tunnel traffic to each other via IPSec
   and that the devices within Cloud-1, Cloud-2 and Cloud-3 want to
   establish RSVP reservations with one another transparently over the
   IPSec Tunnels.  Let us also assume that Cloud-0 supports Diffserv
   (and not per-flow classification -except perhaps at the edge for
   policing purposes) and that there is a need to reserve resources over
   Cloud-0 to achieve the targeted levels of QoS assurance.  Then there
   is a need to establish aggregate reservations within Cloud-0 for the
   IPsec tunnels transiting through Cloud-0.  These aggregate
   reservations will be used to aggregate the end-to-end RSVP
   reservations between Cloud-1/2/3.  This document concerns itself with
   establishment of such aggregate reservations for IPSec tunnels.

   The reader is referred to [SIG-NESTED] for a description of a more
   generic nested VPN environment and for discussion and examples of QoS
   signaling in that environment.




















Le Faucheur, et al.      Expires August 16, 2005                [Page 3]


Internet-Draft      Aggregate Reservations for IPsec       February 2005


                       I----------I               I----------I
                       I  Cloud-1 I               I  Cloud-2 I
                       I----------I               I----------I
                             |                      |
                       IPSec-Router-1     IPSec-Router-2
                                 /         /
                                I----------I
                               I          I
                                I  Cloud-0 I
                               I          I
                                I----------I
                                     /
                             IPSec-Router-3
                                  |
                            I----------I
                            I  Cloud-3 I
                            I----------I
   Figure 1: Example Scenario Requiring Aggregate Reservations for IPsec
   tunnels

   [RSVP-AGG] defines a Session Object containing only the deaggregator
   IP address and the DSCP, and defines a Filter Spec Object containing
   only the aggregator IP address.  Thus, we observe that it is not
   possible to convey the IPSec Security Parameter Index (SPI) that is
   used for a given IPsec tunnel (unlike with [RSVP-IPSEC]).  In turn,
   this means that, if [RSVP-AGG] was used to establish aggregate
   reservations for IPSec tunnels, it would not be possible for the
   (edge) routers within Cloud-0 to classify traffic belonging to the
   reservation corresponding to a given IPsec tunnel (say for the
   purpose of doing policing on the edge of Cloud-0) .  It also means
   that it would not be possible (short of multiplying IP addresses) to
   setup separate reservations for different IPsec tunnels (using
   different SPIs) between the same IPsec encryptor and decryptor (which
   may be used if different types of traffic have different security
   requirements).  Similarly, it would not be possible to set up
   separate reservations for traffic going over the IPsec tunnel and for
   traffic which is not encrypted (which is a useful scenario if some
   traffic has IPSec requirement while the rest doesn't).  Moreover, it
   would not be possible to setup multiple reservations between a given
   pair of IPsec encryptor and decryptor for transport of flows with
   different preemptions [RSVP-PREEMP].  These restrictions illustrate
   why the RSVP extensions defined in [RSVP-AGG] are not sufficient to
   support aggregate reservations for IPSec tunnels.

   [RSVP-IPSEC] defines a Session Object containing several fields
   including a Virtual Destination Port (VDstPort) which allows support
   of a different reservation for each IPSec flow , or even of multiple
   reservations for a given IPSec flow.  However, (unlike with



Le Faucheur, et al.      Expires August 16, 2005                [Page 4]


Internet-Draft      Aggregate Reservations for IPsec       February 2005


   [RSVP-AGG]), the RSVP extensions of [RSVP-IPSEC] do not allow to
   include in the information which uniquely defines the reservation
   (i.e.  the Session and Filter Spec objects) the DSCP of the PHB to be
   used for aggregate classification and scheduling of the corresponding
   traffic.  The extensions of [RSVP-IPSEC] essentially assume a
   per-flow classification model.  This is why the RSVP extensions
   defined in [RSVP-IPSEC] are not sufficient either to support
   aggregate reservations for IPsec tunnels.

   This document defines incremental RSVP extensions which simply
   combine the concepts introduced in [RSVP-IPSEC] and in [RSVP-AGG] so
   their benefits can be obtained simultaneously hence allowing
   aggregate reservations for IPsec tunnels with Diffserv classification
   and scheduling.

   These extensions can be used in a number of scenarios.  They allow
   aggregation of end-to-end RSVP reservations over aggregate
   reservations for IPsec tunnels.  They also allow multi-level
   aggregation for example whereby the end-to-end RSVP reservations are
   first aggregated by a router acting as an [RSVP-AGG] aggregator and
   then where the [RSVP-AGG] aggregate reservations are in turn
   aggregated by the IPsec encryptor into "aggregate reservations for
   IPsec tunnels" as specified in this document.  They may also be used
   to establish an aggregate reservation for an IPsec tunnel between an
   IPsec encryptor and an IPsec decryptor for transport of other traffic
   than the one corresponding to end to end RSVP reservations (for
   example to provide a fixed pipe of Diffserv bandwidth from IPsec
   encryptor to IPsec decryptor to carry end-to-end Diffserv traffic).
   Another possible example usage is for establishment of an aggregate
   reservation end-to-end from an IPsec end-system to another IPsec
   end-system.

   These extensions allow full support of QoS signaling in Nested VPNs
   as discussed in [SIG-NESTED].  Example usage of these extensions in
   Nested VPN is described in section 5.

   The mechanisms defined in [BW-REDUC] (allowing an existing
   reservation to be reduced in allocated bandwidth in lieu of tearing
   that reservation down) are applicable to the aggregate reservations
   for IPsec tunnels defined in the present document.

   [RSVP-TUNNEL] describes a general approach to running RSVP over
   various types of tunnels.  One of the types of tunnel, referred to as
   a "type 2 tunnel", is similar to the tunnels described in this draft,
   in that a single, aggregate reservation is made for the tunnel while
   many individual flows are carried over that tunnel.  However,
   [RSVP-TUNNEL] does not address the case where data flows are
   encrypted, and thus does not deal with the use of the SPI to identify



Le Faucheur, et al.      Expires August 16, 2005                [Page 5]


Internet-Draft      Aggregate Reservations for IPsec       February 2005


   flows and sessions.  Nor does it address the use of Diffserv-based
   classification and queueing in the core of a network (between tunnel
   endpoints), but rather relies on a UDP/IP tunnel header for
   classification.  Thus we require some additional objects and
   procedures, defined in this draft, beyond those of [RSVP-TUNNEL].

   Section 2 presents an overview of the RSVP extensions defined in this
   document and how those are used.  Section 3 provides specification
   for the new RSVP objects.  The changes to existing RSVP processing
   rules are identified in Section 4.  Section 5 provides example usages
   of aggregate reservations for IPsec tunnels in a Nested VPN
   environment.  The IANA Considerations and the Security Considerations
   are discussed in Section 6 and 7, respectively.






































Le Faucheur, et al.      Expires August 16, 2005                [Page 6]


Internet-Draft      Aggregate Reservations for IPsec       February 2005


2.  Overview of Extensions

   The extensions defined in this document can be seen as simply the
   combination of the RSVP extensions defined in [RSVP-IPSEC] and in
   [RSVP-AGG].

   The basic notion of [RSVP-IPSEC] is to extend RSVP to use the IPSEC
   Security Parameter Index (SPI) in place of the UDP/TCP-like ports.
   This was achieved via:

   o  definition of a new FILTER_SPEC object which includes a
      Generalized Port Identifier (GPI) field which is used to convey
      the SPI

   o  definition of a new SESSION object which includes a Virtual
      Destination Port (VDstPort).  The VDstPort effectively allows for
      the differentiation of multiple IPSec sessions destined to the
      same IP address.  (The VDstPort is used in the Session rather than
      the SPI because it isn't feasible to force all senders to a
      session to use the same SPI - which is needed in situations where
      sharing of reservations across multiple senders is required)

   One of the key notions of [RSVP-AGG] is that inside the aggregation
   region, some RSVP reservation state is maintained per aggregate
   reservation, while classification and scheduling state (e.g., DSCPs
   used for classifying traffic) is maintained on a more highly
   aggregated basis.  For example, if Guaranteed Service reservations
   are mapped to the EF DSCP throughout the aggregation region, there
   may be a reservation for each aggregator/deaggregator pair in each
   router, but only the EF DSCP needs to be inspected for classification
   of the data traffic at each interior interface, and only a single
   queue is used for all EF traffic.  Support for this in [RSVP-AGG]
   involved:

   o  definition of a new SESSION object which includes the DSCP

   Hence, in order to simultaneously achieve support of per IPSec flow
   reservations as well as Diffserv aggregate classification and
   scheduling, this document :

   o  reuses the FILTER_SPEC object defined in [RSVP-IPSEC] and
      containing a GPI (which in turn can include the SPI)

   o  defines a new SESSION object which contains both the VDstPort and
      the DSCP

   The use of the VDstPort and GPI fields are as specified in
   [RSVP-IPSEC].  The use of the DSCP field is as specified in



Le Faucheur, et al.      Expires August 16, 2005                [Page 7]


Internet-Draft      Aggregate Reservations for IPsec       February 2005


   [RSVP-AGG].

   Where these RSVP extensions are used to perform aggregation of RSVP
   reservations over aggregate reservations for IPSec tunnels, the
   aggregation and deaggregation functions are as specified in
   [RSVP-AGG] unless explicitly spelled out in the following paragraphs.

   Like with [RSVP-AGG], it is the Deaggregator which is responsible for
   mapping E2E reservations onto Aggregate reservations.  In turn, this
   means the Deaggregator is responsible for requesting the Aggregator
   to initiate establishment of a new aggregate reservation when
   necessary and also for conveying to the Aggregator information about
   which aggregate reservation a given flow needs to be mapped onto.

   Like with [RSVP-AGG], to request establishment of an aggregate
   reservation, the Deaggregator sends an E2E PathErr message with an
   error code of NEW-AGGREGATE-NEEDED.  However, to provide all the
   necessary information about the needed aggregate reservation, this
   document extends the procedures of [RSVP-AGG] and allow the
   Deaggregator to include in the E2E PathErr message a new object
   called AGGREGATION-SESSION.  This object contains all the information
   describing the Session of the needed new aggregate reservation, in
   order to convey those to the Aggregator.

   This document also extends the procedures of [RSVP-AGG] to allow the
   Deaggregator to include the new AGGREGATION-SESSION object in the E2E
   Resv message, in order to convey to the Aggregator which aggregate
   session to map a given E2E reservation onto.























Le Faucheur, et al.      Expires August 16, 2005                [Page 8]


Internet-Draft      Aggregate Reservations for IPsec       February 2005


3.  Object Definition

   This document defines two new objects under the SESSION Class and a
   new object under a new AGGREGATION SESSION Class.

   It reuses the IPv4/GPI FILTER_SPEC, IPv6/GPI FILTER_SPEC, IPv4/GPI
   SENDER_TEMPLATE and IPv6/GPI SENDER_TEMPLATE objects defined in
   [RSVP-IPSEC].

3.1  SESSION Class


           o    AGGREGATE-IPv4/GPI SESSION object:
                  Class = 1
                  C-Type = To be allocated by IANA

            0           7 8          15 16         23 24          31
           +-------------+-------------+-------------+-------------+
           |               IPv4 DestAddress (4 bytes)              |
           +-------------+-------------+-------------+--+----------+
           | Protocol ID |     Flags   |  vDstPort      |  DSCP    |
           +-------------+-------------+-------------+--+----------+
            0           7 8          15 16            25 26       31

           o    AGGREGATE-IPv6/GPI SESSION object:
                  Class = 1
                  C-Type = To be allocated by IANA

            0           7 8          15 16         23 24          31
           +-------------+-------------+-------------+-------------+
           |                                                       |
           +                                                       +
           |                                                       |
           +               IPv6 DestAddress (16 bytes)             +
           |                                                       |
           +                                                       +
           |                                                       |
           +-------------+-------------+-------------+--+----------+
           | Protocol ID |     Flags   |  vDstPort      |   DSCP   |
           +-------------+-------------+-------------+--+----------+
            0           7 8          15 16            25 26       31


3.2  AGGREGATION-SESSION Class







Le Faucheur, et al.      Expires August 16, 2005                [Page 9]


Internet-Draft      Aggregate Reservations for IPsec       February 2005


           o    AGGREGATION-SESSION object:
                  Class = To be allocated by IANA
                  C-Type = To be allocated by IANA

             0           7 8          15 16            25 26       31
            +-------------+-------------+-------------+-------------+
            |       Length (bytes)      |  Class-Num  |   C-Type    |
            +-------------+-------------+-------------+-------------+
            |                                                       |
            //                  SESSION Object                     //
            |                                                       |
            +-------------+-------------+-------------+-------------+


   The Length, Class-Num and C-Type are those of the Session object
   which is included inside the AGGREGATION-SESSION object.  For
   example, if the AGGREGATION-SESSION object is used to indicate that
   the Aggregate Session needed is an AGGREGATE-IPv4/GPI SESSION then
   the AGGREGATION-SESSION will be encoded like this:

             0           7 8          15 16            25 26       31
            +-------------+-------------+-------------+-------------+
            |                           |AGGREGATE/GPI|AGGREGATE/GPI|
            |       Length (bytes)      |  Class-Num  |   C-Type    |
            +-------------+-------------+-------------+-------------+
            |               IPv4 DestAddress (4 bytes)              |
            +-------------+-------------+-------------+--+----------+
            | Protocol ID |     Flags   |  vDstPort      |   DSCP   |
            +-------------+-------------+-------------+--+----------+
             0           7 8          15 16            25 26       31





















Le Faucheur, et al.      Expires August 16, 2005               [Page 10]


Internet-Draft      Aggregate Reservations for IPsec       February 2005


4.  Processing Rules

   This section presents additions to the Processing Rules presented in
   [RSVP-PROCESS] and in [RSVP-IPSEC].  These additions are required in
   order to properly process the AGGREGATE-IPv4/GPI (resp
   AGGREGATE-IPv6/GPI) SESSION object and the IPv4/GPI (resp.
   IPv4-6/GPI) FILTER_SPEC object.  Values for referenced error codes
   can be found in [RSVP].  As with the other RSVP documents, values for
   internally reported (API) errors are not defined.

   When referring to the new AGGREGATE-IPv4/GPI and AGGREGATE-IPv6/GPI
   SESSION objects, IP version will not be included and they will be
   referred to simply as AGGREGATE/GPI SESSION, unless a specific
   distinction between IPv4 and IPv6 is being made.

   Similarly, as per the convention used in [RSVP-IPSEC], when referring
   to the objects defined in [RSVP-IPSEC], IP version will not be
   included unless a specific distinction between IPv4 and IPv6 is being
   made.

4.1  Required Changes

   Both RESV and PATH processing will need to be changed to support the
   new objects.

   The following PATH message processing changes are required:

   o  When a session is defined using the AGGREGATE/GPI SESSION object,
      only the GPI SENDER_TEMPLATE may be used.  When this condition is
      violated, RSVP end-stations should report a "Conflicting C-Type"
      API error to the application and routers should consider this as a
      message formatting error.

   o  For PATH messages that contain the AGGREGATE/GPI SESSION object,
      RSVP end-stations must verify that the protocol ID corresponds to
      a protocol known to use the AGGREGATE/GPI SESSION object.  Values
      51 (AH) or 50 (ESP) must be supported by implementations
      supporting the described IPSEC extensions.  If an unknown protocol
      ID is used, then the API on RSVP end-systems should report an "API
      Error" to the application.  If a router receives such a Path
      message with a protocol ID which doesn't correspond to a protocol
      known to use the AGGREGATE/GPI SESSION object, the router should
      consider this as a message formatting error.

   o  For PATH messages that contain the AGGREGATE/GPI SESSION object,
      the VDstPort value and the DSCP value should be recorded.  These
      values form part of the recorded state of the session.  Only the
      DSCP need be passed to traffic control, since the vDstPort is not



Le Faucheur, et al.      Expires August 16, 2005               [Page 11]


Internet-Draft      Aggregate Reservations for IPsec       February 2005


      contained in data packets.

   The changes to RESV message processing are:

   o  When a RESV message contains a GPI FILTER_SPEC, the session must
      be defined using either the GPI SESSION object (as per
      [RSVP-IPSEC]) or the AGGREGATE/GPI SESSION object (as per this
      document).  Otherwise, this is a message formatting error.

   o  The GPI contained in the GPI FILTER_SPEC must match the GPI
      contained in the SENDER_TEMPLATE.  Otherwise, a "No sender
      information for this Resv message" error is generated.

   o  When the GPI FILTER_SPEC is used and the SESSION type is
      AGGREGATE/GPI, each node must have a data classifier installed for
      the flow:

      *  If the node needs to perform per-flow classification (for
         example to perform per-flow policing on ingress at a trust
         boundary) then the node must create a data classifier described
         by the 5-tuple: (DestAddress, protocol ID, SrcAddress, GPI,
         DSCP).  The data classifier will need to look for the four byte
         GPI at transport header offset +4 for AH, and at transport
         header offset +0 for ESP (see [RSVP-IPSEC], [IPSEC-AG] and
         [IPSEC-ESP]).

      *  If the node only needs to perform Diffserv classification (for
         example inside the aggregation domain downstream of the trust
         boundary) then the node must rely on the Diffserv data
         classifier based on the DSCP only.


4.2  Merging Rules

   When using the extensions defined in this draft, RSVP sessions are
   defined by the 4-tuple: (DestAddress, protocol Id, vDstPort, DSCP).
   Similarly, a sender is defined by the tuple: (SrcAddress, GPI), where
   the GPI field will be a four byte representation of a generalized
   source port.  These extensions have some ramifications depending upon
   the reservation style.

   We note that, when IPSEC tunnels terminate on routers rather than
   extending all the way to end hosts, VDstPorts can be communicated by
   Deaggregators to Aggregators via the AGGREGATION-SESSION object
   included in the E2E PathErr.  This can be used to facilitate various
   sharing scenarios as needed (e.g.  the Deaggregator can convey the
   same VDstPort to different Aggregators which need to share a
   reservation; or conversely, the Deaggregator can communicate



Le Faucheur, et al.      Expires August 16, 2005               [Page 12]


Internet-Draft      Aggregate Reservations for IPsec       February 2005


   different VDstPorts to different Aggregators which need to have
   separate reservations).  Policies followed by the Deaggregator to
   determine which aggregators need shared or separate reservations are
   beyond the scope of this document.

4.2.1  FF and SE Styles

   In the FF and SE Styles, the FILTER_SPEC object contains the
   (SrcAddress, GPI) pair.  This allows the receiver to uniquely
   identify senders based on both elements of the pair.  When merging
   explicit sender descriptors, the senders may only be considered
   identical when both elements are identical.

4.2.2  WF Styles

   As with [RSVP-IPSEC], WF style is not well supported with these
   extensions.  Because there are no FILTER_SPEC objects for a WF
   reservation, any data packets with the session's destination IP
   address, protocol ID and DSCP will match the reservation (even if it
   is not carried inside the relevant IPsec tunnels because the SPI is
   not signaled and cannot be used for data classification).  This
   limitation is considered acceptable because of the expectation that
   WF reservations will not be often used in this environment.




























Le Faucheur, et al.      Expires August 16, 2005               [Page 13]


Internet-Draft      Aggregate Reservations for IPsec       February 2005


5.  Example Usage in Nested VPNs

   Let us consider the example environment presented in [SIG-NESTED] and
   reproduced below in Figure 2.  Let us assume that all the VPN routers
   (referred to as "VPN1", "VPN2" and so on) use IPSec among each other
   as the tunneling technology for support of VPNs .  It is assumed that
   the 6 enclaves attached to the VPN routers VPN1 to VPN6 effectively
   belong to the same VPN and can communicate with each other.
   Similarly, interface domain 1 and interface domain 2, respectively
   attached to VPN routers VPN7 and VPN8, effectively belong to the same
   VPN and can communicate with each other.

                        /                           \
                       (       +--+   +--+   enclave )   ,---------.
         .----------.   \      |H2+---+R2|          / ,-'           `
          +--+   +--+`--.\     +--+   ++-+         / /   +--+   +--+
          |H1+---+R1|    \`.           |         ,' /    |R3+---+H3|
          +--+   +-++     ) '--.    +----++  _.-'  (     ++-+   +--+
                   |     /    _.`---|VPN2||''-.     \     |
         enclave +----+-i.--''      +----++    `----.\ +----+ enclave
         --------|VPN1|'              |              ``|VPN3|       ,
                ,+----+               |                +----+------'
              ,' --+-------+----------+------------------+---`.
            ,'            ++-+                                 `.
          ,'              |R7+--------+                          `.
         / interface      +--+        |                            \
           domain 1                 +-+--+                          \
                          _.--------|VPN7|--------.
                  ,-----''          +--+-+         `------.         .
         `-.   ,-'                     |                   `-.   .-'
            `-:  inner domain        +-++                     `.'
            (                        |R9|                       )
            .'.                      ++-+                     ;-.
          .'   `-.                    |                    ,-'   `-.
         '        `------.          +-+--+         _.-----'         `
           interface      `---------|VPN8|-------''
           domain 2                 +-+--+                          /
         \                            |          +--+              /
          `.                          +----------+R8|            ,'
            `.                                   ++-+          ,'
              `. --+------------------+-----------+------+-- ,'
           ,-----+----+               |                +----+------.
         ,'      |VPN6|.              |              _.|VPN4|       `
                 +----+.`----.      +----+     _.--'' ,+----+
                  |     \     `--=.-|VPN5|---:'      /    |
          +--+   ++-+    :   ,-''   +----+    `--.  ;    ++-+   +--+
          |H6+---+R6|    | ,'          |          `.|    |R4+---+H4|
          +--+   +--+    ;/    +--+   ++-+          :    +--+   +--+



Le Faucheur, et al.      Expires August 16, 2005               [Page 14]


Internet-Draft      Aggregate Reservations for IPsec       February 2005


                        //     |H5+---+R5|           \
          enclave     ,'(      +--+   +--+            `.     enclave
         `.         ,'   \                 enclave   /  '-.         ,
           `-------'      \                         /      `-------'

   Figure 2: Reservations in a Nested VPN

   For clarity we will only consider a subset of the traffic flows and
   will only consider:

   o  the flows from the VPN1 enclave to the VPN5 enclave (e.g.  flows
      from Host H1 to Host H5)

   o  the flows from the VPN2 enclave to the VPN5 enclave (e.g.  flows
      from Host H2 to Host H5)

   Let us assume that:

   o  there is one security association between VPN1 and VPN5 (SPI1)

   o  there are two security associations between VPN2 and VPN5 (SPI2
      and SPI3)

   o  the reservations from VPN1 enclave to VPN5 enclave have a
      preemption P1

   o  the reservations from VPN2 enclave to VPN5 have a preemption of
      either P1 or P2

   o  the reservations are either Voice (which needs to be treated in
      the aggregation region using the EF PHB) or Video (which needs to
      be treated in the aggregation region using the AF41 PHB)

   o  there is one security association between VPN7and VPN8 (SPI4)

   Then, the following RSVP reservations may be established from VPN1 to
   VPN5 for aggregation of the lower level RSVP reservations:

   1.  Reservation for aggregation of Voice reservations from VPN1
       enclave to VPN5 enclave, requiring use of SPI1 and preemption P1:

       *  AGGREGATE-IPv4/GPI SESSION=VPN5/V1/EF

       *  STYLE=FF or SE

       *  IPv4/GPI FILTER_SPEC=VPN1/SPI1

       *  POLICY_DATA (PREEMPTION_PRI)=P1



Le Faucheur, et al.      Expires August 16, 2005               [Page 15]


Internet-Draft      Aggregate Reservations for IPsec       February 2005


   2.  Reservation for aggregation of Video reservations from VPN1
       enclave to VPN5 enclave, requiring use of SPI1 and preemption P1:

       *  AGGREGATE-IPv4/GPI SESSION=VPN5/V2/AF41

       *  STYLE=FF or SE

       *  IPv4/GPI FILTER_SPEC=VPN1/SPI1

       *  POLICY_DATA (PREEMPTION_PRI)=P1

   where V1 and V2 are arbitrary VDstPort values picked by VPN5 within
   the range set aside for dynamic allocation (see section 6).

   The following RSVP reservations may be established from VPN2 to VPN5
   for aggregation of the lower level RSVP reservations:

   1.  Reservation for aggregation of Voice reservations from VPN2
       enclave to VPN5 enclave, requiring use of SPI2 and preemption P1:

       *  AGGREGATE-IPv4/GPI SESSION=VPN5/V3/EF

       *  STYLE=FF or SE

       *  IPv4/GPI FILTER_SPEC=VPN2/SPI2

       *  POLICY_DATA (PREEMPTION_PRI)=P1

   2.  Reservation for aggregation of Video reservations from VPN2
       enclave to VPN5 enclave, requiring use of SPI2 and preemption P1:

       *  AGGREGATE-IPv4/GPI SESSION=VPN5/V4/AF41

       *  STYLE=FF or SE

       *  IPv4/GPI FILTER_SPEC=VPN2/SPI2

       *  POLICY_DATA (PREEMPTION_PRI)=P1

   3.  Reservation for aggregation of Voice reservations from VPN2
       enclave to VPN5 enclave, requiring use of SPI2 and preemption P2:

       *  AGGREGATE-IPv4/GPI SESSION=VPN5/V5/EF

       *  STYLE=FF or SE

       *  IPv4/GPI FILTER_SPEC=VPN2/SPI2




Le Faucheur, et al.      Expires August 16, 2005               [Page 16]


Internet-Draft      Aggregate Reservations for IPsec       February 2005


       *  POLICY_DATA (PREEMPTION_PRI)=P2

   4.  Reservation for aggregation of Video reservations from VPN2
       enclave to VPN5 enclave, requiring use of SPI2 and preemption P2:

       *  AGGREGATE-IPv4/GPI SESSION=VPN5/V6/AF41

       *  STYLE=FF or SE

       *  IPv4/GPI FILTER_SPEC=VPN2/SPI2

       *  POLICY_DATA (PREEMPTION_PRI)=P2

   5.  Reservation for aggregation of Voice reservations from VPN2
       enclave to VPN5 enclave, requiring use of SPI3 and preemption P1:

       *  AGGREGATE-IPv4/GPI SESSION=VPN5/V7/EF

       *  STYLE=FF or SE

       *  IPv4/GPI FILTER_SPEC=VPN2/SPI3

       *  POLICY_DATA (PREEMPTION_PRI)=P1

   6.  Reservation for aggregation of Video reservations from VPN2
       enclave to VPN5 enclave, requiring use of SPI3 and preemption P1:

       *  AGGREGATE-IPv4/GPI SESSION=VPN5/V8/AF41

       *  STYLE=FF or SE

       *  IPv4/GPI FILTER_SPEC=VPN2/SPI3

       *  POLICY_DATA (PREEMPTION_PRI)=P1

   7.  Reservation for aggregation of Voice reservations from VPN2
       enclave to VPN5 enclave, requiring use of SPI3 and preemption P2:

       *  AGGREGATE-IPv4/GPI SESSION=VPN5/V9/EF

       *  STYLE=FF or SE

       *  IPv4/GPI FILTER_SPEC=VPN2/SPI3

       *  POLICY_DATA (PREEMPTION_PRI)=P2

   8.  Reservation for aggregation of Video reservations from VPN2
       enclave to VPN5 enclave, requiring use of SPI3 and preemption P2:



Le Faucheur, et al.      Expires August 16, 2005               [Page 17]


Internet-Draft      Aggregate Reservations for IPsec       February 2005


       *  AGGREGATE-IPv4/GPI SESSION=VPN5/V10/AF41

       *  STYLE=FF or SE

       *  IPv4/GPI FILTER_SPEC=VPN2/SPI3

       *  POLICY_DATA (PREEMPTION_PRI)=P2

   where V3 to V10 are arbitrary VDstPort values picked by VPN5 within
   the range set aside for dynamic allocation (see section 6).

   The following RSVP reservations may be established from VPN7 to VPN8
   for aggregation of the lower level RSVP reservations (i.e.  the
   reservations from VPN1 to VPN5 and from VPN2 to VPN5):

   1.  Reservation for aggregation of Voice reservations from interface
       domain 1 to interface domain 2, requiring use of SPI4 and
       preemption P1:

       *  AGGREGATE-IPv4/GPI SESSION=VPN8/V1/EF

       *  STYLE=FF or SE

       *  IPv4/GPI FILTER_SPEC=VPN7/SPI4

       *  POLICY_DATA (PREEMPTION_PRI)=P1

   2.  Reservation for aggregation of Video reservations from interface
       domain 1 to interface domain 2, requiring use of SPI4 and
       preemption P1:

       *  AGGREGATE-IPv4/GPI SESSION=VPN8/V2/AF41

       *  STYLE=FF or SE

       *  IPv4/GPI FILTER_SPEC=VPN7/SPI4

       *  POLICY_DATA (PREEMPTION_PRI)=P1

   3.  Reservation for aggregation of Voice reservations from interface
       domain 1 to interface domain 2, requiring use of SPI4 and
       preemption P2:

       *  AGGREGATE-IPv4/GPI SESSION=VPN8/V3/EF

       *  STYLE=FF or SE

       *  IPv4/GPI FILTER_SPEC=VPN7/SPI4



Le Faucheur, et al.      Expires August 16, 2005               [Page 18]


Internet-Draft      Aggregate Reservations for IPsec       February 2005


       *  POLICY_DATA (PREEMPTION_PRI)=P2

   4.  Reservation for aggregation of Video reservations from interface
       domain 1 to interface domain 2, requiring use of SPI4 and
       preemption P2:

       *  AGGREGATE-IPv4/GPI SESSION=VPN8/V4/AF41

       *  STYLE=FF or SE

       *  IPv4/GPI FILTER_SPEC=VPN7/SPI4

       *  POLICY_DATA (PREEMPTION_PRI)=P2

   where V1 to V4 are arbitrary VDstPort values picked by VPN8 within
   the range set aside for dynamic allocation (see section 6).



































Le Faucheur, et al.      Expires August 16, 2005               [Page 19]


Internet-Draft      Aggregate Reservations for IPsec       February 2005


6.  IANA Considerations

   This document requests that IANA allocates two new C-Types under the
   Class 1 for the two new RSVP objects defined in section 3.1.

   This document requests that IANA allocates a new Class-Num and a new
   C-Type for the two new RSVP object defined in section 3.2.

   This document defines in section 3.1 a "Virtual Destination Port
   (VDstPort)" field of 8 bits within the new Session objects defined in
   this document.  The range of possible vDstPort values is broken down
   into sections, in a fashion similar to the VDstPort range of
   [RSVP-IPSEC] (but not identical since the VDstPort field of
   [RSVP-IPSEC] has 16 bits):

      0         Illegal Value
      1 - 63    Assigned by IANA
      64 - 255  Dynamic

   IANA is requested to create and maintain this new name space.  The
   IANA guidelines for assignments for this field are as follows: o
   values in the range 1-63 are to be assigned according to the "XXX"
   policy defined in [IANA-CONS].

   Note to RFC Editor: in the process assigning numbers and building
   IANA registries prior to publication, this section will have served
   its purpose.  It may therefore be removed upon publication as an RFC.
























Le Faucheur, et al.      Expires August 16, 2005               [Page 20]


Internet-Draft      Aggregate Reservations for IPsec       February 2005


7.  Security Considerations

   The mechanisms defined in [RSVP-CRYPTO] and [RSVP-CRYPTO2] can be
   used to provide hop-by-hop integrity and authentication of RSVP
   messages related to the aggregate reservations discussed in this
   document.

   The same considerations stated in [RSVP-IPSEC] and [SIG-NESTED] apply
   to the extensions described in this document.

   An additional data element, namely the DSCP is expressed in the
   session object.  The DSCP value of an associated flow should
   correspond to the DSCP value in the session object.  The requirements
   of a router to aggregate a flow using DSCP are further described in
   [RSVP-AGG] and [SIG-NESTED].  Protection against traffic analysis
   attacks based on DSCP is outside the scope of the extensions in this
   document.  If an IPSec router uses a different IP address outside its
   enclave from the one it uses within its enclave, the objects defined
   or extended in this document should contain the external IP address
   of the IPSec router.  Example usage in Section 5 also depicts the
   same preemption priority level being maintained through a nested
   path.  The policy preemption element may literally be the same as
   used within the innermost VPN enclave or a different value as agreed
   at VPN boundaries.  The marking and remarking of priority levels
   across administrative and VPN boundaries is beyond the scope of this
   document.  Protection against traffic analysis attacks based on
   preemption is outside the scope of the extensions in this document.
   Security concerns of message integrity, node and user authentication
   are implicitly met by the security association that exists between
   the IPSec/VPN routers.

   Changes in SPI values for a given IPsec tunnel will affect associated
   aggregate RSVP reservations.  Changes will happen whenever that IPsec
   tunnel changes its Security Association.  Such changes will occur
   when a tunnel is re-keyed (i.e.  to use a new key).  Re-keying
   intervals are typically set based on traffic levels, key size, threat
   environment,and crypto algorithm in use.  When an SPI change occurs
   it will, in most cases, be necessary to update (send) the
   corresponding SENDER_TEMPLATEs and FILTER_SPECs.  Implementations of
   this specification need to take the possibility of changes of SPI
   into account to ensure proper reservation behavior.

   For those applications that do need to deal with changes of SPIs, the
   impact of sending new PATH and RESV messages corresponding to
   aggregate reservations will vary based on the reservation style being
   used.  Builders of such applications may want to select reservation
   style based on interaction with SPI changes.  The least impact of an
   SPI change will be to WF style reservations.  For such reservations,



Le Faucheur, et al.      Expires August 16, 2005               [Page 21]


Internet-Draft      Aggregate Reservations for IPsec       February 2005


   a new SENDER_TEMPLATE will need to be sent, but no new RESV is
   required.  For SE style reservations, both a new SENDER_TEMPLATE and
   a new RESV will need to be sent.  This will result in changes to
   state, but should not affect data packet delivery or actual resource
   allocation in any way.  The FF style will be impacted the most.  Like
   with SE, both PATH and RESV messages will need to be sent.  But,
   since FF style reservations result in sender receiving its own
   resource allocation, resources will be allocated twice for a period
   of time.  Or, even worse, there won't be enough resources to support
   the new flow without first freeing the old flow.

   A way around this FF/SPI-change problem does exist.  Applications
   that want FF style reservations (in other words that want separate
   reservations) can use multiple SE reservations.  Each Aggregator
   would have a separate SESSION definition thanks to a different
   VDstPort value.  This is facilitated by the ability of the
   Deaggregator to distribute different VDstPorts to each Aggregator
   (through the AGGREGATION-SESSION object in the E2E PathErr as
   discussed above).  When it came time to switch SPIs, a shared
   reservation could be made for the new SPI while the old SPI was still
   active.  Once the new SPI was in use, the old reservation could be
   torn down.  This will provide uninterrupted service over the
   aggregate reservations for IPsec tunnels.




























Le Faucheur, et al.      Expires August 16, 2005               [Page 22]


Internet-Draft      Aggregate Reservations for IPsec       February 2005


8.  Acknowledgments

   This document borrows heavily from [RSVP-IPSEC] and [RSVP-AGG].
   Also, we thank Fred Baker, Roger Levesque, Carol Iturralde, Daniel
   Voce and Anil Agarwal for their input into the content of this
   document.













































Le Faucheur, et al.      Expires August 16, 2005               [Page 23]


Internet-Draft      Aggregate Reservations for IPsec       February 2005


9.  References

9.1  Normative References

   [RSVP-IPSEC] "RSVP Extensions for IPSEC Data Flows", Berger et al,
   RFC2207

   [RSVP-AGG] "Aggregation of RSVP for IPv4 and IPv6 Reservations",
   Baker et al, RFC3175

   [SIG-NESTED] "QoS Signaling in a Nested Virtual Private Network",
   Baker et al, draft-baker-tsvwg-vpn-signaled-preemption-02.txt

   [RSVP-PROCESS] "Resource ReSerVation Protocol (RSVP) -- Version 1
   Message Processing Rules", Braden et al, RFC2209

   [IPSEC-AH] "IP Authentication Header", Kent et al, RFC2402

   [IPSEC-ESP] "IP Encapsulating Security Payload (ESP)", Kent et al,
   RFC2406

   [RSVP-CRYPTO] "RSVP Cryptographic Authentication", Baker et al,
   RFC2747

   [RSVP-CRYPTO2] "RSVP Cryptographic Authentication", Braden et al,
   RFC3097

9.2  Informative References

   [BW-REDUC] "A Resource Reservation Extension for the Reduction of
   Bandwidth of a Reservation Flow", Polk et al,
   draft-polk-tsvwg-rsvp-bw-reduction-00.txt

   [RSVP-TUNNEL] "RSVP Operation Over IP Tunnels", Terzis et al., RFC
   2746, January 2000.
















Le Faucheur, et al.      Expires August 16, 2005               [Page 24]


Internet-Draft      Aggregate Reservations for IPsec       February 2005


Authors' Addresses

   Francois Le Faucheur
   Cisco Systems
   Greenside - 400 Avenue de Roumanille
   Sophia Antipolis,   06410
   France

   Phone: +33-4-97-23-26-19
   Fax:   +33-4-97-23-26-26
   Email: flefauch@cisco.com


   Bruce Davie
   Cisco Systems
   1414 Massachusetts Ave.
   Boxborough, MA  01719
   USA

   Phone:
   Fax:
   Email: bdavie@cisco.com


   Pratik Bose
   Lockheed Martin
   22300 Comsat Drive Clarksburg, MD 20814 USA


   Phone: +1 301 428 4215
   Fax:   +1 301 428 5147
   Email: pratik.bose@lmco. com


   Chris Christou
   Booz Allen Hamilton
   8283 Greensboro Drive
   McLean, VA 22102,
   USA

   Phone:
   Fax:
   Email: christou_chris@bah.com








Le Faucheur, et al.      Expires August 16, 2005               [Page 25]


Internet-Draft      Aggregate Reservations for IPsec       February 2005


   Mike Davenport
   Booz Allen Hamilton
   8283 Greensboro Drive McLean, VA 22102
   USA

   Phone:
   Fax:
   Email: davenport_michael@bah.com











































Le Faucheur, et al.      Expires August 16, 2005               [Page 26]


Internet-Draft      Aggregate Reservations for IPsec       February 2005


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights 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; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM 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.


Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Le Faucheur, et al.      Expires August 16, 2005               [Page 27]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/