RSVP Extensions for IPSEC Data Flows
Extracted elements (22)
AH Transparency (having classifiers skip over AH before classifying packets) was rejected despite requiring no protocol changes because it lacks a consistent solution for both AH and ESP—ESP encrypts transport headers, making them unusable for classification.
Applications requiring FF-style semantics but needing to handle SPI rekeying gracefully can use multiple SE reservations with separate SESSION (vDstPort) definitions per sender. A shared reservation for the new SPI is established before tearing down the old, enabling uninterrupted service during rekeying at the cost of additional complexity.
Modifying IPSEC headers to place the SPI at the UDP/TCP port offset was rejected because the AH SPI is not at offset +0 in the transport header, the fix would violate RFC 1826, and using the SPI directly under the existing RSVP model causes setup timing problems and limited support for SE/WF reservation styles.
RSVP Version 1 can support IPSEC only on a per-address, per-protocol basis because it expects UDP/TCP-like port fields. This document extends RSVP to use the IPSEC Security Parameter Index (SPI) in place of ports, enabling per-flow reservation granularity without modifying RFC 1826 or RFC 1827 and adding no per-data-packet overhead.
The four-byte field carrying the SPI is labeled 'Generalized Port Identifier' (GPI) rather than 'SPI' so that the new SESSION, FILTER_SPEC, and SENDER_TEMPLATE objects can be reused for non-IPSEC protocols in the future.
UDP encapsulation (inserting a UDP header between IP and AH/ESP) was rejected because, although it requires no RSVP changes, placing headers at unexpected locations violates RFC 1826 and RFC 1827.
In FF and SE reservation styles, the (SrcAddress, GPI) pair in the FILTER_SPEC uniquely identifies senders; two explicit sender descriptors are considered identical only when both elements are identical.
WF style reservations provide very limited service with these extensions: RESV messages for WF do not contain a FILTER_SPEC and SENDER_TEMPLATEs are ignored, so classifiers match all packets with the session's destination IP address and protocol ID to WF reservations, defeating per-flow granularity.
For PATH messages using the GPI SESSION object, end-stations must verify that the protocol ID is a protocol known to use GPI SESSION. Protocol IDs 51 (AH) and 50 (ESP) must be supported by implementations of these IPSEC extensions.
Non-zero values of vDstPort are required in GPI SESSION objects. This ensures that a non-GPI SESSION object will never merge with a GPI SESSION object; a zero value causes an 'Invalid Destination Port' API error.
When a RESV message contains a GPI FILTER_SPEC, the session must be defined using the GPI SESSION object; otherwise this is a message formatting error. The GPI in the FILTER_SPEC must also match the GPI in the corresponding SENDER_TEMPLATE.
When a session is defined using the GPI SESSION object, only the GPI SENDER_TEMPLATE may be used in PATH messages. Violation should be reported as a 'Conflicting C-Type' API error.
When the GPI FILTER_SPEC is used, each node must create a data classifier for the flow described by the quadruple (DestAddress, protocol ID, SrcAddress, GPI). The GPI must be extracted from transport header offset +4 for AH, and offset +0 for ESP.
A virtual destination port (vDstPort) is introduced and carried in the new GPI SESSION object but not in the IPSEC transport header. It allows differentiation of multiple IPSEC sessions destined to the same IP address and serves as the session demultiplexing value that replaces the DstPort in the (DestAddress, protocol ID, DstPort) session triple.
IPv4/GPI SENDER_TEMPLATE (Class=11, C-Type=4) and IPv6/GPI SENDER_TEMPLATE (Class=11, C-Type=5) have identical formats to their respective GPI FILTER_SPEC objects, containing SrcAddress and GPI.
IANA is directed to manage a vDstPort registry analogous to UDP/TCP ports: value 0 is illegal, 1–10 are reserved (contact authors), 11–8191 are assigned by IANA upon request (requiring point of contact, intended use description, and short name), and 8192–65535 are dynamic.
SPI values change whenever a Security Association is rekeyed. When an SPI change occurs, the corresponding SENDER_TEMPLATEs and FILTER_SPECs must generally be updated. FF style reservations are most affected: resources may be double-allocated or insufficient during the transition; SE style causes state changes without affecting delivery; WF style requires only a new SENDER_TEMPLATE.
The vDstPort mechanism exposes additional flow metadata in RSVP control messages that could aid traffic analysis attacks by an adversary monitoring both data packets and RSVP signaling. Protection against such attacks is outside the scope of this mechanism; link-layer confidentiality such as encryption is one possible mitigation.
IPv4/GPI FILTER_SPEC object (Class=10, C-Type=4): 4-byte IPv4 SrcAddress followed by a 4-byte Generalized Port Identifier (GPI) field carrying the IPSEC SPI.
IPv4/GPI SESSION object (Class=1, C-Type=3): 4-byte IPv4 DestAddress followed by 1-byte Protocol ID, 1-byte Flags, and 2-byte vDstPort.
IPv6/GPI FILTER_SPEC object (Class=10, C-Type=5): 16-byte IPv6 SrcAddress followed by a 4-byte Generalized Port Identifier (GPI) field carrying the IPSEC SPI.
IPv6/GPI SESSION object (Class=1, C-Type=4): 16-byte IPv6 DestAddress followed by 1-byte Protocol ID, 1-byte Flags, and 2-byte vDstPort.