Internet DRAFT - draft-roach-sip-herfp-avoidance
draft-roach-sip-herfp-avoidance
SIP WG A. B. Roach
Internet-Draft R. Sparks
Expires: April 19, 2006 B. Campbell
Estacado Systems
October 16, 2005
An Extension to Avoid the Occurance of HERFP
draft-roach-sip-herfp-avoidance-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 19, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
The processing of SIP reqeusts by certain types of proxies can lead
to situations in which multiple non-sucessful responses are
generated, only one of which is ultimately reported to the originator
of the response. In many cases, these non-successful responses
indicate conditions that can be addressed by the requestor, and then
retried; therefore, the elision of them by proxies can lead to a
decrease in the rechability of certain network entites.
Roach, et al. Expires April 19, 2006 [Page 1]
Internet-Draft MSRP Relays October 2005
This document defines a mechanism that can be employed to avoid the
dropping of such requests with minimal implementation complexity.
Table of Contents
1. Conventions and Definitions . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. User Agent Client Behavior . . . . . . . . . . . . . . . . 3
3.2. User Agent Server Behavior . . . . . . . . . . . . . . . . 4
3.3. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . 4
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
6.1. Normative References . . . . . . . . . . . . . . . . . . . 5
6.2. Informative References . . . . . . . . . . . . . . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6
Intellectual Property and Copyright Statements . . . . . . . . . . 7
Roach, et al. Expires April 19, 2006 [Page 2]
Internet-Draft MSRP Relays October 2005
1. Conventions and Definitions
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 RFC 2119.
2. Introduction
RFC 3261 defines a behavior by which a proxy is allowed, upon receipt
of a request, to retarget it to multiple destinations (serially, in
parallel, or a combination of the two). This behavior is referred to
as "forking." If a proxy forks a request, it generally waits until
one of the multiple requests succeeds (with a 200-class response), or
until they all fail. Upon failure, only one error response -- the
one deemed "best" by the proxy -- is returned towards the UAC that
initiated the request. As a consequence, such forking can result in
a significant loss of information about the User Agent Servers that
were contacted. This behavior leads to a whole class of problems,
historically referred to as Heterogeneous Error Response Forking
Problems (HERFPs). These problems include the inablity to perform
HTTP-style authentication through forking proxies, difficulty in
negotiating many extensions, and forcing proxies to recurse on 300-
class responses (thus taking control of such retargeting out of the
hands of the users).
Several key architects of the SIP protocol have been working on this
problem for nearly five years. Even the most promising of such
solutions (draft-mahy-sipping-herfp-fix-00) result in a significant
increase in implementation complexity at proxies, and require
gyrations at the UAC to deal with relatively intimate knowledge of
"failed" branches of forked requests.
As a consequence of the stubborness of this class of problem and the
resultant complexity of any proposed solutions, the authors of this
document have concluded that HERFPs may be incurable, and should
instead be avoided. This document describes prophylactic measures by
which networks can prevent HERFPs altogether, instead of trying to
solve the symptoms that arise after such problems have already
occured.
3. Mechanism
3.1. User Agent Client Behavior
User Agent Clients that wish to require that the behavior exhibited
in this document can indicate such a requirement by including a
Roach, et al. Expires April 19, 2006 [Page 3]
Internet-Draft MSRP Relays October 2005
"Proxy-Require" header field containing a token of "rmt". ("rmt" is
an abbreviation for "Redirect Multiple Targets").
In general, however, proxies implementing the mechanism described in
this document are expected to apply it in all cases; the inclusion of
such a "Proxy-Require" header field is useful only if the UAC wishes
for requests through non-compliant proxies to actually fail.
User Agent Clients are generally required to handle 300-class
responses with multiple "Contact" header fields in an intelligent
manner, typically taking q-values into consideration. The mechanism
described in this document does nothing to change this fact; however,
it does emphasize the importance of such handling.
As with proxies, one common ordering mechanism for clients is to use
the qvalue parameter of targets obtained from Contact header fields.
Targets are processed from highest qvalue to lowest. Targets with
equal qvalues may be processed in parallel. Additionally, the
ordering mechanism may interact with the user to determine a
preferred behavior, providing finer-grained control over calls than
is possible with proxy recursion.
Note that this specification places no normative requirements on User
Agent Clients.
3.2. User Agent Server Behavior
No modification to the behavior of User Agent Servers is necessary
for this mechanism.
3.3. Proxy Behavior
Proxies compliant to this specification have two simple requirements
placed upon them:
o Proxies MUST NOT recurse on 300-class responses.
o Proxies MUST NOT fork requests of any kind.
The first requirement can be met by trivially proxying all 300-class
responses back towards the UAC instead of acting upon them.
One trivial way to meet the second requirement is as follows: proxies
form the target set as they normally do. If the target set contains
more than one target, the proxy responds to the request with a 300
response instead of proxying it. This response contains a Contact
header-field containing every target in the target set. Handling in
the case of target sets with zero or one targets remains unchanged.
Roach, et al. Expires April 19, 2006 [Page 4]
Internet-Draft MSRP Relays October 2005
The only additional normative behavior described for proxies
compliant to this specification is that such proxies are not required
to return a 420 response as a consequence of encountering a "Proxy-
Require" header field containing a token of "rmt".
4. Security Considerations
One salient difference between a proxy forking a request and
returning a 300-class response to the requestor is that responding
with a 300-class response provides the requestor with a full list of
targets, whereas forking the request reveals only the contact
information for the successful respondant. While providing this full
list of contacts is not likely to reveal private information (since
some subset of them will be revealed when the request completes), it
is possible that some parties may imagine a requirement for hiding
the full set of targets. If such is the case, this requirement can
be satisfied without requiring any additional protocol modification:
instead of returning the target set to the requestor, the server
instead creates a set of unique tokens -- one for each target -- and
uses them to create new URIs. The host portion of these URIs will
resolve to the server itself. When a request arrives for any of
these tokens, the server rewrites the URI to be the appropriate
target and proxies the request normally. This technique can be
performed either statefully (the token is simply a correlator), or
statelessly (the token is an encrypted form of the target URI,
possibly with an embedded timestamp to limit validity).
5. IANA Considerations
[TODO: Add "rmt" Proxy-Require tag]
6. References
6.1. Normative References
6.2. Informative References
Roach, et al. Expires April 19, 2006 [Page 5]
Internet-Draft MSRP Relays October 2005
Authors' Addresses
Adam Roach
Estacado Systems
17210 Campbell Rd.
Suite 250
Dallas, TX 75252
US
Phone: sip:adam@estacado.net
Email: adam@estacado.net
Robert Sparks
Estacado Systems
17210 Campbell Rd.
Suite 250
Dallas, TX 75252
US
Phone: sip:RjS@estacado.net
Email: RjS@estacado.net
Ben Campbell
Estacado Systems
17210 Campbell Rd.
Suite 250
Dallas, TX 75252
US
Phone: sip:ben@estacado.net
Email: ben@estacado.net
Roach, et al. Expires April 19, 2006 [Page 6]
Internet-Draft MSRP Relays October 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.
Roach, et al. Expires April 19, 2006 [Page 7]
