TOC 
SIP -- Session Initiation ProtocolD. Willis
Working Groupdynamicsoft Inc.
Internet-DraftB. Hoeneisen
Expires: November 3, 2002Nokia
 May 5, 2002

SIP Extension for Registering Non-Adjacent Contacts
draft-willis-sip-path-05

Status of this Memo

This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026.

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 November 3, 2002.

Copyright Notice

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

Abstract

The REGISTER function is used in a SIP system primarily to associate a temporary contact address with an address-of-record. This contact is generally in the form of a URI, such as Contact: <sip:alice@pc33.atlanta.com> and is generally dynamic and associated with the IP address or hostname of the SIP UA. The problem is that network topology may be that there are one or more SIP proxies between the UA and the registrar, such that any message 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, "Path" which provides such a mechanism.



 TOC 

Table of Contents




 TOC 

1. Background

3GPP established a requirement for discovering intermediate p roxies during SIP registration and published this requirement in draft-garcia-sipping-3gpp-reqs[5].

Scenario:

UA----P1-----P2-----P3------REGISTRAR

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

UA has a standing relationship with REGISTRAR, which it considers its "Home". How UA establishes this relationship is outside the scope of this document. UA discovers P1 as a result of a DHCP assignment or similar operation, also outside the scope of this document. REGISTRAR has a similar "default outbound proxy" relationship with P3.

Eventually, REGISTRAR or a service proxy closely related to it will receive a message for UA. It needs to know which proxies must be transited by that message in order to get back to UA. 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 proposed Path extension header allows accumulating and transmitting the list of proxies between UA 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 messages. The routing established by the Path header mechanism applies only to to requests transiting or originating in the home domain.



 TOC 

2. 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 set of intervening proxies MUST be visited by request messages between a home service proxy and the UA. That is, the proxy route between the home service proxy and the UA is the exact reverse of the proxy route between the UA and its 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.



 TOC 

3. Path Header Definition and Syntax

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

A Path header may be inserted into a REGISTER by any SIP node traversed by that message. Like the Route header, sequential Path headers are evaluated in the sequence in which they are present in the message, and Path header values may be combined into compound Path elements in a single Path header. 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 primary difference between Path and Record-Route is that Path applies to REGISTER and 200 OK responses to REGISTER. Record-Route doesn't, and can't be defined in REGISTER for reasons of backward compatibility.

The syntax for Path can be given as:

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

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

The allowable usage of headers is described in Tables 2 and 3 of SIPbis[2]. The following additions to this table are needed for Path.

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

Addition of Path to SIP Table 3:


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

        


 TOC 

4. Usage of Path Header

4.1 Procedures at the UA

The UA executes its register operation as usual. The response may contain a Path header. The general operation of the UA is to ignore the Path header in the response. It MAY choose to display the contents of the Path header 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.

It has been suggested that the UA MAY choose to store the contents of the Path header for future use as a preloaded Route for use when the UA wishes to send a SIP message that, for reasons of acquiring services in the home network, need to transit the service proxies in the home network. Such usage is explicitly outside the scope of this document.

The UA should include the option tag "Path" in any Supported headers.

4.2 Procedures at Intermediate Proxies

When a proxy processing a REGISTER request wishes to be on the path for future transmissions toward the UA originating that REGISTER request, the proxy inserts a URI for that proxy as the topmost element in the Path header (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 element 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.

Proxies processing a REGISTER response MUST NOT alter the value of any Path headers that may be present in the response.

4.3 Procedures at the Registrar

If a Path header exists in a successful REGISTER request, the registrar constructs an ordered list of route elements from the nodes listed in the Path elements, preserving the order as indicated in the Path header(s). The registrar then stores this route set in association with that contact and the addres-of-record indicated in the Register request (the "binding" as defined in RFC 2543[1]). The registrar copies the Path elements list as one or more Path headers into into the successful (200 OK) REGISTER response message.

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

4.4 Procedures at the Home Proxy

In the common SIP model, there is a home service proxy associated with the registrar for a user. Each incoming message 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 message should be retargeted. The home service proxy, in its basic mode of operation, rewrites the request-URI from the incoming message with the value of the registered contact and retransmits the message.

With the addition of Path, the home service proxy also copies the route set associated with the specific contact in the registrar database into the Route header(s) of the outgoing message as a preloaded route. This causes the outgoing message to transit the set of proxies that indicated that they were to be used in future messages to that contact by including themselves in the Path header on the REGISTER message.

Loose routes may interact with routing policy in interesting ways. The specifics of how the stored route set 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 route set is appended to any locally configured route needed to egress the service cluster. Systems designers must match the Path recording policy of their nodes with the routing poilicy in order to get a workable system.

4.5 Examples of Usage

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

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

Note that the names used, such as "UA1", are symbols for "real" host names or IP addresses. The substitution provides a shorter and hopefully more readable presentation. The node marked REGISTRAR is also a proxy and serves as a home service proxy.

4.6 Example of Mechanism in REGISTER Transaction

In this example, UA1 sends a REGISTER message to REGISTRAR. This message 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 messages 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 headers on REGISTER messages 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 SIP/2.0
   Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7
   To: UA1@REGISTRAR <sip:UA1@REGISTRAR>
   From: UA1@REGISTRAR <sip:UA1@REGISTRAR>;tag=456248
   Call-ID: 843817637684230@998sdasdh09
   CSeq: 1826 REGISTER
   Contact: <sip:UA1@192.0.2.4>
    . . .


F2 Register P1 -> P2

   REGISTER sip:REGISTRAR SIP/2.0
   Via: SIP/2.0/UDP P1:5060;branch=34ghi7ab04
   Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7
   To: UA1@REGISTRAR <sip:UA1@REGISTRAR>
   From: UA1@REGISTAR <sip:UA1@REGISTAR>;tag=456248
   Call-ID: 843817637684230@998sdasdh09
   CSeq: 1826 REGISTER
   Contact: <sip:UA1@192.0.2.4>
   Path: <sip:P1;lr>
    . . .

   Note: P1 has added itself to the Path.

F3 Register P2 -> P3

   REGISTER sip:REGISTRAR SIP/2.0
   Via: SIP/2.0/UDP P2:5060;branch=iokioukju908
   Via: SIP/2.0/UDP P1:5060;branch=34ghi7ab04
   Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7
   To: UA1@REGISTRAR <sip:UA1@REGISTRAR>
   From: UA1@REGISTRAR <sip:UA1@REGISTRAR>;tag=456248
   Call-ID: 843817637684230@998sdasdh09
   CSeq: 1826 REGISTER
   Contact: <sip:UA1@192.0.2.4>
   Path: <sip:P1;lr>
    . . .

   Note: P2 did NOT add itself to the Path. 

F4 Register P3 -> REGISTRAR

   REGISTER sip:REGISTRAR SIP/2.0
   Via: SIP/2.0/UDP P3:5060;branch=p3wer654363
   Via: SIP/2.0/UDP P2:5060;branch=iokioukju908
   Via: SIP/2.0/UDP P1:5060;branch=34ghi7ab04
   Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7
   To: UA1@REGISTRAR <sip:UA1@REGISTRAR>
   From: UA1@REGISTRAR <sip:UA1@REGISTRAR>;tag=456248
   Call-ID: 843817637684230@998sdasdh09
   CSeq: 1826 REGISTER
   Contact: <sip:UA1@192.0.2.4>
   Path: <sip:P3;lr>
   Path: <sip:P1;lr>
    . . .

   Note: P3 added itself to the Path.

F5 REGISTRAR executes Register

   REGISTRAR Stores:
   For UA1@REGISTRAR
   Contact = <sip:UA1@192.0.2.4>
   Stored Route Set = <sip:P3;lr>,<sip:P1;lr>


F6 Register Response REGISTRAR -> P3

   SIP/2.0 200 OK
   Via: SIP/2.0/UDP P3:5060;branch=p3wer654363
   Via: SIP/2.0/UDP P2:5060;branch=iokioukju908
   Via: SIP/2.0/UDP P1:5060;branch=34ghi7ab04
   Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7
   To: UA1@REGISTRAR <sip:UA1@REGISTRAR>
   From: UA1@REGISTRAR <sip:UA1@REGISTRAR>;tag=456248
   Call-ID: 843817637684230@998sdasdh09
   CSeq: 1826 REGISTER
   Contact: <sip:UA1@192.0.2.4>
   Path: <sip:P3;lr>,<sip:P1;lr>
    . . .

   Note: The Path header 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 P2:5060;branch=iokioukju908
   Via: SIP/2.0/UDP P1:5060;branch=34ghi7ab04
   Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7
   To: UA1@REGISTRAR <sip:UA1@REGISTRAR>
   From: UA1@REGISTRAR <sip:UA1@REGISTRAR>;tag=456248
   Call-ID: 843817637684230@998sdasdh09
   CSeq: 1826 REGISTER
   Contact: <sip:UA1@192.0.2.4>
   Path: <sip:P3;lr>,<sip:P1;lr>
    . . .


F8 Register Response P2 -> P1

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


F9 Register Response P1 -> UA1

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

          

4.7 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 retargetted INVITE along the Path towards UA1. Note that this example introduces foreign user agent UA2 (address "71.91.180.10") and foreign domain FOREIGNDOMAIN. 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@REGISTRAR SIP/2.0
   Via: SIP/2.0/UDP 71.91.180.10:5060;branch=e2i95c5st3R
   To: UA1@REGISTRAR <sip:UA1@REGISTRAR>
   From: UA2@FOREIGNDOMAIN <sip:UA2@FOREIGNDOMAIN>;tag=224497
   Call-ID: 48273181116@71.91.180.10
   CSeq: 29 INVITE
   Contact: <sip:UA2@71.91.180.10>
    . . .


F2 REGISTRAR processing

   REGISTRAR looks up name "UA1@REGISTRAR" and returns:
    - Contact = <sip:UA1@192.0.2.4>
    - Route Set = <sip:P3;lr>,<sip:P1;lr>

   Note: The Contact replaces the request-URI. The Route Set is pushed
   onto the Route stack (preloaded Route) of the outgoing INVITE
   request. The topmost Route is used for making the routing decision.


F3 Invite REGISTRAR  -> P3

   INVITE UA1@192.0.2.4 SIP/2.0
   Via: SIP/2.0/UDP 143.70.6.83:5060;branch=lj25C107a7b176
   Via: SIP/2.0/UDP 71.91.180.10:5060;branch=e2i95c5st3R
   To: UA1@REGISTRAR <sip:UA1@REGISTRAR>
   From: UA2@FOREIGNDOMAIN <sip:UA2@FOREIGNDOMAIN>;tag=224497
   Call-ID: 48273181116@71.91.180.10
   CSeq: 29 INVITE
   Contact: <sip:UA2@71.91.180.10>
   Route: <sip:P3;lr>,<sip:P1;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 P3:5060;branch=jasg7li7nc9e
   Via: SIP/2.0/UDP 143.70.6.83:5060;branch=lj25C107a7b176
   Via: SIP/2.0/UDP 71.91.180.10:5060;branch=e2i95c5st3R
   To: UA1@REGISTRAR <sip:UA1@REGISTRAR>
   From: UA2@FOREIGNDOMAIN <sip:UA2@FOREIGNDOMAIN>;tag=224497
   Call-ID: 48273181116@71.91.180.10
   CSeq: 29 INVITE
   Contact: <sip:UA2@71.91.180.10>
   Record-Route: <sip:P3;lr>
   Route: <sip:P1;lr>
    . . .

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

F5 Invite P1 -> UA1

   INVITE UA1@192.0.2.4 SIP/2.0
   Via: SIP/2.0/UDP P1:5060;branch=k5l1833o43p
   Via: SIP/2.0/UDP P3:5060;branch=jasg7li7nc9e
   Via: SIP/2.0/UDP 143.70.6.83:5060;branch=lj25C107a7b176
   Via: SIP/2.0/UDP 71.91.180.10:5060;branch=e2i95c5st3R
   To: UA1@REGISTRAR <sip:UA1@REGISTRAR>
   From: UA2@FOREIGNDOMAIN <sip:UA2@FOREIGNDOMAIN>;tag=224497
   Call-ID: 48273181116@71.91.180.10
   CSeq: 29 INVITE
   Contact: <sip:UA2@71.91.180.10>
   Record-Route: <sip:P1;lr>
   Record-Route: <sip:P3;lr>
    . . .

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

          


 TOC 

5. Security Considerations

There are few security considerations for this draft beyond those in SIPbis[2]. From a security perspective, the Path extension and its usage are identical to the Record-Route header 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 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.

5.1 Considerations in REGISTER Request Processing

Information accumulated in REGISTER processsing causes additional proxies to be included in future messages between the registrar's location and that of the UA. An attack that allowed an intruding proxy to add itself to this chain would allow the attacker to intercept future calls directed toward 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" is addressed adequately by the use of transport-layer integrity protection mechanisms such as TLS or IPSEC. Proxy insertion can be addressed by mutual authentication at the proxy layer, which can also be provided by TLS or IPSEC. The "sips:" URI class defined in [2] 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.

5.2 Considerations in REGISTER Response Processing

The data returned to the UA by the Path header 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, the UA may be able to detect node insertion attacks that involve inserting an proxy into the SIP routing chain. Of course, the attacker may try to alter returned Path headers, perhaps deleting self-references.

As specified, there is no requirement for proxies between the UA and the registrar to modify the Path header in the REGISTER response. Consequently, we may use an end-to-end protection technique. The S/MIME technique defined in [2] 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 unmodifed Path header is received.

In addtion to the hop-by-hop integrity protection and mutual authentication measures suggested for REGISTER request processing in the preceding section, systems using Path headers SHOULD implement end-to-end protection using S/MIME. More specifically, registrars returning a Path header SHOULD attach a signed S/MIME of the the response, and UAs receiving a REGISTER response containing a Path header SHOULD validate the message using the S/MIME technique. Furthermore, UAs receiving a Path header in a REGISTER response SHOULD render it to the user, or (where feasible) check it programmatically.



 TOC 

6. IANA Considerations

This document defines the SIP extension header name "Path", which IANA will add to the registry of SIP header names defined in SIPbis[2]

This document also defines the sip option tag "Path" which IANA will add to the registry of SIP option tags defined in SIPbis[2]



 TOC 

7. 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 service proxy with this technique in this document.



 TOC 

Normative References

[1] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999.
[2] Rosenberg, J., "SIP: Session Initiation Protocol", draft-ietf-sip-rfc2543bis-09 (work in progress), March 2002.
[3] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[4] Postel, J. and J. Reynolds, "Instructions to RFC Authors", RFC 2223, October 1997.


 TOC 

Non-Normative References

[5] Garcia-Martin, MA., "3GPP Requirements On SIP", draft-garcia-sipping-3gpp-reqs-03 (work in progress), March 2002.
[6] Mankin, A., "SIP Change Process", draft-tsvarea-sipchange-01 (work in progress), March 2002.


 TOC 

Authors' Addresses

  Dean Willis
  dynamicsoft Inc.
  5100 Tennyson Parkway
  Suite 1200
  Plano, TX 75028
  US
Phone:  +1 972 473 5455
EMail:  dwillis@dynamicsoft.com
URI:  http://www.dynamicsoft.com/
  
  Bernie Hoeneisen
  Nokia
  Helsinki, Hiomo 3/6
  P.O. Box 312
  00045 NOKIA Group
  Finland
Phone:  +358-40-821 9 831
EMail:  bernhard.honeisen@nokia.com, b.hoeneisen@ieee.org
URI:  http://www.nokia.com/


 TOC 

Full Copyright Statement

Acknowledgement