path: root/doc/rfc/rfc3327.txt

Network Working Group                                          D. Willis
Request for Comments: 3327                              dynamicsoft Inc.
Category: Standards Track                                   B. Hoeneisen
                                                                  Switch
                                                           December 2002


        Session Initiation Protocol (SIP) Extension Header Field
                 for Registering Non-Adjacent Contacts

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Abstract

   The REGISTER function is used in a Session Initiation Protocol (SIP)
   system primarily to associate a temporary contact address with an
   address-of-record.  This contact is generally in the form of a
   Uniform Resource Identifier (URI), such as Contact:
   <sip:alice@pc33.atlanta.com> and is generally dynamic and associated
   with the IP address or hostname of the SIP User Agent (UA).  The
   problem is that network topology may have one or more SIP proxies
   between the UA and the registrar, such that any request traveling
   from the user's home network to the registered UA must traverse these
   proxies.  The REGISTER method does not give us a mechanism to
   discover and record this sequence of proxies in the registrar for
   future use.  This document defines an extension header field, "Path"
   which provides such a mechanism.














Willis & Hoeneisen          Standards Track                     [Page 1]
^L
RFC 3327          Path Extension Header Field for SIP      December 2002


Table of Contents

   1.    Background . . . . . . . . . . . . . . . . . . . . . . . . .  2
   2.    Terminology  . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.    Applicability Statement  . . . . . . . . . . . . . . . . . .  3
   4.    Path Header Field Definition and Syntax  . . . . . . . . . .  3
   5.    Usage of Path Header Field . . . . . . . . . . . . . . . . .  5
   5.1   Procedures at the UA . . . . . . . . . . . . . . . . . . . .  5
   5.2   Procedures at Intermediate Proxies . . . . . . . . . . . . .  5
   5.3   Procedures at the Registrar  . . . . . . . . . . . . . . . .  6
   5.4   Procedures at the Home Proxy . . . . . . . . . . . . . . . .  6
   5.5   Examples of Usage  . . . . . . . . . . . . . . . . . . . . .  7
   5.5.1 Example of Mechanism in REGISTER Transaction . . . . . . . .  7
   5.5.2 Example of Mechanism in INVITE Transaction . . . . . . . . . 11
   6.    Security Considerations  . . . . . . . . . . . . . . . . . . 13
   6.1   Considerations in REGISTER Request Processing  . . . . . . . 13
   6.2   Considerations in REGISTER Response Processing . . . . . . . 14
   7.    IANA Considerations  . . . . . . . . . . . . . . . . . . . . 15
   8.    Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
         Normative References . . . . . . . . . . . . . . . . . . . . 16
         Non-Normative References . . . . . . . . . . . . . . . . . . 16
         Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 16
         Full Copyright Statement . . . . . . . . . . . . . . . . . . 17

1. Background

   3GPP established a requirement for discovering intermediate proxies
   during SIP registration and published this requirement in [5].

   Scenario:

   UA1----P1-----P2-----P3------REGISTRAR

   UA1 wishes to register with REGISTRAR.  However, due to network
   topology, UA1 must use P1 as an "outbound proxy", and all requests
   between UA1 and REGISTRAR must also traverse P1, P2, and P3 before
   reaching REGISTRAR.  Likewise, all requests between REGISTRAR and UA1
   must also traverse P3, P2, and P1 before reaching UA1.

   UA1 has a standing relationship with REGISTRAR.  How UA1 establishes
   this relationship is outside the scope of this document.  UA1
   discovers P1 as a result of configuration, DHCP assignment or other
   similar operation, also outside the scope of this document.
   REGISTRAR has a similar "default outbound proxy" relationship with
   P3.






Willis & Hoeneisen          Standards Track                     [Page 2]
^L
RFC 3327          Path Extension Header Field for SIP      December 2002


   Eventually, REGISTRAR or a "home proxy" (a proxy serving as the
   terminal point for routing an address-of-record) closely related to
   it will receive a request destined for UA1.  It needs to know which
   proxies must be transited by that request in order to get back to
   UA1.  In some cases, this information may be deducible from SIP
   routing configuration tables or from DNS entries.  In other cases,
   such as that raised by 3GPP, the information is not readily available
   outside of the SIP REGISTER transaction.

   The Path extension header field allows accumulating and transmitting
   the list of proxies between UA1 and REGISTRAR.  Intermediate nodes
   such as P1 may statefully retain Path information if needed by
   operational policy.  This mechanism is in many ways similar to the
   operation of Record-Route in dialog-initiating requests.  The routing
   established by the Path header field mechanism applies only to
   requests transiting or originating in the home domain.

2. Terminology

   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 BCP 14, RFC 2119 [3].

3. Applicability Statement

   The Path mechanism is applicable whenever there are intermediate
   proxies between a SIP UA and a SIP Registrar used by that UA where
   the following conditions are true:

   1. One or more of the intermediate proxies are visited by
      registration requests from the UA to the Registrar.
   2. The same intermediate proxies or a set of proxies known to the
      intermediate proxies must be traversed, in reverse order, by
      requests sent through a home proxy to the UA.  In the simplest
      form, the route between the home proxy and the UA is the exact
      inverse of the route between the UA and the route between the UA
      and the registrar.
   3. The network topology is such that the intermediate proxies which
      must be visited are NOT implied by SIP routing tables, DNS, or
      similar mechanisms.

4. Path Header Field Definition and Syntax

   The Path header field is a SIP extension header field with syntax
   very similar to the Record-Route header field.  It is used in
   conjunction with SIP REGISTER requests and with 200 class messages in
   response to REGISTER (REGISTER responses).




Willis & Hoeneisen          Standards Track                     [Page 3]
^L
RFC 3327          Path Extension Header Field for SIP      December 2002


   A Path header field MAY be inserted into a REGISTER by any SIP node
   traversed by that request.  Like the Route header field, sequential
   Path header fields are evaluated in the sequence in which they are
   present in the request, and Path header fields MAY be combined into
   compound Path header in a single Path header field.  The registrar
   reflects the accumulated Path back into the REGISTER response, and
   intermediate nodes propagate this back toward the originating UA.
   The originating UA is therefore informed of the inclusion of nodes on
   its registered Path, and MAY use that information in other capacities
   outside the scope of this document.

   The difference between Path and Record-Route is that Path applies to
   REGISTER and 200 class responses to REGISTER.  Record-Route doesn't,
   and can't be defined in REGISTER for reasons of backward
   compatibility.  Furthermore, the vector established by Record-Route
   applies only to requests within the dialog that established that
   Record-Route, whereas the vector established by Path applies to
   future dialogs.

   The syntax for Path is defined as follows:

   Path = "Path" HCOLON path-value *( COMMA path-value )

   path-value = name-addr *( SEMI rr-param )

   Note that the Path header field values conform to the syntax of a
   Route element as defined in [1].  As suggested therein, such values
   MUST include the loose-routing indicator parameter ";lr" for full
   compliance with [1].

   The allowable usage of header fields is described in Tables 2 and 3
   of SIP [1].  The following additions to this table are needed for
   Path.

   Support for the Path header field MAY be indicated by a UA by
   including the option-tag "path" in a Supported header field.

   Addition of Path to SIP Table 3:

      Header field          where   proxy ACK BYE CAN INV OPT REG
      ___________________________________________________________
      Path                    R       ar   -   -   -   -   -   o
      Path                   2xx       -   -   -   -   -   -   o








Willis & Hoeneisen          Standards Track                     [Page 4]
^L
RFC 3327          Path Extension Header Field for SIP      December 2002


5. Usage of Path Header Field

5.1 Procedures at the UA

   The UA executes its register operation as usual.  The response MAY
   contain a Path header field.  The general operation of the UA is to
   ignore the Path header field in the response.  It MAY choose to
   display the contents of the Path header field to the user or take
   other action outside the scope of this document.  The Path
   information in the REGISTER response lets the UA know what
   intermediate proxies were added during registration.  Examination of
   this information may be important from a security perspective, as
   such inspection might allow the UA to detect intermediate proxies
   that have inappropriately added themselves.

   The UA SHOULD include the option tag "path" as a header field value
   in all Supported header fields, and SHOULD include a Supported header
   field in all requests.

   The UA MAY include a Path header field in a request.  This is not
   broadly applicable and caution must be taken to insure proper
   function, as the Path header field inserted by the UA may have
   additional Path header field values appended by intermediate proxies.
   Such proxies are not aware that the Path header field value was
   inserted by a UA, and will treat it as if it had been inserted by a
   previously traversed proxy, which could result in unexpected routing
   behavior wherein the UA is asked to act as a proxy.

5.2 Procedures at Intermediate Proxies

   When a proxy processing a REGISTER request wishes to be on the path
   for future requests toward the UA originating that REGISTER request,
   the proxy inserts a URI for that proxy as the topmost value in the
   Path header field (or inserts a new topmost Path header) before
   proxying that request.  It is also possible for a proxy with specific
   knowledge of network topology to add a Path header field value
   referencing another node, thereby allowing construction of a Path
   which is discongruent with the route taken by the REGISTER request.
   Such a construction is implementation specific and outside the scope
   of this document.

   Intermediate proxies SHOULD NOT add a Path header field to a request
   unless the UA has indicated support for this extension with a
   Supported header field value.  If the UA has indicated support and
   the proxy requires the registrar to support the Path extension, then
   the proxy SHOULD insert a Requires header field value for this
   extension.  If the UA has not indicated support for the extension and
   the proxy requires support for it in the registrar, the proxy SHOULD



Willis & Hoeneisen          Standards Track                     [Page 5]
^L
RFC 3327          Path Extension Header Field for SIP      December 2002


   reject the request with a 421 response indicating a requirement for
   the extension.

   Proxies processing a REGISTER response SHOULD NOT alter any Path
   header field values that may be present in the response.  The
   registrar MAY protect the Path header field in the response by
   including it in a protected S/MIME body, and alterations of the Path
   by an intermediate proxy can therefore be detected by the UA as man-
   in-the-middle attacks.  Proxies SHOULD only consider altering the
   value of a Path header field in the REGISTER response if they have
   the credentials to correctly alter the S/MIME body to account for the
   change.

5.3 Procedures at the Registrar

   If a Path header field exists in a successful REGISTER request, the
   registrar constructs an ordered list of route elements (a path
   vector) from the nodes listed in the Path header field values,
   preserving the order as indicated in the Path header field values.
   The registrar then stores this path vector in association with that
   contact and the address-of-record indicated in the REGISTER request
   (the "binding" as defined in [1]).  The registrar copies the Path
   header field values into a Path header field in the successful (200
   class) REGISTER response.  In the event that the home proxy and
   registrar are not co-located, the registrar MAY apply a locally-
   determined transformation to the stored path vector.

   If a registrar receives a REGISTER request containing a Path header
   field and there is no indication of support for the extension in the
   UA (via a Supported header field), the registrar must rely on local
   policy in determining how to treat this request.  The recommended
   policy is for the registrar to reject the request with a 420 "Bad
   Extension" response indicating the Path extension.  This approach
   allows the UA to detect that an intermediate proxy has
   inappropriately added a Path header field.  However, the Path
   mechanism should technically work in the absence of UA support (at
   some compromise to security), so some registrars MAY choose to
   support the extension in the absence of a Supported header field
   value in the request.

5.4 Procedures at the Home Proxy

   In the common SIP model, there is a home proxy associated with the
   registrar for a user.  Each incoming request targeted to the public
   address-of-record for the user is routed to this proxy, which
   consults the registrar's database in order to determine the contact
   to which the request should be retargeted.  The home proxy, in its
   basic mode of operation, rewrites the request-URI from the incoming



Willis & Hoeneisen          Standards Track                     [Page 6]
^L
RFC 3327          Path Extension Header Field for SIP      December 2002


   request with the value of the registered contact and retransmits the
   request.

   With the addition of Path, the home proxy also copies the stored path
   vector associated with the specific contact in the registrar database
   into the Route header field of the outgoing request as a preloaded
   route.  This causes the outgoing request to transit the proxies that
   were included in the Path header field of the REGISTER request.

   In normal processing, the home proxy is the "terminal point" for the
   user's address-of-record (AOR).  Consequentially, the Route header
   field on the incoming request will have been exhausted in reaching
   the home proxy.  If it isn't, then things get interesting.  In the
   most common case, the home proxy generates the outgoing Route header
   field by inserting the stored path vector ahead of the Route header
   field values contained in the incoming request. This procedure may be
   altered by a local policy at the home proxy.

   Loose routes may interact with routing policy in interesting ways.
   The specifics of how the stored path vector integrates with any
   locally required default route and local policy are implementation
   dependent.  For example, some devices will use locally-configured
   explicit loose routing to reach a next-hop proxy, and others will use
   a default outbound-proxy routing rule.  However, for the result to
   function, the combination must provide valid routing in the local
   environment.  In general, the stored path vector is appended to any
   locally configured route needed to egress the service cluster.  The
   service proxy (or registrar, as noted earlier) MAY also transform the
   stored path vector as needed to provide correct functionality.
   Systems designers must match the Path recording policy of their nodes
   with the routing policy in order to get a workable system.

5.5 Examples of Usage

   Note that some header fields (e.g. Content-Length) and session
   descriptions are omitted to provide a shorter and hopefully more
   readable presentation. The node marked REGISTRAR is a registrar and a
   proxy and serves as a home proxy. Thus, in the DNS the domain
   EXAMPLEHOME.COM points to the same host as REGISTRAR.EXAMPLEHOME.COM.

5.5.1 Example of Mechanism in REGISTER Transaction

   As an example, we use the scenario from the Background section:

   UA1----P1-----P2----P3-----REGISTRAR






Willis & Hoeneisen          Standards Track                     [Page 7]
^L
RFC 3327          Path Extension Header Field for SIP      December 2002


   In this example, UA1 sends a REGISTER request to REGISTRAR.  This
   request transits its default outbound proxy P1, an intermediate proxy
   P2, and the firewall proxy for the home domain, P3, before reaching
   REGISTRAR.  Due to network topology and operational policy, P1 and
   and P3 need to be transited by requests from REGISTRAR or other nodes
   in the home network targeted to UA1.  P2 does not.  P1 and P3 have
   been configured to include themselves in Path header fields on
   REGISTER requests that they process.  UA1 has a current IP address of
   "192.0.2.4".

   Message sequence for REGISTER with Path:

   F1 Register UA1 -> P1

      REGISTER sip:REGISTRAR.EXAMPLEHOME.COM SIP/2.0
      Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7
      To: UA1 <sip:UA1@EXAMPLEHOME.COM>
      From: UA1 <sip:UA1@EXAMPLEHOME.COM>;tag=456248
      Call-ID: 843817637684230@998sdasdh09
      CSeq: 1826 REGISTER
      Contact: <sip:UA1@192.0.2.4>
      Supported: path
       . . .

   F2 Register P1 -> P2

      REGISTER sip:REGISTRAR.EXAMPLEHOME.COM SIP/2.0
      Via: SIP/2.0/UDP 112.68.155.4:5060;branch=z9hG4bK34ghi7ab04
      Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7
      To: UA1 <sip:UA1@EXAMPLEHOME.COM>
      From: UA1 <sip:UA1@EXAMPLEHOME.COM>;tag=456248
      Call-ID: 843817637684230@998sdasdh09
      CSeq: 1826 REGISTER
      Contact: <sip:UA1@192.0.2.4>
      Supported: path
      Path: <sip:P1.EXAMPLEVISITED.COM;lr>
       . . .

      Note: P1 has added itself to the Path.












Willis & Hoeneisen          Standards Track                     [Page 8]
^L
RFC 3327          Path Extension Header Field for SIP      December 2002


   F3 Register P2 -> P3

      REGISTER sip:REGISTRAR.EXAMPLEHOME.COM SIP/2.0
      Via: SIP/2.0/UDP 178.73.76.230:5060;branch=z9hG4bKiokioukju908
      Via: SIP/2.0/UDP 112.68.155.4:5060;branch=z9hG4bK34ghi7ab04
      Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7
      To: UA1 <sip:UA1@EXAMPLEHOME.COM>
      From: UA1 <sip:UA1@EXAMPLEHOME.COM>;tag=456248
      Call-ID: 843817637684230@998sdasdh09
      CSeq: 1826 REGISTER
      Contact: <sip:UA1@192.0.2.4>
      Supported: path
      Path: <sip:P1.EXAMPLEVISITED.COM;lr>
       . . .

      Note: P2 did NOT add itself to the Path.

   F4 Register P3 -> REGISTRAR

      REGISTER sip:REGISTRAR.EXAMPLEHOME.COM SIP/2.0
      Via: SIP/2.0/UDP 19.31.97.3:5060;branch=z9hG4bKp3wer654363
      Via: SIP/2.0/UDP 178.73.76.230:5060;branch=z9hG4bKiokioukju908
      Via: SIP/2.0/UDP 112.68.155.4:5060;branch=z9hG4bK34ghi7ab04
      Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7
      To: UA1 <sip:UA1@EXAMPLEHOME.COM>
      From: UA1 <sip:UA1@EXAMPLEHOME.COM>;tag=456248
      Call-ID: 843817637684230@998sdasdh09
      CSeq: 1826 REGISTER
      Contact: <sip:UA1@192.0.2.4>
      Supported: path
      Path: <sip:P3.EXAMPLEHOME.COM;lr>,<sip:P1.EXAMPLEVISITED.COM;lr>
       . . .

      Note: P3 added itself to the Path.

   F5 REGISTRAR executes Register

      REGISTRAR Stores:
      For UA1@EXAMPLEHOME.COM
      Contact: <sip:UA1@192.0.2.4>
      Supported: path
      Path: <sip:P3.EXAMPLEHOME.COM;lr>,<sip:P1.EXAMPLEVISITED.COM;lr>









Willis & Hoeneisen          Standards Track                     [Page 9]
^L
RFC 3327          Path Extension Header Field for SIP      December 2002


   F6 Register Response REGISTRAR -> P3

      SIP/2.0 200 OK
      Via: SIP/2.0/UDP 19.31.97.3:5060;branch=z9hG4bKp3wer654363
      Via: SIP/2.0/UDP 178.73.76.230:5060;branch=z9hG4bKiokioukju908
      Via: SIP/2.0/UDP 112.68.155.4:5060;branch=z9hG4bK34ghi7ab04
      Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7
      To: UA1 <sip:UA1@EXAMPLEHOME.COM>;tag=251077
      From: UA1 <sip:UA1@EXAMPLEHOME.COM>;tag=456248
      Call-ID: 843817637684230@998sdasdh09
      CSeq: 1826 REGISTER
      Contact: <sip:UA1@192.0.2.4>
      Supported: path
      Path: <sip:P3.EXAMPLEHOME.COM;lr>,<sip:P1.EXAMPLEVISITED.COM;lr>
       . . .

      Note: The Path header field in the response is identical to the
      one received in the REGISTER request.

   F7 Register Response P3 -> P2

      SIP/2.0 200 OK
      Via: SIP/2.0/UDP 178.73.76.230:5060;branch=z9hG4bKiokioukju908
      Via: SIP/2.0/UDP 112.68.155.4:5060;branch=z9hG4bK34ghi7ab04
      Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7
      To: UA1 <sip:UA1@EXAMPLEHOME.COM>;tag=251077
      From: UA1 <sip:UA1@EXAMPLEHOME.COM>;tag=456248
      Call-ID: 843817637684230@998sdasdh09
      CSeq: 1826 REGISTER
      Contact: <sip:UA1@192.0.2.4>
      Supported: path
      Path: <sip:P3.EXAMPLEHOME.COM;lr>,<sip:P1.EXAMPLEVISITED.COM;lr>
       . . .

   F8 Register Response P2 -> P1

      SIP/2.0 200 OK
      Via: SIP/2.0/UDP 112.68.155.4:5060;branch=z9hG4bK34ghi7ab04
      Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7
      To: UA1 <sip:UA1@EXAMPLEHOME.COM>;tag=251077
      From: UA1 <sip:UA1@EXAMPLEHOME.COM>;tag=456248
      Call-ID: 843817637684230@998sdasdh09
      CSeq: 1826 REGISTER
      Contact: <sip:UA1@192.0.2.4>
      Supported: path
      Path: <sip:P3.EXAMPLEHOME.COM;lr>,<sip:P1.EXAMPLEVISITED.COM;lr>
       . . .




Willis & Hoeneisen          Standards Track                    [Page 10]
^L
RFC 3327          Path Extension Header Field for SIP      December 2002


   F9 Register Response P1 -> UA1

      SIP/2.0 200 OK
      Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7
      To: UA1 <sip:UA1@EXAMPLEHOME.COM>;tag=251077
      From: UA1 <sip:UA1@EXAMPLEHOME.COM>;tag=456248
      Call-ID: 843817637684230@998sdasdh09
      CSeq: 1826 REGISTER
      Contact: <sip:UA1@192.0.2.4>
      Supported: path
      Path: <sip:P3.EXAMPLEHOME.COM;lr>,<sip:P1.EXAMPLEVISITED.COM;lr>
       . . .

5.5.2 Example of Mechanism in INVITE Transaction

   This example shows the message sequence for an INVITE transaction
   originating from UA2 eventually arriving at UA1.  REGISTRAR inserts a
   preloaded Route toward UA1 and retargets the request by replacing the
   request URI with the registered Contact.  It then sends the
   retargeted INVITE along the Path towards UA1.  Note that this example
   introduces foreign user agent UA2 (address "71.91.180.10") and
   foreign domain FOREIGN.ELSEWHERE.ORG.  We have extended the diagram
   from the previous example by adding UA2, and by showing P2 out-of-
   line indicating that it did not include itself in the path during
   registration.

   Scenario

         UA1----P1---------P3-----REGISTRAR
                     |               |
                     P2              |
                                     |
         UA2--------------------------

   Message sequence for INVITE using Path:

   F1 Invite UA2 -> REGISTRAR

      INVITE UA1@EXAMPLEHOME.COM SIP/2.0
      Via: SIP/2.0/UDP 71.91.180.10:5060;branch=z9hG4bKe2i95c5st3R
      To: UA1 <sip:UA1@EXAMPLEHOME.COM>
      From: UA2 <sip:UA2@FOREIGN.ELSEWHERE.ORG>;tag=224497
      Call-ID: 48273181116@71.91.180.10
      CSeq: 29 INVITE
      Contact: <sip:UA2@71.91.180.10>
       . . .





Willis & Hoeneisen          Standards Track                    [Page 11]
^L
RFC 3327          Path Extension Header Field for SIP      December 2002


   F2 REGISTRAR processing

      REGISTRAR looks up name "UA1@EXAMPLEHOME.COM" and returns:
       - Contact = <sip:UA1@192.0.2.4>
       - Path vector = <sip:P3.EXAMPLEHOME.COM;lr>,
                       <sip:P1.EXAMPLEVISITED.COM;lr>

      Note: The Contact replaces the request-URI.  The path vector is
      pushed onto the Route stack (preloaded Route) of the outgoing
      INVITE request.  The topmost Route is used for making the
      routing decision (in conjunction with local policy).

   F3 Invite REGISTRAR  -> P3

      INVITE UA1@192.0.2.4 SIP/2.0
      Via: SIP/2.0/UDP 143.70.6.83:5060;branch=z9hG4bKlj25C107a7b176
      Via: SIP/2.0/UDP 71.91.180.10:5060;branch=z9hG4bKe2i95c5st3R
      To: UA1 <sip:UA1@EXAMPLEHOME.COM>
      From: UA2 <sip:UA2@FOREIGN.ELSEWHERE.ORG>;tag=224497
      Call-ID: 48273181116@71.91.180.10
      CSeq: 29 INVITE
      Contact: <sip:UA2@71.91.180.10>
      Route: <sip:P3.EXAMPLEHOME.COM;lr>,<sip:P1.EXAMPLEVISITED.COM;lr>
       . . .

      Note: In this example REGISTRAR does not want to stay on the
      Route and therefore does not insert a Record-Route.

   F4 Invite P3 -> P1

      INVITE UA1@192.0.2.4 SIP/2.0
      Via: SIP/2.0/UDP 19.31.97.3:5060;branch=z9hG4bKjasg7li7nc9e
      Via: SIP/2.0/UDP 143.70.6.83:5060;branch=z9hG4bKlj25C107a7b176
      Via: SIP/2.0/UDP 71.91.180.10:5060;branch=z9hG4bKe2i95c5st3R
      To: UA1 <sip:UA1@EXAMPLEHOME.COM>
      From: UA2 <sip:UA2@FOREIGN.ELSEWHERE.ORG>;tag=224497
      Call-ID: 48273181116@71.91.180.10
      CSeq: 29 INVITE
      Contact: <sip:UA2@71.91.180.10>
      Record-Route: <sip:P3.EXAMPLEHOME.COM;lr>
      Route: <sip:P1.EXAMPLEVISITED.COM;lr>
       . . .

      Note: P3 has added a Record-Route entry, indicating that it wants
      to be traversed by future messages in this dialog.






Willis & Hoeneisen          Standards Track                    [Page 12]
^L
RFC 3327          Path Extension Header Field for SIP      December 2002


   F5 Invite P1 -> UA1

      INVITE UA1@192.0.2.4 SIP/2.0
      Via: SIP/2.0/UDP 112.68.155.4:5060;branch=z9hG4bKk5l1833o43p
      Via: SIP/2.0/UDP 19.31.97.3:5060;branch=z9hG4bKjasg7li7nc9e
      Via: SIP/2.0/UDP 143.70.6.83:5060;branch=z9hG4bKlj25C107a7b176
      Via: SIP/2.0/UDP 71.91.180.10:5060;branch=z9hG4bKe2i95c5st3R
      To: UA1 <sip:UA1@EXAMPLEHOME.COM>
      From: UA2 <sip:UA2@FOREIGN.ELSEWHERE.ORG>;tag=224497
      Call-ID: 48273181116@71.91.180.10
      CSeq: 29 INVITE
      Contact: <sip:UA2@71.91.180.10>
      Record-Route: <sip:P1.EXAMPLEVISITED.COM;lr>
      Record-Route: <sip:P3.EXAMPLEHOME.COM;lr>
       . . .

      Note: P1 has added a Record-Route entry, indicating that it wants
      to be traversed by future messages in this dialog.

6. Security Considerations

   There are few security considerations for this document beyond those
   in SIP [1].  From a security perspective, the Path extension and its
   usage are identical to the Record-Route header field of basic SIP.
   Note that the transparency of the user expectations are preserved by
   returning the final Path to the originating UA -- that is, the UA is
   informed which additional proxies have been inserted into the path
   for the registration associated with that response.

   The Path header field accumulates information in a hop-by-hop manner
   during REGISTER processing.  The return information is essentially
   end-to-end, that is, it is not altered by intermediate proxies.  This
   leads to two slightly different security approaches.

6.1 Considerations in REGISTER Request Processing

   Information accumulated in REGISTER processing causes additional
   proxies to be included in future requests between the registrar's
   location and the UA.  An attack that allowed an intruding proxy to
   add itself to this chain would allow the attacker to intercept future
   calls intended for the UA.

   An attacker could conceivably alter the Path either by altering data
   "on the wire" or by other manipulations (such as impersonation) that
   would cause it to be included in the SIP routing chain (a "node
   insertion" attack).  Altering data "on the wire" may be addressed
   adequately by the use of transport-layer integrity protection
   mechanisms such as TLS or IPSEC.  Proxy insertion can be addressed by



Willis & Hoeneisen          Standards Track                    [Page 13]
^L
RFC 3327          Path Extension Header Field for SIP      December 2002


   mutual authentication at the proxy layer, which can also be provided
   by TLS or IPSEC.  The "sips:" URI class defined in [1] provides a
   mechanism by which a UA may request that intermediate proxies provide
   integrity protection and mutual authentication.

   Systems using the Path mechanism SHOULD use appropriate mechanisms
   (TLS, IPSEC, etc.) to provide message integrity and mutual
   authentication.  UAs SHOULD use "sips:" to request transitive
   protection.

   The registering UA SHOULD use S/MIME mechanisms to provide a
   protected copy of the original request to the registrar.  In this
   case, the UA SHOULD include a Supported header field with a value
   indicating support for the Path extension in the protected copy.
   Registrars receiving such as request MUST honor the Path extension
   only if support is indicated in the protected header field.  Further,
   they SHOULD compare the unprotected Supported header field with the
   protected Supported header field and take appropriate action in the
   event that an intermediate has altered the message to indicate
   support for Path when it was not indicated by the requesting UA.

6.2 Considerations in REGISTER Response Processing

   The data returned to the UA by the Path header field in the response
   to the REGISTER request is there to provide openness to the UA.  The
   registrar is telling the UA, "These are the intermediate proxies that
   will be included on future requests to you processed through me".  By
   inspection of this header field, the UA may be able to detect node
   insertion attacks that involve inserting a proxy into the SIP routing
   chain.  S/MIME techniques may be used to prevent alteration of this
   header field by intermediate proxies during response processing.

   As specified, there is no requirement for arbitrary proxies between
   the UA and the registrar to modify the Path header field in the
   REGISTER response.  Consequently, we may use an end-to-end protection
   technique.  The S/MIME technique defined in [1] provides an effective
   mechanism.  Using this technique, the registrar makes a copy of the
   complete response, signs it, and attaches it as a body to the
   response.  The UA may then verify this response, assuring an
   unmodified Path header field is received.

   In addition to the hop-by-hop integrity protection and mutual
   authentication measures suggested for REGISTER request processing in
   the preceding section, systems using Path header fields SHOULD
   implement end-to-end protection using S/MIME.  More specifically,
   registrars returning a Path header field SHOULD attach a signed
   S/MIME of the response, and UAs receiving a REGISTER response
   containing a Path header field SHOULD validate the message using the



Willis & Hoeneisen          Standards Track                    [Page 14]
^L
RFC 3327          Path Extension Header Field for SIP      December 2002


   S/MIME technique.  Furthermore, UAs receiving a Path header field in
   a REGISTER response SHOULD render it to the user, or (where feasible)
   check it programmatically.

7. IANA Considerations

   This document defines the SIP extension header field "Path", which
   the IANA has added to the registry of SIP header fields defined in
   SIP [1].

   This document also defines the SIP option tag "path" which IANA has
   added to the registry of SIP option tags defined in SIP [1].

   The following is the registration for the Path header field:

      RFC Number: RFC3327

      Header Field Name: Path

      Compact Form: none

   The following is the registration for the path option tag:

      RFC Number: RFC3327

      Option Tag: path

8. Acknowledgements

   Min Huang and Stinson Mathai, who put together the original proposal
   in 3GPP for this mechanism, and worked out most of the 3GPP
   procedures in 24.229.

   Keith Drage, Bill Marshall, and Miguel Angel Garcia-Martin who argued
   with everybody a lot about the idea as well as helped refine the
   requirements.

   Juha Heinanen, who argued steadfastly against standardizing the
   function of discovering the home proxy with this technique in this
   document.











Willis & Hoeneisen          Standards Track                    [Page 15]
^L
RFC 3327          Path Extension Header Field for SIP      December 2002


Normative References

   [1] 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.

   [2] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
       9, RFC 2026, October 1996.

   [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
       Levels", BCP 14, RFC 2119, March 1997.

   [4] Postel, J. and J. Reynolds, "Instructions to RFC Authors", RFC
       2223, October 1997.

Non-Normative References

   [5] Garcia-Martin, MA., "3GPP Requirements On SIP", Work in Progress.

   [6] Mankin, A., "SIP Change Process", Work in Progress.

Authors' Addresses

   Dean Willis
   dynamicsoft Inc.
   5100 Tennyson Parkway
   Suite 1200
   Plano, TX  75028
   US

   Phone: +1 972 473 5455
   EMail: dean.willis@softarmor.com
   URI:   http://www.dynamicsoft.com/


   Bernie Hoeneisen
   Switch
   Limmatquai 138
   CH-8001 Zuerich
   Switzerland

   Phone: +41 1 268 1515
   EMail: hoeneisen@switch.ch, b.hoeneisen@ieee.org
   URI:   http://www.switch.ch/







Willis & Hoeneisen          Standards Track                    [Page 16]
^L
RFC 3327          Path Extension Header Field for SIP      December 2002


Full Copyright Statement

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Willis & Hoeneisen          Standards Track                    [Page 17]
^L