Network Working Group L. Berger
Request for Comments: 2207 FORE Systems
Category: Standards Track T. O'Malley
BBN
September 1997
RSVP Extensions for IPSEC Data Flows
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Abstract
This document presents extensions to Version 1 of RSVP. These
extensions permit support of individual data flows using RFC 1826, IP
Authentication Header (AH) or RFC 1827, IP Encapsulating Security
Payload (ESP). RSVP Version 1 as currently specified can support the
IPSEC protocols, but only on a per address, per protocol basis not on
a per flow basis. The presented extensions can be used with both
IPv4 and IPv6.
Berger & O'Malley Standards Track [Page 1]
RFC 2207 RSVP Extensions for IPSEC September 1997
Table of Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . 2
2 Overview of Extensions . . . . . . . . . . . . . . . . . . 3
3 Object Definition. . . . . . . . . . . . . . . . . . . . . 4
3.1 SESSION Class . . . . . . . . . . . . . . . . . . . . 5
3.2 FILTER_SPEC Class . . . . . . . . . . . . . . . . . . 5
3.3 SENDER_TEMPLATE Class . . . . . . . . . . . . . . . . 6
4 Processing Rules . . . . . . . . . . . . . . . . . . . . . 6
4.1 Required Changes. . . . . . . . . . . . . . . . . . . 6
4.2 Merging Flowspecs . . . . . . . . . . . . . . . . . . 7
4.2.1 FF and SE Styles. . . . . . . . . . . . . . . . . . 7
4.2.2 WF Styles . . . . . . . . . . . . . . . . . . . . . 8
5 IANA Considerations. . . . . . . . . . . . . . . . . . . . 8
6 Security Considerations. . . . . . . . . . . . . . . . . . 8
7 References . . . . . . . . . . . . . . . . . . . . . . . .10
8 Acknowledgments . . . . . . . . . . . . . . . . . . . . .10
9 Authors' Addresses . . . . . . . . . . . . . . . . . . . .10
A Options Considered . . . . . . . . . . . . . . . . . . . .11
A.1 UDP Encapsulation . . . . . . . . . . . . . . . . . .11
A.2 FlowID Header Encapsulation . . . . . . . . . . . . .12
A.3 IPSEC Protocol Modification . . . . . . . . . . . . .12
A.4 AH Transparency . . . . . . . . . . . . . . . . . . .13
1 Introduction
Recently published Standards Track RFCs specify protocol mechanisms
to provide IP level security. These IP Security, or IPSEC, protocols
support packet level authentication, [RFC 1826], and integrity and
confidentiality [RFC 1827]. A number of interoperable
implementations already exist and several vendors have announced
commercial products that will use these mechanisms.
The IPSEC protocols provide service by adding a new header between a
packet's IP header and the transport (e.g. UDP) protocol header. The
two security headers are the Authentication Header (AH), for
authentication, and the Encapsulating Security Payload (ESP), for
integrity and confidentiality.
RSVP is being developed as a resource reservation (dynamic QoS setup)
protocol. RSVP as currently specified [RFC 2205] is tailored towards
IP packets carrying protocols that have TCP or UDP-like ports.
Protocols that do not have such UDP/TCP-like ports, such as the IPSEC
protocols, can be supported, but only with limitations.
Specifically, for flows of IPSEC data packets, flow definition can
only be done on per IP address, per protocol basis.
Berger & O'Malley Standards Track [Page 2]
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