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
