HTTP/1.1 200 OK Date: Mon, 08 Apr 2002 22:50:12 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Fri, 25 Jun 1999 16:34:46 GMT ETag: "2e6ffe-3c06-3773afa6" Accept-Ranges: bytes Content-Length: 15366 Connection: close Content-Type: text/plain Internet Draft S. Berson Expiration: January 2000 ISI File: draft-berson-rsvp-ipv6-fl-00.txt RSVP and Integrated Services with IPv6 Flow Labels 23 June 1999 Status of Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract Currently, there is a brief definition about how RSVP works with IPv6[2]. However, there are a number of recent issues that need to be elaborated. These include issues with changes in the IPv6 Flow Label definition, routing RSVP messages, and security. Table of Contents Berson Expiration: January 2000 [Page 1] Internet Draft RSVP and IPv6 July 1999 1. Introduction There are potential significant benefits to the use of IPv6 flow labels with RSVP and integrated services. For layering reasons, it would be preferred if reservations were based only on the network layer. Since the flow label field is in the IPv6 header, RSVP reservations for IPv6 can be based only on fields in the IP header. This draft addresses several issues that are related to the use of RSVP with IPv6 and flow labels. First, a new FILTER_SPEC format needs to be specified that contains both the IPv6 flow label and the source port. In addition, there has been a change in the format of a flow label in IPv6; RSVP needs to reflect this new format in its IPv6 Flow Label FILTER_SPEC. Second, there is no IPv6 API specified for an RSVP implementation to acquire a flow label. Third, the routing of a packet may depend on the flow label (as well as other fields). If RSVP is to route a message the same way as data packets are routed, the RSVP interface to routing will need access to the flow label. Finally, there are security issues where a node can spoof a flow label (and source address) to get preferred service or for a denial-of-service attack. For information about IPv6 and flow labels including updated field definitions, see [3]. For information about a sockets interface to IPv6 including the use of flow labels, see [5,9]. For general information about how flow labels are meant to be used, see [7]. Some of the ideas in this draft were originally described in [8]. 2. Change of IPv6 Flow Label FILTER_SPEC Format We expect that IPv6 with flow labels will be deployed incrementally. This means that an RSVP flow may encounter both routers that support IPv6 flow labels and routers that do not. If an RSVP reservation is to provide end-to-end reservations in this environment, it is necessary to provide a source port as well as a flow label in a filterspec. Thus, a FILTER_SPEC (and a SENDER_TEMPLATE) object needs to be defined that contains both an IPv6 flow label and a source port. Also, since the RSVP specification first came out, the flow label field has been shortened from 24 bits to 20 bits[3]. This needs to be reflected in the RSVP specification. To support this, the following needs to be appended to section A.9 of the RSVP specification: Berson Expiration: January 2000 [Page 2] Internet Draft RSVP and IPv6 July 1999 2.1 New Filterspec Object o IPv6 Flow Label FILTER_SPEC object: Class = 10, C-Type = 6 +-------------+-------------+-------------+-------------+ | | + + | | + IPv6 SrcAddress (16 bytes) + | | + + | | +-------------+-------------+-------------+-------------+ | ////// | ////// | SrcPort | +-------------+------+------+-------------+-------------+ | /////////////// | Flow Label (20 bits) | +-------------+------+------+-------------+-------------+ Flow Label A 20-bit Flow Label, defined in IPv6. This value may be used by the packet classifier to efficiently identify the packets belonging to a particular (sender->destination) flow. There is a corresponding new format for a SENDER_TEMPLATE object. To support this the following text should be added to section A.10 of the RSVP specification: o IPv6 Flow label SENDER_TEMPLATE object: Class = 11, C-Type = 6 Definition same as IPv6 flow label FILTER_SPEC object. These new FILTER_SPEC and SENDER_TEMPLATE objects logically replace the old FILTER_SPEC and SENDER_TEMPLATE objects, i.e. Class=10, C-Type=3 and Class=11, C-Type=3, and so the relevant text from sections A.9 and A.10 should be deleted. Note that there is a missing sentence in section A.10 that should have been in the RSVP specification that is now obsolete. o IPv6 Flow label SENDER_TEMPLATE object: Class = 11, C-Type = 3 Definition same as IPv6 flow label FILTER_SPEC object. 3. Flow Label Allocation In the definition of an IPv6 Flow Label[3], there are two main requirements on how a flow label is chosen. First, a flow label needs to be unique per sender, and second, the flow label needs to be Berson Expiration: January 2000 [Page 3] Internet Draft RSVP and IPv6 July 1999 pseudo-random (and uniform). The current sockets interface definition[5,9] does not define a mechanism for establishing flow labels (draft versions of these RFCs specified mechanisms for use of flow labels, but this has been removed for the RFC). Clearly, the flow label should be chosen by the operating system (and not by the application) to ensure both the uniqueness and the randomness, but the details of the interface need to be completed. The main requirement for RSVP is that this flow label be accessible to RSVP, since RSVP needs to include the flow label in PATH messages (as well as to properly route the PATH message as described in section 4. There is an analogous problem with the GPI used for IPSEC data flows[1]. There are several different approaches for providing an IPv6 flow with an IPv6 flow label. The simplest approach is to provide a system call that allocates a new flow label. This flow label can then be used in the flowinfo field of the sockaddr6 structure for the destination as well as passed to RSVP. The problem with this approach is that assigning labels to packets should be a system function, not a user function. An alternative approach is for the application to request that a socket use flow labels, e.g. by using a setsockopt(). For flow labels, a bind call should be required to use flow labels, and then a flow label would be associated with the bound socket. It would still be necessary to provide a call (e.g. a getsockopt) for the application to extract the flow label from a socket so that the flow label can be provided to RSVP. A final approach is for the kernel to automatically start using a flow label when flow-like behavior is observed. In this case, the kernel would need to have an RSVP upcall that would pass the current RSVP flow descriptor (with source and destination addresses, source and destination ports, and protocol) to the RSVP daemon. RSVP would then need to locate the correct reservation and add the flow label field. 4. IPv6 Flow Labels and Routing RSVP messages RSVP is intended to route RSVP signalling messages along the same path (forward or reverse) used by data messages for the same session. This is accomplished by using a routing interface that has been defined for RSVP[10] that allows RSVP access to kernel routing information. Currently this interface includes primarily source and destination address. The definition of the IPv6 flow label allows routing to be based on the flow label as well as source and destination addresses. In order to support proper routing of RSVP messages for IPv6 flow label sessions, the flow label must be Berson Expiration: January 2000 [Page 4] Internet Draft RSVP and IPv6 July 1999 included in the RSRR interface. Routing of messages may be affected by other fields in the IP header that are currently not part of the RSRR interface. An IPv4 packet can have a source route listed as an IP option. Routing might also be affected by the Type-Of-Service bits in the IP header now being used for differentiated services[6]. In these and potentially other cases, the additional information should be provided to RSRR from RSVP in order to correctly route RSVP messages. For example, this may require passing a complete IP header to RSRR. 5. Security Issues According to the IPv6 specification[3], a router does not need to look at the IPv6 destination address to route a packet. Thus a packet at an IPv6 router might be forwarded based only on the IPv6 source address and the flow label. Similarly an RSVP reservation can provide preferred service for a certain IPv6 source address and flow label pair. Thus using RSVP with IPv6 flow labels, spoofing of the source address and flow label potentially allows both theft-of- service and denial-of-service attacks. For a denial of service attack, an attacking router would inject packets carrying a spoofed source address and flow label. These packets would need to arrive at one of the routers along the reserved data path. Once the packets reach the data path, the packets will follow the path as long as forwarding is done by source address and flow label. To understand this better, consider figure . Figure shows several routers including R2 and R3 that use flow labels and source address (but not destination address) for routing. Destination D1 has a IPv6 flow label reservation for traffic from source S1 using flow label f. To deny service to D1, an attacker A1 sends data spoofing the address of S1 and the flow label f. A similar approach can be used for theft of service. In this case, the attacker A1 wants to send reserved data to A2. A1 spoofs S1's source address and the flow label f and sends data with destination address A2. The data will follow the flow label path going from R2 to R3 to R4. Since R4 is outside the IPv6 flow label routing cloud, the packets would then be forwarded to A2. This allows A2 to receive reserved service over the R2-R3-R4 links without having a reservation, essentially stealing reserved service over these links. [Figure omitted] Figure 1: Security attacks One approach to solving these security problems is to keep the Berson Expiration: January 2000 [Page 5] Internet Draft RSVP and IPv6 July 1999 identity of flow labels secret. With random assignment in a a 20 bit space, guessing a flow label will be difficult. However, the flow label must be exposed to all ISPs along the data path. An alternate approach for this security problem is for packet scheduling to filter on destination address as well as source address and flow label, but this removes the potential advantage of using flow labels. A final approach would be to periodically change flow labels for the same flow similar to the way keys are changed in [1]. This approach works well with secret keys, but likely will not work well with flow labels as flow labels are sent in the clear in IP messages. Thus an attacker will probably be able to acquire the new flow label as it changes. 6. Conclusions In order for IPv6 with flow labels to be useful with RSVP, several steps must be taken. The first is to complete the sockets interface for use with IPv6 flow labels including support for RSVP to acquire the flow label. The second is to adapt RSRR to handle flow labels. The third is to make two technical changes to the RSVP specification to deal with 20 bit IPv6 flow labels and filters with both flow label and source ports. The final is to solve the security problems related to spoofing source addresses and flow labels. REFERENCES [1] Berger, L., O'Malley, T., "RSVP Extensions for IPSEC Data Flows," RFC 2207. [2] Braden, R., Zhang, L., Berson, S., Herzog, S., and Jamin, S., "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification," RFC 2205. [3] Deering, S., Hinden, R., "Internet Protocol, Version 6 (IPv6) Specification," RFC 2460. [4] Gan, D., Guerin, R., Kamat, S., Li, T., Rosen, E., "Setting up Reservations on Explicit Paths using RSVP," Internet Draft. [5] Gilligan, R., Thomson, S., Bound, J., Stevens, W., "Basic Socket Interface Extensions for IPv6," RFC 2553. [6] Nichols, K., Blake, S., Baker, F., Black, D., "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers," RFC 2474. [7] Partridge, C., "Using the Flow Label Field in IPv6," RFC 1809. Berson Expiration: January 2000 [Page 6] Internet Draft RSVP and IPv6 July 1999 [8] Schmid, S., Dunmore, M., Scott, A., "RSVP Extensions for IPv6 Flow Label Support," Internet Draft. [9] Stevens, W., Thomas, M., "Advanced Sockets API for IPv6," RFC 2292. [10] Zappala, D., Kann, J., "RSRR: A Routing Interface For RSVP," Internet Draft. Security Considerations See section 5. Author's Address Steven Berson USC Information Sciences Institute 4676 Admiralty Way Marina del Rey, CA 90292 Phone: +1 310 822 1511 EMail: berson@isi.edu Berson Expiration: January 2000 [Page 7]