[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/