diff options
Diffstat (limited to 'doc/rfc/rfc6140.txt')
| -rw-r--r-- | doc/rfc/rfc6140.txt | 1963 |
1 files changed, 1963 insertions, 0 deletions
diff --git a/doc/rfc/rfc6140.txt b/doc/rfc/rfc6140.txt new file mode 100644 index 0000000..addb43c --- /dev/null +++ b/doc/rfc/rfc6140.txt @@ -0,0 +1,1963 @@ + + + + + + +Internet Engineering Task Force (IETF) A.B. Roach +Request for Comments: 6140 Tekelec +Updates: 3680 March 2011 +Category: Standards Track +ISSN: 2070-1721 + + + Registration for Multiple Phone Numbers + in the Session Initiation Protocol (SIP) + +Abstract + + This document defines a mechanism by which a Session Initiation + Protocol (SIP) server acting as a traditional Private Branch Exchange + (PBX) can register with a SIP Service Provider (SSP) to receive phone + calls for SIP User Agents (UAs). In order to function properly, this + mechanism requires that each of the Addresses of Record (AORs) + registered in bulk map to a unique set of contacts. This requirement + is satisfied by AORs representing phone numbers regardless of the + domain, since phone numbers are fully qualified and globally unique. + This document therefore focuses on this use case. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6140. + +Copyright Notice + + Copyright (c) 2011 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + + + + +Roach Standards Track [Page 1] + +RFC 6140 Globally Identifiable Number Routing March 2011 + + + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction ....................................................3 + 2. Constraints .....................................................3 + 3. Terminology and Conventions .....................................4 + 4. Mechanism Overview ..............................................5 + 5. Registering for Multiple Phone Numbers ..........................5 + 5.1. SIP-PBX Behavior ...........................................5 + 5.2. Registrar Behavior .........................................6 + 5.3. SIP URI "user" Parameter Handling ..........................8 + 6. SSP Processing of Inbound Requests ..............................8 + 7. Interaction with Other Mechanisms ...............................9 + 7.1. Globally Routable User Agent URIs (GRUU) ...................9 + 7.1.1. Public GRUUs ........................................9 + 7.1.2. Temporary GRUUs ....................................11 + 7.2. Registration Event Package ................................16 + 7.2.1. SIP-PBX Aggregate Registration State ...............16 + 7.2.2. Individual AOR Registration State ..................16 + 7.3. Client-Initiated (Outbound) Connections ...................18 + 7.4. Non-Adjacent Contact Registration (Path) and + Service-Route Discovery ...................................19 + 8. Examples .......................................................20 + 8.1. Usage Scenario: Basic Registration ........................20 + 8.2. Usage Scenario: Using Path to Control Request URI .........22 + 9. IANA Considerations ............................................24 + 9.1. New SIP Option Tag ........................................24 + 9.2. New SIP URI Parameters ....................................25 + 9.2.1. 'bnc' SIP URI Parameter ............................25 + 9.2.2. 'sg' SIP URI Parameter .............................25 + 9.3. New SIP Header Field Parameter ............................25 + 10. Security Considerations .......................................25 + 11. Acknowledgements ..............................................28 + 12. References ....................................................28 + 12.1. Normative References .....................................28 + 12.2. Informative References ...................................29 + Appendix A. Requirements Analysis .................................31 + + + + + + + + + + + +Roach Standards Track [Page 2] + +RFC 6140 Globally Identifiable Number Routing March 2011 + + +1. Introduction + + The Session Initiation Protocol (SIP) is an application-layer control + (signaling) protocol for creating, modifying, and terminating + sessions with one or more participants. One of SIP's primary + functions is providing rendezvous between users. By design, these + rendezvous have been provided through a combination of the server + look-up procedures defined in RFC 3263 [4] and the registrar + procedures described in RFC 3261 [3]. + + The intention of the original protocol design was that any user's AOR + (Address of Record) would be handled by the authority indicated by + the hostport portion of the AOR. The users would register individual + reachability information with this authority, which would then route + incoming requests accordingly. + + In actual deployments, some SIP servers have been deployed in + architectures that, for various reasons, have requirements to provide + dynamic routing information for large blocks of AORs, where all of + the AORs in the block were to be handled by the same server. For + purposes of efficiency, many of these deployments do not wish to + maintain separate registrations for each of the AORs in the block. + Thus, an alternate mechanism to provide dynamic routing information + for blocks of AORs is desirable. + + Although the use of SIP REGISTER request messages to update + reachability information for multiple users simultaneously is + somewhat beyond the original semantics defined for REGISTER requests + by RFC 3261 [3], this approach has seen significant deployment in + certain environments. In particular, deployments in which small to + medium SIP-PBX servers are addressed using E.164 numbers have used + this mechanism to avoid the need to maintain DNS entries or static IP + addresses for the SIP-PBX servers. + + In recognition of the momentum that REGISTER-based approaches have + seen in deployments, this document defines a REGISTER-based approach. + Since E.164-addressed UAs are very common today in SIP-PBX + environments, and since SIP URIs in which the user portion is an + E.164 number are always globally unique, regardless of the domain, + this document focuses on registration of SIP URIs in which the user + portion is an E.164 number. + +2. Constraints + + Within the problem space that has been established for this work, + several constraints shape our solution. These are defined in the + MARTINI requirements document [22] and are analyzed in Appendix A. + In terms of impact to the solution at hand, the following two + + + +Roach Standards Track [Page 3] + +RFC 6140 Globally Identifiable Number Routing March 2011 + + + constraints have the most profound effect: (1) The SIP-PBX cannot be + assumed to be assigned a static IP address; and (2) No DNS entry can + be relied upon to consistently resolve to the IP address of the SIP- + PBX. + +3. Terminology and Conventions + + 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]. + + Further, the term "SSP" is meant as an acronym for a "SIP Service + Provider," while the term "SIP-PBX" is used to indicate a SIP Private + Branch Exchange. + + Indented portions of the document, such as this one, form non- + normative, explanatory sections of the document. + + Although SIP is a text-based protocol, some of the examples in this + document cannot be unambiguously rendered without additional markup + due to the constraints placed on the formatting of RFCs. This + document uses the <allOneLine/> markup convention established in RFC + 4475 [17] to avoid ambiguity and meet the RFC layout requirements. + For the sake of completeness, the text defining this markup (Section + 2.1 of RFC 4475 [17]) is reproduced in its entirety below: + + Several of these examples contain unfolded lines longer than 72 + characters. These are captured between <allOneLine/> tags. The + single unfolded line is reconstructed by directly concatenating + all lines appearing between the tags (discarding any line feeds or + carriage returns). There will be no whitespace at the end of + lines. Any whitespace appearing at a fold-point will appear at + the beginning of a line. + + The following represent the same string of bits: + + Header-name: first value, reallylongsecondvalue, third value + + <allOneLine> + Header-name: first value, + reallylongsecondvalue + , third value + </allOneLine> + + + + + + + + +Roach Standards Track [Page 4] + +RFC 6140 Globally Identifiable Number Routing March 2011 + + + <allOneLine> + Header-name: first value, + reallylong + second + value, + third value + </allOneLine> + + Note that this is NOT SIP header-line folding, where different + strings of bits have equivalent meaning. + +4. Mechanism Overview + + The overall mechanism is achieved using a REGISTER request with a + specially formatted Contact URI. This document also defines an + option tag that can be used to ensure that a registrar and any + intermediaries understand the mechanism described herein. + + The Contact URI itself is tagged with a URI parameter to indicate + that it actually represents multiple phone-number-associated + contacts. + + We also define some lightweight extensions to the Globally Routable + UA URIs (GRUU) mechanism defined by RFC 5627 [20] to allow the use of + public and temporary GRUUs assigned by the SSP. + + Aside from these extensions, the REGISTER request itself is processed + by a registrar in the same way as normal registrations: by updating + its location service with additional AOR-to-Contact bindings. + + Note that the list of AORs associated with a SIP-PBX is a matter of + local provisioning at the SSP and the SIP-PBX. The mechanism defined + in this document does not provide any means to detect or recover from + provisioning mismatches (although the registration event package can + be used as a standardized means for auditing such AORs; see + Section 7.2.1). + +5. Registering for Multiple Phone Numbers + +5.1. SIP-PBX Behavior + + To register for multiple AORs, the SIP-PBX sends a REGISTER request + to the SSP. This REGISTER request varies from a typical REGISTER + request in two important ways. First, it MUST contain an option tag + of "gin" in both a "Require" header field and a "Proxy-Require" + header field. (The option tag "gin" is an acronym for "generate + implicit numbers".) Second, in at least one "Contact" header field, + it MUST include a Contact URI that contains the URI parameter "bnc" + + + +Roach Standards Track [Page 5] + +RFC 6140 Globally Identifiable Number Routing March 2011 + + + (which stands for "bulk number contact") and has no user portion + (hence no "@" symbol). A URI with a "bnc" parameter MUST NOT contain + a user portion. Except for the SIP URI "user" parameter, this URI + MAY contain any other parameters that the SIP-PBX desires. These + parameters will be echoed back by the SSP in any requests bound for + the SIP-PBX. + + Because of the constraints discussed in Section 2, the host portion + of the Contact URI will generally contain an IP address, although + nothing in this mechanism enforces or relies upon that fact. If the + SIP-PBX operator chooses to maintain DNS entries that resolve to the + IP address of his SIP-PBX via RFC 3263 resolution procedures, then + this mechanism works just fine with domain names in the "Contact" + header field. + + The "bnc" URI parameter indicates that special interpretation of the + Contact URI is necessary: instead of indicating the insertion of a + single Contact URI into the location service, it indicates that + multiple URIs (one for each associated AOR) should be inserted. + + Any SIP-PBX implementing the registration mechanism defined in this + document MUST also support the path mechanism defined by RFC 3327 + [10], and MUST include a 'path' option tag in the "Supported" header + field of the REGISTER request (which is a stronger requirement than + imposed by the path mechanism itself). This behavior is necessary + because proxies between the SIP-PBX and the registrar may need to + insert "Path" header field values in the REGISTER request for this + document's mechanism to function properly, and, per RFC 3327 [10], + they can only do so if the User Agent Client (UAC) inserted the + option tag in the "Supported" header field. In accordance with the + procedures defined in RFC 3327 [10], the SIP-PBX is allowed to ignore + the "Path" header fields returned in the REGISTER response. + +5.2. Registrar Behavior + + The registrar, upon receipt of a REGISTER request containing at least + one "Contact" header field with a "bnc" parameter, will use the value + in the "To" header field to identify the SIP-PBX for which + registration is being requested. It then authenticates the SIP-PBX + (e.g., using SIP digest authentication, mutual Transport Layer + Security (TLS) [18], or some other authentication mechanism). After + the SIP-PBX is authenticated, the registrar updates its location + service with a unique AOR-to-Contact mapping for each of the AORs + associated with the SIP-PBX. Semantically, each of these mappings + will be treated as a unique row in the location service. The actual + implementation may, of course, perform internal optimizations to + reduce the amount of memory used to store such information. + + + + +Roach Standards Track [Page 6] + +RFC 6140 Globally Identifiable Number Routing March 2011 + + + For each of these unique rows, the AOR will be in the format that the + SSP expects to receive from external parties (e.g., + "sip:+12145550102@ssp.example.com"). The corresponding contact will + be formed by adding to the REGISTER request's Contact URI a user + portion containing the fully qualified, E.164-formatted number + (including the preceding "+" symbol) and removing the "bnc" + parameter. Aside from the initial "+" symbol, this E.164-formatted + number MUST consist exclusively of digits from 0 through 9 and + explicitly MUST NOT contain any visual separator symbols (e.g., "-", + ".", "(", or ")"). For example, if the "Contact" header field + contains the URI <sip:198.51.100.3:5060;bnc>, then the contact value + associated with the aforementioned AOR will be + <sip:+12145550102@198.51.100.3:5060>. + + Although the SSP treats this registration as a number of discrete + rows for the purpose of re-targeting incoming requests, the renewal, + expiration, and removal of these rows is bound to the registered + contact. In particular, this means that REGISTER requests that + attempt to de-register a single AOR that has been implicitly + registered MUST NOT remove that AOR from the bulk registration. In + this circumstance, the registrar simply acts as if the UA attempted + to unregister a contact that wasn't actually registered (e.g., return + the list of presently registered contacts in a success response). A + further implication of this property is that an individual extension + that is implicitly registered may also be explicitly registered using + a normal, non-bulk registration (subject to SSP policy). If such a + registration exists, it is refreshed independently of the bulk + registration and is not removed when the bulk registration is + removed. + + A registrar that receives a REGISTER request containing a Contact URI + with both a "bnc" parameter and a user portion MUST NOT send a 200- + class (Success) response. If no other error is applicable, the + registrar can use a 400 (Bad Request) response to indicate this error + condition. + + Note that the preceding paragraph is talking about the user + portion of a URI: + + sip:+12145550100@example.com + ^^^^^^^^^^^^ + + A registrar compliant with this document MUST support the path + mechanism defined in RFC 3327 [10]. The rationale for support of + this mechanism is given in Section 5.1. + + + + + + +Roach Standards Track [Page 7] + +RFC 6140 Globally Identifiable Number Routing March 2011 + + + Aside from the "bnc" parameter, all URI parameters present on the + Contact URI in the REGISTER request MUST be copied to the contact + value stored in the location service. + + If the SSP servers perform processing based on User Agent + Capabilities (as defined in RFC 3840 [13]), they will treat any + feature tags present on a "Contact" header field with a "bnc" + parameter in its URI as applicable to all of the resulting AOR-to- + Contact mappings. Similarly, any option tags present on the REGISTER + request that indicate special handling for any subsequent requests + are also applicable to all of the AOR-to-Contact mappings. + +5.3. SIP URI "user" Parameter Handling + + This document does not modify the behavior specified in RFC 3261 [3] + for inclusion of the "user" parameter on Request URIs. However, to + avoid any ambiguity in handling at the SIP-PBX, the following + normative behavior is imposed on its interactions with the SSP. + + When a SIP-PBX registers with an SSP using a Contact URI containing a + "bnc" parameter, that Contact URI MUST NOT include a "user" + parameter. A registrar that receives a REGISTER request containing a + Contact URI with both a "bnc" parameter and a "user" parameter MUST + NOT send a 200-class (success) response. If no other error is + applicable, the registrar can use a 400 (Bad Request) response to + indicate this error condition. + + Note that the preceding paragraph is talking about the "user" + parameter of a URI: + + sip:+12145550100@example.com;user=phone + ^^^^^^^^^^ + + When a SIP-PBX receives a request from an SSP, and the Request URI + contains a user portion corresponding to an AOR registered using a + Contact URI containing a "bnc" parameter, then the SIP-PBX MUST NOT + reject the request (or otherwise cause the request to fail) due to + the absence, presence, or value of a "user" parameter on the Request + URI. + +6. SSP Processing of Inbound Requests + + In general, after processing the AOR-to-Contact mapping described in + the preceding section, the SSP proxy/registrar (or equivalent entity) + performs traditional proxy/registrar behavior, based on the mapping. + For any inbound SIP requests whose AOR indicates an E.164 number + assigned to one of the SSP's customers, this will generally involve + setting the target set to the registered contacts associated with + + + +Roach Standards Track [Page 8] + +RFC 6140 Globally Identifiable Number Routing March 2011 + + + that AOR and performing request forwarding as described in Section + 16.6 of RFC 3261 [3]. An SSP using the mechanism defined in this + document MUST perform such processing for inbound INVITE requests and + SUBSCRIBE requests to the "reg" event package (see Section 7.2.2) and + SHOULD perform such processing for all other method types, including + unrecognized SIP methods. + +7. Interaction with Other Mechanisms + + The following sections describe the means by which this mechanism + interacts with relevant REGISTER-related extensions currently defined + by the IETF. + +7.1. Globally Routable User Agent URIs (GRUU) + + To enable advanced services to work with UAs behind a SIP-PBX, it is + important that the GRUU mechanism defined by RFC 5627 [20] work + correctly with the mechanism defined by this document -- that is, + that user agents served by the SIP-PBX can acquire and use GRUUs for + their own use. + +7.1.1. Public GRUUs + + Support of public GRUUs is OPTIONAL in SSPs and SIP-PBXes. + + When a SIP-PBX registers a Bulk Number Contact (a contact with a + "bnc" parameter), and also invokes GRUU procedures for that contact + during registration, then the SSP will assign a public GRUU to the + SIP-PBX in the normal fashion. Because the URI being registered + contains a "bnc" parameter, the GRUU will also contain a "bnc" + parameter. In particular, this means that the GRUU will not contain + a user portion. + + When a UA registers a contact with the SIP-PBX using GRUU procedures, + the SIP-PBX provides to the UA a public GRUU formed by adding an "sg" + parameter to the GRUU parameter it received from the SSP. This "sg" + parameter contains a disambiguation token that the SIP-PBX can use to + route inbound requests to the proper UA. + + So, for example, when the SIP-PBX registers with the following + "Contact" header field: + + Contact: <sip:198.51.100.3;bnc>; + +sip.instance="<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>" + + the SSP may choose to respond with a "Contact" header field that + looks like this: + + + + +Roach Standards Track [Page 9] + +RFC 6140 Globally Identifiable Number Routing March 2011 + + + <allOneLine> + Contact: <sip:198.51.100.3;bnc>; + pub-gruu="sip:ssp.example.com;bnc;gr=urn: + uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"; + +sip.instance="<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>" + ;expires=7200 + </allOneLine> + + When its own UAs register using GRUU procedures, the SIP-PBX can then + add whatever device identifier it feels appropriate in an "sg" + parameter and present this value to its own UAs. For example, assume + the UA associated with the AOR "+12145550102" sent the following + "Contact" header field in its REGISTER request: + + Contact: <sip:line-1@10.20.1.17>; + +sip.instance="<urn:uuid:d0e2f290-104b-11df-8a39-0800200c9a66>" + + The SIP-PBX will add an "sg" parameter to the pub-gruu it received + from the SSP with a token that uniquely identifies the device + (possibly the URN itself; possibly some other identifier), insert a + user portion containing the fully qualified E.164 number associated + with the UA, and return the result to the UA as its public GRUU. The + resulting "Contact" header field sent from the SIP-PBX to the + registering UA would look something like this: + + <allOneLine> + Contact: <sip:line-1@10.20.1.17>; + pub-gruu="sip:+12145550102@ssp.example.com;gr=urn: + uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6;sg=00:05:03:5e:70:a6"; + +sip.instance="<urn:uuid:d0e2f290-104b-11df-8a39-0800200c9a66>" + ;expires=3600 + </allOneLine> + + When an incoming request arrives at the SSP for a GRUU corresponding + to a bulk number contact ("bnc"), the SSP performs slightly different + processing for the GRUU than it would for a URI without a "bnc" + parameter. When the GRUU is re-targeted to the registered bulk + number contact, the SSP MUST copy the "sg" parameter from the GRUU to + the new target. The SIP-PBX can then use this "sg" parameter to + determine to which user agent the request should be routed. For + example, the first line of an INVITE request that has been re- + targeted to the SIP-PBX for the UA shown above would look like this: + + INVITE sip:+12145550102@198.51.100.3;sg=00:05:03:5e:70:a6 SIP/2.0 + + + + + + + +Roach Standards Track [Page 10] + +RFC 6140 Globally Identifiable Number Routing March 2011 + + +7.1.2. Temporary GRUUs + + In order to provide support for privacy, the SSP SHOULD implement the + temporary GRUU mechanism described in this section. Reasons for not + doing so would include systems with an alternative privacy mechanism + that maintains the integrity of public GRUUs (i.e., if public GRUUs + are anonymized, then the anonymizer function would need to be capable + of providing -- as the anonymized URI -- a globally routable URI that + routes back only to the target identified by the original public + GRUU). + + Temporary GRUUs are used to provide anonymity for the party creating + and sharing the GRUU. Being able to correlate two temporary GRUUs as + having originated from behind the same SIP-PBX violates this + principle of anonymity. Consequently, rather than relying upon a + single, invariant identifier for the SIP-PBX in its UA's temporary + GRUUs, we define a mechanism whereby the SSP provides the SIP-PBX + with sufficient information for the SIP-PBX to mint unique temporary + GRUUs. These GRUUs have the property that the SSP can correlate them + to the proper SIP-PBX, but no other party can do so. To achieve this + goal, we use a slight modification of the procedure described in + Appendix A.2 of RFC 5627 [20]. + + The SIP-PBX needs to be able to construct a temp-gruu in a way that + the SSP can decode. In order to ensure that the SSP can decode + GRUUs, we need to standardize the algorithm for creation of temp- + gruus at the SIP-PBX. This allows the SSP to reverse the algorithm + in order to identify the registration entry that corresponds to the + GRUU. + + It is equally important that no party other than the SSP be capable + of decoding a temporary GRUU, including other SIP-PBXes serviced by + the SSP. To achieve this property, an SSP that supports temporary + GRUUs MUST create and store an asymmetric key pair: {K_e1,K_e2}. + K_e1 is kept secret by the SSP, while K_e2 is shared with the SIP- + PBXes via provisioning. + + All base64 encoding discussed in the following sections MUST use the + character set and encoding defined in Section 4 of RFC 4648 [8], + except that any trailing "=" characters are discarded on encoding and + added as necessary to decode. + + The following sections make use of the term "HMAC-SHA256-80" to + describe a particular Hashed Message Authentication Code (HMAC) + algorithm. In this document, HMAC-SHA256-80 is defined as the + application of the SHA-256 [24] secure hashing algorithm, truncating + the results to 80 bits by discarding the trailing (least-significant) + bits. + + + +Roach Standards Track [Page 11] + +RFC 6140 Globally Identifiable Number Routing March 2011 + + +7.1.2.1. Generation of "temp-gruu-cookie" by the SSP + + An SSP that supports temporary GRUUs MUST include a "temp-gruu- + cookie" parameter on all "Contact" header fields containing a "bnc" + parameter in a 200-class REGISTER response. This "temp-gruu-cookie" + MUST have the following properties: + + 1. It can be used by the SSP to uniquely identify the registration + to which it corresponds. + + 2. It is encoded using base64. This allows the SIP-PBX to decode it + into as compact a form as possible for use in its calculations. + + 3. It is of a fixed length. This allows for its extraction once the + SIP-PBX has concatenated a distinguisher onto it. + + 4. The temp-gruu-cookie MUST NOT be forgeable by any party. In + other words, the SSP needs to be able to examine the cookie and + validate that it was generated by the SSP. + + 5. The temp-gruu-cookie MUST be invariant during the course of a + registration, including any refreshes to that registration. This + property is important, as it allows the SIP-PBX to examine the + temp-gruu-cookie to determine whether the temp-gruus it has + issued to its UAs are still valid. + + The above properties can be met using the following algorithm, which + is non-normative. Implementors may chose to implement any algorithm + of their choosing for generation of the temp-gruu-cookie, as long as + it fulfills the five properties listed above. + + The registrar maintains a counter, I. This counter is 48 bits + long and initialized to zero. This counter is persistently + stored, using a back-end database or similar technique. When the + registrar creates the first temporary GRUU for a particular SIP- + PBX and instance ID (as defined by [20]), the registrar notes the + current value of the counter, I_i, and increments the counter in + the database. The registrar then maps I_i to the contact and + instance ID using the database, a persistent hash-map, or similar + technology. If the registration expires such that there are no + longer any contacts with that particular instance ID bound to the + GRUU, the registrar removes the mapping. Similarly, if the + temporary GRUUs are invalidated due to a change in Call-ID, the + registrar removes the current mapping from I_i to the AOR and + instance ID, notes the current value of the counter I_j, and + stores a mapping from I_j to the contact containing a "bnc" + parameter and instance ID. Based on these rules, the hash-map + + + + +Roach Standards Track [Page 12] + +RFC 6140 Globally Identifiable Number Routing March 2011 + + + will contain a single mapping for each contact containing a "bnc" + parameter and instance ID for which there is a currently valid + registration. + + The registrar maintains a symmetric key SK_a, which is regenerated + every time the counter rolls over or is reset. When the counter + rolls over or is reset, the registrar remembers the old value of + SK_a for a while. To generate a temp-gruu-cookie, the registrar + computes: + + SA = HMAC(SK_a, I_i) + temp-gruu-cookie = base64enc(I_i || SA) + + where || denotes concatenation. "HMAC" represents any suitably + strong HMAC algorithm; see RFC 2104 [1] for a discussion of HMAC + algorithms. One suitable HMAC algorithm for this purpose is HMAC- + SHA256-80. + +7.1.2.2. Generation of temp-gruu by the SIP-PBX + + According to Section 3.2 of RFC 5627 [20], every registration refresh + generates a new temp-gruu that is valid for as long as the contact + remains registered. This property is both critical for the privacy + properties of temp-gruu and is expected by UAs that implement the + temp-gruu procedures. Nothing in this document should be construed + as changing this fundamental temp-gruu property in any way. SIP- + PBXes that implement temporary GRUUs MUST generate a new temp-gruu + according to the procedures in this section for every registration or + registration refresh from GRUU-supporting UAs attached to the SIP- + PBX. + + Similarly, if the registration that a SIP-PBX has with its SSP + expires or is terminated, then the temp-gruu cookie it maintains with + the SSP will change. This change will invalidate all the temp-gruus + the SIP-PBX has issued to its UAs. If the SIP-PBX tracks this + information (e.g., to include <temp-gruu> elements in registration + event bodies, as described in RFC 5628 [9]), it can determine that + previously issued temp-gruus are invalid by observing a change in the + temp-gruu-cookie provided to it by the SSP. + + A SIP-PBX that issues temporary GRUUs to its UAs MUST maintain an + HMAC key: PK_a. This value is used to validate that incoming GRUUs + were generated by the SIP-PBX. + + + + + + + + +Roach Standards Track [Page 13] + +RFC 6140 Globally Identifiable Number Routing March 2011 + + + To generate a new temporary GRUU for use by its own UAs, the SIP-PBX + MUST generate a random distinguisher value: D. The length of this + value is up to implementors, but it MUST be long enough to prevent + collisions among all the temporary GRUUs issued by the SIP-PBX. A + size of 80 bits or longer is RECOMMENDED. See RFC 4086 [16] for + further considerations on the generation of random numbers in a + security context. After generating the distinguisher D, the SIP-PBX + MUST calculate: + + M = base64dec(SSP-cookie) || D + E = RSA-Encrypt(K_e2, M) + PA = HMAC(PK_a, E) + + Temp-Gruu-userpart = "tgruu." || base64(E) || "." || base64(PA) + + where || denotes concatenation. "HMAC" represents any suitably + strong HMAC algorithm; see RFC 2104 [1] for a discussion of HMAC + algorithms. One suitable HMAC algorithm for this purpose is HMAC- + SHA256-80. + + Finally, the SIP-PBX adds a "gr" parameter to the temporary GRUU that + can be used to uniquely identify the UA registration record to which + the GRUU corresponds. The means of generation of the "gr" parameter + are left to the implementor, as long as they satisfy the properties + of a GRUU as described in RFC 5627 [20]. + + One valid approach for generation of the "gr" parameter is + calculation of "E" and "A" as described in Appendix A.2 of RFC + 5627 [20] and forming the "gr" parameter as: + + gr = base64enc(E) || base64enc(A) + + Using this procedure may result in a temporary GRUU returned to the + registering UA by the SIP-PBX that looks similar to this: + + <allOneLine> + Contact: <sip:line-1@10.20.1.17> + ;temp-gruu="sip:tgruu.MQyaRiLEd78RtaWkcP7N8Q.5qVbsasdo2pkKw@ + ssp.example.com;gr=YZGSCjKD42ccxO08pA7HwAM4XNDIlMSL0HlA" + ;+sip.instance="<urn:uuid:d0e2f290-104b-11df-8a39-0800200c9a66>" + ;expires=3600 + </allOneLine> + + + + + + + + + +Roach Standards Track [Page 14] + +RFC 6140 Globally Identifiable Number Routing March 2011 + + +7.1.2.3. Decoding of temp-gruu by the SSP + + When the SSP proxy receives a request in which the user part begins + with "tgruu.", it extracts the remaining portion and splits it at the + "." character into E' and PA'. It discards PA'. It then computes E + by performing a base64 decode of E'. Next, it computes: + + M = RSA-Decrypt(K_e1, E) + + The SSP proxy extracts the fixed-length temp-gruu-cookie information + from the beginning of this M and discards the remainder (which will + be the distinguisher added by the SIP-PBX). It then validates this + temp-gruu-cookie. If valid, it uses it to locate the corresponding + SIP-PBX registration record and routes the message appropriately. + + If the non-normative, exemplary algorithm described in + Section 7.1.2.1 is used to generate the temp-gruu-cookie, then + this identification is performed by splitting the temp-gruu-cookie + information into its 48-bit counter I and 80-bit HMAC. It + validates that the HMAC matches the counter I and then uses + counter I to locate the SIP-PBX registration record in its map. + If the counter has rolled over or reset, this computation is + performed with the current and previous SK_a. + +7.1.2.4. Decoding of temp-gruu by the SIP-PBX + + When the SIP-PBX receives a request in which the user part begins + with "tgruu.", it extracts the remaining portion and splits it at the + "." character into E' and PA'. It then computes E and PA by + performing a base64 decode of E' and PA', respectively. Next, it + computes: + + PAc = HMAC(PK_a, E) + + where HMAC is the HMAC algorithm used for the steps in + Section 7.1.2.2. If this computed value for PAc does not match the + value of PA extracted from the GRUU, then the GRUU is rejected as + invalid. + + The SIP-PBX then uses the value of the "gr" parameter to locate the + UA registration to which the GRUU corresponds, and routes the message + accordingly. + + + + + + + + + +Roach Standards Track [Page 15] + +RFC 6140 Globally Identifiable Number Routing March 2011 + + +7.2. Registration Event Package + + Neither the SSP nor the SIP-PBX is required to support the + registration event package defined by RFC 3680 [12]. However, if + they do support the registration event package, they MUST conform to + the behavior described in this section and its subsections. + + As this mechanism inherently deals with REGISTER transaction + behavior, it is imperative to consider its impact on the registration + event package defined by RFC 3680 [12]. In practice, there will be + two main use cases for subscribing to registration data: learning + about the overall registration state for the SIP-PBX and learning + about the registration state for a single SIP-PBX AOR. + +7.2.1. SIP-PBX Aggregate Registration State + + If the SIP-PBX (or another interested and authorized party) wishes to + monitor or audit the registration state for all of the AORs currently + registered to that SIP-PBX, it can subscribe to the SIP registration + event package at the SIP-PBX's main URI -- that is, the URI used in + the "To" header field of the REGISTER request. + + The NOTIFY messages for such a subscription will contain a body that + contains one record for each AOR associated with the SIP-PBX. The + AORs will be in the format expected to be received by the SSP (e.g., + "sip:+12145550105@ssp.example.com"), and the contacts will correspond + to the mapped contact created by the registration (e.g., + "sip:+12145550105@98.51.100.3"). + + In particular, the "bnc" parameter is forbidden from appearing in the + body of a reg-event NOTIFY request unless the subscriber has + indicated knowledge of the semantics of the "bnc" parameter. The + means for indicating this support are out of scope of this document. + + Because the SSP does not necessarily know which GRUUs have been + issued by the SIP-PBX to its associated UAs, these records will not + generally contain the <temp-gruu> or <pub-gruu> elements defined in + RFC 5628 [9]. This information can be learned, if necessary, by + subscribing to the individual AOR registration state, as described in + Section 7.2.2. + +7.2.2. Individual AOR Registration State + + As described in Section 6, the SSP will generally re-target all + requests addressed to an AOR owned by a SIP-PBX to that SIP-PBX + according to the mapping established at registration time. Although + policy at the SSP may override this generally expected behavior, + proper behavior of the registration event package requires that all + + + +Roach Standards Track [Page 16] + +RFC 6140 Globally Identifiable Number Routing March 2011 + + + "reg" event SUBSCRIBE requests are processed by the SIP-PBX. As a + consequence, the requirements on an SSP for processing registration + event package SUBSCRIBE requests are not left to policy. + + If the SSP receives a SUBSCRIBE request for the registration event + package with a Request URI that indicates an AOR registered via the + "Bulk Number Contact" mechanism defined in this document, then the + SSP MUST proxy that SUBSCRIBE to the SIP-PBX in the same way that it + would proxy an INVITE bound for that AOR, unless the SSP has and can + maintain a copy of complete, accurate, and up-to-date information + from the SIP-PBX (e.g., through an active back-end subscription). + + If the Request URI in a SUBSCRIBE request for the registration event + package indicates a contact that is registered by more than one SIP- + PBX, then the SSP proxy will fork the SUBSCRIBE request to all the + applicable SIP-PBXes. Similarly, if the Request URI corresponds to a + contact that is both implicitly registered by a SIP-PBX and + explicitly registered directly with the SSP proxy, then the SSP proxy + will semantically fork the SUBSCRIBE request to the applicable SIP- + PBX or SIP-PBXes and to the registrar function (which will respond + with registration data corresponding to the explicit registrations at + the SSP). The forking in both of these cases can be avoided if the + SSP has and can maintain a copy of up-to-date information from the + PBXes. + + Section 4.9 of RFC 3680 [12] indicates that "a subscriber MUST NOT + create multiple dialogs as a result of a single [registration event] + subscription request". Consequently, subscribers who are not aware + of the extension described by this document will accept only one + dialog in response to such requests. In the case described in the + preceding paragraph, this behavior will result in such clients + receiving accurate but incomplete information about the registration + state of an AOR. As an explicit change to the normative behavior of + RFC 3680, this document stipulates that subscribers to the + registration event package MAY create multiple dialogs as the result + of a single subscription request. This will allow subscribers to + create a complete view of an AOR's registration state. + + Defining the behavior as described above is important, since the reg- + event subscriber is interested in finding out about the comprehensive + list of devices associated with the AOR. Only the SIP-PBX will have + authoritative access to this information. For example, if the user + has registered multiple UAs with differing capabilities, the SSP will + not know about the devices or their capabilities. By contrast, the + SIP-PBX will. + + + + + + +Roach Standards Track [Page 17] + +RFC 6140 Globally Identifiable Number Routing March 2011 + + + If the SIP-PBX is not registered with the SSP when a registration + event subscription for a contact that would be implicitly registered + if the SIP-PBX were registered is received, then the SSP SHOULD + accept the subscription and indicate that the user is not currently + registered. Once the associated SIP-PBX is registered, the SSP + SHOULD use the subscription migration mechanism defined in RFC 3265 + [5] to migrate the subscription to the SIP-PBX. + + When a SIP-PBX receives a registration event subscription addressed + to an AOR that has been registered using the bulk registration + mechanism described in this document, then each resulting + registration information document SHOULD contain an 'aor' attribute + in its <registration/> element that corresponds to the AOR at the + SSP. + + For example, consider a SIP-PBX that has registered with an SSP + that has a domain of "ssp.example.com". The SIP-PBX used a + Contact URI of "sip:198.51.100.3:5060;bnc". After such + registration is complete, a registration event subscription + arriving at the SSP with a Request URI of + "sip:+12145550102@ssp.example.com" will be re-targeted to the SIP- + PBX, with a Request URI of "sip:+12145550102@198.51.100.3:5060". + The resulting registration document created by the SIP-PBX would + contain a <registration/> element with an "aor" attribute of + "sip:+12145550102@ssp.example.com". + + This behavior ensures that subscribers external to the system (and + unaware of GIN (generate implicit numbers) procedures) will be + able to find the relevant information in the registration document + (since they will be looking for the publicly visible AOR, not the + address used for sending information from the SSP to the SIP-PBX). + + A SIP-PBX that supports both GRUU procedures and the registration + event packages SHOULD implement the extension defined in RFC 5628 + [9]. + +7.3. Client-Initiated (Outbound) Connections + + RFC 5626 [19] defines a mechanism that allows UAs to establish long- + lived TCP connections or UDP associations with a proxy in a way that + allows bidirectional traffic between the proxy and the UA. This + behavior is particularly important in the presence of NATs, and + whenever TLS [18] security is required. Neither the SSP nor the SIP- + PBX is required to support client-initiated connections. + + Generally, the outbound mechanism works with the solution defined in + this document, without any modifications. Implementors should note + that the instance ID used between the SIP-PBX and the SSP's registrar + + + +Roach Standards Track [Page 18] + +RFC 6140 Globally Identifiable Number Routing March 2011 + + + identifies the SIP-PBX itself, and not any of the UAs registered with + the SIP-PBX. As a consequence, any attempts to use caller + preferences (defined in RFC 3841 [14]) to target a specific instance + are likely to fail. This shouldn't be an issue, as the preferred + mechanism for targeting specific instances of a user agent is GRUU + (see Section 7.1). + +7.4. Non-Adjacent Contact Registration (Path) and Service-Route + Discovery + + RFC 3327 [10] defines a means by which a registrar and its associated + proxy can be informed of a route that is to be used between the proxy + and the registered user agent. The scope of the route created by a + "Path" header field is contact specific; if an AOR has multiple + contacts associated with it, the routes associated with each contact + may be different from each other. Support for non-adjacent contact + registration is required in all SSPs and SIP-PBXes implementing the + multiple-AOR-registration protocol described in this document. + + At registration time, any proxies between the user agent and the + registrar may add themselves to the "Path" header field. By doing + so, they request that any requests destined to the user agent as a + result of the associated registration include them as part of the + Route towards the user agent. Although the path mechanism does + deliver the final path value to the registering UA, UAs typically + ignore the value of the path. + + To provide similar functionality in the opposite direction -- that + is, to establish a route for requests sent by a registering UA -- RFC + 3608 [11] defines a means by which a UA can be informed of a route + that is to be used by the UA to route all outbound requests + associated with the AOR used in the registration. This information + is scoped to the AOR within the UA, and is not specific to the + contact (or contacts) in the REGISTER request. Support of service + route discovery is OPTIONAL in SSPs and SIP-PBXes. + + The registrar unilaterally generates the values of the service route + using whatever local policy it wishes to apply. Although it is + common to use the "Path" and/or "Route" header field information in + the request in composing the service route, registrar behavior is not + constrained in any way that requires it to do so. + + In considering the interaction between these mechanisms and the + registration of multiple AORs in a single request, implementors of + proxies, registrars, and intermediaries must keep in mind the + following issues, which stem from the fact that GIN effectively + registers multiple AORs and multiple contacts. + + + + +Roach Standards Track [Page 19] + +RFC 6140 Globally Identifiable Number Routing March 2011 + + + First, all location service records that result from expanding a + single Contact URI containing a "bnc" parameter will necessarily + share a single path. Proxies will be unable to make policy decisions + on a contact-by-contact basis regarding whether to include themselves + in the path. Second, and similarly, all AORs on the SIP-PBX that are + registered with a common REGISTER request will be forced to share a + common service route. + + One interesting technique that the path and service route mechanisms + enable is the inclusion of a token or cookie in the user portion of + the service route or path entries. This token or cookie may convey + information to proxies about the identity, capabilities, and/or + policies associated with the user. Since this information will be + shared among several AORs and several contacts when multiple AOR + registration is employed, care should be taken to ensure that doing + so is acceptable for all AORs and all contacts registered in a single + REGISTER request. + +8. Examples + + Note that the following examples elide any steps related to + authentication. This is done for the sake of clarity. Actual + deployments will need to provide a level of authentication + appropriate to their system. + +8.1. Usage Scenario: Basic Registration + + This example shows the message flows for a basic bulk REGISTER + transaction, followed by an INVITE addressed to one of the registered + UAs. Example messages are shown after the sequence diagram. + + Internet SSP SIP-PBX + | | | + | |(1) REGISTER | + | |Contact:<sip:198.51.100.3;bnc> | + | |<--------------------------------| + | | | + | |(2) 200 OK | + | |-------------------------------->| + | | | + |(3) INVITE | | + |sip:+12145550105@ssp.example.com| | + |------------------------------->| | + | | | + | |(4) INVITE | + | |sip:+12145550105@198.51.100.3 | + | |-------------------------------->| + + + + +Roach Standards Track [Page 20] + +RFC 6140 Globally Identifiable Number Routing March 2011 + + + (1) The SIP-PBX registers with the SSP for a range of AORs. + + REGISTER sip:ssp.example.com SIP/2.0 + Via: SIP/2.0/UDP 198.51.100.3:5060;branch=z9hG4bKnashds7 + Max-Forwards: 70 + To: <sip:pbx@ssp.example.com> + From: <sip:pbx@ssp.example.com>;tag=a23589 + Call-ID: 843817637684230@998sdasdh09 + CSeq: 1826 REGISTER + Proxy-Require: gin + Require: gin + Supported: path + Contact: <sip:198.51.100.3:5060;bnc> + Expires: 7200 + Content-Length: 0 + + + (3) The SSP receives a request for an AOR assigned + to the SIP-PBX. + + INVITE sip:+12145550105@ssp.example.com SIP/2.0 + Via: SIP/2.0/UDP foo.example;branch=z9hG4bKa0bc7a0131f0ad + Max-Forwards: 69 + To: <sip:2145550105@some-other-place.example.net> + From: <sip:gsmith@example.org>;tag=456248 + Call-ID: f7aecbfc374d557baf72d6352e1fbcd4 + CSeq: 24762 INVITE + Contact: <sip:line-1@192.0.2.178:2081> + Content-Type: application/sdp + Content-Length: ... + + <sdp body here> + + + + + + + + + + + + + + + + + + + +Roach Standards Track [Page 21] + +RFC 6140 Globally Identifiable Number Routing March 2011 + + + (4) The SSP re-targets the incoming request according to the + information received from the SIP-PBX at registration time. + + INVITE sip:+12145550105@198.51.100.3 SIP/2.0 + Via: SIP/2.0/UDP ssp.example.com;branch=z9hG4bKa45cd5c52a6dd50 + Via: SIP/2.0/UDP foo.example;branch=z9hG4bKa0bc7a0131f0ad + Max-Forwards: 68 + To: <sip:2145550105@some-other-place.example.net> + From: <sip:gsmith@example.org>;tag=456248 + Call-ID: f7aecbfc374d557baf72d6352e1fbcd4 + CSeq: 24762 INVITE + Contact: <sip:line-1@192.0.2.178:2081> + Content-Type: application/sdp + Content-Length: ... + + <sdp body here> + +8.2. Usage Scenario: Using Path to Control Request URI + + This example shows a bulk REGISTER transaction with the SSP making + use of the "Path" header field extension [10]. This allows the SSP + to designate a domain on the incoming Request URI that does not + necessarily resolve to the SIP-PBX when the SSP applies RFC 3263 + procedures to it. + + Internet SSP SIP-PBX + | | | + | |(1) REGISTER | + | |Path:<sip:pbx@198.51.100.3;lr> | + | |Contact:<sip:pbx.example;bnc> | + | |<--------------------------------| + | | | + | |(2) 200 OK | + | |-------------------------------->| + | | | + |(3) INVITE | | + |sip:+12145550105@ssp.example.com| | + |------------------------------->| | + | | | + | |(4) INVITE | + | |sip:+12145550105@pbx.example | + | |Route:<sip:pbx@198.51.100.3;lr> | + | |-------------------------------->| + + + + + + + + +Roach Standards Track [Page 22] + +RFC 6140 Globally Identifiable Number Routing March 2011 + + + (1) The SIP-PBX registers with the SSP for a range of AORs. + It includes the form of the URI it expects to receive in the + Request URI in its "Contact" header field, and it includes + information that routes to the SIP-PBX in the "Path" header + field. + + REGISTER sip:ssp.example.com SIP/2.0 + Via: SIP/2.0/UDP 198.51.100.3:5060;branch=z9hG4bKnashds7 + Max-Forwards: 70 + To: <sip:pbx@ssp.example.com> + From: <sip:pbx@ssp.example.com>;tag=a23589 + Call-ID: 326983936836068@998sdasdh09 + CSeq: 1826 REGISTER + Proxy-Require: gin + Require: gin + Supported: path + Path: <sip:pbx@198.51.100.3:5060;lr> + Contact: <sip:pbx.example;bnc> + Expires: 7200 + Content-Length: 0 + + + (3) The SSP receives a request for an AOR assigned + to the SIP-PBX. + + INVITE sip:+12145550105@ssp.example.com SIP/2.0 + Via: SIP/2.0/UDP foo.example;branch=z9hG4bKa0bc7a0131f0ad + Max-Forwards: 69 + To: <sip:2145550105@some-other-place.example.net> + From: <sip:gsmith@example.org>;tag=456248 + Call-ID: 7ca24b9679ffe9aff87036a105e30d9b + CSeq: 24762 INVITE + Contact: <sip:line-1@192.0.2.178:2081> + Content-Type: application/sdp + Content-Length: ... + + <sdp body here> + + + + + + + + + + + + + + +Roach Standards Track [Page 23] + +RFC 6140 Globally Identifiable Number Routing March 2011 + + + (4) The SSP re-targets the incoming request according to the + information received from the SIP-PBX at registration time. + Per the normal processing associated with "Path", it + will insert the "Path" value indicated by the SIP-PBX at + registration time in a "Route" header field, and + set the Request URI to the registered contact. + + INVITE sip:+12145550105@pbx.example SIP/2.0 + Via: SIP/2.0/UDP ssp.example.com;branch=z9hG4bKa45cd5c52a6dd50 + Via: SIP/2.0/UDP foo.example;branch=z9hG4bKa0bc7a0131f0ad + Route: <sip:pbx@198.51.100.3:5060;lr> + Max-Forwards: 68 + To: <sip:2145550105@some-other-place.example.net> + From: <sip:gsmith@example.org>;tag=456248 + Call-ID: 7ca24b9679ffe9aff87036a105e30d9b + CSeq: 24762 INVITE + Contact: <sip:line-1@192.0.2.178:2081> + Content-Type: application/sdp + Content-Length: ... + + <sdp body here> + +9. IANA Considerations + + This document registers a new SIP option tag to indicate support for + the mechanism it defines, two new SIP URI parameters, and a "Contact" + header field parameter. The process governing registration of these + protocol elements is outlined in RFC 5727 [21]. + +9.1. New SIP Option Tag + + This section defines a new SIP option tag per the guidelines in + Section 27.1 of RFC 3261 [3]. + + Name: gin + + Description: This option tag is used to identify the extension that + provides registration for Multiple Phone Numbers in SIP. When + present in a "Require" or "Proxy-Require" header field of a + REGISTER request, it indicates that support for this extension is + required of registrars and proxies, respectively, that are a party + to the registration transaction. + + Reference: RFC 6140 + + + + + + + +Roach Standards Track [Page 24] + +RFC 6140 Globally Identifiable Number Routing March 2011 + + +9.2. New SIP URI Parameters + + This specification defines two new SIP URI parameters, as per the + registry created by RFC 3969 [7]. + +9.2.1. 'bnc' SIP URI Parameter + + Parameter Name: bnc + + Predefined Values: No (no values are allowed) + + Reference: RFC 6140 + +9.2.2. 'sg' SIP URI Parameter + + Parameter Name: sg + + Predefined Values: No + + Reference: RFC 6140 + +9.3. New SIP Header Field Parameter + + This section defines a new SIP header field parameter per the + registry created by RFC 3968 [6]. + + Header field: Contact + + Parameter name: temp-gruu-cookie + + Predefined values: No + + Reference: RFC 6140 + +10. Security Considerations + + The change proposed for the mechanism described in this document + takes the unprecedented step of extending the previously defined + REGISTER method to apply to more than one AOR. In general, this kind + of change has the potential to cause problems at intermediaries -- + such as proxies -- that are party to the REGISTER transaction. In + particular, such intermediaries may attempt to apply policy to the + user indicated in the "To" header field (i.e., the SIP-PBX's + identity), without any knowledge of the multiple AORs that are being + implicitly registered. + + + + + + +Roach Standards Track [Page 25] + +RFC 6140 Globally Identifiable Number Routing March 2011 + + + The mechanism defined by this document solves this issue by adding an + option tag to a "Proxy-Require" header field in such REGISTER + requests. Proxies that are unaware of this mechanism will not + process the requests, preventing them from misapplying policy. + Proxies that process requests with this option tag are clearly aware + of the nature of the REGISTER request and can make reasonable policy + decisions. + + As noted in Section 7.4, intermediaries need to take care if they use + a policy token in the path and service route mechanisms, as doing so + will cause them to apply the same policy to all users serviced by the + same SIP-PBX. This may frequently be the correct behavior, but + circumstances can arise in which differentiation of user policy is + required. + + Section 7.4 also notes that these techniques use a token or cookie in + the "Path" and/or "Service-Route" header values, and that this value + will be shared among all AORs associated with a single registration. + Because this information will be visible to user agents under certain + conditions, proxy designers using this mechanism in conjunction with + the techniques described in this document need to take care that + doing so does not leak sensitive information. + + One of the key properties of the outbound client connection mechanism + discussed in Section 7.3 is the assurance that a single connection is + associated with a single user and cannot be hijacked by other users. + With the mechanism defined in this document, such connections + necessarily become shared between users. However, the only entity in + a position to hijack calls as a consequence is the SIP-PBX itself. + Because the SIP-PBX acts as a registrar for all the potentially + affected users, it already has the ability to redirect any such + communications as it sees fit. In other words, the SIP-PBX must be + trusted to handle calls in an appropriate fashion, and the use of the + outbound connection mechanism introduces no additional + vulnerabilities. + + The ability to learn the identity and registration state of every + user on the PBX (as described in Section 7.2.1) is invaluable for + diagnostic and administrative purposes. For example, this allows the + SIP-PBX to determine whether all its extensions are properly + registered with the SSP. However, this information can also be + highly sensitive, as many organizations may not wish to make their + entire list of phone numbers available to external entities. + Consequently, SSP servers are advised to use explicit (i.e., white- + list) and configurable policies regarding who can access this + information, with very conservative defaults (e.g., an empty access + list or an access list consisting only of the PBX itself). + + + + +Roach Standards Track [Page 26] + +RFC 6140 Globally Identifiable Number Routing March 2011 + + + The procedure for the generation of temporary GRUUs requires the use + of an HMAC to detect any tampering that external entities may attempt + to perform on the contents of a temporary GRUU. The mention of HMAC- + SHA256-80 in Section 7.1.2 is intended solely as an example of a + suitable HMAC algorithm. Since all HMACs used in this document are + generated and consumed by the same entity, the choice of an actual + HMAC algorithm is entirely up to an implementation, provided that the + cryptographic properties are sufficient to prevent third parties from + spoofing GRUU-related information. + + The procedure for the generation of temporary GRUUs also requires the + use of RSA keys. The selection of the proper key length for such + keys requires careful analysis, taking into consideration the current + and foreseeable speed of processing for the period of time during + which GRUUs must remain anonymous, as well as emerging cryptographic + analysis methods. The most recent guidance from RSA Laboratories + [25] suggests a key length of 2048 bits for data that needs + protection through the year 2030, and a length of 3072 bits + thereafter. + + Similarly, implementors are warned to take precautionary measures to + prevent unauthorized disclosure of the private key used in GRUU + generation. Any such disclosure would result in the ability to + correlate temporary GRUUs to each other and, potentially, to their + associated PBXes. + + Further, the use of RSA decryption when processing GRUUs received + from arbitrary parties can be exploited by Denial-of-Service (DoS) + attackers to amplify the impact of an attack: because of the presence + of a cryptographic operation in the processing of such messages, the + CPU load may be marginally higher when the attacker uses (valid or + invalid) temporary GRUUs in the messages employed by such an attack. + Normal DoS mitigation techniques, such as rate-limiting processing of + received messages, should help to reduce the impact of this issue as + well. + + Finally, good security practices should be followed regarding the + duration an RSA key is used. For implementors, this means that + systems MUST include an easy way to update the public key provided to + the SIP-PBX. To avoid immediately invalidating all currently issued + temporary GRUUs, the SSP servers SHOULD keep the retired RSA key + around for a grace period before discarding it. If decryption fails + based on the new RSA key, then the SSP server can attempt to use the + retired key instead. By contrast, the SIP-PBXes MUST discard the + retired public key immediately and exclusively use the new public + key. + + + + + +Roach Standards Track [Page 27] + +RFC 6140 Globally Identifiable Number Routing March 2011 + + +11. Acknowledgements + + This document represents the hard work of many people in the IETF + MARTINI working group and the IETF RAI community as a whole. + Particular thanks are owed to John Elwell for his requirements + analysis of the mechanism described in this document, to Dean Willis + for his analysis of the interaction between this mechanism and the + "Path" and "Service-Route" extensions, to Cullen Jennings for his + analysis of the interaction between this mechanism and the SIP + Outbound extension, and to Richard Barnes for his detailed security + analysis of the GRUU construction algorithm. Thanks to Eric + Rescorla, whose text in the appendix of RFC 5627 was lifted directly + to provide substantial portions of Section 7.1.2. Finally, thanks to + Bernard Aboba, Francois Audet, Brian Carpenter, John Elwell, David + Hancock, Ted Hardie, Martien Huysmans, Cullen Jennings, Alan + Johnston, Hadriel Kaplan, Paul Kyzivat, and Radia Perlman for their + careful reviews of and constructive feedback on this document. + +12. References + +12.1. Normative References + + [1] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing + for Message Authentication", RFC 2104, February 1997. + + [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [3] 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. + + [4] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol + (SIP): Locating SIP Servers", RFC 3263, June 2002. + + [5] Roach, A., "Session Initiation Protocol (SIP)-Specific Event + Notification", RFC 3265, June 2002. + + [6] Camarillo, G., "The Internet Assigned Number Authority (IANA) + Header Field Parameter Registry for the Session Initiation + Protocol (SIP)", BCP 98, RFC 3968, December 2004. + + [7] Camarillo, G., "The Internet Assigned Number Authority (IANA) + Uniform Resource Identifier (URI) Parameter Registry for the + Session Initiation Protocol (SIP)", BCP 99, RFC 3969, + December 2004. + + + + + +Roach Standards Track [Page 28] + +RFC 6140 Globally Identifiable Number Routing March 2011 + + + [8] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", + RFC 4648, October 2006. + + [9] Kyzivat, P., "Registration Event Package Extension for Session + Initiation Protocol (SIP) Globally Routable User Agent URIs + (GRUUs)", RFC 5628, October 2009. + +12.2. Informative References + + [10] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP) + Extension Header Field for Registering Non-Adjacent Contacts", + RFC 3327, December 2002. + + [11] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP) + Extension Header Field for Service Route Discovery During + Registration", RFC 3608, October 2003. + + [12] Rosenberg, J., "A Session Initiation Protocol (SIP) Event + Package for Registrations", RFC 3680, March 2004. + + [13] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating + User Agent Capabilities in the Session Initiation Protocol + (SIP)", RFC 3840, August 2004. + + [14] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller + Preferences for the Session Initiation Protocol (SIP)", + RFC 3841, August 2004. + + [15] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, + December 2004. + + [16] Eastlake, D., Schiller, J., and S. Crocker, "Randomness + Requirements for Security", BCP 106, RFC 4086, June 2005. + + [17] Sparks, R., Hawrylyshen, A., Johnston, A., Rosenberg, J., and + H. Schulzrinne, "Session Initiation Protocol (SIP) Torture Test + Messages", RFC 4475, May 2006. + + [18] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) + Protocol Version 1.2", RFC 5246, August 2008. + + [19] Jennings, C., Mahy, R., and F. Audet, "Managing Client- + Initiated Connections in the Session Initiation Protocol + (SIP)", RFC 5626, October 2009. + + [20] Rosenberg, J., "Obtaining and Using Globally Routable User + Agent URIs (GRUUs) in the Session Initiation Protocol (SIP)", + RFC 5627, October 2009. + + + +Roach Standards Track [Page 29] + +RFC 6140 Globally Identifiable Number Routing March 2011 + + + [21] Peterson, J., Jennings, C., and R. Sparks, "Change Process for + the Session Initiation Protocol (SIP) and the Real-time + Applications and Infrastructure Area", BCP 67, RFC 5727, + March 2010. + + [22] Elwell, J. and H. Kaplan, "Requirements for Multiple Address of + Record (AOR) Reachability Information in the Session Initiation + Protocol (SIP)", RFC 5947, September 2010. + + [23] Kaplan, H., "GIN with Literal AORs for SIP in SSPs (GLASS)", + Work in Progress, November 2010. + + [24] National Institute of Standards and Technology, "Secure Hash + Standard (SHS)", FIPS PUB 180-3, October 2008, <http:// + csrc.nist.gov/publications/fips/fips180-3/fips180-3_final.pdf>. + + [25] Kaliski, B., "TWIRL and RSA Key Size", May 2003. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Roach Standards Track [Page 30] + +RFC 6140 Globally Identifiable Number Routing March 2011 + + +Appendix A. Requirements Analysis + + The document "Requirements for Multiple Address of Record (AOR) + Reachability Information in the Session Initiation Protocol (SIP)" + [22] contains a list of requirements and desired properties for a + mechanism to register multiple AORs with a single SIP transaction. + This section evaluates those requirements against the mechanism + described in this document. + + REQ1 - The mechanism MUST allow a SIP-PBX to enter into a trunking + arrangement with an SSP whereby the two parties have agreed on a set + of telephone numbers assigned to the SIP-PBX. + + The requirement is satisfied. + + REQ2 - The mechanism MUST allow a set of assigned telephone numbers + to comprise E.164 numbers, which can be in contiguous ranges, + discrete, or in any combination of the two. + + The requirement is satisfied. The Direct Inward Dialing (DID) + numbers associated with a registration are established by + bilateral agreement between the SSP and the SIP-PBX; they are not + part of the mechanism described in this document. + + REQ3 - The mechanism MUST allow a SIP-PBX to register reachability + information with its SSP, in order to enable the SSP to route to the + SIP-PBX inbound requests targeted at assigned telephone numbers. + + The requirement is satisfied. + + REQ4 - The mechanism MUST allow UAs attached to a SIP-PBX to register + with the SIP-PBX for AORs based on assigned telephone numbers, in + order to receive requests targeted at those telephone numbers, + without needing to involve the SSP in the registration process. + + The requirement is satisfied; in the presumed architecture, SIP- + PBX UAs register with the SIP-PBX and require no interaction with + the SSP. + + REQ5 - The mechanism MUST allow a SIP-PBX to handle requests + originating at its own UAs and targeted at its assigned telephone + numbers, without routing those requests to the SSP. + + The requirement is satisfied; SIP-PBXes may recognize their own + DID numbers and GRUUs, and perform on-SIP-PBX routing without + sending the requests to the SSP. + + + + + +Roach Standards Track [Page 31] + +RFC 6140 Globally Identifiable Number Routing March 2011 + + + REQ6 - The mechanism MUST allow a SIP-PBX to receive requests to its + assigned telephone numbers originating outside the SIP-PBX and + arriving via the SSP, so that the SIP-PBX can route those requests + onwards to its UAs, as it would for internal requests to those + telephone numbers. + + The requirement is satisfied + + REQ7 - The mechanism MUST provide a means whereby a SIP-PBX knows + which of its assigned telephone numbers an inbound request from its + SSP is targeted at. + + The requirement is satisfied. For ordinary calls and calls using + public GRUUs, the DID number is indicated in the user portion of + the Request URI. For calls using Temp GRUUs constructed with the + mechanism described in Section 7.1.2, the "gr" parameter provides + a correlation token the SIP-PBX can use to identify to which UA + the call should be routed. + + REQ8 - The mechanism MUST provide a means of avoiding problems due to + one side using the mechanism and the other side not. + + The requirement is satisfied through the 'gin' option tag and the + 'bnc' Contact URI parameter. + + REQ9 - The mechanism MUST observe SIP backwards compatibility + principles. + + The requirement is satisfied through the 'gin' option tag. + + REQ10 - The mechanism MUST work in the presence of a sequence of + intermediate SIP entities on the SIP-PBX-to-SSP interface (i.e., + between the SIP-PBX and the SSP's domain proxy), where those + intermediate SIP entities indicated during registration a need to be + on the path of inbound requests to the SIP-PBX. + + The requirement is satisfied through the use of the path mechanism + defined in RFC 3327 [10] + + REQ11 - The mechanism MUST work when a SIP-PBX obtains its IP address + dynamically. + + The requirement is satisfied by allowing the SIP-PBX to use an IP + address in the Bulk Number Contact URI contained in a REGISTER + "Contact" header field. + + + + + + +Roach Standards Track [Page 32] + +RFC 6140 Globally Identifiable Number Routing March 2011 + + + REQ12 - The mechanism MUST work without requiring the SIP-PBX to have + a domain name or the ability to publish its domain name in the DNS. + + The requirement is satisfied by allowing the SIP-PBX to use an IP + address in the Bulk Number Contact URI contained in a REGISTER + "Contact" header field. + + REQ13 - For a given SIP-PBX and its SSP, there MUST be no impact on + other domains, which are expected to be able to use normal RFC 3263 + procedures to route requests, including requests needing to be routed + via the SSP in order to reach the SIP-PBX. + + The requirement is satisfied by allowing the domain name in the + Request URI used by external entities to resolve to the SSP's + servers via normal RFC 3263 resolution procedures. + + REQ14 - The mechanism MUST be able to operate over a transport that + provides end-to-end integrity protection and confidentiality between + the SIP-PBX and the SSP, e.g., using TLS as specified in [3]. + + The requirement is satisfied; nothing in the proposed mechanism + prevents the use of TLS between the SSP and the SIP-PBX. + + REQ15 - The mechanism MUST support authentication of the SIP-PBX by + the SSP and vice versa, e.g., using SIP digest authentication plus + TLS server authentication as specified in [3]. + + The requirement is satisfied; SIP-PBXes may employ either SIP + digest authentication or mutually authenticated TLS for + authentication purposes. + + REQ16 - The mechanism MUST allow the SIP-PBX to provide its UAs with + public or temporary Globally Routable UA URIs (GRUUs) [20]. + + The requirement is satisfied via the mechanisms detailed in + Section 7.1. + + REQ17 - The mechanism MUST work over any existing transport specified + for SIP, including UDP. + + The requirement is satisfied to the extent that UDP can be used + for REGISTER requests in general. The application of certain + extensions and/or network topologies may exceed UDP MTU sizes, but + such issues arise both with and without the mechanism described in + this document. This document does not exacerbate such issues. + + + + + + +Roach Standards Track [Page 33] + +RFC 6140 Globally Identifiable Number Routing March 2011 + + + REQ18 - Documentation MUST give guidance or warnings about how + authorization policies may be affected by the mechanism, to address + the problems described in Section 3.3 [of RFC 5947]. + + These issues are addressed at length in Section 10, as well as + summarized in Section 7.4. + + REQ19 - The mechanism MUST be extensible to allow a set of assigned + telephone numbers to comprise local numbers as specified in RFC 3966 + [15], which can be in contiguous ranges, discrete, or in any + combination of the two. + + Assignment of telephone numbers to a registration is performed by + the SSP's registrar, which is not precluded from assigning local + numbers in any combination it desires. + + REQ20 - The mechanism MUST be extensible to allow a set of + arbitrarily assigned SIP URI's as specified in RFC 3261 [3], as + opposed to just telephone numbers, without requiring a complete + change of mechanism as compared to that used for telephone numbers. + + The mechanism is extensible in such a fashion, as demonstrated by + the document "GIN with Literal AoRs for SIP in SSPs (GLASS)" [23]. + + DES1 - The mechanism SHOULD allow an SSP to exploit its mechanisms + for providing SIP service to normal UAs in order to provide a SIP + trunking service to SIP-PBXes. + + The desired property is satisfied; the routing mechanism described + in this document is identical to the routing performed for singly + registered AORs. + + DES2 - The mechanism SHOULD scale to SIP-PBXes of several thousand + assigned telephone numbers. + + The desired property is satisfied; nothing in this document + precludes DID number pools of arbitrary size. + + DES3 - The mechanism SHOULD scale to support several thousand SIP- + PBX's on a single SSP. + + The desired property is satisfied; nothing in this document + precludes an arbitrary number of SIP-PBXes from attaching to a + single SSP. + + + + + + + +Roach Standards Track [Page 34] + +RFC 6140 Globally Identifiable Number Routing March 2011 + + +Author's Address + + Adam Roach + Tekelec + 17210 Campbell Rd. + Suite 250 + Dallas, TX 75252 + US + + EMail: adam@nostrum.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Roach Standards Track [Page 35] + |