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 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]