Network Working Group J. van Bemmel Internet-Draft Lucent Technologies Expires: March 18, 2006 September 14, 2005 A solution for the HERFP caused by forked SIP INVITE requests draft-jbemmel-sipping-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 March 18, 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 March 18, 2006 [Page 1] Internet-Draft A solution for the HERFP September 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. Formulation of the HERFP notification . . . . . . . . 13 3.2.3. Formulation of the modified INVITE request . . . . . . 14 3.2.4. Forwarding/routing of the modified INVITE request . . 14 4. Proposed solution . . . . . . . . . . . . . . . . . . . . . . 16 4.1. Outline . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.2. Argumentation . . . . . . . . . . . . . . . . . . . . . . 17 4.3. Detailed normative guidelines . . . . . . . . . . . . . . 18 4.3.1. Construction of a FIX request . . . . . . . . . . . . 18 4.3.2. UAC behavior . . . . . . . . . . . . . . . . . . . . . 20 4.3.3. B2BUA behavior . . . . . . . . . . . . . . . . . . . . 21 4.3.4. Forking proxy behavior . . . . . . . . . . . . . . . . 22 4.3.5. UAS behavior . . . . . . . . . . . . . . . . . . . . . 23 4.4. Example call flow . . . . . . . . . . . . . . . . . . . . 24 4.4.1. FIX forking proxy -> UAC . . . . . . . . . . . . . . . 25 4.5. Open issues . . . . . . . . . . . . . . . . . . . . . . . 25 5. Security Considerations . . . . . . . . . . . . . . . . . . . 27 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 6.1. New Methods . . . . . . . . . . . . . . . . . . . . . . . 28 6.2. New headers . . . . . . . . . . . . . . . . . . . . . . . 30 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 8.1. Normative References . . . . . . . . . . . . . . . . . . . 32 8.2. Informative References . . . . . . . . . . . . . . . . . . 32 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 33 Intellectual Property and Copyright Statements . . . . . . . . . . 34 van Bemmel Expires March 18, 2006 [Page 2] Internet-Draft A solution for the HERFP September 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 March 18, 2006 [Page 3] Internet-Draft A solution for the HERFP September 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 March 18, 2006 [Page 4] Internet-Draft A solution for the HERFP September 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 |------------------------------------------>| |<----------| | | Figure 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 March 18, 2006 [Page 5] Internet-Draft A solution for the HERFP September 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 March 18, 2006 [Page 6] Internet-Draft A solution for the HERFP September 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 forked 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 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: van Bemmel Expires March 18, 2006 [Page 7] Internet-Draft A solution for the HERFP September 2005 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 March 18, 2006 [Page 8] Internet-Draft A solution for the HERFP September 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 March 18, 2006 [Page 9] Internet-Draft A solution for the HERFP September 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) | | | | | 500 Server internal | When caused by the information in the | | error | INVITE | | | | | 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 March 18, 2006 [Page 10] Internet-Draft A solution for the HERFP September 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 (if not) likely to be | | | generated by all branches. | | | | | 408 Request Timeout | Not caused by something the UAC can fix. | | | | | 483 Too Many Hops | The UAC has little control over the number | | | of hops the request traverses. 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. | | | | | 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 | Never forwarded by proxies unless they can | | Unavailable | determine it will always be the case, so | | | notifying the UAC would imply that it is | | | not repairable. | +---------------------+---------------------------------------------+ 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 March 18, 2006 [Page 11] Internet-Draft A solution for the HERFP September 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 March 18, 2006 [Page 12] Internet-Draft A solution for the HERFP September 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. 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. van Bemmel Expires March 18, 2006 [Page 13] Internet-Draft A solution for the HERFP September 2005 3.2.3. Formulation of the modified INVITE request The modification to the INVITE request depends on the specific error 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. If the modified INVITE should contain the same headers added by proxies along the path of the original request, the UAC should not be made aware of these. In that case it would be necessary 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. This avoids complex merging by the proxy and several other issues. 3.2.4. 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 could be directly targeted at the element that sent the 'repairable' error response. However, it will not follow the same route (it will likely not go through the proxy, and possibly through additional elements). This could mean that it has additional headers or is missing headers that were present when the original INVITE was received. o If the modified INVITE is sent to the same request URI as originally, 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 van Bemmel Expires March 18, 2006 [Page 14] Internet-Draft A solution for the HERFP September 2005 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 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. If it is acceptible that the modified INVITE does not follow the same route, then sending it directly to the element that sent the repairable error seems easiest. If a request URI is used that is not an AoR, the modified request would (normally) not be forked again, at least not until it reaches the target element (which could be a forking proxy). van Bemmel Expires March 18, 2006 [Page 15] Internet-Draft A solution for the HERFP September 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 proxy reports the URI it used to forward the INVITE. The UAC may then decide to submit a modified INVITE to this contact directly. 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 stops timer C. It then 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/ sip), and the proxy adds a Contact header that contains the URI it used for the branch. 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). 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 The proxy retains the status code of the FIX request. If the best response algorithm selects a repairable error for which a FIX was sent, the proxy adds a 'FIX-Status' header with the response code received from the UAC. o The UAC formulates a modified version of its INVITE, taking into account the error response received. The UAC sends this INVITE using the route set and Contact received in the FIX request, as a new call attempt. o The UAS (or other element) that originally sent the repairable error now receives the modified INVITE. If the problem is solved van Bemmel Expires March 18, 2006 [Page 16] Internet-Draft A solution for the HERFP September 2005 it will likely generate zero or more provisional responses and a 2xx response, resulting in a new dialog. 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). 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 going via all intermediate elements. A 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). Using a request also enables the use of the Identity header [10] such that the UAC can determine if the FIX request comes from a trusted source. The UAC could also challenge the FIX. 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 that response. Other proxies further downstream could receive it when it is selected as best response, but since the FIX status is attached such a proxy would not attempt a second FIX unless the first one failed (e.g. due to timeout or transport failure). van Bemmel Expires March 18, 2006 [Page 17] Internet-Draft A solution for the HERFP September 2005 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. o An earlier version of this draft had the UAC send its modified INVITE in the body of the FIX response or a new FIX request, which the proxy would merge with the original. This is now considered too complex; the concession made is that the modified INVITE does not follow the same route, and may therefore have different headers upon arrival. The UAC could perhaps use Caller preferences [ref] and send the INVITE using the original Request URI. However, that would still not guarantee that it will follow the same route. 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 A proxy/UAS MUST calculate a Route set from the Record-Route headers found in the received INVITE request, taken in order and preserving any parameters. o If the route set is empty, the proxy/UAS MUST place the URI from the Contact header from the received INVITE 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 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 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 MUST add a Route header field containing the remainder of the route set values in order, including all parameters. The proxy/UAS 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 INVITE. van Bemmel Expires March 18, 2006 [Page 18] Internet-Draft A solution for the HERFP September 2005 o The From header MUST be set to a value that identifies the element constructing the FIX request. The tag parameter MUST be equal to the tag value from the From header in the received INVITE. o The URI in the To header MUST be set to URI of the From header in the received request. The tag MUST be omitted. 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 UAS the CSeq number MUST be set equal to the CSeq number received in the INVITE. o A Max-Forwards header with a recommended value of 70 MUST be added o A single Via header with a new unique branch ID MUST be added o A proxy MUST add a Contact header containing the information that was obtained from the location service for the branch that received the repairable response (in particular the request URI that was used). A UAS MUST add a Contact header reflecting an address at which it can be reached. The URI used in the Contact header SHOULD be a GRUU. If it is, a 'Supported: gruu' SHOULD be added. o If the request URI is not a GRUU and not directly addressable by the UAC, a proxy MUST add a single Record-Route header, pointing to itself (including a 'lr' parameter). If the Contact is not a GRUU, it is assumed that it is only reachable via the proxy. Therefore it must stay in the path to forward the request. This is not needed if the UAC is in the same private network. o An authentication service SHOULD be used, such that an Identity header is added. o Suitable headers for the body content MUST be added. In particular, a Content-Type: message/sip header MUST be added, as well as a Content-Length header. o A stripped version of the received/generated repairable response MUST be used as the body. As a minimum, all but the last Via header (which was inserted by the UAC) MUST be removed. A FIX request is sent as an out-of-dialog request. The reason for constructing a route set is that although the INVITE Contact URI van Bemmel Expires March 18, 2006 [Page 19] Internet-Draft A solution for the HERFP September 2005 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. Even if the proxy/UAS can determine that the Contact URI is a GRUU (e.g. through presence of the 'gruu' support), the route MUST be followed to avoid bypassing proxies that Record-Route the FIX. 4.3.2. 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. The UAC SHOULD use a GRUU in the Contact URI of every INVITE it sends; if applicable, it SHOULD add a 'Supported: gruu' header. 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 use the additional contact based on local policy. The UAC SHOULD verify that the response matches its original INVITE transaction. The UAC MAY challenge the FIX request using a '401 Unauthorized'. If the FIX contains an Identity header, the UAC SHOULD validate it. If not, the UAC MAY accept the FIX based on local policy, or respond with an '428 Use Identity Header' otherwise. After the above steps, the UAC checks if it is willing and able to construct a modified INVITE request. If so, it MUST send a 200 response. If not, it MUST send a '603 Decline'. If user interaction is required to decide and/or perform the fix, the UAC MUST respond with a '202 Accepted' promptly before engaging in user interaction. To attempt a fix, the UAC SHOULD formulate a modified INVITE request, taking into consideration the repairable error response that was received in the body of the FIX request. The UAC MUST construct a route set from the Record-Route headers contained in the received FIX, taken in order, according to the van Bemmel Expires March 18, 2006 [Page 20] Internet-Draft A solution for the HERFP September 2005 procedures defined in RFC3261. It MAY prepend any locally configured route set entries, but each entry MUST be unique. Constructing the route set enables proxies to Record-Route the FIX request in order to receive the modified INVITE too (when sent). An outbound proxy may have Record-Routed the FIX, so the UAC should be careful when appending additional entries. If the route set is empty, the UAC MUST place the Contact URI found in the FIX into the Request-URI. The UAC MUST NOT add a Route header field to the request. 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 UAC MUST place the Contact URI found in the FIX into the Request-URI and MUST include a Route header field containing the route set values in order, including all parameters. If the route set is not empty, and its first URI does not contain the lr parameter, the 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 UAC MUST add a Route header field containing the remainder of the route set values in order, including all parameters. The UAC MUST then place the Contact URI found in the FIX into the Route header field as the last value. Just like re-INVITEs, the modified INVITE is targeted at a specific UA (or proxy) instance rather than an address-of-record. For this reason, it will not be forked until it reaches this element. The UAC MAY add an Accept-Contact header in the modified INVITE request, e.g. using information from the Contact header received in the FIX. 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), it is up to local policy whether to cancel any modified attempts. When the UAC receives a repairable error containing a 'FIX-Status' with a status denoting success, it MUST NOT send a new INVITE as an attempt to resolve the problem. 4.3.3. 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 van Bemmel Expires March 18, 2006 [Page 21] Internet-Draft A solution for the HERFP September 2005 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 and the Contact. It MUST then formulate a FIX request of its own to send upstream. 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 '503 Service Unavailable'. TBD: More? 4.3.4. 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 a proxy receives a repairable error response which is in the 'HERFP set', it MUST stop Timer C for that INVITE transaction. It MUST associate a FIX status with the branch, initialized to the value of a 'FIX-Status' header contained in the response, or '503' if no such header exists. For repairable responses in the 'HERFP set' a FIX request should be sent according to the rules in Section 4.3.1, if the FIX status of the branch matches 4xx or 5xx (except 481). If not, a FIX request MUST NOT be sent. When the proxy receives a response to a FIX request, it MUST update the FIX status of the corresponding branch with the status code of the received response. 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 '481 Call does not exist' FIX response, it MUST CANCEL all remaining INVITE transactions and terminate any remaining FIX transactions. van Bemmel Expires March 18, 2006 [Page 22] Internet-Draft A solution for the HERFP September 2005 A timeout of a FIX transaction SHOULD be handled as if a 408 response was received. A transport error for a FIX transaction SHOULD be handled as if a 503 response was received. When the "best response selection algorithm" selects a response for which a FIX status exists, the proxy MUST add (or update) a 'FIX- Status: nnn' header to the response with 'nnn' set to the FIX status of the branch. The proxy SHOULD consider responses with a 2xx FIX status as 'better' than responses with a non-2xx FIX status. In case the selected best response is a 401 or 407 and contains aggregated authentication headers as described in RFC3261 section 16.7 point 7, the FIX status MUST also be aggregated. It MUST be set to 2xx when at least one of the corresponding branches has a 2xx FIX status. The proxy MUST NOT add authentication headers from branches with a 6xx FIX status. 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 (considered as if 487 was received) in addition to CANCELing all remaining INVITE transactions. 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.5. UAS behavior A UAS supporting this HERFP solution MAY generate a FIX request before responding with a repairable error response to an incoming INVITE (both new and re-INVITEs), if the INVITE indicates the UAC allows 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 with the from-tag and an increasing CSeq number taken from that dialog. The UAS SHOULD create a new client transaction and associate this with the INVITE servertransaction. If no provisional response for the INVITE was sent before, a 100 Trying MUST be sent first to quench any retransmissions. Upon reception of a response to the FIX, the UAS MUST add a 'FIX- Status: nnn' header to the repairable response, with 'nnn' set to the van Bemmel Expires March 18, 2006 [Page 23] Internet-Draft A solution for the HERFP September 2005 status code of the FIX response. It MUST then submit this response to the original INVITE server transaction. 4.4. Example call flow To illustrate the workings of the proposed mechanism, this example shows how HERFP is solved for the call flow shown in Figure 1, assuming that UAC, UAS1 and UAS2 are all in the same private network. UAC Forking Proxy UAS1 UAS2 | INVITE | | | |---------->| | | | | INVITE | | | |-------------------------------->| | | | INVITE | | | |------------------------------------------>| | | 415 Unsupported Media Type | | | |<--------------------------------| | | | ACK | | | |-------------------------------->| | | FIX(415) | | | |<----------| | | | 200 OK | | | |---------->| | | | | 180 Ringing | | | 180 |<------------------------------------------| |<----------| | | | | | | | | INVITE (modified) | | |-------------------------------------------->| | | | 200 OK | | | 200 |<------------------------------------------| |<----------| | | | | ACK | | |------------------------------------------------------>| | | 180 Ringing | | |<--------------------------------------------| | | | | | | | 200 OK | | |<--------------------------------------------| | | | ACK | | |-------------------------------------------->| | | | BYE | | |------------------------------------------------------>| | | 200 | | |<------------------------------------------------------| Figure 2: Sample call flow illustrating the HERFP solution van Bemmel Expires March 18, 2006 [Page 24] Internet-Draft A solution for the HERFP September 2005 When the proxy receives the 415 repairable error, it formulates a FIX and sends it to the UAC. The UAC can repair it without user interaction so it responds with 200 OK, and formulates a modified INVITE. In the mean time the second branch returns 180 and then 200, which ends the response context at the proxy. The UAC attempts the modified INVITE which succeeds; the user then decides to end the dialog with UAS2 (e.g. a voice response system) and continues with UAS1. 4.4.1. FIX forking proxy -> UAC FIX sip:uac@example.com SIP/2.0 Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bKnashds8 Max-Forwards: 70 To: UAC From: Forking Proxy ;tag=630285328 Call-ID: a84b4c76e66710 CSeq: 1234 FIX Contact: Supported: gruu Identity: "..." Identity-Info: ;alg=rsa-sha1 Content-Type: message/sip Content-Length: 266 SIP/2.0 415 Unsupported media type Via: SIP/2.0/UDP uac.example.com;branch=z9hG4bKxy567ep ;received=192.0.2.2 To: Callee ;tag=a6c85cf From: UAC ;tag=630285328 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Content-Length: 0 Accept: application/sdp Note that the based64 encoded Identity value is omitted for clarity reasons. 4.5. Open issues 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 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? van Bemmel Expires March 18, 2006 [Page 25] Internet-Draft A solution for the HERFP September 2005 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 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 A Contact header normally contains an element's own URI, perhaps a different header should be used to convey the Request URI for the element that sent a repairable error. o Perhaps a new unique from-tag for the FIX is better than copying the one found in the INVITE? van Bemmel Expires March 18, 2006 [Page 26] Internet-Draft A solution for the HERFP September 2005 5. Security Considerations An attacker that intercepts an INVITE could forge a FIX request and cause the victim to INVITE a target UA of his choice. This cannot be detected, but the attacker's chance to succeed can be reduced by using request authentication for the FIX (e.g. requiring an Identity header or responding with a WWW-Authenticate challenge). Interception of the INVITE can be mitigated by using sips. An attacker that intercepts 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. 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 March 18, 2006 [Page 27] Internet-Draft A solution for the HERFP September 2005 6. IANA Considerations This document registers a new method name and a new SIP header. 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 | | | | | | Content-Language | R | o | | | | | | Content-Encoding | R | o | | | | | | Content-Length | R | m | | | | | | Content-Type | R | m | | | | | | CSeq | c | m | | | | | | Error-Info | R | o | | | | | | From | c | m | | | | | van Bemmel Expires March 18, 2006 [Page 28] Internet-Draft A solution for the HERFP September 2005 | Max-Forwards | R | m | | | | | | MIME-Version | R | o | | | | | | Proxy-Require | R | o | | | | | | Record-Route | R | o | | | | | | Retry-After | 413 | o | | | | | | Require | R | o | | | | | | Supported | | 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 | +--------------------+-------+-----+ | Allow-Events | | o | | | | | | Identity | R | o | +--------------------+-------+-----+ Table 4: Usage of non-RFC3261 headers in FIX requests and responses van Bemmel Expires March 18, 2006 [Page 29] Internet-Draft A solution for the HERFP September 2005 6.2. New headers This table expands on tables 2 and 3 in SIP [2], as amended by the changes described in Section 6.1. +------------+---------+---+---+---+---+---+---+---+---+---+---+----+ | Header | where | p | A | B | C | F | I | O | R | P | S | NO | | field | | r | C | Y | A | I | N | P | E | R | U | T | | | | o | K | E | N | X | V | T | G | A | B | | | | | x | | | | | | | | | | | +------------+---------+---+---+---+---+---+---+---+---+---+---+----+ | FIX-Status | 4xx,5xx | a | - | - | - | - | o | - | - | - | - | - | | | | m | | | | | | | | | | | +------------+---------+---+---+---+---+---+---+---+---+---+---+----+ Table 5: New SIP headers van Bemmel Expires March 18, 2006 [Page 30] Internet-Draft A solution for the HERFP September 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 March 18, 2006 [Page 31] Internet-Draft A solution for the HERFP September 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 March 18, 2006 [Page 32] Internet-Draft A solution for the HERFP September 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 March 18, 2006 [Page 33] Internet-Draft A solution for the HERFP September 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 March 18, 2006 [Page 34]