TOC |
|
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 October 28, 2002.
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document proposes a private SIP extension header used in conjunction with responses to REGISTER messages to provide a mechanism by which a registrar may inform a registering UA of a service route that the UA may use to request outbound services from the registrar's domain.
TOC |
TOC |
3GPP established a requirement for discovering home proxies during SIP registration and published this requirement in draft-garcia-sipping-3gpp-reqs[6]. Unlike many other network environments, the 3GPP network dynamically assigns a home service proxy to each address-of-record. This assignment may occur in conjunction with a REGISTER operation, or out-of-band as needed to support call services when the address-of-record has no registrations. This home service proxy may provide both inbound (UA terminated) and outbound (UA originated) services.
For inbound (UA terminated) session cases, the home proxy network routes messages having a request-URI targeting the address-of-record associated with the UA to the assigned home service proxy by using some sort of look-up-mechanism outside the scope of this document.
Outbound (UA originated) session cases raise another issue. Specifically, "How does the UA know which service proxy to use and how to get there?"
Several mechanisms have been proposed in list discussions, including:
This document discusses this final alternative: using a header in the REGISTER response to indicate a service route that the UA may wish to use if requesting services from the proxy network associated with the registrar generating the response.
Scenario
UA1----P1-----| |--R-------| | | | P2---| DBMS | | | UA2-----------| |--HSP-----|
In this scenario, we have a "home network" containing routing proxy P2, registrar R, home service proxy HSP, and database DBMS used by both R and HSP. P2 represents the "edge" of the home network from a SIP perspective, and might be called an "edge proxy". UA1 is an external UA behind proxy P1. UA1 discovers P1 via DHCP. UA2 is another UA on the Internet, and does not use a default outbound proxy. We do not show DNS elements in this diagram, but will assume their reasonable availability in the discussion. The mission is for UA1 to discover HSP so that outbound messages from UA1 may be routed (at the discretion of UA1) through HSP, thereby receiving outbound services from HSP.
TOC |
The proposed mechanism uses a private header "P-Service-Route" in the REGISTER response to indicate a service route that the UA may wish to use if requesting services from the proxy network associated with the registrar generating the response.
Simply put, the registrar generates a service route for the registering UA and returns it in the response to each successful REGISTER request. This service route has the form of a Route header that the registering UA may use to send messages through the service proxy selected by the registrar. The UA would use this route by inserting it as a preloaded Route header in messages originated by the UA intended for routing through the service proxy.
The mechanism by which the registrar constructs the header value is specific to the local implementation and outside the scope of this document.
TOC |
The P-Service-Route mechanism is applicable when:
TOC |
The syntax for the P-Service-Route header is:
P-Service-Route = "P-Service-Route" HCOLON 1#( p-sr-value)
p-sr-value = name-addr *( SEMI rr-param )
rr-param = generic-param
The allowable usage of headers is described in Tables 2 and 3 of SIPbis[1]. The following additions to this table are needed for P-Service-Route.
Addition of P-Service-Route to SIP Table 3:
Header field where proxy ACK BYE CAN INV OPT REG PRA _______________________________________________________________ P-Service-Route 2xx ar - - - - - o -
TOC |
The UA performs a register as usual. The register response may contain a P-Service-Route header. If so, the UA MAY store the value of the P-Service-Route header in an association with the address-of-record for which the REGISTER message had registered a contact. If the UA supports multiple address of records, it may be able to store multiple service routes, one per address-of-record. If the UA refreshes the registration, the stored value of the P-Service-Route is updated according to the P-Service-Route header of the latest 200 OK response. If there is no P-Service-Route header in the response, the UA clears any service route for that registrar previously stored by the UA.
Loose routes may interact with routing policy in interesting ways. The specifics of how the service 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 service route set is appended to any locally configured route needed to egress the access proxy chain. Systems designers must match the service routing policy of their nodes with the basic SIP routing poilicy in order to get a workable system.
- Note:
- A Fetching Bindings operation, i.e. no Contact header field is present in the REGISTER request, does not affect any stored value of P-Service-Route.
The UA MAY choose to exercise a service route for future messages associated with a given address-of-record for which a service route is known. If so, it appends the given service route to any locally required Route headers, and uses the result as a preloaded Route header in outgoing messages. The UA MUST preserve the order, in case there is more than one P-Service-Route header or element.
The P-Service-Route header is generally treated like any other unknown header by intermediate proxies. They simply forward it on towards the destination.
There is an question of whether proxies processing a REGISTER response may add themselves to the route set in the P-Service-Route header. While this would enable dynamic construction of service routes, it has two significant problems. The first is one of transparency, as seen by the registrar: Intermediate proxies could add themselves without the knowledge or consent of the registrar. The second problem is interaction with end-to-end security. If the registrar uses S/MIME techniques to protect the REGISTER response, such additions would be visible to the UA as "man in the middle" alterations in the response. Consequently, intermediate proxies SHOULD NOT alter the value of P-Service-Route in REGISTER responses, and if they do, acceptance of the alteration by the UA MUST NOT be required.
When a registrar receives a successful REGISTER message, it MAY choose to return one or more P-Service-Route header(s) in the 200 OK response. The determinations of whether to include these header(s) into the 200 OK response and what value(s) to insert are a matter of local policy and outside the scope of this document.
Having inserted a P-Service-Route header, the registrar returns the 200 OK response to the UA in accordance with standard procedures.
Certain network topologies MAY require a specific proxy (e.g. firewall proxy) to be traversed before the home service proxy. Thus, a registrar with specific knowledge of the network topology MAY return more than one P-Service-Route header or element in the 200 OK response; the order is specified as top-down, meaning the topmost P-Service-Route entry will be visited first. Such constructions are implementation specific and outside the scope of this document.
In general, the P-Service-Route header contains references to elements strictly within the administrative domain of the registrar and home service proxy. For example, consider a case where a user leaves the "home" network and roams into a "visited" network. The registar cannot be assumed to have knowledge of the topology of the visited network, so the P-Service-Route it returns contains elements only within the home network.
We present an example in the context of the scenario presented in the Background section earlier in this document. The network diagram is replicated below:
Scenario
UA1----P1-----| |--R-------| | | | P2---| DBMS | | | UA2-----------| |--HSP-----|
This example shows the message sequence for user agent UA1 registering to HOMEDOMAIN using registrar R. R returns a P-Service-Route indicating that UA1 may use home service proxy HSP to receive outbound services from HOMEDOMAIN.
Please note that the name UA1, HOMEDOMAIN, etc. are placeholders for approprate user and host names or addresses.
Message sequence for REGISTER returning P-Service-Route:
F1 Register UA1 -> P1 REGISTER sip:HOMEDOMAIN SIP/2.0 Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7 To: UA1@HOMEDOMAIN <sip:UA1@HOMEDOMAIN> From: UA1@HOMEDOMAIN <sip:UA1@HOMEDOMAIN>;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Contact: <sip:UA1@192.0.2.4> . . . F2 Register P1 -> P2 REGISTER sip:HOMEDOMAIN 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@HOMEDOMAIN <sip:UA1@HOMEDOMAIN> From: UA1@REGISTAR <sip:UA1@REGISTAR>;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Contact: <sip:UA1@192.0.2.4> . . . F3 Register P2 -> R REGISTER sip:HOMEDOMAIN 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@HOMEDOMAIN <sip:UA1@HOMEDOMAIN> From: UA1@HOMEDOMAIN <sip:UA1@HOMEDOMAIN>;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Contact: <sip:UA1@192.0.2.4> . . . F4 R executes Register R Stores: For <sip:UA1@HOMEDOMAIN> Contact = <sip:UA1@192.0.2.4> F5 R calculates Service Route In this example, R is statically configured to reference HSP as a service route, so P-Service-Route=<sip:HSP;lr> F6 Register Response r -> 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@HOMEDOMAIN <sip:UA1@HOMEDOMAIN> From: UA1@HOMEDOMAIN <sip:UA1@HOMEDOMAIN>;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Contact: <sip:UA1@192.0.2.4> P-Service-Route=<sip:HSP;lr> . . . F7 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@HOMEDOMAIN <sip:UA1@HOMEDOMAIN> From: UA1@HOMEDOMAIN <sip:UA1@HOMEDOMAIN>;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Contact: <sip:UA1@192.0.2.4> P-Service-Route=<sip:HSP;lr> . . . F8 Register Response P1 -> UA1 SIP/2.0 200 OK Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7 To: UA1@HOMEDOMAIN <sip:UA1@HOMEDOMAIN> From: UA1@HOMEDOMAIN <sip:UA1@HOMEDOMAIN>;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Contact: <sip:UA1@192.0.2.4> P-Service-Route=<sip:HSP;lr> . . . F9 UA1 stores service route for HOMEDOMAIN
This example shows the message sequence for an INVITE transaction originating from UA1 eventually arriving at UA2 using outbound services from HOMEDOMAIN, where UA1 has previously registered with HOMEDOMAIN and been informed of a service route through HSP. The service being provided by HOMEDOMAIN is a "logging" service, which provides a record of the call for UA1's use (perhaps the user of UA1 is an attorney who bills for calls to customers).
Message sequence for INVITE using P-Service-Route:
F1 INVITE UA1 -> P1 INVITE sip:UA2@HOMEDOMAIN SIP/2.0 Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7 To: Customer <sip:UA2@HOMEDOMAIN> From: Lawyer <sip:UA1@HOMEDOMAIN>;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 18 INVITE Contact: <sip:UA1@192.0.2.4> Route: <sip:HSP;lr> . . . Note: P1 is selected using the "outbound proxy" rule in UA1. F2 INVITE P1 -> P2 INVITE sip:UA2@HOMEDOMAIN 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: Customer <sip:UA2@HOMEDOMAIN> From: Lawyer <sip:UA1@HOMEDOMAIN>;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 18 INVITE Contact: <sip:UA1@192.0.2.4> Record-Route: <sip:P1;lr> Route: <sip:HSP;lr> . . . Note: P2 is selected using a DNS lookup on the domain of HSP. P1 has added itself to the Record Route. F3 INVITE P2 -> HSP INVITE sip:UA2@HOMEDOMAIN 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: Customer <sip:UA2@HOMEDMAIN> From: Lawyer <sip:UA1@HOMEDOMAIN>;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 18 INVITE Contact: <sip:UA1@192.0.2.4> Record-Route: <sip:P2;lr> Record-Route: <sip:P1;lr> Route: <sip:HSP;lr> . . . Note: HSP is selected using a DNS lookup for HSP within HOMEDOMAIN. P2 has addded itself to the Record Route. F4 HSP executes service HSP identifies the service to be executed from UA1's stored profile. The specifics of this are outside the scope of this document. HSP writes a record to "Lawyer"s log book, then looks up name "sip:UA2@HOMEDOMAIN and discovers that the current contact for UA2 is address 18.19.20.21. This will be the request-URI of the next-hop INVITE F5 INVITE HSP->P2 INVITE sip:UA2@18.19.20.21 Via: SIP/2.0/USP HSP:5060;branch=HSP10120323 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: Customer <sip:UA2@HOMEDOMAIN> From: UA1@HOMEDOMAIN <sip:UA1@HOMEDOMAIN>;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 18 INVITE Contact: <sip:UA1@192.0.2.4> Record-Route: <sip:HSP;lr> Record-Route: <sip:P2;lr> Record-Route: <sip:P1;lr> . . . Note: P2 selected by outbound proxy rule on HSP. INVITE propagates toward UA2 as usual.
TOC |
It is possible for proxies between the UA and the registrar during the REGISTER transaction to modify the value of P-Service-Route returned by the registrar, or to insert a P-Service-Route even when one was not returned by the registrar. It is also possible for proxies on the INVITE path to execute many different attacks. It is therefore desirable to apply transitive mutual authentication using sips: or other available mechanisms in order to prevent such attacks.
The "sips:" URI as defined in [1] defines a mechanism by which a UA may request transport-level message integrity and mutual authentication. Since there is no requirement for proxies to modify message, S/MIME signed bodies may be used to provide end-to-end protection for the returned value.
Systems using P-Service-Route SHOULD provide hop-by-hop message integrity and mutual authentication. UAs SHOULD request this support by using a "sips:" URI. Registrars returning a P-Service-Route SHOULD provide end-to-end protection on the return using S/MIME. UAs receiving P-Service-Route SHOULD authenticate attached S/MIME bodies.
TOC |
This document defines the SIP extension header "P-Service-Route" which should be included in the registry of SIP headers defined in SIP bis[1]. As required by the SIP change process draft-tsvarea-sipchange[7] the SIP extension header name "Service-Route" should also be registered in association with this extension. However, "Service-Route" MUST not be used until documented by a standards-track RFC. Expert review as required for this process is to be provided by the SIP Working Group.
TOC |
[1] | Rosenberg, J., "SIP: Session Initiation Protocol", draft-ietf-sip-rfc2543bis-09 (work in progress), March 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. |
[5] | Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999. |
TOC |
[6] | Garcia-Martin, MA., "3GPP Requirements On SIP", draft-garcia-sipping-3gpp-reqs-03 (work in progress), March 2002. |
[7] | Mankin, A., "SIP Change Process", draft-tsvarea-sipchange-01 (work in progress), March 2002. |
TOC |
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 |
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.
Funding for the RFC Editor function is currently provided by the Internet Society.