RFC 2207 (rfc2207) - Page 3 of 14
RSVP Extensions for IPSEC Data Flows
Alternative Format: Original Text Document
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