As per Relevance of the word september, we have this rfc below:
Network Working Group L.
Request for Comments: 2207 FORE
Category: Standards Track T. O'
September 1997
RSVP Extensions for IPSEC Data
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
This document presents extensions to Version 1 of RSVP.
extensions permit support of individual data flows using RFC 1826,
Authentication Header (AH) or RFC 1827, IP Encapsulating
Payload (ESP). RSVP Version 1 as currently specified can support
IPSEC protocols, but only on a per address, per protocol basis not
a per flow basis. The presented extensions can be used with
IPv4 and IPv6.
Berger & O'Malley Standards Track [Page 1]
RFC 2207 RSVP Extensions for IPSEC September 1997
Table of
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
Recently published Standards Track RFCs specify protocol
to provide IP level security. These IP Security, or IPSEC,
support packet level authentication, [RFC 1826], and integrity
confidentiality [RFC 1827]. A number of
implementations already exist and several vendors have
commercial products that will use these mechanisms
The IPSEC protocols provide service by adding a new header between
packet's IP header and the transport (e.g. UDP) protocol header.
two security headers are the Authentication Header (AH),
authentication, and the Encapsulating Security Payload (ESP),
integrity and confidentiality
RSVP is being developed as a resource reservation (dynamic QoS setup
protocol. RSVP as currently specified [RFC 2205] is tailored
IP packets carrying protocols that have TCP or UDP-like ports
Protocols that do not have such UDP/TCP-like ports, such as the
protocols, can be supported, but only with limitations
Specifically, for flows of IPSEC data packets, flow definition
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
IPSEC protocols can be controlled at a granularity similar to what
already specified for UDP and TCP. The proposed extensions can
used with both IPv4 and IPv6. Section 2 of this memo will provide
overview of extensions. Section 3 contains a description of
protocol mechanisms. Section 4 presents extended protocol
rules. Section 5 defines the additional RSVP data objects
2 Overview of
The basic notion is to extend RSVP to use the IPSEC
Parameter Index, or SPI, in place of the UDP/TCP-like ports.
will require a new FILTER_SPEC object, which will contain the
SPI, and a new SESSION object
While SPIs are allocated based on destination address, they
typically be associated with a particular sender. As a result,
senders to the same unicast destination will usually have
SPIs. In order to support the control of multiple independent
between source and destination IP addresses, the SPI will be
as part of the FILTER_SPEC. When using WF, however, all flows to
same IP destination address using the same IP protocol ID will
the same reservation. (This limitation exists because the
transport headers do not contain a destination demultiplexing
like the UDP/TCP destination port.)
Although the RESV message format will not change, RESV
will require modification. Processing of the new IPSEC FILTER_
will depend on the use of the new SESSION object and on the
ID contained in the session definition. When the new FILTER_
object is used, the complete four bytes of the SPI will need to
extracted from the FILTER_SPEC for use by the packet classifier.
location of the SPI in the transport header of the IPSEC packets
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
object, it contains UDP/TCP destination ports, specifically "a 16-
quantity carried at the octet offset +2 in the transport header"
zero for protocols that lack such a field. The IPSEC protocols
Berger & O'Malley Standards Track [Page 3]
RFC 2207 RSVP Extensions for IPSEC September 1997
not contain such a field, but there remains a requirement
demultiplexing sessions beyond the IP destination address. In
to satisfy this requirement, a virtual destination port, or vDstPort
is introduced. The vDstPort value will be carried in the new
object but not in the IPSEC transport header. The vDstPort
for the differentiation of multiple IPSEC sessions destined to
same IP address. See Section 5 for a discussion of vDstPort ranges
In PATH messages, the SENDER_TEMPLATE for IPSEC flows will have
same format as the modified FILTER_SPEC. But, a new SESSION
will be used to unambiguously distinguish the use of a
destination port
Traffic will be mapped (classified) to reservations based on SPIs
FILTER_SPECs. This, of course, means that when WF is used all
to the same IP destination address and with the same IP protocol
will share the same reservation
The advantages to the described approach are that no changes
RFC1826 and 1827 are required and that there is no additional
data packet overhead. Appendix A contains a discussion of
advantages of this approach compared to several other alternatives
This approach does not take advantage of the IPv6 Flow Label field
so greater efficiency may be possible for IPv6 flows. The details
IPv6 Flow Label usage is left for the future
3 Object
The FILTER_SPEC and SENDER_TEMPLATE used with IPSEC protocols
contain a four byte field that will be used to carry the SPI.
than label the modified field with an IPSEC specific label, SPI,
label "Generalized Port Identifier", or GPI, will be so that
object may be reused for non-IPSEC uses in the future. The name
these objects are the IPv4/GPI FILTER_SPEC, IPv6/GPI FILTER_SPEC
IPv4/GPI SENDER_TEMPLATE, and IPv6/GPI SENDER_TEMPLATE. Similarly
the new SESSION objects will be the IPv4/GPI SESSION and the IPv6/
SESSION. When referring to the new objects, IP version will not
included unless a specific distinction between IPv4 and IPv6 is
made
Berger & O'Malley Standards Track [Page 4]
RFC 2207 RSVP Extensions for IPSEC September 1997
3.1 SESSION
SESSION Class = 1.
o IPv4/GPI SESSION object: Class = 1, C-Type = 3
+-------------+-------------+-------------+-------------+
| IPv4 DestAddress (4 bytes) |
+-------------+-------------+-------------+-------------+
| Protocol ID | Flags | vDstPort |
+-------------+-------------+-------------+-------------+
o IPv6/GPI SESSION object: Class = 1, C-Type = 4
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ IPv6 DestAddress (16 bytes) +
| |
+ +
| |
+-------------+-------------+-------------+-------------+
| Protocol ID | Flags | vDstPort |
+-------------+-------------+-------------+-------------+
3.2 FILTER_SPEC
FILTER_SPEC class = 10.
o IPv4/GPI FILTER_SPEC object: Class = 10, C-Type = 4
+-------------+-------------+-------------+-------------+
| IPv4 SrcAddress (4 bytes) |
+-------------+-------------+-------------+-------------+
| Generalized Port Identifier (GPI) |
+-------------+-------------+-------------+-------------+
Berger & O'Malley Standards Track [Page 5]
RFC 2207 RSVP Extensions for IPSEC September 1997
o IPv6/GPI FILTER_SPEC object: Class = 10, C-Type = 5
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ IPv6 SrcAddress (16 bytes) +
| |
+ +
| |
+-------------+-------------+-------------+-------------+
| Generalized Port Identifier (GPI) |
+-------------+-------------+-------------+-------------+
3.3 SENDER_TEMPLATE
SENDER_TEMPLATE class = 11.
o IPv4/GPI SENDER_TEMPLATE object: Class = 11, C-Type = 4
Definition same as IPv4/GPI FILTER_SPEC object
o IPv6/GPI SENDER_TEMPLATE object: Class = 11, C-Type = 5
Definition same as IPv6/GPI FILTER_SPEC object
4 Processing
This section presents additions to the Processing Rules presented
[RFC 2209]. These additions are required in order to
process the GPI SESSION and FILTER_SPEC objects. Values
referenced error codes can be found in [RFC 2205]. As in with
other RSVP documents, values for internally reported (API) errors
not defined
4.1 Required
Both RESV and PATH processing will need to be changed to support
new objects. The changes ensure consistency and extend
processing
The following PATH message processing changes are required
o When a session is defined using the GPI SESSION object,
the GPI SENDER_TEMPLATE may be used. When this condition
violated, end-stations should report a "Conflicting C-Type"
error to the application
Berger & O'Malley Standards Track [Page 6]
RFC 2207 RSVP Extensions for IPSEC September 1997
o For PATH messages that contain the GPI SESSION object
end-stations must verify that the protocol ID corresponds to
protocol known to use the GPI SESSION object. Values 51 (AH
or 50 (ESP) must be supported by implementations
the described IPSEC extensions. If an unknown protocol ID
used, then the API should report an "API Error" to
application
o For such messages, the vDstPort value should be recorded
The vDstPort value forms part of the recorded state and is
to match Resv messages, but it is not passed to traffic control
Non-zero values of vDstPort are required. This
ensures that a non-GPI SESSION object will never merge with
GPI SESSION object. Violation of this condition causes
"Invalid Destination Port" API error
The changes to RESV message processing are
o When a RESV message contains a GPI FILTER_SPEC, the
must be defined using the GPI SESSION object. Otherwise, this
a message formatting error
o The GPI contained in the FILTER_SPEC must match the
contained in the SENDER_TEMPLATE. Otherwise, a "No
information for this Resv message" error is generated
o When the GPI FILTER_SPEC is used, each node must
a data classifier for the flow described by the quadruple
(DestAddress, protocol ID, SrcAddress, GPI). The data
will need to look for the four byte GPI at transport
offset +4 for AH, and at transport header offset +0 for ESP
4.2 Merging
When using this extension for IPSEC data flows, RSVP sessions
defined by the triple: (DestAddress, protocol Id, vDstPort).
Similarly, a sender is defined by the tuple: (SrcAddress, GPI),
the GPI field will be a four byte representation of a
source port. These extensions have some ramifications depending
the reservation style
4.2.1 FF and SE
In the FF and SE Styles, the FILTER_SPEC object contains
(SrcAddress, GPI) pair. This allows the receiver to
identify senders based on both elements of the pair. When
explicit sender descriptors, the senders may only be
identical when both elements are identical
Berger & O'Malley Standards Track [Page 7]
RFC 2207 RSVP Extensions for IPSEC September 1997
4.2.2 WF
These extensions provide very limited service when used with WF
reservations. As described, the SENDER_TEMPLATE and FILTER_SPEC
contain the GPI. In a WF style reservation, the RESV message
NOT contain a FILTER_SPEC (after all, it is a wildcard filter),
the SENDER_TEMPLATE is ignored (again, because any sender
allowed). As a result, classifiers may match all packets
contain both the session's destination IP address and protocol ID
such WF reservations
Although a solution for this limitation is not proposed, this
is not seen as significant since IPSEC applications are less
to use WF style reservations
5 IANA
The range of possible vDstPort values is broken down into sections
in a fashion similar to the UDP/TCP port ranges
0 Illegal
1 - 10 Reserved. Contact authors
11 - 8191 Assigned by
8192 - 65535
IANA is directed to assign the well-known vDstPorts using
following criteria: Anyone who asks for an assigned vDstPort
provide a) a Point of Contact, b) a brief description of
use, and c) a short name to be associated with the assignment (e.g
"ftp").
6 Security
The same considerations stated in [RFC 2205], [RFC 1826], and [
1827] apply to the extensions described in this note. There are
additional issue related to these extensions
First, the vDstPort mechanism represents another data element
the IP Flow that might be available to an adversary. Such data
be useful to an adversary engaging in traffic analysis by
not only the data packets of the IP Flow but also the RSVP
messages associated with that Flow. Protection against
analysis attacks is outside the scope of this mechanism.
possible approach to precluding such attacks would be deployment
use of appropriate link-layer confidentiality mechansisms, such
encryption
Berger & O'Malley Standards Track [Page 8]
RFC 2207 RSVP Extensions for IPSEC September 1997
Secondly, Changes in SPI values for a given flow will affect
flows and reservations. Changes will happen whenever that
changes its Security Association. Such changes will occur when
flow is rekeyed (i.e. to use a new key). Rekeying intervals
typically set based on traffic levels, key size, threat environment
and crypto algorithm in use. When an SPI change occurs it will,
most cases, be necessary to update (send) the
SENDER_TEMPLATEs and FILTER_SPECs. IPSEC implementations,
applications, and RSVP end-station implementations will need to
the possibility of changes of SPI into account to ensure
reservation behavior. This issue is likely to be a tolerable,
rekeying intervals are under the control of local administrators
Many, if not most, RSVP sessions will not need to deal with
rekeying issue. For those applications that do need to deal
changes of SPIs during a session, the impact of sending new PATH
RESV messages will vary based on the reservation style being used
Builders of such applications may want to select reservation
based on interaction with SPI changes
The least impact of an SPI change will be to WF style reservations
For such reservations, a new SENDER_TEMPLATE will need to be sent
but no new RESV is required. For SE style reservations, both a
SENDER_TEMPLATE and a new RESV will need to be sent. This
result in changes to state, but should not affect data
delivery or actual resource allocation in any way. The FF style
be impacted the most. Like with SE, both PATH and RESV messages
need to be sent. But, since FF style reservations result in
receiving its own resource allocation, resources will be
twice for a period of time. Or, even worse, there won't be
resources to support the new flow without first freeing the old flow
A way around this FF/SPI-change problem does exist.
that want FF style reservations can use multiple SE reservations
Each real sender would have a separate SESSION (vDstPort) definition
When it came time to switch SPIs, a shared reservation could be
for the new SPI while the old SPI was still active. Once the new
was in use, the old reservation could be torn down. This is
than optimal, but will provide uninterrupted service for a set
applications
Berger & O'Malley Standards Track [Page 9]
RFC 2207 RSVP Extensions for IPSEC September 1997
7
[RFC 2205] Braden, R., Ed., Zhang, L., Estrin, D., Herzog, S.,
and S. Jamin, "Resource ReSerVation Protocol (RSVP
-- Version 1 Functional Specification", RFC 2205,
September 1997.
[RFC 2209] Braden, R., Ed., Zhang, "Resource
Protocol (RSVP) -- Version 1 Message
Rules", RFC 2209, September 1997.
[RFC 1825] Atkinson, R., "Security Architecture for the
Protocol", RFC 1825, NRL, August 1995.
[RFC 1826] Atkinson, R., "IP Authentication Header", RFC 1826, NRL
August 1995.
[RFC 1827] Atkinson, R., "IP Encapsulating Security Payload",
1827, NRL, August 1995.
8
This note includes ideas originated and reviewed by a number
individuals who did not participate in this note's writing.
authors would like to acknowledge their contribution. We thank
Atkinson , Fred Baker , Greg
, John Krawczyk for
appreciated input and feedback. Special appreciation goes to
Braden for his detailed editorial and
comments. We also thank Buz Owen, Claudio Topolcic, Andy Veitch,
Luis Sanchez for their help in coming up with the proposed approach
If any brain-damage exists in this note, it originated solely
the authors
9 Authors'
Lou Berger Tim O'
FORE Systems BBN
6905 Rockledge Drive 10 Moulton
Suite 800 Cambridge, MA 02138
Bethesda, MD 20817
Phone: 301-571-2534 Phone: 617-873-3076
EMail: lberger@fore.com EMail: timo@bbn.
Berger & O'Malley Standards Track [Page 10]
RFC 2207 RSVP Extensions for IPSEC September 1997
A Options
This sections reviews other approaches that were explored
developing the described extensions. They are included here
provide additional context into the general problem. All
options were rejected by the working group
Four other options were considered
1. UDP
Add a UDP header between the IP and the IPSEC AH or
headers
2. FlowID Header
Add a new type of header between the IP and the IPSEC AH
ESP headers
3. IPSEC
Modify IPSEC headers so that there are appropriate fields
same location as UDP and TCP ports
4. AH
Skip over the Authentication Header packet
processing
A.1 UDP
Since current SESSION and FILTER object expect UDP or TCP ports,
proposal says let's just give it to them. The basic concept is
add a UDP port between the IP and AH/ESP headers. The UDP
would provide the granularity of control that is need to
specific flows with reservations
Source and destination ports would be used, as normal, in
session definition and control. The port fields would also need
be used to identify the real transport level protocol (e.g. ESP
being used. Also since many UDP ports are assigned as well
ports, use of port numbers would be limited. So, the port
would need to be used to unambiguously identify 1) the next
protocol, 2) the RSVP session, and 3) the RSVP reservation
The advantages of this option is that no RSVP changes are required
The disadvantages is that, since the headers aren't in the
location, RFC 1826 and RFC 1827 are violated
Berger & O'Malley Standards Track [Page 11]
RFC 2207 RSVP Extensions for IPSEC September 1997
A.2 FlowID Header
[This option was originally proposed by Greg Troxel .]
This option is very similar to option 1, but is more generic
could be adopted as a standard solution. The notion is to use
like ports for the sole purpose of flow identification. RSVP
treat this new protocol exactly the same as UDP
The difference between this and UDP encapsulation is in
host processing. The destination host would essentially ignore
information and use a new field, protocol ID, to identify
protocol should process the packet next. Some examples of
IDs correspond to TCP, UDP, ESP, or AH
The format of the FlowID Header would be
+---------------+---------------+---------------+---------------+
| Source Port | Dest Port |
+---------------+---------------+---------------+---------------+
| Ver | Len | Protocol ID | Checksum |
+---------------+---------------+---------------+---------------+
1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8
2 bytes source port 4 bits length-32 (2)
2 bytes dest port 8 bits protocol
4 bits version (1) 16 bits
The advantage of this protocol is that flow identification
separated from all other protocol processing. The disadvantage
that the addition of a header violates RFC 1826 and 1827, and
that applications using RSVP will need to add this extra header
all data packets whose transport headers do not have UDP/TCP
ports
A.3 IPSEC Protocol
The basic notion of this option is to leave RSVP as
specified and use the Security Association Identifier (SPI) found
the IPSEC headers for flow identification. There are two issues
using the SPI. The first is that the SPI is located in the
location when using Authentication (AH). The second issue is how
make use of the SPI
The first issue is easy to fix, but violates RFC 1826. UDP and
have port assignments in the first 4 bytes of their headers, each
two bytes long, source comes first, then destination. The ESP
has the SPI in the same location as UDP/TCP ports, the AH doesn't
Berger & O'Malley Standards Track [Page 12]
RFC 2207 RSVP Extensions for IPSEC September 1997
The IP Authentication Header has the following syntax
+---------------+---------------+---------------+---------------+
| Next Header | Length | RESERVED |
+---------------+---------------+---------------+---------------+
| Security Parameters Index |
+---------------+---------------+---------------+---------------+
| |
+ Authentication Data (variable number of 32-bit words) |
| |
+---------------+---------------+---------------+---------------+
1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8
Simply reversing the first 4 bytes with the SPI we will have the
in the location that RSVP expects. This would be non-standard,
require a major (i.e. not backward compatible) change to RSVP 1826.
The second issue is how to make use of the SPI. Per the current
specification, the first two bytes of a flow's SPI will need to
carried in the PATH message and the second two bytes in the
message. The biggest problem is that the SPI is normally selected
the receiver and is likely to be different for EACH sender. (
is a special case where the same SPI is used by all senders in
multicast group. But this is a special case.) It is possible
have the SPI selected prior to starting the RSVPsession. This
work for unicast and the special multicast case. But using
approach means that setup time will usually be extended by at least 1
round trip time. Its not clear how to support SE and WF
reservations
The advantage of this approach is no change to RSVP.
disadvantages are modification to RFC1827 and limited support of
reservation styles
A.4 AH
The source of the RSVP support of IPSEC protocols problem is that
real transport header is not in the expected location. With
packets, the real source and destination ports are encrypted
therefore useless to RSVP. This is not the case for authentication
For AH, the real header just follows the Authentication Header. So
it would be possible to use the real transport header for
session definition and reservation
To use the transport header, all that would need to be done is
the flow classifier to skip over AHs before classifying packets.
modification to RSVP formats or setup processing would be required
Applications would make reservations based on transport (i.e., UDP
Berger & O'Malley Standards Track [Page 13]
RFC 2207 RSVP Extensions for IPSEC September 1997
TCP) ports as usual
The advantages of this approach are no changes to either
protocols or RSVP formats. The major disadvantage is that
and hosts must skip all AHs before classifying packets. The
group decided that it was best to have a consistent solution for
AH and ESP
Berger & O'Malley Standards Track [Page 14]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
