One document matched: draft-berger-rsvp-ext-00.txt
Internet Draft L. Berger
Expiration: July 16, 1996 BBN
File: draft-berger-rsvp-ext-00.txt T. O'Malley
BBN
Proposed
RSVP Extensions for IPSEC IPv4 Data Flows
January 16, 1996
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as ``work in progress.''
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet- Drafts
Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
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
IPv4 IPSEC protocols, but only on a per protocol basis not on a per
flow basis.
Berger, O'Malley, et al. Expires July 16, 1996 [Page 1]
Internet Draft RSVP Extensions for IPSEC Flows January 16, 1996
Table of Contents
1 Introduction 3
2 Overview of Extensions 3
3 Mechanisms 5
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 7
5 Object Definition 7
5.1 FILTER_SPEC Class 7
5.2 SENDER_TEMPLATE Class 8
6 Options Considered 8
6.1 UDP Encapsulation 8
6.2 FlowID Header Encapsulation 9
6.3 IPSEC Protocol Modification 10
6.4 AH Transparency 11
7 Security Considerations 11
8 References 12
9 Acknowledgments and Authors' Information 12
9.1 Acknowledgments 12
9.2 Authors' Information 12
Berger, O'Malley, et al. Expires July 16, 1996 [Page 2]
Internet Draft RSVP Extensions for IPSEC Flows January 16, 1996
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, [RFC1826], and integrity and
confidentiality [RFC1827]. 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 next level (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. For IPv4, RSVP as currently specified [RSVP95] is really
tailored towards IP packets carrying TCP or UDP data. This means
that the flows of IP packets containing the IPSEC protocols are not
very well supported. The RSVP specification does say that other
protocols such as the IPSEC protocols may be carried, but only with
limitations. Specifically, since the IPSEC protocols do not have
UDP/TCP like ports, flow definition can only be done on an IP address
basis.
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. Section 2 of this memo will
provide an overview of RSVP extensions. Section 3 contains a
description of extended protocol mechanisms. Section 4 presents
extended protocol processing mechanisms. Section 5 defines the
additional RSVP data objects. Section 6 provides an overview of some
other possible solutions that were considered.
2 Overview of Extensions
The basic notion is to extend RSVP to use the IPSEC Security
Parameter Index, or SPI, in place of UDP/TCP ports. This will
require a new FILTER_SPEC object which will contain the IPSEC
Security Parameter Index, or SPI. The extension will also require a
change in the processing of the SESSION object.
The extension will require modifying RESV processing. While SPIs are
allocated based on destination address, they will typically be
associated with a particular sender. (Two senders to the same
unicast destination will usually have different SPIs, but the
receiver may want to share reservations for both senders.) For this
Berger, O'Malley, et al. Expires July 16, 1996 [Page 3]
Internet Draft RSVP Extensions for IPSEC Flows January 16, 1996
reason the SPI will be included as part of the FILTER_SPEC. This
approach will support multiple independent flows between source and
destination IP addresses using FF and SE filter styles. With WF, all
flows to the same IP destination address will share the same
reservation. This is because the IPSEC protocols do not contain
UDP/TCP-like destination ports.
The RESV message itself will not need any modification. It will just
need to contain the FILTER_SPEC as usual. On the other hand, RESV
processing will need to change. When the FILTER_SPEC is used with
IPSEC protocols, processing will need to be dependent on the next
protocol field contained in the session definition. When the next
protocol is AH (50) or ESP (51), the complete four bytes of the SPI
will need to be extracted from the FILTER_SPEC for use by the packet
classifier.
The extension will require a change to PATH processing, specifically
in usage of the port field in session definition. An RSVP session is
defined by the triple: (DestAddress, ProtocolId, DstPort). The
DstPort field of the SESSION object is currently defined as being "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 not contain such a field, but there remains the
requirement for demultiplexing sessions beyond the IP destination
address. RSVP defines such a demultiplexing point as a "generalized
destination port." For IPSEC protocols, DstPort will be used as the
generalized port but DstPort value will not be carried in the IPSEC
transport header. This change will allow control of multiple IPSEC
flows to a single destination. Traffic will be mapped (classified)
to reservations based on SPIs in FILTER_SPECs. This, of course,
means that when WF is used all flows to the same IP destination
address will share the same reservation.
For IPSEC protocols, AH (50) and ESP (51), the PATH message and the
SESSION objects will be used as currently specified. The
SENDER_TEMPLATE for IPSEC flows will match the modified FILTER_SPEC.
For such flows, SESSION definition and PATH processing will need to
be changed to permit the use of SESSION DstPort as a generalized
destination port rather than as a transport header value.
To make use of this extension, communicating hosts will need to match
RSVP sessions and reservations to appropriate SPIs. To make best use
of reservations, the WF reservation style should be avoided and
multiple SPIs will need to be used when supporting multiple data
flows between hosts. The use of multiple SPIs is supported by the
IPSEC protocols, so this should not be an issue. Avoiding WF and
only using SE and FF style reservations should also not be a major
issue since, when using IPSEC protocols, receivers must identify all
Berger, O'Malley, et al. Expires July 16, 1996 [Page 4]
Internet Draft RSVP Extensions for IPSEC Flows January 16, 1996
valid senders and their associated SPIs.
End-stations will also need to track when the SPI value associated
with an RSVP flow changes. Changes will happen whenever that flow
changes its Security Association. Such changes will occur when a
flow is rekeyed (i.e. to use a new key). Rekeying intervals are
typically set based on traffic levels, key size, threat environment,
and crypto algorithm in use. This issue is also likely to be a
tolerable, since rekeying intervals are under the control of local
administrators.
The advantages to the described approach are that no changes to
RFC1826 and 1827 are required, and that there is no additional per
data packet overhead. The disadvantages to this approach are that we
have to modify RSVP and, to a lesser degree, that the use of SPI is
overloaded.
3 Mechanisms
This extension does not alter the mechanisms described in [RSVP95]
with the exception of Port Usage. For IPSEC data flows, Port Usage
is primarily replaced by the IPSEC SPI.
Implementations of RSVP that support IPSEC flows will need to
understand the IPSEC ProtocolIds. Such systems must not generate
errors as would be done in other cases for protocols that do not
support UDP/TCP-like ports.
Session definition for IPSEC flows will continue to use the triple:
(DestAddress, ProtocolId, DstPort). The DstPort field will represent
a generalized destination port rather than a specific value in the
transport header. ProtocolId must be set to either AH (50) or ESP
(51). System implementations of RSVP must permit non-zero values of
DstPort when either IPSEC protocol is used. A zero value of DstPort
is not valid. End-stations should give an error to an application
that specifies a zero value.
The FLITER_SPEC used with IPSEC protocols will be very similar to the
current IPv4 FILTER_SPEC. (The 2 reserved bytes and 2 UDP/TCP port
bytes of the IPv4 FILTER_SPEC will be replaced by a four byte SPI
field.) The SENDER_TEMPLATE used with IPSEC protocols will match the
FILTER_SPEC. Both the IPSEC filter spec and IPSEC sender template
will be defined by the pair: (SrcAddress, SPI). SPI may be omitted
(set to zero) in certain cases. When SPIs are used, SPIs used in
SENDER_TEMPLATEs must match the SPIs used in FILTER_SPECs.
The FILTER_SPEC and SENDER_TEMPLATE used with IPSEC protocols will
Berger, O'Malley, et al. Expires July 16, 1996 [Page 5]
Internet Draft RSVP Extensions for IPSEC Flows January 16, 1996
contain a four byte field that will be used to carry the SPI. Rather
than label the modified field with an IPSEC specific label, SPI, the
label "Generalized Port Identifier", or GPI, will be so that these
object may be reused for non-IPSEC uses in the future. The name of
the objects will be IPv4/GPI FILTER_SPEC and IPv4/GPI
SENDER_TEMPLATE.
4 Processing Rules
4.1 Required Changes
Use of the GPI FILTER_SPEC extension requires some minor
modifications to RSVP message processing. Specifically, PATH message
processing requires one small change, and RESV message processing,
including the establishment of a traffic classifier, require a few
changes.
The single change to PATH message processing:
o When a SESSION object in a PATH message contains a ProtocolId with
the value 50(AH) or 51(ESP), the DstPort value should be recorded
and no special action should be taken. (Non-zero values of
DstPort are permitted even though the IPSEC protocols do not
have UDP/TCP-like ports.)
The changes to RESV message processing are listed below:
o When a RESV message contains an IPv4 GPI FILTER_SPEC, the next
protocol field in the SESSION object must be a protocol known
to use the GPI FILTER_SPEC. Values 50(AH) or 51(ESP) must be
supported by implementations supporting the described IPSEC
extensions.
o When a RESV message contains an IPv4 GPI FILTER_SPEC, the
SENDER_TEMPLATE of the associated Path state must be an IPv4
GPI SENDER_TEMPLATE object.
o The GPI contained in the FILTER_SPEC must match the GPI contained
in the SENDER_TEMPLATE.
RSVP end-stations should enforce the above three requirements.
Intermediate network elements are not required to enforce them.
o When the IPv4 GPI FILTER_SPEC is used, each network element must
create a data classifier for the flow described by the quadruple:
(DestAddress, ProtocolId, SrcAddress, GPI). Specifically, the
data classifier must NOT include any source or destination ports!
Berger, O'Malley, et al. Expires July 16, 1996 [Page 6]
Internet Draft RSVP Extensions for IPSEC Flows January 16, 1996
4.2 Merging Flowspecs
When using this extension for IPSEC data flows, RSVP sessions are
defined by the triple: (DestAddress, ProtocolId, DstPort). The
DstPort field will be a two byte representation of a generalized
destination port. Similarly, a sender is defined by the tuple:
(SrcAddress, GPI). Effectively, these extensions have added the GPI
to both definitions, which has some ramifications on filter styles.
4.2.1 FF and SE Styles
In the FF and SE Styles, the FILTER_SPEC object(s) contain(s) the
(SrcAddress, GPI) pair. When merging explicit sender descriptors,
the senders may only be considered identical when both elements of
the pair are identical. This allows the receiver to share
reservations among senders or to differentiate reservations based
upon SrcAddress or GPI.
4.2.2 WF Styles
These extensions provide very limited service when used with WF style
reservations. As described, the SENDER_TEMPLATE and FILTER_SPEC each
contain the GPI. In a WF style reservation, the RESV message does
NOT contain a FILTER_SPEC (after all, it is a wildcard filter), and
the SENDER_TEMPLATE is ignored (again, because any sender is
allowed). As a result, classifiers are likely to match all packets
that contain both the session's destination IP address and next
protocol ID to such WF reservations. For this reason, it is
recommended that WF style reservations not be used with IPSEC
protocols.
A solution for this limitation is not proposed. This is not seen as
a significant issue since IPSEC applications are unlikely to use WF
style reservations. Although, it would be nice to have a filter
style which specifies a wildcard sender but specific GPI. The
mechanism to support such a filter, however, seems non-trivial.
5 Object Definition
As previously mentioned, rather than label the modified FILTER_SPEC
and SENDER_TEMPLATE with IPSEC the specific fields, SPI, we use the
label "Generalized Port Identifier", or GPI, so that these object may
be reused for non-IPSEC uses in the future.
5.1 FILTER_SPEC Class
FILTER_SPEC class = 10.
Berger, O'Malley, et al. Expires July 16, 1996 [Page 7]
Internet Draft RSVP Extensions for IPSEC Flows January 16, 1996
o IPv4/GPI FILTER_SPEC object: Class = 10, C-Type = 4
+-------------+-------------+-------------+-------------+
| IPv4 SrcAddress (4 bytes) |
+-------------+-------------+-------------+-------------+
| Generalized Port Identifier |
+-------------+-------------+-------------+-------------+
5.2 SENDER_TEMPLATE Class
SENDER_TEMPLATE class = 11.
o IPv4/GPI SENDER_TEMPLATE object: Class = 11, C-Type = 3
Definition same as IPv4/GPI FILTER_SPEC object.
6 Options Considered
This section is included for the purpose of review and general
discussion. This section will be deleted once agreement is reached.
Four other options main were considered:
1. UDP Encapsulation
Add a UDP header between the IP and the IPSEC AH or ESP
headers.
2. FlowID Header Encapsulation
Add a new type of header between the IP and the IPSEC AH or
ESP headers.
3. IPSEC modification
Modify IPSEC headers so that there are appropriate fields in
same location as UDP and TCP ports.
4. AH Transparency
Skip over the Authentication Header packet classifier
processing.
6.1 UDP Encapsulation
Since current SESSION and FILTER object expect UDP or TCP ports, this
proposal says let's just give it to them. The basic concept is to
add a UDP port between the IP and AH/ESP headers. The UDP ports
would provide the granularity of control that is need to associate
specific flows with reservations.
Berger, O'Malley, et al. Expires July 16, 1996 [Page 8]
Internet Draft RSVP Extensions for IPSEC Flows January 16, 1996
Source and destination ports would be used, as normal, in RSVP
session definition and control. The port fields would also need to
be used to identify the real transport level protocol (e.g. ESP)
being used. Also since many UDP ports are assigned as well known
ports, use of port numbers would be limited. So, the port fields
would need to be used to unambiguously identify 1) the next level
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 expected
location, RFC1826 and 1827 are violated.
6.2 FlowID Header Encapsulation
[This option was originally proposed by Greg Troxel.]
This option is very similar to option 1, but is more generic and
could be adopted as a standard solution. The notion is to use UDP
like ports for the sole purpose of flow identification. RSVP would
treat this new protocol exactly the same as UDP.
The difference between this and UDP encapsulation is in destination
host processing. The destination host would essentially ignore port
information and use a new field, next-protocol, to identify which
protocol should process the packet next. Some examples of next-
protocol are TCP, UDP, ESP, or AH.
The format of the FlowID Header would be:
+---------------+---------------+---------------+---------------+
| Source Port | Dest Port |
+---------------+---------------+---------------+---------------+
| Ver | Len | Next Protocol | 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
2 bytes dest port
4 bits version (1)
4 bits length-32 (2)
8 bits next protocol
16 bits checksum
The advantage of this protocol is that flow identification is
separated from all other protocol processing. The disadvantage is
that the addition of a header violates RFC 1826 and 1827, and also
that applications using RSVP will need to add this extra header on
all data packets whose transport headers do not have UDP/TCP like
Berger, O'Malley, et al. Expires July 16, 1996 [Page 9]
Internet Draft RSVP Extensions for IPSEC Flows January 16, 1996
ports.
6.3 IPSEC Protocol Modification
The basic notion of this option is to leave RSVP as currently
specified and use the Security Association Identifier (SPI) found in
the IPSEC headers for flow identification. There are two issues with
using the SPI. The first is that the SPI is located in the wrong
location when using Authentication (AH). The second issue is how to
make use of the SPI.
The first issue is easy to fix, but violates RFC 1826. UDP and TCP
have port assignments in the first 4 bytes of their headers, each is
2 bytes long, source comes first, then destination. The ESP header
has the SPI in the same location as UDP/TCP ports, the AH doesn't.
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
So if we simply reverse the first 4 bytes with the SPI we will have
the SPI in the location that RSVP expects. This would be non-
standard, or 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 RSVP
specification, the first two bytes of a flow's SPI will need to be
carried in the PATH message and the second two bytes in the RESV
message. The biggest problem is that the SPI is normally selected by
the receiver and is likely to be different for EACH sender. (There
is a special case where the same SPI is used by all senders in a
multicast group. But this is a special case.) It is possible to
have the SPI selected prior to starting the RSVP session. This will
work for unicast and the special multicast case. But using this
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 style
reservations.
The advantage of this approach is no change to RSVP. The
disadvantages are modification to RFC1827 and limited support of RSVP
Berger, O'Malley, et al. Expires July 16, 1996 [Page 10]
Internet Draft RSVP Extensions for IPSEC Flows January 16, 1996
reservation styles.
6.4 AH Transparency
The source of the RSVP support of IPSEC protocols problem is that the
real transport header is not in the expected location. With ESP
packets, the real source and destination ports are encrypted and
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 RSVP
session definition and reservation.
To use the transport header, all that would need to be done is for
the flow classifier to skip over AHs before classifying packets. No
modification to RSVP formats or setup processing would be required.
Applications would make reservations based on transport (i.e., UDP or
TCP) ports as usual.
The advantages of this approach are no changes to either IPSEC
protocols or RSVP formats. The major disadvantage is that routers
and hosts must skip all AHs before classifying packets. If this is
considered to be a non-issue by vendors, then this option should be
reconsidered.
7 Security Considerations
The same considerations stated in [RSVP95], [RFC1826], and [RFC1827]
apply to the extensions described in this note. There are three
additional issues related to these extensions.
The first issue is that the use of SPIs to identify reservations may
introduce greater opportunity for traffic analysis. The significance
of the added traffic analysis threat will, of course, vary on a
case-by-case basis. Applications or users may choose to reduce the
threat by aggregating reservations and flows, or even aggregating all
traffic into a single flow and reservation.
The second issue is that there may be an added burden placed on key
setup protocols. Specifically, since SPIs are used to identify
reservations, the end-station IPSEC implementation will need to
provide SPIs on a per flow basis. For flows with multiple senders,
the same SPI must be used or each source must be individually
identified in an appropriate (FF or SE) filter entry. This
requirement may place new restrictions on IPSEC implementations, key
negotiation, or possibly even future uses the IPSEC protocols.
The third issued is that changes in SPI values for a given flow will
Berger, O'Malley, et al. Expires July 16, 1996 [Page 11]
Internet Draft RSVP Extensions for IPSEC Flows January 16, 1996
affect RSVP flows and reservations. As mentioned earlier, changes
will happen whenever that flow changes its Security Association.
Such changes will occur when a flow is rekeyed (i.e. to use a new
key). The frequency of key changes will depend on duration and size
of the flow, key size, threat environment, and crypto algorithm in
use. When an SPI change occurs it will, in most cases, be necessary
to update the corresponding SENDER_TEMPLATEs and FILTER_SPECs. IPSEC
implementations, RSVP applications, and RSVP end-station
implementations will need to take the possibility of changes of SPI
into account to ensure proper reservation behavior.
8 References
[RSVP95] Braden, R., Ed., Zhang, L., Estrin, D., Herzog, S., and
S. Jamin, "Resource ReSerVation Protocol (RSVP) --
Version 1 Functional Specification. Internet Draft
draft-ietf-rsvp-spec-08.ps, November 1995.
[RFC1825] Atkinson, R., "Security Architecture for the Internet
Protocol", RFC 1825, NRL, August 1995.
[RFC1826] Atkinson, R., "IP Authentication Header", RFC 1826, NRL,
August 1995.
[RFC1827] Atkinson, R., "IP Encapsulating Security Payload", RFC
1827, NRL, August 1995.
9 Acknowledgments and Authors' Information
9.1 Acknowledgments
This note includes ideas originated and reviewed by a number of
individuals who did not participate in the note's writing. The
authors would like to acknowledge their contribution. We thank Fred
Baker <fred@cisco.com> for his input. We also thank Buz Owen,
Claudio Topolcic, Andy Veitch, and Luis Sanchez for their help in
developing the proposed approach. If any brain-damage exists in this
note, it solely originated from the authors.
9.2 Authors' Information
Lou Berger
BBN
1300 North 17th Street, Suite 1200
Arlington, VA 22209
Berger, O'Malley, et al. Expires July 16, 1996 [Page 12]
Internet Draft RSVP Extensions for IPSEC Flows January 16, 1996
Phone: 703-284-4651
EMail: lberger@bbn.com
Tim O'Malley
BBN
10 Moulton Street
Cambridge, MA 02138
Phone: 617-873-3076
EMail: timo@bbn.com
Randall Atkinson
cisco Systems
170 West Tasman Drive
San Jose, CA 95134-1706
Phone: 408-526-6566
EMail: rja@cisco.com
Gregory Troxel
BBN
10 Moulton Street
Cambridge, MA 02138
Phone: 617-873-2494
EMail: gtroxel@bbn.com
Berger, O'Malley, et al. Expires July 16, 1996 [Page 13]
| PAFTECH AB 2003-2026 | 2026-04-24 02:50:23 |