Network Working Group J. Manner Internet-Draft University of Helsinki Intended status: Standards Track October 16, 2006 Expires: April 19, 2007 Localized RSVP for Controlling RSVP Proxies draft-manner-tsvwg-rsvp-proxy-sig-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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. This Internet-Draft will expire on April 19, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Manner Expires April 19, 2007 [Page 1] Internet-Draft LRSVP October 2006 Abstract This draft specifies a mechanism for explicit control of RSVP proxies. The scheme is based on one bit and two new RSVP messages, and allows triggering both RSVP Sender and Receiver proxies. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. RSVP Proxy Signaling . . . . . . . . . . . . . . . . . . . . . 4 2.1. RSVP Receiver Proxy Operation . . . . . . . . . . . . . . 4 2.2. RSVP Sender Proxy Operation . . . . . . . . . . . . . . . 5 2.3. Additional functionality . . . . . . . . . . . . . . . . . 7 2.4. Addressing Issues . . . . . . . . . . . . . . . . . . . . 7 3. Interworking Issues . . . . . . . . . . . . . . . . . . . . . 8 4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 7.1. Normative References . . . . . . . . . . . . . . . . . . . 12 7.2. Informative References . . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . . . 14 Manner Expires April 19, 2007 [Page 2] Internet-Draft LRSVP October 2006 1. Introduction The usual signaling model of RSVP [RFC2205] includes the data sender and receiver, and a network of RSVP routers. The data sender initiates the RSVP signaling by sending the Path message. This message is routed through the network, setting states in RSVP routers, and finally arriving at the data receiver. The receiver then responds to the signaling by sending the Resv message, which applies the reservation for the data stream. If the data receiver is not RSVP-aware, it can not respond to the signaling and make the resource reservation happen. Similarly, if the receiver is RSVP-aware, but the sender is not, the sender can not initiate the signaling for the resource reservation. RSVP proxies for data senders and receivers have been shown to be a good idea [I-D.lefaucheur-tsvwg-rsvp-proxy]. These proxies can be triggered to run a sender or receiver proxy operation either through implicit mechanisms, such as, traffic filters, or by an explicit signaling protocol. This draft presents an extension to RSVP that provides explicit requests to RSVP proxies to operate proxy functionality for given flows. Essentially, the mechanism in this draft enables the Path-Triggered Receiver Proxy and the Path- Triggered Sender Proxy for Reverse Direction [I-D.lefaucheur-tsvwg-rsvp-proxy]. The mechanism is flexible and can be used along standard end-to-end signaling sessions. Manner Expires April 19, 2007 [Page 3] Internet-Draft LRSVP October 2006 2. RSVP Proxy Signaling In this specification, we assume a model where an end host triggers the RSVP proxy to operate either a sender or receiver proxy. Yet, it is possible to trigger the RSVP proxies from an off-path node. An RSVP proxy can be located anywhere on the path between data sender and receiver. In order to distinguish reservations targeted to the proxy from end-to-end reservations, we use one bit in the unused Flags field in the RSVP Session Object. The Proxy bit (P-bit) (currently we use bit 0x8) is used to differentiate reservations that are proxied. When the bit is set the RSVP message is part of a proxied resource signaling and the RSVP router running the proxy will operate as the end point of the signaling session. A default value of zero indicates standard end-to-end signaling, where the RSVP proxy is not concerned. In this case, the RSVP proxy only operates as a standard RSVP router. The RSVP Proxy node discussed in this draft is an enhanced RSVP router. Fully standard RSVP messages are processed as the RSVP standards describe. Only when the Proxy bit is set in RSVP messages, the RSVP router includes the proxy functions. One implementation option is to run the proxy application as a local client on top of the RSVP stack; all RSVP messages that have the Proxy bit set are provide through an upcall to the local proxy application. Thus, all proxy functions are handled in a separate application process. Note that this specification does not support a concept of nested proxies, where the data path between sender and receiver includes several proxies. The proxy RSVP signaling session discussed in this draft terminates at the first proxy encountered on the data path. Still, it is possible for two communicating nodes to run their own RSVP proxies, thus, both end points would be communicating with their own domain RSVP proxies. In addition, we present two new messages, a Path Request and a Path Request Tear. Due to the new bit and message types, all RSVP routers within the proxied region must be upgraded to understand the RSVP proxy signaling. The operation of our scheme is presented below. 2.1. RSVP Receiver Proxy Operation When an end host wants to trigger an RSVP receiver proxy, it sends a Path message as usuall, but sets the Proxy bit (Figure 1). The Session Object of the message defines the destination of the flow that will eventually be transmitted from the local end host, and the Sender Template provides information about the local end host itself. When the RSVP proxy eventually gets the Path message, it notes the Proxy bit is set, and replies back to the end host with a Resv. A Manner Expires April 19, 2007 [Page 4] Internet-Draft LRSVP October 2006 Path is not sent further towards the data receiver. When a Resv message arrives at the end host, the resources for the session defined in the Path message have been allocated. [Data] [END HOST] [RSVP ROUTER] [RSVP ROUTER] [PROXY] ... [receiver] | | | | | |----- Path -> data receiver (P-bit = 1) ----->| | | | | | | | | | (proxy | | | | intercepts) | | | | | | | | |<- Resv (P=1)--| | | |<- Resv (P=1)--| | | |<- Resv (P=1)-| | | | | | | | | Figure 1: RSVP Receiver Proxy operation 2.2. RSVP Sender Proxy Operation Before triggering an RSVP sender proxy, the end host needs to be aware of the data senders for which proxy operation will be requested. For multimedia communications, a session is usually initiated with application layer protocols like SIP [RFC3261] or RTSP [RFC2326]. Based on this correspondence, the end host knows the necessary information about the sender. Another, more coarse reservation could be set, for example, for browsing different audio servers; the end host would indicate in the RSVP messages that the sender will use UDP. It is, therefore, possible to make resource reservations for any sender that wants to communicate with the end host. However, in order to allow for more accurate QoS support, more information should be given. The way to find this information is out of scope of this document, this is discussed in more detail in [I-D.lefaucheur-tsvwg-rsvp-proxy]. When an end host wants to make a resource reservation for an incoming flow, i.e., trigger RSVP sender proxy operation, it needs a mechanism to trigger the proxy to send a Path message towards the end host. This signaling mechanism can be implemented with a number of different mechanisms. In our scheme, the end host sends a new message called Path Request towards the data source, or to an indicated RSVP proxy (addressing issues are discussed later in this document). This message instructs the RSVP proxy to send a Path message towards the end host (Figure 2). The end host can then reply with a Resv, and set up a reservation on behalf of a data sender. All these messages carry the Proxy bit in order to distinguish the Manner Expires April 19, 2007 [Page 5] Internet-Draft LRSVP October 2006 messages from standard end-to-end sessions. [Data] [END HOST] [RSVP Router] [X-OVER ROUTER] [PROXY] ... [sender] | | | | | |--- Path Request -> Data sender (P-bit=1) --->| | | | | | | | | | (proxy | | | | intercepts ) | | | | | | | | |<- Path (P=1)--| | | |<- Path (P=1) -| | | |<- Path (P=1)-| | | | | | | | | |- Resv (P=1)->| | | | | |-- Resv (P=1)->| | | | | |-- Resv (P=1)->| | | | | | | Figure 2: RSVP Sender Proxy operation The Path Request message is essentially identical to a standard Path message apart from the message type field. The Session Object must include information about the recipient, the local end host in this case, and the Sender Template must define the expected sender(s). The Traffic specification (Tspec) can either be based on the end user's wishes, a best estimate of the incoming traffic characteristics, or on application level session signaling prior to the transfer. The Path Request message can also be used end-to-end, to request the correspondent node to initiate a resource reservation. In this case, the Proxy bit must not be set, since it would stop the message at the edge of a proxied domain. There is one concern related to the Sender Proxy signaling, namely the case of asymmetric routing, and reverse routing. When the end host sends the Path Request towards a data sender, a RSVP Sender Proxy will reply to the signaling. Yet, due to the nature of IP routing, the data coming from the data sender may not arrive through the RSVP Sender Proxy, and through the path where the reservation is set up. This case is more probable the further away the data sender is from the RSVP Sender Proxy. Ultimately, the data receiver sending the Path Request should be able to run a reverse-routing scheme to find out the routing path of the incoming data stream, or some other scheme to find out the proper RSVP Sender Proxy to trigger. Manner Expires April 19, 2007 [Page 6] Internet-Draft LRSVP October 2006 2.3. Additional functionality All the other features of RSVP are used in the standard way including the local repair mechanism and reservation tear down. Reservations from a RSVP Sender Proxy are torn down with the Path Request Tear message. The operation follows that of the Path Request: the message does not change states within the network, but only triggers the proxy to send a Path Tear message towards the end host for the specified session. All messages used for the proxied reservation session must have the Proxy bit set in order to distinguish the session from standard end- to-end sessions. Intermediate RSVP routers between the end host and the RSVP proxy should not process the Path Request message and they should forward it as an ordinary IP packet. 2.4. Addressing Issues When an end host sends Path or Path Request messages, it needs to use some IP address as the destination in the IP header. There are various options which address the local end host can or can not use. The end host must use in priority order (if known): 1. The address of the correspondent host, 2. The address of a designated RSVP proxy, 3. The address of the next-hop RSVP router, or 4. The address of the default router. The first option may not be possible, if the end host wants to allocate resources only for certain services regardless of the sender, HTTP, for example. The second possible address could be given through auto-configuration. The third option would be to send the IP packet to the next-hop RSVP router, if the end host has knowledge of it - ideally, this would be the default router. The final option would be to send the RSVP packet to the default router, and see if the router is also running an RSVP daemon and could handle the reservation attempt. If the default router is not running an RSVP daemon, it will return an ICMP error message. Manner Expires April 19, 2007 [Page 7] Internet-Draft LRSVP October 2006 3. Interworking Issues The proposed scheme makes use of one bit in the Session Object and adds two new message types. There can be situations where such a currently non-standard message arrives at a standard RSVP router. According to the message processing rules in RFC2209 [RFC2209], the Path Request and Path Request Tear messages would be forwarded intact by standard RSVP routers. However, for standard RSVP message, the Proxy bit may or may not be kept between RSVP hops, and, thus, the indication of proxy signaling may be lost. Therefore, all RSVP routers between the end host the RSVP proxy must be set to keep the bits intact. The network of the end host may not understand the proxy extension or even standard RSVP. Thus, Path messages with the Proxy bit and Path Request message can be routed out of the local network. If the domain of the correspondent node has support for the proxy mode, that network RSVP proxy gets the Path or Path Request message with the Proxy bit set from possibly a wrong network interface. The proxy must drop the message and respond with a PathErr message and a new error code called "LRSVP not supported". This would inform the host that RSVP proxy mode is not supported and it still can try end-to-end signaling. If the recipients network does not either support the RSVP proxies, an end host will receive the proxy mode RSVP message. If the end host supports the RSVP proxy operation, it can operate as follows: o If an end host receives a Path message with the Proxy bit set, it should respond with a Resv message and not set the Proxy bit. The reason is that that if the RSVP proxies drop Path messages with the Proxy bit set coming from seemingly erroneous networks, end hosts can trust that if they receive such a message, it must have (if the network is properly configured) arrived from the corresponding and RSVP-capable end host. Now, if our end host that sent the Path message receives the Resv without the Proxy bit, it can use this as an indication that the correspondent node is RSVP-aware and may remove the Proxy bit in subsequent messages belonging to the same session. o Similarly, if the correspondent node receives a Path Request message, it should respond with a Path message that does not have the Proxy bit set. Again, if our end host receives a Path message without the Proxy bit set in response to the proxy mode Path Request sent earlier, it can use this as an indication that the correspondent node is RSVP-aware and it should remove the Proxy bit in subsequent messages belonging to the same session. Manner Expires April 19, 2007 [Page 8] Internet-Draft LRSVP October 2006 4. Summary In summary, the Localized RSVP requires the following changes in the standard RSVP protocol: 1. A new message type and number, named Path Request (initially number 8). 2. A new message type and number, named Path Request Tear (initially number 9). 3. A bit from the Session Object for the use as the Proxy bit (P-bit) (initially bit 0x8). 4. An RSVP router must keep the Proxy bit set in all messages belonging to that session, if it encounters packets with the bit set. 5. An RSVP router that is not also a proxy, must forward an RSVP packet with a message type "Path Request" without storing state. 6. An RSVP router that is not also a proxy, must forward an RSVP packet with a message type "Path Request Tear" without affecting the stored state. 7. A new error code to indicate that the access network does not support local reservations. If local resources cannot be requested, the end-host can always try to do end-to-end signaling. Manner Expires April 19, 2007 [Page 9] Internet-Draft LRSVP October 2006 5. Security Considerations The Path Request message triggers most processing at the RSVP Sender proxy. This could potentially be used for Denial of Service attacks. A typical security check in RSVP is for a RSVP router connected to end hosts verify that the session is truly for the end host in question. This has the benefit that the RSVP proxy may trust that the previous RSVP routers have validated the message; this can be seen as distributed processing of the authentication and authorization data. The same considerations apply for the Path message. The RSVP daemon at the end hosts and the proxy must also modify their security/sanity checks to allow the end host to send the Path Request with apparently suspicious session information (identifying the correspondent node(s)). Also, the RSVP Sender proxy must be able to send RSVP messages on-behalf of external network nodes. The RSVP proxy must be configured to identify the interfaces from where proxy mode messages are supported. If the proxy receives a Path or a Path Request message with the Proxy bit set from an erroneous interface, it must drop the message. The two new messages can make use of the standard RSVP INTEGRITY and POLICY objects. For the remaining functionality, the security considerations with standard RSVP apply [RFC4230]. Manner Expires April 19, 2007 [Page 10] Internet-Draft LRSVP October 2006 6. IANA Considerations IANA needs to allocate one flag bit in the RSVP Session Object, the Proxy bit. In addition, IANA needs to give two RSVP message type numbers to the Path Request and Path Request Tear messages and one Error Type indicating that a proxy resource reservation is not allowed. Manner Expires April 19, 2007 [Page 11] Internet-Draft LRSVP October 2006 7. References 7.1. Normative References [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997. [RFC2209] Braden, B. and L. Zhang, "Resource ReSerVation Protocol (RSVP) -- Version 1 Message Processing Rules", RFC 2209, September 1997. [RFC4230] Tschofenig, H. and R. Graveman, "RSVP Security Properties", RFC 4230, December 2005. 7.2. Informative References [I-D.lefaucheur-tsvwg-rsvp-proxy] Le Faucheur, F., Manner, J., and D. Wing, "RSVP Proxy Approaches", October 2006. [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. Manner Expires April 19, 2007 [Page 12] Internet-Draft LRSVP October 2006 Author's Address Jukka Manner University of Helsinki P.O. Box 68 University of Helsinki FIN-00014 University of Helsinki Finland Phone: +358 9 191 51298 Email: jmanner@cs.helsinki.fi URI: http://www.cs.helsinki.fi/u/jmanner/ Manner Expires April 19, 2007 [Page 13] Internet-Draft LRSVP October 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Manner Expires April 19, 2007 [Page 14]