RFC 2207 (rfc2207) - Page 3 of 14

RSVP Extensions for IPSEC Data Flows

RFC 2207               RSVP Extensions for IPSEC          September 1997


   This memo proposes extensions to RSVP so that data flows containing
   IPSEC protocols can be controlled at a granularity similar to what is
   already specified for UDP and TCP.  The proposed extensions can be
   used with both IPv4 and IPv6.  Section 2 of this memo will provide an
   overview of extensions.  Section 3 contains a description of extended
   protocol mechanisms.  Section 4 presents extended protocol processing
   rules.  Section 5 defines the additional RSVP data objects.

2   Overview of Extensions

   The basic notion is to extend RSVP to use the IPSEC Security
   Parameter Index, or SPI, in place of the UDP/TCP-like ports.  This
   will require a new FILTER_SPEC object, which will contain the IPSEC
   SPI, and a new SESSION object.

   While SPIs are allocated based on destination address, they will
   typically be associated with a particular sender.  As a result, two
   senders to the same unicast destination will usually have different
   SPIs.  In order to support the control of multiple independent flows
   between source and destination IP addresses, the SPI will be included
   as part of the FILTER_SPEC.  When using WF, however, all flows to the
   same IP destination address using the same IP protocol ID will share
   the same reservation.  (This limitation exists because the IPSEC
   transport headers do not contain a destination demultiplexing value
   like the UDP/TCP destination port.)

   Although the RESV message format will not change, RESV processing
   will require modification.  Processing of the new IPSEC FILTER_SPEC
   will depend on the use of the new SESSION object and on the protocol
   ID contained in the session definition.  When the new FILTER_SPEC
   object is used, the complete four bytes of the SPI will need to be
   extracted from the FILTER_SPEC for use by the packet classifier.  The
   location of the SPI in the transport header of the IPSEC packets is
   dependent on the protocol ID field.

   The extension will also require a change to PATH processing,
   specifically in the usage of the port field in a session definition.
   An RSVP session is defined by the triple: (DestAddress, protocol ID,
   DstPort).  [RFC 2205] includes the definition of one type of SESSION
   object, it contains UDP/TCP destination ports, specifically "a 16-bit
   quantity carried at the octet offset +2 in the transport header" or
   zero for protocols that lack such a field.  The IPSEC protocols do









Berger & O'Malley           Standards Track