One document matched: draft-berger-rsvp-ext-01.txt
Differences from draft-berger-rsvp-ext-00.txt
Internet Draft L. Berger
Expiration: August 9, 1996 BBN
File: draft-berger-rsvp-ext-01.txt T. O'Malley
BBN
R. Atkinson
Cisco
Proposed
RSVP Extensions for IPSEC IPv4 Data Flows
February 8, 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 address, per protocol basis
not on a per flow basis.
Berger, O'Malley, Atkinson Expires August 9, 1996 [Page 1]
Internet Draft RSVP Extensions for IPv4 IPSEC Flows February 9, 1996
Table of Contents
1 Introduction 3
2 Overview of Extensions 4
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 8
5 Object Definition 8
5.1 SESSION Class 8
5.2 FILTER_SPEC Class 8
5.3 SENDER_TEMPLATE Class 9
6 Security Considerations 9
7 References 10
8 Acknowledgments and Authors' Information 10
8.1 Acknowledgments 10
8.2 Authors' Information 11
Berger, O'Malley, Atkinson Expires August 9, 1996 [Page 2]
Internet Draft RSVP Extensions for IPv4 IPSEC Flows February 9, 1996
Changes From Previous Version
The most significant changes from the previous version are:
o Introduction of new SESSION object. New session object is used
to unambiguously distinguish use of generalized destination port
rather than use of UDP/TCP-like port. Format of new SESSION
object is identical to IPv4/UDP SESSION object.
o Removal of section on other possible solutions.
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 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. For IPv4, RSVP as currently specified [RSVP95] is really
tailored towards IP packets carrying TCP or UDP data. This means
that flows of IP packets containing the IPSEC protocols are not very
well supported. The RSVP specification does detail support for other
protocols such as the IPSEC protocols, 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, per
protocol 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 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.
Berger, O'Malley, Atkinson Expires August 9, 1996 [Page 3]
Internet Draft RSVP Extensions for IPv4 IPSEC Flows February 9, 1996
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-like ports. This will
require a new FILTER_SPEC object, which will contain the IPSEC SPI,
and a new 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
reason the SPI will be included as part of the FILTER_SPEC. This
approach will support the control of 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 using
the same protocol will share the same reservation. This limitation
results because the IPSEC protocols do not contain UDP/TCP-like
destination ports.
The RESV message itself will not need modification. It will still
contain a 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 use of the new
SESSION object and on the next protocol field contained in the
session definition. When the new SESSION 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
next protocol field. The SPI is located at transport header offset
+4 for AH (50), and at +0 for ESP (51).
The extension will also 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 "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 a
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 and protocol ID will share the same reservation.
Berger, O'Malley, Atkinson Expires August 9, 1996 [Page 4]
Internet Draft RSVP Extensions for IPv4 IPSEC Flows February 9, 1996
For IPSEC protocols, AH (50) and ESP (51), PATH messages will not be
changed. PATH messages will still contain SENDER_TEMPLATE and
SESSION objects. The SENDER_TEMPLATE for IPSEC flows will match the
modified FILTER_SPEC. (The SENDER_TEMPLATE will contain a
"generalized source port" rather than a "generalized destination
port.") But, a new SESSION object will be used to unambiguously
distinguish the use of generalized destination ports from the use of
UDP/TCP-like ports. Session definition and PATH processing will need
to be modified to support the new message class types.
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 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 the IPSEC
protocols require receivers to identify all 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, UDP/TCP-like
ports are primarily replaced by IPSEC SPIs.
Implementations of RSVP that support IPSEC flows must recognize the
new SESSION object and the IPSEC ProtocolIds. When the new SESSION
object is used, such systems must permit non-zero destination port
values even though the IPSEC protocols don't support UDP/TCP-like
ports. The SESSION object used with IPSEC protocols will have the
same format of the IPv4/UDP SESSION object, only the C-Type will
Berger, O'Malley, Atkinson Expires August 9, 1996 [Page 5]
Internet Draft RSVP Extensions for IPv4 IPSEC Flows February 9, 1996
differ.
Session definition for IPSEC flows will continue to use the triple:
(DestAddress, ProtocolId, DstPort), where the DstPort field will
represent a generalized destination port rather than a specific value
in the transport header. The ProtocolId field must be set to either
AH (50) or ESP (51). Implementations of RSVP must require non-zero
values of DstPort when either IPSEC protocol is used. A zero value
of DstPort is not valid and end-stations should give an error to an
application that specifies a zero value.
The FILTER_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 field
that will contain an SPI.) 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).
When the new objects are used, SPIs in SENDER_TEMPLATEs and
FILTER_SPECs must match.
The FILTER_SPEC and SENDER_TEMPLATE used with IPSEC protocols will
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. Similarly, the name of the new SESSION object will
be IPv4/GPI SESSION.
4 Processing Rules
This section presents additions to the Processing Rules section of
the [RSVP95]. These additions are required in order to properly
process the new IPv4/GPI SESSION object and IPv4/GPI FILTER_SPEC.
4.1 Required Changes
Both RESV and PATH processing will need to be changed to support the
new IPv4/GPI objects. The changes ensure consistency and extend port
processing.
The following PATH message processing changes are required:
o When a session is defined using the IPv4/GPI SESSION object,
only the IPv4/GPI SENDER_TEMPLATE may be used.
Berger, O'Malley, Atkinson Expires August 9, 1996 [Page 6]
Internet Draft RSVP Extensions for IPv4 IPSEC Flows February 9, 1996
o For PATH messages that contain the IPv4/GPI SESSION object,
the value of the ProtocolId must correspond to a protocol
known to use the IPv4/GPI SESSION object. Values 50(AH)
or 51(ESP) must be supported by implementations supporting
the described IPSEC extensions.
o For such messages, the DstPort value should be recorded
and no special action should be taken. (Non-zero values of
DstPort are required even though the IPSEC protocols do not
have UDP/TCP-like ports.)
The changes to RESV message processing are:
o When a RESV message contains an IPv4/GPI FILTER_SPEC, the
session must be defined using the IPv4/GPI SESSION object.
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.
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 UDP/TCP-like source or
destination ports! The data classifier will need to look for
the four byte GPI at transport header offset +4 for AH, and at
transport header offset +0 for ESP.
4.2 Merging Flowspecs
When using this extension for IPSEC data flows, RSVP sessions are
defined by the triple: (DestAddress, ProtocolId, DstPort), where the
DstPort field will be a two byte representation of a generalized
destination port. Similarly, a sender is defined by the tuple:
(SrcAddress, GPI). Where the GPI field will be a four byte
representation of a generalized source port. Effectively, these
extensions have added generalized port to both definitions, which has
some ramifications on merging of filter style.
4.2.1 FF and SE Styles
In the FF and SE Styles, the FILTER_SPEC object contains the
(SrcAddress, GPI) pair. This allows the receiver to uniquely
identify senders based on both elements of the pair. When merging
explicit sender descriptors, the senders may only be considered
Berger, O'Malley, Atkinson Expires August 9, 1996 [Page 7]
Internet Draft RSVP Extensions for IPv4 IPSEC Flows February 9, 1996
identical when both elements are identical.
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 issue is not
seen as significant 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 SESSION Class
SESSION Class = 1.
o IPv4/GPI SESSION object: Class = 1, C-Type = 3
Definition same as IPv4/UDP SESSION object.
5.2 FILTER_SPEC Class
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, Atkinson Expires August 9, 1996 [Page 8]
Internet Draft RSVP Extensions for IPv4 IPSEC Flows February 9, 1996
5.3 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 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 of the IPSEC protocols.
The third issue is that changes in SPI values for a given flow will
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 (send) 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.
Many, if not most, RSVP sessions will not need to deal with this last
issue. For those applications that do need to deal with changes of
SPIs during a session, the impact of sending new PATH and RESV
messages will vary based on the reservation style being used.
Builders of such applications may want to select reservation style
based on interaction with SPI changes.
Berger, O'Malley, Atkinson Expires August 9, 1996 [Page 9]
Internet Draft RSVP Extensions for IPv4 IPSEC Flows February 9, 1996
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 new
SENDER_TEMPLATE and a new RESV will need to be sent. This will
result in changes to state, but should not affect data packet
delivery or actual resource allocation in any way. The FF style will
be impacted the most. Like with SE, both PATH and RESV messages will
need to be sent. But, since FF style reservations result in sender
receiving its own resource allocation, resources will be allocated
twice for a period of time. Or, even worse, there won't be enough
resources to support the new flow without first freeing the old flow.
A way around this FF/SPI-change problem does exist, but it is not
elegant: Applications that want FF style reservations can use
multiple SE reservations. Each real sender would have a separate
SESSION (DstPort) definition. When it came time to switch SPIs, a
shared reservation could be made for the new SPI while the old SPI
was still active. Once the new SPI was in use, the old reservation
could be torn down. This is inelegant, but will provide
uninterrupted service for a set of applications.
7 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.
8 Acknowledgments and Authors' Information
8.1 Acknowledgments
This note includes ideas originated and reviewed by a number of
individuals who did not participate in this note's writing. The
authors would like to acknowledge their contribution. We thank Fred
Baker <fred@cisco.com> for proposing a SPI FILTER_SPEC, Greg Troxel
<gdt@bbn.com> for proposing a solution that we didn't use, and John
Berger, O'Malley, Atkinson Expires August 9, 1996 [Page 10]
Internet Draft RSVP Extensions for IPv4 IPSEC Flows February 9, 1996
Krawczyk <jkrawczyk@BayNetworks.com> for his detailed feedback. We
also thank Buz Owen, Claudio Topolcic, Andy Veitch, and Luis Sanchez
for their help in coming up with the proposed approach. If any
brain-damage exists in this note, it originated solely from the
authors.
8.2 Authors' Information
Lou Berger
BBN
1300 North 17th Street, Suite 1200
Arlington, VA 22209
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
Berger, O'Malley, Atkinson Expires August 9, 1996 [Page 11]
| PAFTECH AB 2003-2026 | 2026-04-24 02:49:11 |