Network Working Group J. van Bemmel Internet-Draft Lucent Technologies Expires: February 2, 2006 August 2005 A solution for the HERFP caused by forked SIP INVITE requests draft-jbemmel-herfp-solution-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 February 2, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document describes a solution to the Heterogeneous Error Response Forking Problem (HERFP), a situation in which a UAC remains unaware of elements that are responding to its INVITE with a 'repairable' error response, because a forking proxy in the signalling path only forwards what it considers the 'best' final response. This issue may cause communication establishment to be delayed or even fail. To address this issue this document proposes a new method [preliminarily called 'FIX'] to be used by a forking proxy that detects a HERFP to notify the UAC of a repairable error. van Bemmel Expires February 2, 2006 [Page 1] Internet-Draft A solution for the HERFP August 2005 Table of Contents 1. Conventions used in this document . . . . . . . . . . . . . . 3 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Problem analysis and requirements . . . . . . . . . . . . . . 7 3.1. Repairable errors . . . . . . . . . . . . . . . . . . . . 8 3.2. Analysis of possible solutions . . . . . . . . . . . . . . 11 3.2.1. Notification mechanism . . . . . . . . . . . . . . . . 11 3.2.2. Forwarding/routing of the modified INVITE request . . 13 3.2.3. Formulation of the HERFP notification . . . . . . . . 14 3.2.4. Formulation of the modified INVITE request . . . . . . 14 4. Proposed solution . . . . . . . . . . . . . . . . . . . . . . 16 4.1. Outline . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.2. Argumentation . . . . . . . . . . . . . . . . . . . . . . 18 4.2.1. Interaction between UAC and proxy . . . . . . . . . . 19 4.2.2. SUBSCRIBE/NOTIFY based alternative . . . . . . . . . . 20 4.3. Detailed normative guidelines . . . . . . . . . . . . . . 20 4.3.1. Construction of a FIX request . . . . . . . . . . . . 20 4.3.2. Merging of the original and modified INVITE . . . . . 22 4.3.3. UAC behavior . . . . . . . . . . . . . . . . . . . . . 22 4.3.4. B2BUA behavior . . . . . . . . . . . . . . . . . . . . 23 4.3.5. Forking proxy behavior . . . . . . . . . . . . . . . . 24 4.3.6. UAS behavior . . . . . . . . . . . . . . . . . . . . . 25 4.4. Open issues . . . . . . . . . . . . . . . . . . . . . . . 26 5. Security Considerations . . . . . . . . . . . . . . . . . . . 27 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 6.1. New Methods . . . . . . . . . . . . . . . . . . . . . . . 28 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 8.1. Normative References . . . . . . . . . . . . . . . . . . . 31 8.2. Informative References . . . . . . . . . . . . . . . . . . 31 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 32 Intellectual Property and Copyright Statements . . . . . . . . . . 33 van Bemmel Expires February 2, 2006 [Page 2] Internet-Draft A solution for the HERFP August 2005 1. Conventions used in this document 1.1. Requirements notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [1]. 1.2. Terminology o 'HERFP' means "Heterogeneous Error Response Forking Problem". o 'Forking' is the forwarding of a (SIP) request to more than one destination, either sequentially or in parallel o A 'repairable' response is a final error response to an INVITE request that represents a condition which could potentially be fixed by submitting a modified INVITE request. The response codes are typically in the 4xx range; some examples are "401 Unauthorized" or "415 Unsupported Media Type". van Bemmel Expires February 2, 2006 [Page 3] Internet-Draft A solution for the HERFP August 2005 2. Background The Session Initiation Protocol (SIP) [2] allows a stateful SIP proxy that is responsible for the domain in the request URI to fork a request to multiple destinations. These 'targets' may be other proxies, UAC or UAS elements. Each branch of the fork is an independent client transaction, and may result in zero or more provisional responses and at most one final response. According to the current standard the proxy is to forward all provisional responses and 2xx OKs upstream immediately. When all branches have finished and no final response was forwarded yet, it should eventually forward one 'best' final response from all those received. It can therefore occur that an answer from a respondent never reaches the caller, since it is blocked by the proxy in favor of another 'better' response. If the blocked response is due to an error condition that could have been fixed (e.g. by responding to an authentication challenge), a communication opportunity is lost. This situation is known as the Heterogeneous Error Response Forking Problem (HERFP) To illustrate a simple case of HERFP, consider the example below adopted from [8]. The UAC sends a request that includes a body format which is understood by UAS2, but not by UAS1. For example, the UAC might have used a multipart/mixed with a session description and an optional image or sound (e.g. a personal ring tone). UAS1 does not support multipart/mixed, so it returns a 415 response. The UAC could trivially repair this 415 response by resending the request with just the session description. Unfortunately, the proxy has to wait until all branches generate a final response before forwarding the best response. UAS2 keeps ringing until finally the user at the calling UAC gives up and cancels the call. At this point the proxy cancels all pending branches and returns the 415 as a best final response. The calling UAC may now retry but that is unlikely since the user already hung up. Even when it would retry, precious time is lost. In case UAS2 would represent an automatic response system (e.g. a voicemail box) and returned a 2xx response instead, the caller would never even know about the possibility of direct contact. van Bemmel Expires February 2, 2006 [Page 4] Internet-Draft A solution for the HERFP August 2005 UAC Forking Proxy UAS1 UAS2 | INVITE | | | |---------->| | | | | INVITE | | | |-------------------------------->| | | | INVITE | | | |------------------------------------------>| | | 415 Unsupported Media Type | | | |<--------------------------------| | | | ACK | | | |-------------------------------->| | | | 180 Ringing | | | 180 |<------------------------------------------| |<----------| | | ~ ~ time passes... ~ ~ | CANCEL | | | |---------->| | | | 200 OK | | | |<----------| CANCEL | | | |------------------------------------------>| | | 200 OK | | | |<------------------------------------------| | | 487 Request Terminated | | | |<------------------------------------------| | | ACK | | | 415 |------------------------------------------>| |<----------| | | Fig. 1 : Sample call flow illustrating the HERFP Previous approaches to solve this issue are outlined in [9] (expired) and more recently [8]. In [9] - which addresses several other issues simultaneously - it is proposed that the proxy adds a 'Require' header which causes the UAS to generate a 155 provisional response when it would normally generate a repairable error (401, etc), encapsulating the 'real' error response in a 'Reason' header. The client receives this 155 and can then send an updated INVITE, using a new method called 'COMET' (later replaced with UPDATE [3]). Drawback of this proposal is that it requires updates to UACs, proxies and UASs, and the use of 'Require' would cause each 'old' UAS to refuse the request. In other words, modifications to each UAS would be needed. The status of this work is that 'The proposal was accepted, and the text has found its way into the UPDATE and manyfolks specifications. There will be no more revisions of this document.' However, neither [3](UPDATE) nor [4] (manyfolks work) mentions HERFP. In [8] an additional requirement is proposed to ensure that a solution would work with existing UAS. This rules out the above van Bemmel Expires February 2, 2006 [Page 5] Internet-Draft A solution for the HERFP August 2005 solution; instead it is proposed to have the proxy send a new '130 Repairable Error' provisional response when it receives a repairable error. This 130 response would have a to-tag generated by the proxy and contain a contact that points to the specific branch at the proxy. The UAC would then send a modified INVITE request to this URI, which the proxy would receive and merge with the ongoing call attempt. If the UAC does not wish to retry the INVITE, it should send a special CANCEL to tell the proxy to abandon the branch. Some issues with this approach are: 1. The proposed solution might not work when there are other proxies on the path between the UAC and the HERFP-solving proxy. The request URI of the modified INVITE points directly at the proxy that sent the 130, thus bypassing all other elements on the original route. As a result, the modified INVITE could lack headers that would have been inserted by those intermediate proxies, or contain headers that would have been stripped or modified. The presence or absence of these headers could cause the request to fail, or certain features to break. As concrete examples, consider privacy services [5] or identity services [6] that would be bypassed or session timers [7] that would not get set. 2. The proposal defines a 'repairable' error response as 'a 400- class or 500-class response other than a 503, 487, or 408'. This range is too broad as it includes e.g. 403 Forbidden. Moreover, UAC behavior for some specific responses such as a 486 Busy here (with/without a Retry-After header) should be explicitly specified to avoid interoperability issues and/or network flooding. 3. The usage of CANCEL is somewhat particular, as CANCEL is normally sent to the same URI as the request being CANCELed (in fact, it is not a request being cancelled here, but a particular branch). 4. The proposal allows reliable transmission of the 130 response, which implies that the proxy must formulate a response to any session offer or answer that was contained in the original INVITE. It is suggested to generate a minimal offer or answer. This sets up a session that has little use, and triggers a PRACK/OK sequence. 5. The entire error response is to be included as the body of the 130 response. This response could contain information that the network does not want to make public, such as IP addresses of specific proxies. van Bemmel Expires February 2, 2006 [Page 6] Internet-Draft A solution for the HERFP August 2005 3. Problem analysis and requirements The HERFP was first identified in late 2001, but up until now no satisfactory solution was proposed. Generally stated, a solution to the HERFP would enable a UAC to learn about repairable errors received by a forking proxy, and give it a chance to issue a modified INVITE request in an attempt to resolve the problem. The following list of requirements for a HERFP solution are identified: o The UAC SHOULD indicate support for the protocol feature(s) required for the HERFP solution o The HERFP solution SHOULD work regardless whether the element that sent the repairable error response is a UAC, UAS, proxy or B2BUA o The HERFP solution SHOULD work regardless of intermediary elements between the forking proxy with HERFP solution and the UAC; in particular it SHOULD NOT break services or features provided by such intermediary elements o A UAC supporting the HERFP solution SHOULD be notified promptly of all 'repairable' error responses received by any forking proxy along the signalling path that supports the HERFP solution o To attempt to fix a repairable error, a UAC with HERFP solution support SHOULD cause a modified INVITE request to arrive at the element that sent the error response o Until it is received by the element that sent the repairable error, the modified INVITE request MUST NOT be received by any element that was not in the original path. This implies that the modified INVITE request MUST NOT be forked by any element on the path of the original INVITE, from the UAC up to and including the forking proxy that detected HERFP (i.e. those listed in the Via headers of the error response) even if they are not aware of the HERFP solution o The modified INVITE SHOULD be received by the element that sent the repairable error, which SHOULD see it as a new call attempt In addition there is a list of 'nice to have' features: o A solution SHOULD require only minimal changes to the SIP protocol, and preferably reuse existing mechanisms where possible van Bemmel Expires February 2, 2006 [Page 7] Internet-Draft A solution for the HERFP August 2005 o A solution SHOULD require only minimal changes to SIP protocol entities, in particular it SHOULD work without modifying existing UAS elements o A solution MUST be backwards compatible Specific issues and scenarios to be addressed: o What happens when an element first sends a provisional response (with a to-tag, establishing an early dialog) and then a repairable error? o What happens if multiple forking proxies are in the path, some of which are unaware of the HERFP solution? o What happens if the modified INVITE request also fails with a repairable error response, possibly the same? o What happens if the fix requires a change of transport? 3.1. Repairable errors To avoid interoperability issues with implementations of a HERFP solution, it must be clearly specified which error responses are to be considered 'repairable'. In general, error responses in the 4xx- 5xx range SHOULD be considered repairable unless explicitly stated otherwise. This is especially true for codes that have no assigned meaning yet, as not forwarding these would imply that all proxies would need to be updated each time a new response code in this range is introduced. This draft only covers response codes defined in [2]. van Bemmel Expires February 2, 2006 [Page 8] Internet-Draft A solution for the HERFP August 2005 The following error responses from RFC3261 are repairable [ possibly under specified conditions ] when returned in response to an INVITE request +---------------------+---------------------------------------------+ | response code | when / how | +---------------------+---------------------------------------------+ | 401 Unauthorized | Always, by attaching credentials for the | | | requested realm | | | | | 406 Not Acceptable | Always, by changing the Accept header in | | | the INVITE (if supported) | | | | | 407 Proxy | Always, by attaching credentials for the | | Authentication | requested realm | | Required | | | | | | 413 Request Entity | Always, by making the request body smaller | | Too Large | if possible. If a Retry-After header is | | | included, the condition is temporary and | | | the request could be retried unmodified | | | after the specified time interval. If this | | | interval is larger than an Expires header | | | added to the original INVITE, the UAC | | | SHOULD decline the fix and offer the user | | | the possibility to retry later. | | | | | 414 Request-URI Too | Possibly, by using a shorter URI (if the | | Long | UAC/proxy have control over this) | | | | | 415 Unsupported | Always, by using only media supported by | | Media Type | the responding entity | | | | | 416 Unsupported URI | Possibly, if the forking proxy did not | | Scheme | change the URI scheme itself. If so, the | | | forking proxy SHOULD add a URI with a SIP | | | scheme to its target set (see RFC3261 | | | section 16.7 point 4) and not notify the | | | UAC. | | | | | 420 Bad Extension | Always, if the UAC is willing to do without | | | the extension | | | | | 421 Extension | Always, if the UAC supports the required | | Required | extension. | | | | van Bemmel Expires February 2, 2006 [Page 9] Internet-Draft A solution for the HERFP August 2005 | 480 Temporarily | Not repairable but SHOULD be forwarded to | | Unavailable | notify the UAC including reason phrase and | | | any Retry-After information. The UAC MUST | | | decline to repair | | | | | 485 Ambiguous | Always, but only after user input is | | | collected | | | | | 486 Busy Here | Not repairable but SHOULD be forwarded to | | | notify the UAC including any Retry-After | | | information. The UAC MUST decline to | | | repair | | | | | 488 Not Acceptable | Always, if acceptable media capabilities | | Here | are supported by the UAC | | | | | 493 Undecipherable | Always, using an encryption key not used | | | before for that target (e.g. the one | | | provided in the response body) | | | | | 504 Server Time-out | With caution, no more than 2 retries is | | | RECOMMENDED | | | | | 505 Version Not | If the UAC (and proxy) support a different | | Supported | SIP version | | | | | 513 Message Too | Always, using a smaller message or | | Large | different transport (if possible) | +---------------------+---------------------------------------------+ Table 1: Repairable responses in RFC3261 van Bemmel Expires February 2, 2006 [Page 10] Internet-Draft A solution for the HERFP August 2005 Some responses were intentionally left out of this table. In particular: +---------------------+---------------------------------------------+ | response code | why not | +---------------------+---------------------------------------------+ | 400 Bad Request | More likely to be generated by the forking | | | proxy itself, and some causes (e.g. missing | | | Call-ID header) cannot be fixed. | | | | | 408 Request Timeout | Not caused by something the UAC can fix. | | | | | 483 Too Many Hops | The UAC cannot change the number of hops | | | the request traversed. It could be that a | | | shorter path exists between the UAC and the | | | failing element, but it is more likely a | | | signal of misconfiguration in the network | | | (a looping request) | | | | | 484 Address | It is assumed that a proxy would not fork a | | Incomplete | request with an incomplete address, in | | | particular because it cannot determine | | | whether it is responsible for the | | | (incomplete) domain | | | | | 491 Request Pending | Another INVITE is apparently already | | | pending | | | | | 503 Service | RFC3261 states that proxies SHOULD NOT | | Unavailable | forward 503 responses upstream, but replace | | | it with a 500 response instead. | +---------------------+---------------------------------------------+ Table 2: Non-Repairable responses in RFC3261 A forking proxy SHOULD process non-repairable responses as defined in RFC3261. 3.2. Analysis of possible solutions 3.2.1. Notification mechanism A forking proxy that receives a 'repairable' error on one of its branches has several options to notify the UAC: 1. Send a request van Bemmel Expires February 2, 2006 [Page 11] Internet-Draft A solution for the HERFP August 2005 * Using an existing method : The proxy could use an existing method, e.g. SUBSCRIBE/NOTIFY [ref], UPDATE [3], INFO [ref], PUBLISH [ref] or others. Support for each method is indicated in the 'Allow' header, but that is not sufficient for the proxy to determine whether the UAC supports the HERFP-related semantics of the method. For SUBSCRIBE/NOTIFY or PUBLISH a new event could be defined, such that 'Allow-Events: fix' would be sufficient proof of support. * Using a newly defined method : This has the advantage of cleanly and exactly matching the intended semantics, at the cost of adding yet another method to SIP. * A request would be sent with the same Call-ID and a to-tag equal to the from-tag of the original INVITE, to allow the UAC to match it against an ongoing call attempt. 2. Send a response * provisional (1xx): A provisional response could be sent. RFC3261 disallows a proxy from generating its own provisional responses, but allows 'virtual co-location' with a UAS element. Technically the proxy would forward the request to a virtual UAS, which would generate the response. The provisional response might or might not contain a to-tag, depending on whether the intention is to create an early dialog between the virtual UAS on the proxy and the UAC. * final success (2xx): Sending a final success response would terminate any transactions in upstream intermediate elements, and thus block any responses from other branches. Such a 2xx response would be expected to contain an SDP offer/answer. In addition, according to the rules in [2] section 16.7 the proxy should CANCEL all other pending branches. * final error (300-699): Sending a final error response would cause any transactions in upstream intermediate elements to move to the 'confirmed' state. As for a final 2xx response, this would block any responses from other branches and the proxy should CANCEL all pending client transactions. Sending a new request rather than a response has the advantage that any upstream transaction state is unaffected. Furthermore, a request could be routed directly to the UAC (using the Contact address from the INVITE if it is a GRUU), and does not need to travel along the established signalling path. A request can be acknowledged by the UAC with a response, a response would require PRACK(1xx), ACK(2xx) or some other mechanism (300-699 since these get ACKed hop-by-hop). van Bemmel Expires February 2, 2006 [Page 12] Internet-Draft A solution for the HERFP August 2005 Drawback of PRACK is that it would trigger an additional response to the PRACK itself. For the notification mechanism the choice is between sending a request or a provisional response. The transport path for the response is already setup (DNS names have been resolved and cached, connections are setup) but a request could be sent directly. Sending a request would provoke a response, which would acknowledge reception of the notification. It is currently uncommon for UACs to receive PUBLISH requests, but a SUBSCRIBE with a body containing the repairable response could be feasible. This would require standardization of a new event package, e.g. the "fix" event. A NOTIFY could then be used to carry the modified INVITE (and terminate the subscription). However, currently the NOTIFY is required to be sent promptly, while it could take some time (in particular in case of user interaction) before the modified INVITE is ready to be sent. 3.2.2. Forwarding/routing of the modified INVITE request The question is how the modified INVITE request gets from the UAC to the element that sent the repairable error. There are several things to consider here: o The modified request cannot be directly targeted at the element that sent the 'repairable' error response. To understand why, consider the case that this element is in a different domain than the forking proxy (i.e. the proxy did a rewrite of the domain part of the request URI). Then a request targeted at this domain will likely not pass through the proxy and follows a different route, thus violating the requirements. o If the modified INVITE is not sent with the established route of the original request attached, it is not guaranteed that it will follow the same route. Theoretically a proxy along the path could base its routing decision on any property of the request, including some that are modified from the original INVITE. o If the modified INVITE is sent within an early dialog established by a provisional response to the initial INVITE, proxies that did not Record-Route the original will not receive the modified request. This could be troublesome if the network depends on these elements for inserting particular information in INVITE requests. It could be assumed that such elements would be configured to Record-Route, but this would restrict applicability of the solution o The forking proxy has insufficient information to calculate a Route which would take the modified request along exactly the same van Bemmel Expires February 2, 2006 [Page 13] Internet-Draft A solution for the HERFP August 2005 path as the initial request. It can extract information from Via headers and Record-Route headers, but for proxies that did not Record-Route it cannot determine whether they are strict or loose routers. o RFC3261[2] section 19.1.5 strongly discourages UACs to accept Route headers encoded in a Contact URI The best way to guarantee that the modified request arrives at the proxy without passing through other elements, would be to include it in the body of a request or response targeted at the proxy. The proxy could subsequently take the request from the body, possibly modify some headers and then forward it to the element that sent the repairable error. 3.2.3. Formulation of the HERFP notification The HERFP notification sent to the UAC to notify it of a repairable error SHOULD contain the following information: o The response code that was sent o Any headers from the response relevant for determining how the UAC should react o All information required to match the notification to an INVITE sent previously by the UAC o Information needed to associate the response with the branch on which the error occurred (for proper routing of the modified request at the forking proxy) or the request URI that the proxy used to forward the original INVITE (in which case matching is not needed). To be robust the best solution would probably be to send the received response including most headers and its body to the UAC. For both efficiency and security reasons non-essential information SHOULD be stripped. A guideline for stripping some headers is that the response should be received by the UAC as if it was sent as a final response by the proxy. This means all but the last Via header (which the UAC put in there) should get removed. Including the response body does not constitute an additional security issue, since this is what the UAC would receive if the repairable error were the only response received by a non-modified proxy. 3.2.4. Formulation of the modified INVITE request The modification to the INVITE request depends on the specific error van Bemmel Expires February 2, 2006 [Page 14] Internet-Draft A solution for the HERFP August 2005 response received. Typical changes consist of o Adding some headers, e.g. an authentication response o Changing the format of the request body, e.g. removing MIME multipart bodies It is expected that the modified INVITE request will for the most part be the same as the original request, with only minor modifications. Given the HERFP solution requirements it SHOULD contain any headers added by proxies along the path of the original request, but the UAC is not aware of these. Moreover, for security reasons it should not be informed about these headers. Therefore it seems better to have the forking proxy append any missing headers, and possibly remove or adjust some others. In fact, the UAC could send only the required (minimal) changes and the proxy could apply this as a 'patch' to the original request it received. The set of allowed modifications should be well defined (specific for each repairable error) to avoid security holes, otherwise the UAC could e.g. insert headers that are not allowed. On the other hand, given the end-to-end nature of SIP it would be preferable if the endpoint were responsible for formulating the modified INVITE request. van Bemmel Expires February 2, 2006 [Page 15] Internet-Draft A solution for the HERFP August 2005 4. Proposed solution 4.1. Outline The proposed solution consists of a new method [preliminarily called 'FIX' for lack of a better name, to be discussed] used by the proxy to inform the UAC of any repairable responses it receives during forking. The UAC then submits a modified INVITE to the proxy as the body of either its response or another FIX request. The proxy merges this with the original INVITE it received, and forwards the resulting request to the element that sent the repairable response. More specifically: o A UAC supporting this HERFP solution formulates an INVITE as usual, including an 'Allow: FIX' header o A forking proxy that receives a repairable error response on a branch, sends an ACK and checks if the original INVITE allows 'FIX'. If so, a FIX request is formulated based on the received response. Suitable headers for the content are added. The body of the FIX request consists of a stripped version of the repairable response received (MIME type: message/sipfrag), and routing is arranged such that the request will arrive at the UAC. A CSeq number is chosen which increases monotonically for the response context. The FIX request is sent as a new non-INVITE transaction, with a new Via branch parameter. The transaction is associated with the response context (just like a forked INVITE transaction would be). The proxy excludes the error response from consideration as a 'best' final response for the given response context, instead considering the branch being fixed as if a '408 Request Timeout' was received; timer C is canceled. o A UAC that receives a FIX request determines if it is willing and able to fix the issue. It first checks whether the FIX request matches an ongoing call attempt (based on the transaction for the contained repairable error response). If there is no match, it should respond with a '481 Call/Transaction does not exist'. To attempt a fix, the UAC responds with a 2xx code. If no fix is possible/desired, the UAC responds with a '603 Decline'. o If the UAC can formulate a modified INVITE within a reasonable time (200ms), it puts this request in the body of a '200 OK' response. If not (for example because user interaction is required) it sends a '202 Accepted' response without a body, and remembers the route set (including Contact header) and CSeq number from the FIX request. van Bemmel Expires February 2, 2006 [Page 16] Internet-Draft A solution for the HERFP August 2005 o When the proxy receives a 2xx response to its FIX, it locates the response context and the specific branch. If found, and the response contains a body, the modified INVITE is processed as below. Else a Timer R is started for that branch, and the mapping CSeq -> branch is recorded in the response context. If the branch is not found or the response is a retransmission, it is ignored. o If no modified INVITE was sent in the response, at some later point in time (likely after consulting the user) the UAC formulates a modified version of its INVITE, taking into account the error response received. The UAC sends this INVITE as the body of a new FIX request it formulates. This request is sent using the route set, Contact and CSeq that were obtained from the proxy's FIX, using the same Call-ID and From-tag as the original INVITE. o If the response context still exists (lookup using Call-ID + From- tag), the proxy locates the original branch (using the CSeq number) and merges the modified INVITE request with changes found in the original INVITE request. In particular, Record-Route and Via headers are added, as well as other headers added or modified by intermediate elements. It then adds a new Via header of its own and sends this modified INVITE to the same target that sent the repairable error response (in many cases, using the same request URI). This new INVITE client transaction is added to the response context, as a new branch. Unlike the description in RFC3261 section 8.1.3.5, the patched INVITE MUST have the same CSeq value as the original INVITE. o The UAS (or other element) that originally sent the repairable error now receives the modified INVITE. If the problem is solved it will likely generate zero or more provisional responses and a 2xx response, resulting in a new dialog. o Any provisional or final responses that result from the modified INVITE are included in the response context processing as usual. A new repairable response is handled as under point (2) above (even if it is the same as before). o When all transactions have ended and no Timer R is active anymore, the proxy selects a final response for forwarding if none was sent yet, counting branches for which a FIX was sent as '408'. o When the response context is destroyed (e.g. the original request is CANCELed), the proxy should also terminate any FIX transactions associated with the response context (treat them as if '487 Request Terminated' was received but not CANCEL them) and cancel any timer R. van Bemmel Expires February 2, 2006 [Page 17] Internet-Draft A solution for the HERFP August 2005 Although it is not the primary objective of this solution, an UAS could also opt to support the FIX mechanism. Instead of sending a repairable response, it would formulate a FIX request with the intended response (stripped of some headers). This allows for example an optimized challenge-response sequence that takes place only between the UAS and the UAC, without involving all intermediate elements. An UAS supporting FIX partially solves HERFP in case a forking proxy on the path does not support it. 4.2. Argumentation o Like [8] this solution works with existing UAS, with modifications to UACs and forking proxies. It also works with existing forking proxies and modified UAC/UAS. Non-forking proxies can remain unchanged, but enabling them to support FIX could offer a (minor) improvement in network efficiency, in particular when many intermediate elements are present. o A new method is defined rather than reusing an existing one. To reuse an existing method an additional 'Supported' header (or a new event definition) would be needed to inform the forking proxy that the UAC supports this HERFP solution. Rather than adding an additional way of using an existing method it is considered more elegant and clear to introduce a new method. o Using a new request rather than a provisional response avoids any effects that might affect intermediary elements. The UAC is contacted directly (when a GRUU is used as Contact) and its reply is guaranteed to be routed to the forking proxy. Using a request also enables the use of the Identity header [10] such that the UAC can determine the FIX request comes from a trusted source. o By embedding the modified INVITE in the body of a FIX request or response, it is guaranteed that the modified INVITE is only received by the proxy, without any state changes in intermediary proxies. It does mean that any existing proxy behavior based on request properties that now get modified is bypassed. To avoid this, proxies that are aware of this HERFP solution could Record- Route the INVITE to receive FIX requests and their responses. o By merging with the original INVITE it is guaranteed that any headers added, modified or removed by proxies on the path also appear in (or are removed from) the modified request. This avoids the problem of having to visit all intermediaries that were involved in the original INVITE request. o A repairable error response will be acted upon by the first HERFP enabled proxy that receives it, the one closest to the sender of van Bemmel Expires February 2, 2006 [Page 18] Internet-Draft A solution for the HERFP August 2005 that response. Any other proxies further downstream will never see it and thus the same response is never FIXED twice. o An earlier version of this draft proposed to have the UAC respond with a provisional response to the proxy's FIX request if formulating the modified INVITE would take longer than 200ms, in order to send the modifications in the final FIX response. This idea was abandoned since provisional responses are not allowed for non-INVITE requests. FIX could be considered as an INVITE request, but that would introduce other issues. o For UAS the use of a provisional response was briefly considered. However, this would make the solution asymmetric and complicates processing rules. Furthermore, an Identity header could then not be used. 4.2.1. Interaction between UAC and proxy Three different interaction patterns between the proxy and the UAC were considered for this document. A specific issue addressed is the case when constructing the modified INVITE takes more time than a typical non-INVITE transaction should take, due to user interaction. When formulating a FIX response takes longer than 200ms, the following alternatives could be followed: 1. The UAC sends a provisional response to the FIX 2. The UAC sends a final 486 Busy Here response to the FIX without body but with a Retry-After header, the proxy/UAS retransmits the FIX after that interval until a body is received (or some time limit / max requests). 3. The UAC sends a final 202 Accepted response to the FIX without body, the UAC formulates a new FIX request of its own (with body) when ready. Each of these alternatives has good and bad sides. RFC3261 states that provisional responses SHOULD NOT be sent for non-INVITE requests (such as FIX is). However, the user experience would be better than option (2), since in that case the UAC has to wait for a response opportunity (there is a tradeoff between waiting interval and network efficiency). Option (3) does allow prompt submission when ready, but requires the proxy to provide a Contact header, and the UAC to construct and remember a route set. The proxy must start a timeout timer. The present document is written according to option (3). Discussion is encouraged for the other options, in particular option (1) as it van Bemmel Expires February 2, 2006 [Page 19] Internet-Draft A solution for the HERFP August 2005 could simplify the solution and could be considered more elegant. In combination with a different default T2 (4 seconds seems too little for retransmission over unreliable transports while awaiting user interaction, perhaps 10 seconds? elements unaware of FIX would still use their own T2 values though) this could be a reasonable compromise. 4.2.2. SUBSCRIBE/NOTIFY based alternative For sake of discussion, this section sketches another HERFP solution alternative based on SUBSCRIBE/NOTIFY. A UAC sending an INVITE adds 'Allow-Events: herfp'. A proxy that receives a repairable error checks if the UAC supports this event, and sends a provisional response "112 HERFP Detected" containing a Contact address (GRUU) with method=SUBSCRIBE. The UAC SUBSCRIBEs to the 'herfp' event at this URI. The proxy then sends a NOTIFY with a body containing the stripped repairable response received. The UAC responds with a modified INVITE body, else a 202 and later a reSUBSCRIBE containing the modified INVITE. The proxy merges both INVITEs, and re-submits the resulting request (as described). The subscription can last until the response context is destroyed. For a UAS the scenario would be similar, noting that the 112 response could have a to-tag if the UAS sent a provisional response before some repairable error. A brief comparison: to notify the UAC, this solution would use 112->SUBSCRIBE->OK,NOTIFY where this document proposes a single FIX request. Sending non-2xx to a NOTIFY ends the subscription, so a different solution would probably be needed for the UAC to decline a fix. 4.3. Detailed normative guidelines 4.3.1. Construction of a FIX request A FIX request is constructed based on both the original INVITE request and the repairable response received for it. In particular: o In the following statements the "received request" refers to the received INVITE for a proxy/UAS, and to the received FIX for a UAC. o A proxy/UAS MUST calculate a Route set from the Record-Route headers found in the received request. A UAC MUST do this only when it is needed for sending a response in a FIX request body of its own. van Bemmel Expires February 2, 2006 [Page 20] Internet-Draft A solution for the HERFP August 2005 o If the route set is empty, the proxy/UAS/UAC MUST place the URI from the Contact header from the received request into the Request-URI. It MUST NOT add any Route headers. o If the route set is not empty, and the first URI in the route set contains the lr parameter (see RFC3261 Section 19.1.1), the proxy/ UAS/UAC MUST place the Contact URI into the Request-URI and MUST include a Route header field containing the route set values in order, including all parameters. o If the route set is not empty, and its first URI does not contain the lr parameter, the proxy/UAS/UAC MUST place the first URI from the route set into the Request-URI, stripping any parameters that are not allowed in a Request-URI. The proxy/UAS/UAC MUST add a Route header field containing the remainder of the route set values in order, including all parameters. The proxy/UAS/UAC MUST then place the Contact URI into the Route header field as the last value. o The Call-ID header value MUST be identical to the one in the received request. o The From header MUST be set to a value that identifies the element constructing the FIX request. For a proxy the tag parameter MUST be set to a unique value for each response context. A UAS MUST set the tag according to the local tag of the dialog ID, generating one if it does not yet exist. A UAC MUST set the tag equal to the From-tag it used for the original INVITE. o The URI in the To header MUST be set to the URI of the From header in the received request. A UAS MUST use the tag value found in the From header of the received INVITE, a Proxy/UAC MUST use the tag value found in the To header of the repairable response. o A CSeq header MUST be added with a method of 'FIX'. For a proxy, a sequence number increasing monotonically for the given response context MUST be selected ( an initial value MUST be chosen using the guidelines of RFC3261 Section 8.1.1.5. ). For a UAC the CSeq number MUST be equal to the one in the received request. For a UAS the CSeq MUST be set using the value from the dialog, creating one if it did not exist. o A Max-Forwards header with a value of 70 MUST be added o A single Via header with a new unique branch ID MUST be added o For a proxy/UAS, a Contact header containing a global URI (GRUU) that leads to the element sending the FIX MUST be added. A van Bemmel Expires February 2, 2006 [Page 21] Internet-Draft A solution for the HERFP August 2005 'Supported: gruu' SHOULD be added when appropriate. A UAC MUST NOT add a Contact header. o An Identity header SHOULD be added. o Suitable headers for the body content MUST be added. In particular, a Content-Type: message/sipfrag header MUST be added, as well as a Content-Length header. o For a proxy/UAS, a stripped version of the received/generated repairable response MUST be used as the body. As a minimum, all but the last Via header MUST be removed. For a UAC, the modified INVITE request MUST be used as the body. Sending a FIX request is very similar to sending a request within a dialog, but strictly speaking for proxies it is not. The reason for constructing a route set is that although the Contact URI should be a GRUU, firewall/NAT issues could prevent reachability of the UAC. In theory there could be several NAT domains being traversed, therefore all Record-Route headers must be honored. Initially an optimization was considered that if the proxy/UAS could determine the Contact URI to be a GRUU (e.g. through presence of the 'gruu' support), it could send the request to the UAC's Contact URI directly. However, this idea was abandoned in favor of Record-Routing proxies that would like to inspect (and potentially modify or block) FIX requests/responses. 4.3.2. Merging of the original and modified INVITE TBD 4.3.3. UAC behavior A UAC supporting the HERFP solution mechanism described in this document MAY add an 'Allow: FIX' header to any INVITE it creates. It MAY do so selectively, i.e. for some requests but not for others, based on a local policy. When a UAC receives a FIX request, it SHOULD perform general request processing as specified in Section 8.2 (UAS behavior) in RFC3261. Next it SHOULD attempt to locate a matching ongoing call attempt (by locating the transaction for the repairable response). If no match is found, the UAC SHOULD respond with a '481 Call/Transaction does not exist'. If a matching call attempt has already resulted in an active session, the UAC MAY decide to fix the additional branch based on local policy. The UAC SHOULD verify that the response matches its original INVITE van Bemmel Expires February 2, 2006 [Page 22] Internet-Draft A solution for the HERFP August 2005 transaction. The UAC MAY challenge the FIX request using a '401 Unauthorized'. After the above steps, the UAC checks if it is willing and able to provide a suitable fix response. This step MAY require user interaction. If the time to formulate a final response is more than 200ms (as is e.g. the case when user interaction is required), the UAC SHOULD send a '202 Accepted' response without a body and retain the route set (including Contact URI) and the CSeq number. This state SHOULD be removed after a FIX request with the modified the INVITE has been sent or when the INVITE transaction terminates. If the FIX request has a To-tag, the UAC MUST check if it matches any existing (early) dialog. If so, and the UAC responds with 2xx it MUST discard any SDP offer/answer received for that dialog. If the UAC declines the fix, it SHOULD consider any matching dialog as terminated. To attempt a fix, the UAC formulates a modified INVITE request, taking into consideration the repairable error response that was received in the body of the FIX request. If the modified INVITE was not sent in the FIX response body, the UAC formulates a new FIX request. This request is sent using the recorded route-set (including the Contact header of the proxy/UAS). The modified INVITE MUST be set as the body of this FIX request. When the original INVITE transaction terminates (e.g. it is CANCELed either by the UAC itself or by some other element, or a 6xx response is received) the UAC SHOULD respond with '487 Request Terminated' to any pending FIX transactions, and stop any FIX related user interaction. When a 2xx response is received to the original INVITE, it is up to local policy whether to abort FIXing other branches. 4.3.4. B2BUA behavior A B2BUA supporting the HERFP solution mechanism described in this document MAY add an 'Allow: FIX' header to any INVITE it creates. It MAY do so selectively, i.e. for some requests but not for others, based on a local policy. When a 'FIX' request is received, the B2BUA SHOULD determine whether it can resolve the error locally. If not and the original caller is a SIP element that allows FIX, the B2BUA MUST respond with a '202 Accepted' and retain the route set (including Contact) and CSeq number.It MUST then formulate a FIX request of its own to send upstream. van Bemmel Expires February 2, 2006 [Page 23] Internet-Draft A solution for the HERFP August 2005 For non-SIP elements, the B2BUA SHOULD use any suitable mapping onto a mechanism supported by such an element if possible. If no such mapping exists, the B2BUA SHOULD respond with a '603 Decline'. TBD: More 4.3.5. Forking proxy behavior Proxy behavior intended to solve HERFP SHOULD be configurable by local policy. This policy SHOULD define the set of status codes (the 'HERFP set') for which a FIX is attempted, which MAY be empty. It is foreseen that a future specification COULD define a mechanism to selectively disable HERFP behavior on a per-request basis. When the proxy receives a repairable error response which is in the 'HERFP set', it MUST treat the corresponding branch as if a '408 Request Timeout' was received and cancel Timer C for that INVITE transaction. For repairable responses in the 'HERFP set' a FIX request should be sent according to the rules in Section 4.3.1. When a 200 response to a FIX is received, the proxy MUST process the INVITE contained in the body. When a 202 response to a FIX is received, the proxy MUST start a timer R and store the CSeq -> branch (with Request URI used) relation in the response context. When a FIX request containing an INVITE body is received, the proxy SHOULD lookup the corresponding branch using the CSeq number. If it is not found, the proxy MUST respond with a 487. Otherwise it MUST cancel Timer R associated with that branch and process the INVITE body. When the proxy receives a 401 FIX response with a challenge, it SHOULD resubmit the FIX request with the challenge response and a new CSeq number (taken from the response context). If no credentials can be provided, it SHOULD be handled as a non-2xx response (see below). When the proxy receives a non-2xx response to its FIX request or Timer R fires, it SHOULD check if all transactions in the response context have now terminated (both FIX and INVITE client transactions) and no Timer R is pending. If so, the proxy SHOULD select a final response for the INVITE if none was sent yet, choosing amongst those received if available or '408 Request Timeout' (without to-tag) otherwise. To process a received modified INVITE body, the proxy SHOULD check van Bemmel Expires February 2, 2006 [Page 24] Internet-Draft A solution for the HERFP August 2005 the INVITE request provided against a security policy of allowed changes. When verified, the proxy MUST construct a new INVITE request that results from merging the modified INVITE with the original INVITE request, as specified in Section 4.3.2. To send the modified INVITE the proxy SHOULD set the Request-URI to the value that was used for the original INVITE on that branch (TBD: except when there was some issue with it), and send the result using a new client transaction. This client transaction SHOULD be associated with the response context. A timeout of a FIX transaction SHOULD be handled as if a 408 response was received. When the response context is destroyed (e.g. because a 2xx/6xx response is received on any of the INVITE branches or the original INVITE is CANCELed), all FIX transactions SHOULD be terminated in addition to CANCELing all remaining INVITE transactions. All remaining timer Rs SHOULD be canceled. A proxy that receives a FIX request or response for which it is not the final destination, MUST forward the request/response rather than process it locally. A FIX request MUST NOT be forwarded to more than one destination. 4.3.6. UAS behavior A UAS supporting this HERFP solution SHOULD generate a FIX request instead of a repairable error response to an incoming INVITE (both new and re-INVITEs), if the INVITE indicates the UAC supports this (i.e. it contains an 'Allow: FIX' header). If the UAS already sent a provisional response to the INVITE containing a to-tag, the FIX request SHOULD be sent within that dialog (i.e. have the same to-tag and an increasing CSeq number for multiple FIXes). The UAS SHOULD create a new client transaction and associate this with the INVITE servertransaction. If no 100 Trying for the INVITE was sent before, this MUST be done first to quench any retransmissions. Upon reception of a 2xx FIX response which matches a proceeding INVITE server transaction, the UAS SHOULD check if the response contains a valid modified INVITE request. If so, it MUST merge this request with the original INVITE (following the rules in Section 4.3.2), and MUST act as if the resulting INVITE was received instead. In case the UAS already sent a provisional response to the original INVITE containing a to-tag, the UAS MUST update relevant dialog state and use the same to-tag for any provisional or final responses to the patched INVITE. The UAS MAY use a different offer or answer than was sent for the original INVITE. van Bemmel Expires February 2, 2006 [Page 25] Internet-Draft A solution for the HERFP August 2005 4.4. Open issues o Identify common scenarios in which intermediate proxies would behave differently for the modified request, and bypassing them creates problems o There may be more elements that should be stripped from the response before sending it to the UAC, for security reasons or other o If the URI is the problem, it should be specified how the proxy would be involved in resolving it. o Should a proxy apply this solution also when the first element in a list of targets tried sequentially returns a repairable error response, or is it better to simply forward that response and stop forking? o Merging the request might break an integrity protection scheme that was applied by either the UAC or an intermediary element. o Should a header be defined to disable the use of this feature, e.g. for use by proxies that are aware of this HERFP feature and know that it would break a feature they provide? o Should FIX be considered as an INVITE-transaction instead, including an ACK from the proxy? o Should update RFC3841 with a request disposition regarding the application of HERFP fixes by proxies? o Definition of non-repairable responses not specified in RFC3261. o What about 3xx class responses? o Should a proxy that forwards to only 1 destination apply HERFP procedures too or not? o Should add a 'Content-Disposition: fix' to a FIX request? o An unaware intermediate element may see inconsistent SDP offer/ answers passing by, when the UAS sent a provisional response before a FIX was made. In some situations this might be an issue. o What happens if the modified INVITE requires a change of transport? van Bemmel Expires February 2, 2006 [Page 26] Internet-Draft A solution for the HERFP August 2005 5. Security Considerations An attacker that somehow learns the Call-ID, From-tag and Contact address for an ongoing call attempt (e.g. by intercepting an INVITE) could forge a FIX request and bomb the victim with it, resulting in a DoS attack. If the fixing of the selected response code involves significant computing (e.g. cryptographic calculations) and/or user interaction, this could effectively take out the UAC. To reduce the impact of such an attack, an UAC could put an upperlimit on the number of FIX requests accepted per call attempt, and ignore any requests beyond this limit. Alternatively, in some environments the UAC could respond with an authentication challenge. If the Identity header [10] is present, it can be used to verify the source of the FIX request. Some network configurations might depend on border proxies to strip certain confidential information from responses, such as IP addresses of intermediate elements (topology hiding), charging information, etc. The body of a FIX request would bypass such a stripping element, and thus potentially exposes sensitive information to the UAC. To avoid this, implementors should carefully consider which parts of the response to be fixed are needed by the UAC to compose a fix, and leave out any unnecessary (sensitive) information. van Bemmel Expires February 2, 2006 [Page 27] Internet-Draft A solution for the HERFP August 2005 6. IANA Considerations This document registers a new method name. 6.1. New Methods This document registers a new SIP method name, defined by the following information, which has been added to the method and response-code sub-registry under http://www.iana.org/assignments/sip-parameters Method Name: FIX Reference: [ XXXXXXX ] This table expands on tables 2 and 3 in SIP [2]; headers not mentioned in this table are not allowed +--------------------+-------+-------------------+ | Header | Where | FIX | +--------------------+-------+-------------------+ | Accept | R | o | | | | | | Accept-Encoding | R | o | | | | | | Accept-Language | R | o | | | | | | Allow | 405 | m | | | | | | Authorization | R | o | | | | | | Call-ID | c | m | | | | | | Contact | R | m (for proxy/UAS) | | | | | | Content-Encoding | | o | | | | | | Content-Length | R | m | | | | | | Content-Length | 200 | m | | | | | | Content-Type | R | m | | | | | | Content-Type | 200 | m | | | | | | CSeq | c | m | | | | | | Error-Info | R | o | | | | | van Bemmel Expires February 2, 2006 [Page 28] Internet-Draft A solution for the HERFP August 2005 | From | c | m | | | | | | Max-Forwards | R | m | | | | | | MIME-Version | | o | | | | | | Retry-After | 413 | o | | | | | | Require | R | o | | | | | | Timestamp | | o | | | | | | To | c | m | | | | | | Unsupported | 420 | m | | | | | | User-Agent | | o | | | | | | Via | c | m | | | | | | WWW-Authenticate | 407 | m | +--------------------+-------+-------------------+ Table 3: Usage of headers in FIX requests and responses This table lists allowed non-RFC3261 headers; headers not mentioned in this table are not allowed +--------------------+-------+-----+ | Header | Where | FIX | +--------------------+-------+-----+ | Identity | R | o | +--------------------+-------+-----+ Table 4: Usage of non-RFC3261 headers in FIX requests and responses van Bemmel Expires February 2, 2006 [Page 29] Internet-Draft A solution for the HERFP August 2005 7. Acknowledgements The author would like to thank Vijay Gurbani of Lucent Technologies for his valuable comments on an earlier version of this draft. This work is part of the Freeband AWARENESS project (http://awareness.freeband.nl). Freeband is sponsored by the Dutch government under contract BSIK 03025. van Bemmel Expires February 2, 2006 [Page 30] Internet-Draft A solution for the HERFP August 2005 8. References 8.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] 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. [3] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002. [4] Camarillo, G., Marshall, W., and J. Rosenberg, "Integration of Resource Management and Session Initiation Protocol (SIP)", RFC 3312, October 2002. 8.2. Informative References [5] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002. [6] Jennings, C., Peterson, J., and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, November 2002. [7] Donovan, S. and J. Rosenberg, "Session Timers in the Session Initiation Protocol (SIP)", RFC 4028, April 2005. [8] Mahy, R., "A Solution to the Heterogeneous Error Response Forking Problem (HERFP) in the Session Initiation Protocol (SIP)", draft-mahy-sipping-herfp-fix-00 (work in progress), July 2005. [9] Rosenberg, J., "Unifying Early Media, Manyfolks, And HERFP", draft-rosenberg-sip-unify-00 (work in progress), January 2002. [10] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", draft-ietf-sip-identity-05 (work in progress), May 2005. van Bemmel Expires February 2, 2006 [Page 31] Internet-Draft A solution for the HERFP August 2005 Author's Address Jeroen van Bemmel Lucent Technologies Larenseweg 50 Hilversum The Netherlands Email: jbemmel@lucent.com URI: http://www.lucent.com van Bemmel Expires February 2, 2006 [Page 32] Internet-Draft A solution for the HERFP August 2005 Intellectual Property Statement 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. Disclaimer of Validity 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. Copyright Statement Copyright (C) The Internet Society (2005). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. van Bemmel Expires February 2, 2006 [Page 33]