idnits 2.17.1
draft-ietf-martini-gin-10.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
-- The draft header indicates that this document updates RFC3680, but the
abstract doesn't seem to mention this, which it should.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
(Using the creation date from RFC3680, updated by this document, for
RFC5378 checks: 2002-10-31)
-- The document seems to lack a disclaimer for pre-RFC5378 work, but may
have content which was first submitted before 10 November 2008. If you
have contacted all the original authors and they are all willing to grant
the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
this comment. If not, you may need to add the pre-RFC5378 disclaimer.
(See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (October 18, 2010) is 4940 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. '2')
** Obsolete normative reference: RFC 3265 (ref. '6') (Obsoleted by RFC 6665)
Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 MARTINI WG A. B. Roach
3 Internet-Draft Tekelec
4 Updates: 3680 (if approved) October 18, 2010
5 Intended status: Standards Track
6 Expires: April 21, 2011
8 Registration for Multiple Phone Numbers in the Session Initiation
9 Protocol (SIP)
10 draft-ietf-martini-gin-10
12 Abstract
14 This document defines a mechanism by which a SIP server acting as a
15 traditional Private Branch Exchange (SIP-PBX) can register with a SIP
16 Service Provider (SSP) to receive phone calls for UAs designated by
17 phone numbers. In order to function properly, this mechanism relies
18 on the fact that the phone numbers are fully qualified and globally
19 unique.
21 Status of this Memo
23 This Internet-Draft is submitted in full conformance with the
24 provisions of BCP 78 and BCP 79.
26 Internet-Drafts are working documents of the Internet Engineering
27 Task Force (IETF). Note that other groups may also distribute
28 working documents as Internet-Drafts. The list of current Internet-
29 Drafts is at http://datatracker.ietf.org/drafts/current/.
31 Internet-Drafts are draft documents valid for a maximum of six months
32 and may be updated, replaced, or obsoleted by other documents at any
33 time. It is inappropriate to use Internet-Drafts as reference
34 material or to cite them other than as "work in progress."
36 This Internet-Draft will expire on April 21, 2011.
38 Copyright Notice
40 Copyright (c) 2010 IETF Trust and the persons identified as the
41 document authors. All rights reserved.
43 This document is subject to BCP 78 and the IETF Trust's Legal
44 Provisions Relating to IETF Documents
45 (http://trustee.ietf.org/license-info) in effect on the date of
46 publication of this document. Please review these documents
47 carefully, as they describe your rights and restrictions with respect
48 to this document. Code Components extracted from this document must
49 include Simplified BSD License text as described in Section 4.e of
50 the Trust Legal Provisions and are provided without warranty as
51 described in the Simplified BSD License.
53 Table of Contents
55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
56 2. Constraints . . . . . . . . . . . . . . . . . . . . . . . . . 3
57 3. Terminology and Conventions . . . . . . . . . . . . . . . . . 4
58 4. Mechanism Overview . . . . . . . . . . . . . . . . . . . . . . 5
59 5. Registering for Multiple Phone Numbers . . . . . . . . . . . . 5
60 5.1. SIP-PBX Behavior . . . . . . . . . . . . . . . . . . . . . 5
61 5.2. Registrar Behavior . . . . . . . . . . . . . . . . . . . . 6
62 5.3. SIP URI "user" Parameter Handling . . . . . . . . . . . . 8
63 6. SSP Processing of Inbound Requests . . . . . . . . . . . . . . 8
64 7. Interaction with Other Mechanisms . . . . . . . . . . . . . . 9
65 7.1. Globally Routable User-Agent URIs (GRUU) . . . . . . . . . 9
66 7.1.1. Public GRUUs . . . . . . . . . . . . . . . . . . . . . 9
67 7.1.2. Temporary GRUUs . . . . . . . . . . . . . . . . . . . 11
68 7.2. Registration Event Package . . . . . . . . . . . . . . . . 15
69 7.2.1. SIP-PBX Aggregate Registration State . . . . . . . . . 15
70 7.2.2. Individual AOR Registration State . . . . . . . . . . 16
71 7.3. Client-Initiated (Outbound) Connections . . . . . . . . . 18
72 7.4. Non-Adjacent Contact Registration (Path) and Service
73 Route Discovery . . . . . . . . . . . . . . . . . . . . . 18
74 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
75 8.1. Usage Scenario: Basic Registration . . . . . . . . . . . . 20
76 8.2. Usage Scenario: Using Path to Control Request URI . . . . 21
77 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
78 9.1. New SIP Option Tag . . . . . . . . . . . . . . . . . . . . 24
79 9.2. New SIP URI Parameters . . . . . . . . . . . . . . . . . . 24
80 9.2.1. 'bnc' SIP URI parameter . . . . . . . . . . . . . . . 24
81 9.2.2. 'sg' SIP URI parameter . . . . . . . . . . . . . . . . 24
82 9.3. New SIP Header Field Parameter . . . . . . . . . . . . . . 24
83 10. Security Considerations . . . . . . . . . . . . . . . . . . . 24
84 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26
85 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
86 12.1. Normative References . . . . . . . . . . . . . . . . . . . 27
87 12.2. Informative References . . . . . . . . . . . . . . . . . . 27
88 Appendix A. Requirements Analysis . . . . . . . . . . . . . . . . 28
89 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 32
91 1. Introduction
93 One of SIP's primary functions is providing rendezvous between users.
94 By design, this rendezvous has been provided through a combination of
95 the server look-up procedures defined in RFC 3263 [5], and the
96 registrar procedures described in RFC 3261 [4].
98 The intention of the original protocol design was that any user's AOR
99 would be handled by the authority indicated by the hostport portion
100 of the AOR. The users registered individual reachability information
101 with this authority, which would then route incoming requests
102 accordingly.
104 In actual deployments, some SIP servers have been deployed in
105 architectures that, for various reasons, have requirements to provide
106 dynamic routing information for large blocks of AORs, where all of
107 the AORs in the block were to be handled by the same server. For
108 purposes of efficiency, many of these deployments do not wish to
109 maintain separate registrations for each of the AORs in the block.
110 This leads to the desire for an alternate mechanism for providing
111 dynamic routing information for blocks of AORs.
113 Although the use of REGISTER requests to update reachability
114 information for multiple users simultaneously is somewhat beyond the
115 original semantics defined for REGISTER requests, this approach has
116 seen significant deployment in certain environments. In particular,
117 deployments in which small to medium SIP-PBX servers are addressed
118 using E.164 numbers have used this mechanism to avoid the need to
119 maintain DNS entries or static IP addresses for the SIP-PBX servers.
121 In recognition of the momentum that REGISTER-based approaches have
122 seen in deployments, this document defines a REGISTER-based approach
123 that is tailored to E.164-addressed UAs in a SIP-PBX environment. It
124 does not address registration of SIP URIs in which the user portion
125 is not an E.164 number.
127 2. Constraints
129 The following paragraph is perhaps the most important in
130 understanding the reasons for the design decisions made in this
131 document.
133 Within the problem space that has been established for this work,
134 several constraints shape our solution. These are defined in the
135 MARTINI requirements document [18]. In terms of impact to the
136 solution at hand, the following two constraints have the most
137 profound effect: (1) The SIP-PBX cannot be assumed to be assigned a
138 static IP address; and (2) No DNS entry can be relied upon to
139 consistently resolve to the IP address of the SIP-PBX.
141 3. Terminology and Conventions
143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
145 document are to be interpreted as described in RFC 2119 [3].
147 Further, the term "SSP" is meant as an acronym for a "SIP Service
148 Provider," while the term "SIP-PBX" is used to indicate a SIP Private
149 Branch Exchange.
151 Indented portions of the document, such as this one, form non-
152 normative, explanatory sections of the document.
154 Although SIP is a text-based protocol, some of the examples in this
155 document cannot be unambiguously rendered without additional markup
156 due to the constraints placed on the formatting of RFCs. This
157 document uses the markup convention established in RFC
158 4475 [15] to avoid ambiguity and meet the RFC layout requirements.
159 For the sake of completeness, the text defining this markup from
160 Section 2.1 of RFC 4475 [15] is reproduced in its entirety below:
162 Several of these examples contain unfolded lines longer than 72
163 characters. These are captured between tags. The
164 single unfolded line is reconstructed by directly concatenating
165 all lines appearing between the tags (discarding any line feeds or
166 carriage returns). There will be no whitespace at the end of
167 lines. Any whitespace appearing at a fold-point will appear at
168 the beginning of a line.
170 The following represent the same string of bits:
172 Header-name: first value, reallylongsecondvalue, third value
174
175 Header-name: first value,
176 reallylongsecondvalue
177 , third value
178
180
181 Header-name: first value,
182 reallylong
183 second
184 value,
185 third value
186
188 Note that this is NOT SIP header-line folding, where different
189 strings of bits have equivalent meaning.
191 4. Mechanism Overview
193 The overall mechanism is achieved using a REGISTER request with a
194 specially-formatted Contact URI. This document also defines an
195 option tag that can be used to ensure a registrar and any
196 intermediaries understand the mechanism described herein.
198 The Contact URI itself is tagged with a URI parameter to indicate
199 that it actually represents multiple phone-number-associated
200 contacts.
202 We also define some lightweight extensions for Globally Routable UA
203 URIs (GRUU) to allow the use of public and temporary GRUUs assigned
204 by the SSP.
206 Aside from these extensions, the REGISTER request itself is processed
207 by a registrar in the same way as normal registrations: by updating
208 its location service with additional AOR-to-Contact bindings.
210 Note that the list of AORs associated with a SIP-PBX is a matter of
211 local provisioning at the SSP and at the SIP-PBX. The mechanism
212 defined in this document does not provide any means to detect or
213 recover from provisioning mismatches (although the registration event
214 package can be used as a standardized means for auditing such AORs;
215 see Section 7.2.1).
217 5. Registering for Multiple Phone Numbers
219 5.1. SIP-PBX Behavior
221 To register for multiple AORs, the SIP-PBX sends a REGISTER request
222 to the SSP. This REGISTER request varies from a typical REGISTER
223 request in two important ways. First, it MUST contain an option tag
224 of "gin" in both a "Require" header field and a "Proxy-Require"
225 header field. (The option tag "gin" is an acronym for "generate
226 implicit numbers".) Second, in at least one "Contact" header field,
227 it MUST include a Contact URI that contains the URI parameter "bnc"
228 (which stands for "bulk number contact"), and no user portion (hence
229 no "@" symbol). A URI with a "bnc" parameter MUST NOT contain a user
230 portion. Except for the SIP URI "user" parameter, this URI MAY
231 contain any other parameters that the SIP-PBX desires. These
232 parameters will be echoed back by the SSP in any requests bound for
233 the SIP-PBX.
235 Because of the constraints discussed in Section 2, the host portion
236 of the Contact URI will generally contain an IP address, although
237 nothing in this mechanism enforces or relies upon that fact. If the
238 SIP-PBX operator chooses to maintain DNS entries that resolve to the
239 IP address of his SIP-PBX via RFC 3263 resolution procedures, then
240 this mechanism works just fine with domain names in the Contact
241 header field.
243 The "bnc" URI parameter indicates that special interpretation of the
244 Contact URI is necessary: instead of representing a single, concrete
245 Contact URI to be inserted into the location service, it represents
246 multiple URIs (one for each associated AOR), semantically resulting
247 in multiple AOR-to-Contact rows in the location service.
249 Any SIP-PBX implementing the registration mechanism defined in this
250 document MUST also support the Path mechanism defined by RFC 3327
251 [10], and MUST include a 'path' option-tag in the Supported header
252 field of the REGISTER request (which is a stronger requirement than
253 imposed by the Path mechanism itself). This behavior is necessary
254 because proxies between the SIP-PBX and the Registrar may need to
255 insert Path header field values in the REGISTER request for this
256 document's mechanism to function properly, and per RFC 3327 [10],
257 they can only do so if the UAC inserted the option-tag in the
258 Supported header field. In accordance with the procedures defined in
259 RFC 3327 [10], the SIP-PBX is allowed to ignore the Path header
260 fields returned in the REGISTER response.
262 5.2. Registrar Behavior
264 The registrar, upon receipt of a REGISTER request containing at least
265 one Contact header field with a "bnc" parameter will use the value in
266 the "To" header field to identify the SIP-PBX for which registration
267 is being requested. It then authenticates the SIP-PBX (using, e.g.,
268 SIP Digest authentication, mutual TLS, or some other authentication
269 mechanism). After the SIP-PBX is authenticated, the registrar
270 updates its location service with a unique AOR-to-Contact mapping for
271 each of the AORs associated with the SIP-PBX. Semantically, each of
272 these mappings will be treated as a unique row in the location
273 service. The actual implementation may, of course, perform internal
274 optimizations to reduce the amount of memory used to store such
275 information.
277 For each of these unique rows, the AOR will be in the format that the
278 SSP expects to receive from external parties (e.g.
280 "sip:+12145550102@ssp.example.com"), and the corresponding Contact
281 will be formed by adding to the REGISTER request's Contact URI a user
282 portion containing the fully-qualified, E.164-formatted number
283 (including the preceding "+" symbol) and removing the "bnc"
284 parameter. Aside from the initial "+" symbol, this E.164-formatted
285 number MUST consist exclusively of digits from 0 through 9, and
286 explicitly MUST NOT contain any visual separator symbols (e.g., "-",
287 ".", "(", or ")"). For example, if the "Contact" header field
288 contains the URI , then the Contact value
289 associated with the aforementioned AOR will be
290 .
292 Although the SSP treats this registration as a number of discrete
293 rows for the purpose of re-targeting incoming requests, the renewal,
294 expiration, and removal of these rows is bound to the registered
295 contact. In particular, this means that REGISTER requests that
296 attempt to de-register a single AOR that has been implicitly
297 registered MUST NOT remove that AOR from the bulk registration. In
298 this circumstance, the registrar simply acts as if the UA attempted
299 to unregister a contact that wasn't actually registered (e.g., return
300 the list of presently registered contacts in a success response). A
301 further implication of this property is that an individual extension
302 that is implicitly registered may also be explicitly registered using
303 a normal, non-bulk registration (subject to SSP policy). If such a
304 registration exists, it is refreshed independently of the bulk
305 registration, and is not removed when the bulk registration is
306 removed.
308 A registrar that receives a REGISTER request containing a Contact URI
309 with both a "bnc" parameter and a user portion MUST NOT send a 200-
310 class (success) response. If no other error is applicable, the
311 registrar can use a 400 (Bad Request) response to indicate this error
312 condition.
314 Note that the preceding paragraph is talking about the user
315 portion of a URI:
317 sip:+12145550100@example.com
318 ^^^^^^^^^^^^
320 A Registrar compliant with this document MUST support the Path
321 mechanism defined in RFC 3327 [10]. The rationale for support of
322 this mechanism is given in section Section 5.1.
324 Aside from the "bnc" parameter, all URI parameters present on the
325 "Contact" URI in the REGISTER request MUST be copied to the Contact
326 value stored in the location service.
328 If the SSP servers perform processing based on User Agent
329 Capabilities (as defined in RFC 3840 [13]), they will treat any
330 feature tags present on a Contact header field with a "bnc" parameter
331 in its URI as applicable to all of the resulting AOR-to-Contact
332 mappings. Similarly, any option tags present on the REGISTER request
333 that indicate special handling for any subsequent requests are also
334 applicable to all of the AOR-to-Contact mappings.
336 5.3. SIP URI "user" Parameter Handling
338 This document does not modify the behavior specified in RFC 3261 [4]
339 for inclusion of the "user" parameter on request URIs. However, to
340 avoid any ambiguity in handling at the SIP-PBX, the following
341 normative behavior is imposed on its interactions with the SSP.
343 When a SIP-PBX registers with an SSP using a contact containing a
344 "bnc" parameter, that contact MUST NOT include a "user" parameter.
345 An SSP registrar that receives a REGISTER request containing a
346 Contact URI with both a "bnc" parameter and a "user" parameter MUST
347 NOT send a 200-class (success) response. If no other error is
348 applicable, the registrar can use a 400 (Bad Request) response to
349 indicate this error condition.
351 Note that the preceding paragraph is talking about the "user"
352 parameter of a URI:
354 sip:+12145550100@example.com;user=phone
355 ^^^^^^^^^^
357 When a SIP-PBX receives a request from an SSP, and the Request-URI
358 contains a user portion corresponding to an AOR registered using a
359 contact containing a "bnc" parameter, then the SIP-PBX MUST NOT
360 reject the request (or otherwise cause the request to fail) due to
361 the absence, presence, or value of a "user" parameter on the Request-
362 URI.
364 6. SSP Processing of Inbound Requests
366 In general, after processing the AOR-to-Contact mapping described in
367 the preceding section, the SSP Proxy/Registrar (or equivalent entity)
368 performs traditional Proxy/Registrar behavior, based on the mapping.
369 For any inbound SIP requests whose AOR indicates an E.164 number
370 assigned to one of the SSP's customers, this will generally involve
371 setting the target set to the registered contacts associated with
372 that AOR, and performing request forwarding as described in section
373 16.6 of RFC 3261 [4]. An SSP using the mechanism defined in this
374 document MUST perform such processing for inbound INVITE requests and
375 SUBSCRIBE requests to the "reg" event package (see Section 7.2.2),
376 and SHOULD perform such processing for all other method types,
377 including unrecognized SIP methods.
379 7. Interaction with Other Mechanisms
381 The following sections describe the means by which this mechanism
382 interacts with relevant REGISTER-related extensions currently defined
383 by the IETF.
385 7.1. Globally Routable User-Agent URIs (GRUU)
387 To enable advanced services to work with UAs behind a SIP-PBX, it is
388 important that the GRUU mechanism defined by RFC 5627 [17] work
389 correctly with the mechanism defined by this document -- that is,
390 that User Agents served by the SIP-PBX can acquire and use GRUUs for
391 their own use.
393 7.1.1. Public GRUUs
395 Support of public GRUUs is optional in SSPs and SIP-PBXes.
397 When a SIP-PBX registers a Bulk Number Contact (a Contact with a
398 "bnc" parameter), and also invokes GRUU procedures for that Contact
399 during registration, then the SSP will assign a public GRUU to the
400 SIP-PBX in the normal fashion. Because the URI being registered
401 contains a "bnc" parameter, the GRUU will also contain a "bnc"
402 parameter. In particular, this means that the GRUU will not contain
403 a user portion.
405 When a UA registers a contact with the SIP-PBX using GRUU procedures,
406 the SIP-PBX provides to the UA a public GRUU formed by adding an "sg"
407 parameter to the GRUU parameter it received from the SSP. This "sg"
408 parameter contains a disambiguation token that the SIP-PBX can use to
409 route inbound requests to the proper UA.
411 So, for example, when the SIP-PBX registers with the following
412 contact header field:
414 Contact: ;
415 +sip.instance=""
417 Then the SSP may choose to respond with a Contact header field that
418 looks like this:
420
421 Contact: ;
422 pub-gruu="sip:ssp.example.com;bnc;gr=urn:
423 uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6";
424 +sip.instance=""
425 ;expires=7200
426
428 When its own UAs register using GRUU procedures, the SIP-PBX can then
429 add whatever device identifier it feels appropriate in an "sg"
430 parameter, and present this value to its own UAs. For example,
431 assume the UA associated with the AOR "+12145550102" sent the
432 following Contact header field in its REGISTER request:
434 Contact: ;
435 +sip.instance=""
437 The SIP-PBX will add an "sg" parameter to the pub-gruu it received
438 from the SSP with a token that uniquely identifies the device
439 (possibly the URN itself; possibly some other identifier); insert a
440 user portion containing the fully-qualified E.164 number associated
441 with the UA; and return the result to the UA as its public GRUU. The
442 resulting Contact header field sent from the SIP-PBX to the
443 registering UA would look something like this:
445
446 Contact: ;
447 pub-gruu="sip:+12145550102@ssp.example.com;gr=urn:
448 uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6;sg=00:05:03:5e:70:a6";
449 +sip.instance=""
450 ;expires=3600
451
453 When an incoming request arrives at the SSP for a GRUU corresponding
454 to a bulk number contact ("bnc"), the SSP performs slightly different
455 processing for the GRUU than it would for a URI without a "bnc"
456 parameter. When the GRUU is re-targeted to the registered bulk
457 number contact, the SSP MUST copy the "sg" parameter from the GRUU to
458 the new target. The SIP-PBX can then use this "sg" parameter to
459 determine which user agent the request should be routed to. For
460 example, the first line of an INVITE request that has been re-
461 targeted to the SIP-PBX for the UA shown above would look like this:
463 INVITE sip:+12145550102@198.51.100.3;sg=00:05:03:5e:70:a6 SIP/2.0
465 7.1.2. Temporary GRUUs
467 In order to provide support for privacy, the SSP SHOULD implement the
468 temporary GRUU mechanism described in this section. Reasons for not
469 doing so would include systems with an alternative privacy mechanism
470 which maintains the integrity of public GRUUs (i.e., if public GRUUs
471 are anonymized then the anonymizer function would need to be capable
472 of providing as the anonymized URI a globally routable URI that
473 routes back only to the target identified by the original public
474 GRUU).
476 Temporary GRUUs are used to provide anonymity for the party creating
477 and sharing the GRUU. Being able to correlate two temporary GRUUs as
478 having originated from behind the same SIP-PBX violates this
479 principle of anonymity. Consequently, rather than relying upon a
480 single, invariant identifier for the SIP-PBX in its UA's temporary
481 GRUUs, we define a mechanism whereby the SSP provides the SIP-PBX
482 with sufficient information for the SIP-PBX to mint unique temporary
483 GRUUs. These GRUUs have the property that the SSP can correlate them
484 to the proper SIP-PBX, but no other party can do so. To achieve this
485 goal, we use a slight modification of the procedure described in
486 appendix A.2 of RFC 5627 [17].
488 The SIP-PBX needs to be able to construct a temp-gruu in a way that
489 the SSP can decode. In order to ensure that the SSP can decode
490 GRUUs, we need to standardize the algorithm for creation of temp-
491 gruus at the SIP-PBX. This allows the SSP to reverse the algorithm
492 to identify the registration entry that corresponds to the GRUU.
494 It is equally important that no party other than the SSP is capable
495 of decoding a temporary GRUU, including other SIP-PBXes serviced by
496 the SSP. To achieve this property, an SSP that supports temporary
497 GRUUs MUST create and store an asymmetric key pair, {K_e1,K_e2}.
498 K_e1 is kept secret by the SSP, while K_e2 is shared with the SIP-
499 PBXes via provisioning.
501 All base64 encoding discussed in the following sections MUST use the
502 character set and encoding defined in RFC 2045 [1], except that any
503 trailing "=" characters are discarded on encoding, and added as
504 necessary to decode.
506 7.1.2.1. Generation of temp-gruu-cookie by the SSP
508 An SSP that supports temporary GRUUs MUST include a "temp-gruu-
509 cookie" parameter on all Contact header fields containing a "bnc"
510 parameter in a 200-class REGISTER response. This "temp-gruu-cookie"
511 MUST have the following properties:
513 1. It can be used by the SSP to uniquely identify the registration
514 to which it corresponds.
515 2. It is encoded using base64. This allows the SIP-PBX to decode it
516 into as compact a form as possible for use in its calculations.
517 3. It is of a fixed length. This allows for extraction of it once
518 the SIP-PBX has concatenated a distinguisher onto it.
519 4. The temp-gruu-cookie MUST NOT be forgeable by any party. In
520 other words, the SSP needs to be able to examine the cookie and
521 validate that it was generated by the SSP.
522 5. The temp-gruu-cookie MUST be invariant during the course of a
523 registration, including any refreshes to that registration. This
524 property is important, as it allows the SIP-PBX to examine the
525 temp-gruu-cookie to determine whether the temp-gruus it has
526 issued to its UAs are still valid.
528 The above properties can be met using the following algorithm, which
529 is non-normative. Implementors may chose to implement any algorithm
530 of their choosing for generation of the temp-gruu-cookie, as long as
531 it fulfills the five properties listed above.
533 The SSP registrar maintains a counter, I. this counter is 48 bits
534 long, and initialized to zero. This counter is persistently
535 stored, using a back-end database or similar technique. When the
536 SSP registrar creates the first temporary GRUU for a particular
537 SIP-PBX and instance ID (as defined by [17]), the SSP registrar
538 notes the current value of the counter, I_i, and increments the
539 counter in the database. The SSP registrar then maps I_i to the
540 Contact and instance ID using the database, a persistent hash-map
541 or similar technology. If the registration expires such that
542 there are no longer any contacts with that particular instance ID
543 bound to the GRUU, the SSP registrar removes the mapping.
544 Similarly, if the temporary GRUUs are invalidated due to a change
545 in Call-ID, the SSP registrar removes the current mapping from I_i
546 to the AOR and instance ID, notes the current value of the counter
547 I_j, and stores a mapping from I_j to the contact containing a
548 "bnc" parameter and instance ID. Based on these rules, the hash-
549 map will contain a single mapping for each contact containing a
550 "bnc" parameter and instance ID for which there is a currently
551 valid registration.
553 The SSP registrar maintains a symmetric key SK_a, which is
554 regenerated every time the counter rolls over or is is reset.
555 When the counter rolls over or is reset, the SSP registrar
556 remembers the old value of SK_a for a while. To generate a temp-
557 gruu-cookie, the SSP registrar computes:
559 SA = HMAC-SHA256-80(SK_a, I_i)
560 temp-gruu-cookie = base64enc(I_i || SA)
562 where || denotes concatenation.
564 7.1.2.2. Generation of temp-gruu by the SIP-PBX
566 According to RFC5627 [17] section 3.2, every registration refresh
567 generates a new temp-gruu that is valid for as long as the contact
568 remains registered. This property is both critical for the privacy
569 properties of temp-gruu and is expected by UAs that implement the
570 temp-gruu procedures. Nothing in this document should be construed
571 as changing this fundamental temp-gruu property in any way. SIP-
572 PBXes that implement temporary GRUUs MUST generate a new temp-gruu
573 according to the procedures in this section for every registration or
574 registration refresh from GRUU-supporting UAs attached to the SIP-
575 PBX.
577 Similarly, if the registration that a SIP-PBX has with its SSP
578 expires or is terminated, then the temp-gruu cookie it maintains with
579 the SSP will change. This change will invalidate all the temp-gruus
580 the SIP-PBX has issued to its UAs. If the SIP-PBX tracks this
581 information (e.g., to include elements in registration
582 event bodies, as described in RFC 5628 [9]), it can determine that
583 previously issued temp-gruus are invalid by observing a change in the
584 temp-gruu-cookie provided to it by the SSP.
586 A SIP-PBX that issues temporary GRUUs to its UAs MUST maintain an
587 HMAC key, PK_a. This value is used to validate that incoming GRUUs
588 were generated by the SIP-PBX.
590 To generate a new temporary GRUU for use by its own UAs, the SIP-PBX
591 MUST generate a random distinguisher value D. The length of this
592 value is up to implementors, but MUST be long enough to prevent
593 collisions among all the temporary GRUUs issued by the SIP-PBX. A
594 size of 80 bits or longer is RECOMMENDED. The SIP-PBX then MUST
595 calculate:
597 M = base64dec(SSP-cookie) || D
598 E = RSA-Encrypt(K_e2, M)
599 PA = HMAC(PK_a, E)
601 Temp-Gruu-userpart = "tgruu." || base64(E) || "." || base64(PA)
603 where || denotes concatenation. "HMAC" represents any suitably
604 strong HMAC algorithm; see RFC 2104 [2] for a discussion of HMAC
605 algorithms. One suitable HMAC algorithm for this purpose is HMAC-
606 SHA256-80.
608 Finally, the SIP-PBX adds a "gr" parameter to the temporary GRUU that
609 can be used to uniquely identify the UA registration record to which
610 the GRUU corresponds. The means of generation of the "gr" parameter
611 are left to the implementor, as long as they satisfy the properties
612 of a GRUU as described in RFC 5627 [17].
614 One valid approach for generation of the "gr" parameter is
615 calculation of "E" and "A" as described in Appendix A.2 of RFC
616 5627 [17], and forming the "gr" parameter as:
618 gr = base64enc(E) || base64enc(A)
620 Using this procedure may result in a temporary GRUU returned to the
621 registering UA by the SIP-PBX that looks similar to this:
623
624 Contact:
625 ;temp-gruu="sip:tgruu.MQyaRiLEd78RtaWkcP7N8Q.5qVbsasdo2pkKw@
626 ssp.example.com;gr=YZGSCjKD42ccxO08pA7HwAM4XNDIlMSL0HlA"
627 ;+sip.instance=""
628 ;expires=3600
629
631 7.1.2.3. Decoding of temp-gruu by the SSP
633 When the SSP proxy receives a request in which the user part begins
634 with "tgruu.", it extracts the remaining portion, and splits it at
635 the "." character into E' and PA'. It discards PA'. It then
636 computes E by performing a base64 decode of E'. Next, it computes:
638 M = RSA-Decrypt(K_e1, E)
640 The SSP proxy extracts the fixed-length temp-gruu-cookie information
641 from the beginning of this M, and discards the remainder (which will
642 be the distinguisher added by the SIP-PBX). It then validates this
643 temp-gruu-cookie. If valid, it uses it to locate the corresponding
644 SIP-PBX registration record, and routes the message appropriately.
646 If the non-normative, exemplary algorithm described in
647 Section 7.1.2.1 is used to generate the temp-gruu-cookie, then
648 this identification is performed by splitting the temp-gruu-cookie
649 information into its 48-bit counter I and 80-bit HMAC. It
650 validates that the HMAC matches the counter I, and then uses
651 counter I to locate the SIP-PBX registration record in its map.
652 If the counter has rolled over or reset, this computation is
653 performed with the current and previous SK_a.
655 7.1.2.4. Decoding of temp-gruu by the SIP-PBX
657 When the SIP-PBX receives a request in which the user part begins
658 with "tgruu.", it extracts the remaining portion, and splits it at
659 the "." character into E' and PA'. It then computes E and PA by
660 performing a base64 decode of E' and PA' respectively. Next, it
661 computes:
663 PAc = HMAC(PK_a, E)
665 where HMAC is the HMAC algorithm used for the steps in
666 Section 7.1.2.2. If this computed value for PAc does not match the
667 value of PA extracted from the GRUU, then the GRUU is rejected as
668 invalid.
670 The SIP-PBX then uses the value of the "gr" parameter to locate the
671 UA registration to which the GRUU corresponds, and routes the message
672 accordingly.
674 7.2. Registration Event Package
676 Neither the SSP nor the SIP-PBX is required to support the
677 Registration event package defined by RFC 3680 [12]. However, if
678 they do support the Registration event package, they MUST conform to
679 the behavior described in this section and its subsections.
681 As this mechanism inherently deals with REGISTER transaction
682 behavior, it is imperative to consider its impact on the Registration
683 Event Package defined by RFC 3680 [12]. In practice, there will be
684 two main use cases for subscribing to registration data: learning
685 about the overall registration state for the SIP-PBX, and learning
686 about the registration state for a single SIP-PBX AOR.
688 7.2.1. SIP-PBX Aggregate Registration State
690 If the SIP-PBX (or another interested and authorized party) wishes to
691 monitor or audit the registration state for all of the AORs currently
692 registered to that SIP-PBX, it can subscribe to the SIP registration
693 event package at the SIP-PBX's main URI -- that is, the URI used in
694 the "To" header field of the REGISTER request.
696 The NOTIFY messages for such a subscription will contain a body that
697 contains one record for each AOR associated with the SIP-PBX. The
698 AORs will be in the format expected to be received by the SSP (e.g.,
699 "sip:+12145550105@ssp.example.com"), and the Contacts will correspond
700 to the mapped Contact created by the registration (e.g.,
701 "sip:+12145550105@98.51.100.3").
703 In particular, the "bnc" parameter is forbidden from appearing in the
704 body of a reg-event NOTIFY request unless the subscriber has
705 indicated knowledge of the semantics of the "bnc" parameter. The
706 means for indicating this support are out of scope of this document.
708 Because the SSP does not necessarily know which GRUUs have been
709 issued by the SIP-PBX to its associated UAs, these records will not
710 generally the contain or elements defined in
711 RFC 5628 [9]. This information can be learned, if necessary, by
712 subscribing to the individual AOR registration state, as described in
713 Section 7.2.2.
715 7.2.2. Individual AOR Registration State
717 As described in Section 6, the SSP will generally retarget all
718 requests addressed to an AOR owned by a SIP-PBX to that SIP-PBX
719 according to the mapping established at registration time. Although
720 policy at the SSP may override this generally expected behavior,
721 proper behavior of the registration event package requires that all
722 "reg" event SUBSCRIBE requests are processed by the SIP-PBX. As a
723 consequence, the requirements on an SSP for processing registration
724 event package SUBSCRIBE requests are not left to policy.
726 If the SSP receives a SUBSCRIBE request for the registration event
727 package with a Request-URI that indicates an AOR registered via the
728 "Bulk Number Contact" mechanism defined in this document, then the
729 SSP MUST proxy that SUBSCRIBE to the SIP-PBX in the same way that it
730 would proxy an INVITE bound for that AOR, unless the SSP has and can
731 maintain a copy of complete, accurate, and up-to-date information
732 from the SIP-PBX (e.g., through an active back-end subscription).
734 If the Request-URI in a SUBSCRIBE request for the registration event
735 package indicates a contact that is registered by more than one SIP-
736 PBX, then the SSP proxy will fork the SUBSCRIBE request to all the
737 applicable SIP-PBXes. Similarly, if the Request-URI corresponds to a
738 contact that is both implicitly registered by a SIP-PBX and
739 explicitly registered directly with the SSP proxy, then the SSP proxy
740 will semantically fork the SUBSCRIBE request to the applicable SIP-
741 PBX or SIP-PBXes and to the SSP registrar function (which will
742 respond with registration data corresponding to the explicit
743 registrations at the SSP). The forking in both of these cases can be
744 avoided if the SSP has and can maintain a copy of up-to-date
745 information from the PBXes.
747 Section 4.9 of RFC 3680 [12] indicates that "a subscriber MUST NOT
748 create multiple dialogs as a result of a single [registration event]
749 subscription request." Consequently, subscribers who are not aware
750 of the extension described by this document will accept only one
751 dialog in response to such requests. In the case described in the
752 preceding paragraph, this behavior will result in such client
753 receiving accurate but incomplete information about the registration
754 state of an AOR. As an explicit change to the normative behavior of
755 RFC 3680, this document stipulates that subscribers to the
756 registration event package MAY create multiple dialogs as the result
757 of a single subscription request. This will allow subscribers to
758 create a complete view of an AOR's registration state.
760 Defining the behavior as described above is important, since the reg-
761 event subscriber is interested in finding out about the comprehensive
762 list of devices associated with the AOR. Only the SIP-PBX will have
763 authoritative access to this information. For example, if the user
764 has registered multiple UAs with differing capabilities, the SSP will
765 not know about the devices or their capabilities. By contrast, the
766 SIP-PBX will.
768 If the SIP-PBX is not registered with the SSP when a registration
769 event subscription for a contact that would be implicitly registered
770 if the SIP-PBX were registered, then the SSP SHOULD accept the
771 subscription and indicate that the user is not currently registered.
772 Once the associated SIP-PBX is registered, the SSP SHOULD use the
773 subscription migration mechanism defined in RFC 3265 [6] to migrate
774 the subscription to the SIP-PBX.
776 When a SIP-PBX receives a registration event subscription addressed
777 to an AOR that has been registered using the bulk registration
778 mechanism described in this document, then each resulting
779 registration information document SHOULD contain an 'aor' attribute
780 in its element that corresponds to the AOR at the
781 SSP.
783 For example, consider a SIP-PBX that has registered with an SSP
784 that has a domain of "ssp.example.com" The SIP-PBX used a contact
785 of "sip:198.51.100.3:5060;bnc". After such registration is
786 complete, a registration event subscription arriving at the SSP
787 with a Request-URI of "sip:+12145550102@ssp.example.com" will be
788 re-targeted to the SIP-PBX, with a Request-URI of
789 "sip:+12145550102@198.51.100.3:5060". The resulting registration
790 document created by the SIP-PBX would contain a
791 element with an "aor" attribute of
792 "sip:+12145550102@ssp.example.com".
794 This behavior ensures that subscribers external to the system (and
795 unaware of GIN procedures) will be able to find the relevant
796 information in the registration document (since they will be
797 looking for the publicly-visible AOR, not the address used for
798 sending information from the SSP to the SIP-PBX).
800 A SIP-PBX that supports both GRUU procedures and the registration
801 event packages SHOULD implement the extension defined in RFC 5628
802 [9].
804 7.3. Client-Initiated (Outbound) Connections
806 RFC 5626 [16] defines a mechanism that allows UAs to establish long-
807 lived TCP connections or UDP associations with a proxy in a way that
808 allows bidirectional traffic between the proxy and the UA. This
809 behavior is particularly important in the presence of NATs, and
810 whenever TLS security is required. Neither the SSP nor the SIP-PBX
811 is required to support client-initiated connections.
813 The outbound mechanism generally works with the solution defined in
814 this document without any modifications. Implementors should note
815 that the instance ID used between the SIP-PBX and the SSP's registrar
816 identifies the SIP-PBX itself, and not any of the UAs registered with
817 the SIP-PBX. As a consequence, any attempts to use caller
818 preferences (defined in RFC 3841[14]) to target a specific instance
819 are likely to fail. This shouldn't be an issue, as the preferred
820 mechanism for targeting specific instances of a user agent is GRUU
821 (see Section 7.1).
823 7.4. Non-Adjacent Contact Registration (Path) and Service Route
824 Discovery
826 RFC 3327 [10] defines a means by which a registrar and its associated
827 proxy can be informed of a route that is to be used between the proxy
828 and the registered user agent. The scope of the route created by a
829 "Path" header field is contact-specific; if an AOR has multiple
830 contacts associated with it, the routes associated with each contact
831 may be different from each other. Support for non-adjacent contact
832 registration is required in all SSPs and SIP-PBXes implementing the
833 multiple-AOR-registration protocol described in this document.
835 At registration time, any proxies between the user agent and the
836 registrar may add themselves to the Path. By doing so, they request
837 that any requests destined to the user agent as a result of the
838 associated registration include them as part of the Route towards the
839 User Agent. Although the Path mechanism does deliver the final Path
840 value to the registering UA, UAs typically ignore the value of the
841 Path.
843 To provide similar functionality in the opposite direction -- that
844 is, to establish a route for requests sent by a registering UA -- RFC
845 3608 [11] defines a means by which a UA can be informed of a route
846 that is to be used by the UA to route all outbound requests
847 associated with the AOR used in the registration. This information
848 is scoped to the AOR within the UA, and is not specific to the
849 Contact (or Contacts) in the REGISTER request. Support of service
850 route discovery is optional in SSPs and SIP-PBXes.
852 The registrar unilaterally generates the values of the service route
853 using whatever local policy it wishes to apply. Although it is
854 common to use the Path and/or Route information in the request in
855 composing the Service-Route, registrar behavior is not constrained in
856 any way that requires it to do so.
858 In considering the interaction between these mechanisms and the
859 registration of multiple AORs in a single request, implementors of
860 proxies, registrars, and intermediaries must keep in mind the
861 following issues, which stem from the fact that GIN effectively
862 registers multiple AORs and multiple Contacts.
864 First, all location service records that result from expanding a
865 single Contact containing a "bnc" parameter will necessarily share a
866 single path. Proxies will be unable to make policy decisions on a
867 contact-by-contact basis regarding whether to include themselves in
868 the path. Second, and similarly, all AORs on the SIP-PBX that are
869 registered with a common REGISTER request will be forced to share a
870 common Service-Route.
872 One interesting technique that Path and Service-Route enable is the
873 inclusion of a token or cookie in the user portion of the Service-
874 Route or Path entries. This token or cookie may convey information
875 to proxies about the identity, capabilities, and/or policies
876 associated with the user. Since this information will be shared
877 among several AORs and several Contacts when multiple AOR
878 registration is employed, care should be taken to ensure that doing
879 so is acceptable for all AORs and all Contacts registered in a single
880 REGISTER request.
882 8. Examples
884 8.1. Usage Scenario: Basic Registration
886 This example shows the message flows for a basic bulk REGISTER
887 transaction, followed by an INVITE addressed to one of the registered
888 UAs. Example messages are shown after the sequence diagram.
890 Internet SSP SIP-PBX
891 | | |
892 | |(1) REGISTER |
893 | |Contact: |
894 | |<--------------------------------|
895 | | |
896 | |(2) 200 OK |
897 | |-------------------------------->|
898 | | |
899 |(3) INVITE | |
900 |sip:+12145550105@ssp.example.com| |
901 |------------------------------->| |
902 | | |
903 | |(4) INVITE |
904 | |sip:+12145550105@198.51.100.3 |
905 | |-------------------------------->|
907 (1) The SIP-PBX registers with the SSP for a range of AORs.
909 REGISTER sip:ssp.example.com SIP/2.0
910 Via: SIP/2.0/UDP 198.51.100.3:5060;branch=z9hG4bKnashds7
911 Max-Forwards: 70
912 To:
913 From: ;tag=a23589
914 Call-ID: 843817637684230@998sdasdh09
915 CSeq: 1826 REGISTER
916 Proxy-Require: gin
917 Require: gin
918 Supported: path
919 Contact:
920 Expires: 7200
921 Content-Length: 0
922 (3) The SSP receives a request for an AOR assigned
923 to the SIP-PBX.
925 INVITE sip:+12145550105@ssp.example.com SIP/2.0
926 Via: SIP/2.0/UDP foo.example;branch=z9hG4bKa0bc7a0131f0ad
927 Max-Forwards: 69
928 To:
929 From: ;tag=456248
930 Call-ID: f7aecbfc374d557baf72d6352e1fbcd4
931 CSeq: 24762 INVITE
932 Contact:
933 Content-Type: application/sdp
934 Content-Length: ...
936
938 (4) The SSP retargets the incoming request according to the
939 information received from the SIP-PBX at registration time.
941 INVITE sip:+12145550105@198.51.100.3 SIP/2.0
942 Via: SIP/2.0/UDP foo.example;branch=z9hG4bKa0bc7a0131f0ad
943 Via: SIP/2.0/UDP ssp.example.com;branch=z9hG4bKa45cd5c52a6dd50
944 Max-Forwards: 68
945 To:
946 From: ;tag=456248
947 Call-ID: 7ca24b9679ffe9aff87036a105e30d9b
948 CSeq: 24762 INVITE
949 Contact:
950 Content-Type: application/sdp
951 Content-Length: ...
953
955 8.2. Usage Scenario: Using Path to Control Request URI
957 This example shows a bulk REGISTER transaction with the SSP making
958 use of the "Path" header field extension [10]. This allows the SSP
959 to designate a domain on the incoming Request URI that does not
960 necessarily resolve to the SIP-PBX when the SSP applies RFC 3263
961 procedures to it.
963 Internet SSP SIP-PBX
964 | | |
965 | |(1) REGISTER |
966 | |Path: |
967 | |Contact: |
968 | |<--------------------------------|
969 | | |
970 | |(2) 200 OK |
971 | |-------------------------------->|
972 | | |
973 |(3) INVITE | |
974 |sip:+12145550105@ssp.example.com| |
975 |------------------------------->| |
976 | | |
977 | |(4) INVITE |
978 | |sip:+12145550105@pbx.example |
979 | |Route: |
980 | |-------------------------------->|
982 (1) The SIP-PBX registers with the SSP for a range of AORs.
983 It includes the form of the URI it expects to receive in the
984 Request-URI in its "Contact" header field, and includes
985 information that routes to the SIP-PBX in the "Path" header
986 field.
988 REGISTER sip:ssp.example.com SIP/2.0
989 Via: SIP/2.0/UDP 198.51.100.3:5060;branch=z9hG4bKnashds7
990 Max-Forwards: 70
991 To:
992 From: ;tag=a23589
993 Call-ID: 843817637684230@998sdasdh09
994 CSeq: 1826 REGISTER
995 Proxy-Require: gin
996 Require: gin
997 Supported: path
998 Path:
999 Contact:
1000 Expires: 7200
1001 Content-Length: 0
1002 (3) The SSP receives a request for an AOR assigned
1003 to the SIP-PBX.
1005 INVITE sip:+12145550105@ssp.example.com SIP/2.0
1006 Via: SIP/2.0/UDP foo.example;branch=z9hG4bKa0bc7a0131f0ad
1007 Max-Forwards: 69
1008 To:
1009 From: ;tag=456248
1010 Call-ID: f7aecbfc374d557baf72d6352e1fbcd4
1011 CSeq: 24762 INVITE
1012 Contact:
1013 Content-Type: application/sdp
1014 Content-Length: ...
1016
1018 (4) The SSP retargets the incoming request according to the
1019 information received from the SIP-PBX at registration time.
1020 Per the normal processing associated with "Path," it
1021 will insert the "Path" value indicated by the SIP-PBX at
1022 registration time in a "Route" header field, and
1023 set the request URI to the registered Contact.
1025 INVITE sip:+12145550105@pbx.example SIP/2.0
1026 Via: SIP/2.0/UDP foo.example;branch=z9hG4bKa0bc7a0131f0ad
1027 Via: SIP/2.0/UDP ssp.example.com;branch=z9hG4bKa45cd5c52a6dd50
1028 Route:
1029 Max-Forwards: 68
1030 To:
1031 From: ;tag=456248
1032 Call-ID: 7ca24b9679ffe9aff87036a105e30d9b
1033 CSeq: 24762 INVITE
1034 Contact:
1035 Content-Type: application/sdp
1036 Content-Length: ...
1038
1040 9. IANA Considerations
1042 This document registers a new SIP option tag to indicate support for
1043 the mechanism it defines, two new SIP URI parameters, and a "Contact"
1044 header field parameter.
1046 9.1. New SIP Option Tag
1048 This section defines a new SIP option tag per the guidelines in
1049 Section 27.1 of RFC 3261[4].
1050 Name: gin
1051 Description: This option tag is used to identify the extension that
1052 provides Registration for Multiple Phone Numbers in SIP. When
1053 present in a Require or Proxy-Require header field of a REGISTER
1054 request, it indicates that support for this extension is required
1055 of registrars and proxies, respectively, that are a party to the
1056 registration transaction.
1057 Reference: RFCXXXX (this document)
1059 9.2. New SIP URI Parameters
1061 This specification defines two new SIP URI parameters, as per the
1062 registry created by RFC 3969 [8].
1064 9.2.1. 'bnc' SIP URI parameter
1066 Parameter Name: bnc
1067 Predefined Values: No (no values are allowed)
1068 Reference: RFCXXXX (this document)
1070 9.2.2. 'sg' SIP URI parameter
1072 Parameter Name: sg
1073 Predefined Values: No
1074 Reference: RFCXXXX (this document)
1076 9.3. New SIP Header Field Parameter
1078 This section defines a new SIP header field parameter per the
1079 registry created by RFC3968 [7].
1081 Header field: Contact
1082 Parameter name: temp-gruu-cookie
1083 Predefined values: none
1084 Reference: RFCXXXX (this document)
1086 10. Security Considerations
1088 The change proposed for the mechanism described in this document
1089 takes the unprecedented step of extending the previously-defined
1090 REGISTER method to apply to more than one AOR. In general, this kind
1091 of change has the potential to cause problems at intermediaries --
1092 such as proxies -- that are party to the REGISTER transaction. In
1093 particular, such intermediaries may attempt to apply policy to the
1094 user indicated in the "To" header field (i.e. the SIP-PBX's
1095 identity), without any knowledge of the multiple AORs that are being
1096 implicitly registered.
1098 The mechanism defined by this document solves this issue by adding an
1099 option tag to a "Proxy-Require" header in such REGISTER requests.
1100 Proxies that are unaware of this mechanism will not process the
1101 requests, preventing them from mis-applying policy. Proxies that
1102 process requests with this option tag are clearly aware of the nature
1103 of the REGISTER request, and can make reasonable policy decisions.
1105 As noted in Section 7.4, intermediaries need to take care if they use
1106 a policy token in the Path and Service-Route mechanisms, as doing so
1107 will cause them to apply the same policy to all users serviced by the
1108 same SIP-PBX. This may frequently be the correct behavior, but
1109 circumstances can arise in which differentiation of user policy is
1110 required.
1112 One of the key properties of the outbound client connection mechanism
1113 discussed in Section 7.3 is assurances that a single connection is
1114 associated with a single user, and cannot be hijacked by other users.
1115 With the mechanism defined in this document, such connections
1116 necessarily become shared between users. However, the only entity in
1117 a position to hijack calls as a consequence is the SIP-PBX itself.
1118 Because the SIP-PBX acts as a registrar for all the potentially
1119 affected users, it already has the ability to redirect any such
1120 communications as it sees fit. In other words, the SIP-PBX must be
1121 trusted to handle calls in an appropriate fashion, and the use of the
1122 outbound connection mechanism introduces no additional
1123 vulnerabilities.
1125 The ability to learn the identity and registration state of every
1126 user on the PBX (as described in Section 7.2.1) is invaluable for
1127 diagnostic and administrative purposes. For example, this allows the
1128 SIP-PBX to determine whether all the its extensions are properly
1129 registered with the SSP. However, this information can also be
1130 highly sensitive, as many organizations may not wish to make their
1131 entire list of phone numbers available to external entities.
1132 Consequently, SSP servers are advised to use explicit (i.e. white-
1133 list) and configurable policies regarding who can access this
1134 information, with very conservative defaults (e.g., an empty access
1135 list or an access list consisting only of the PBX itself).
1137 The procedure for generation of temporary GRUUs requires the use of
1138 RSA keys. The selection of the proper key length for such keys
1139 requires careful analysis, taking into consideration the current and
1140 foreseeable speed of processing for the period of time during which
1141 GRUUs must remain anonymous, as well as emerging cryptographic
1142 analysis methods. The most recent guidance from RSA Laboratories
1143 [19] suggests a key length of 2048 bits for data that needs
1144 protection through the year 2030, and a length of 3072 bits
1145 thereafter.
1147 Similarly, implementors are warned to take precautionary measures to
1148 prevent unauthorized disclosure of the private key used in GRUU
1149 generation. Any such disclosure would result in the ability to
1150 correlate temporary GRUUs to each other, and potentially to their
1151 associated PBXes.
1153 Further, the use of RSA decryption when processing GRUUs received
1154 from arbitrary parties can be exploited by DoS attackers to amplify
1155 the impact of an attack: because of the presence of a cryptographic
1156 operation in the processing of such messages, the CPU load may be
1157 marginally higher when the attacker uses (valid or invalid) temporary
1158 GRUUs in the messages employed by such an attack. Normal DoS
1159 mitigation techniques, such as rate-limiting processing of received
1160 messages, should help to reduce the impact of this issue as well.
1162 Finally, good security practices should be followed regarding the
1163 duration an RSA key is used. For implementors, this means that
1164 systems MUST include an easy way to update the public key provided to
1165 the SIP-PBX. To avoid immediately invalidating all currently issued
1166 temporary GRUUs, the SSP servers SHOULD keep the retired RSA key
1167 around for a grace period before discarding it. If decryption fails
1168 based on the new RSA key, then the SSP server can attempt to use the
1169 retired key instead. By contrast, the SIP-PBXes MUST discard the
1170 retired public key immediately, and exclusively use the new public
1171 key.
1173 11. Acknowledgements
1175 This document represents the hard work of many people in the IETF
1176 MARTINI working group and the IETF RAI community as a whole.
1177 Particular thanks are owed to John Elwell for his requirements
1178 analysis of the mechanism described in this document, to Dean Willis
1179 for his analysis of the interaction between this mechanism and the
1180 Path and Service-Route extensions, to Cullen Jennings for his
1181 analysis of the interaction between this mechanism and the SIP
1182 Outbound extension, and to to Richard Barnes for his detailed
1183 security analysis of the GRUU construction algorithm. Thanks to Eric
1184 Rescorla, whose text in the appendix of RFC5627 was lifted directly
1185 to provide substantial portions of Section 7.1.2. Finally, thanks to
1186 Bernard Aboba, Francois Audet, John Elwell, David Hancock, Martien
1187 Huysmans, Cullen Jennings, Alan Johnston, Hadriel Kaplan, and Paul
1188 Kyzivat for their careful reviews of and constructive feedback on
1189 this document.
1191 12. References
1193 12.1. Normative References
1195 [1] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
1196 Extensions (MIME) Part One: Format of Internet Message Bodies",
1197 RFC 2045, November 1996.
1199 [2] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing
1200 for Message Authentication", RFC 2104, February 1997.
1202 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
1203 Levels", BCP 14, RFC 2119, March 1997.
1205 [4] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
1206 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
1207 Session Initiation Protocol", RFC 3261, June 2002.
1209 [5] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol
1210 (SIP): Locating SIP Servers", RFC 3263, June 2002.
1212 [6] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
1213 Notification", RFC 3265, June 2002.
1215 [7] Camarillo, G., "The Internet Assigned Number Authority (IANA)
1216 Header Field Parameter Registry for the Session Initiation
1217 Protocol (SIP)", BCP 98, RFC 3968, December 2004.
1219 [8] Camarillo, G., "The Internet Assigned Number Authority (IANA)
1220 Uniform Resource Identifier (URI) Parameter Registry for the
1221 Session Initiation Protocol (SIP)", BCP 99, RFC 3969,
1222 December 2004.
1224 [9] Kyzivat, P., "Registration Event Package Extension for Session
1225 Initiation Protocol (SIP) Globally Routable User Agent URIs
1226 (GRUUs)", RFC 5628, October 2009.
1228 12.2. Informative References
1230 [10] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP)
1231 Extension Header Field for Registering Non-Adjacent Contacts",
1232 RFC 3327, December 2002.
1234 [11] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP)
1235 Extension Header Field for Service Route Discovery During
1236 Registration", RFC 3608, October 2003.
1238 [12] Rosenberg, J., "A Session Initiation Protocol (SIP) Event
1239 Package for Registrations", RFC 3680, March 2004.
1241 [13] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating
1242 User Agent Capabilities in the Session Initiation Protocol
1243 (SIP)", RFC 3840, August 2004.
1245 [14] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller
1246 Preferences for the Session Initiation Protocol (SIP)",
1247 RFC 3841, August 2004.
1249 [15] Sparks, R., Hawrylyshen, A., Johnston, A., Rosenberg, J., and
1250 H. Schulzrinne, "Session Initiation Protocol (SIP) Torture Test
1251 Messages", RFC 4475, May 2006.
1253 [16] Jennings, C., Mahy, R., and F. Audet, "Managing Client-
1254 Initiated Connections in the Session Initiation Protocol
1255 (SIP)", RFC 5626, October 2009.
1257 [17] Rosenberg, J., "Obtaining and Using Globally Routable User
1258 Agent URIs (GRUUs) in the Session Initiation Protocol (SIP)",
1259 RFC 5627, October 2009.
1261 [18] Elwell, J. and H. Kaplan, "Requirements for Multiple Address of
1262 Record (AOR) Reachability Information in the Session Initiation
1263 Protocol (SIP)", RFC 5947, September 2010.
1265 [19] Kaliski, B., "TWIRL and RSA Key Size", May 2003.
1267 Appendix A. Requirements Analysis
1269 The document "Requirements for multiple address of record (AOR)
1270 reachability information in the Session Initiation Protocol (SIP)"
1271 [18] contains a list of requirements and desired properties for a
1272 mechanism to register multiple AORs with a single SIP transaction.
1273 This section evaluates those requirements against the mechanism
1274 described in this document.
1276 REQ1 - The mechanism MUST allow a SIP-PBX to enter into a trunking
1277 arrangement with an SSP whereby the two parties have agreed on a set
1278 of telephone numbers deemed to have been assigned to the SIP-PBX.
1280 The requirement is satisfied.
1282 REQ2 - The mechanism MUST allow a set of assigned telephone numbers
1283 to comprise E.164 numbers, which can be in contiguous ranges,
1284 discrete, or in any combination of the two.
1286 The requirement is satisfied; the DIDs associated with a
1287 registration is established by bilateral agreement between the SSP
1288 and the SIP-PBX, and is not part of the mechanism described in
1289 this document.
1291 REQ3 - The mechanism MUST allow a SIP-PBX to register reachability
1292 information with its SSP, in order to enable the SSP to route to the
1293 SIP-PBX inbound requests targeted at assigned telephone numbers.
1295 The requirement is satisfied.
1297 REQ4 - The mechanism MUST allow UAs attached to a SIP-PBX to register
1298 with the SIP-PBX for AORs based on assigned telephone numbers, in
1299 order to receive requests targeted at those telephone numbers,
1300 without needing to involve the SSP in the registration process.
1302 The requirement is satisfied; in the presumed architecture, SIP-
1303 PBX UAs register with the SIP-PBX, an require no interaction with
1304 the SSP.
1306 REQ5 - The mechanism MUST allow a SIP-PBX to handle requests
1307 originating at its own UAs and targeted at its assigned telephone
1308 numbers, without routing those requests to the SSP.
1310 The requirement is satisfied; SIP-PBXes may recognize their own
1311 DID and their own GRUUs, and perform on-SIP-PBX routing without
1312 sending the requests to the SSP.
1314 REQ6 - The mechanism MUST allow a SIP-PBX to receive requests to its
1315 assigned telephone numbers originating outside the SIP-PBX and
1316 arriving via the SSP, so that the SIP-PBX can route those requests
1317 onwards to its UAs, as it would for internal requests to those
1318 telephone numbers.
1320 The requirement is satisfied
1322 REQ7 - The mechanism MUST provide a means whereby a SIP-PBX knows
1323 which of its assigned telephone numbers an inbound request from its
1324 SSP is targeted at.
1326 The requirement is satisfied. For ordinary calls and calls using
1327 Public GRUUs, the DID is indicated in the user portion of the
1328 Request-URI. For calls using Temp GRUUs constructed with the
1329 mechanism described in Section 7.1.2, the "gr" parameter provides
1330 a correlation token the SIP-PBX can use to identify which UA the
1331 call should be routed to.
1333 REQ8 - The mechanism MUST provide a means of avoiding problems due to
1334 one side using the mechanism and the other side not.
1336 The requirement is satisfied through the 'gin' option tag and the
1337 'bnc' Contact parameter.
1339 REQ9 - The mechanism MUST observe SIP backwards compatibility
1340 principles.
1342 The requirement is satisfied through the 'gin' option tag.
1344 REQ10 - The mechanism MUST work in the presence of a sequence of
1345 intermediate SIP entities on the SIP-PBX-to-SSP interface (i.e.,
1346 between the SIP-PBX and the SSP's domain proxy), where those
1347 intermediate SIP entities indicated during registration a need to be
1348 on the path of inbound requests to the SIP-PBX.
1350 The requirement is satisfied through the use of the Path mechanism
1351 defined in RFC 3327 [10]
1353 REQ11 - The mechanism MUST work when a SIP-PBX obtains its IP address
1354 dynamically.
1356 The requirement is satisfied by allowing the SIP-PBX to use an IP
1357 address in the Bulk Number Contact URI contained in a REGISTER
1358 Contact header field.
1360 REQ12 - The mechanism MUST work without requiring the SIP-PBX to have
1361 a domain name or the ability to publish its domain name in the DNS.
1363 The requirement is satisfied by allowing the SIP-PBX to use an IP
1364 address in the Bulk Number Contact URI contained in a REGISTER
1365 Contact header field.
1367 REQ13 - For a given SIP-PBX and its SSP, there MUST be no impact on
1368 other domains, which are expected to be able to use normal RFC 3263
1369 procedures to route requests, including requests needing to be routed
1370 via the SSP in order to reach the SIP-PBX.
1372 The requirement is satisfied by allowing the domain name in the
1373 Request URI used by external entities to resolve to the SSP's
1374 servers via normal RFC 3263 resolution procedures.
1376 REQ14 - The mechanism MUST be able to operate over a transport that
1377 provides end-to-end integrity protection and confidentiality between
1378 the SIP-PBX and the SSP, e.g., using TLS as specified in [4].
1380 The requirement is satisfied; nothing in the proposed mechanism
1381 prevent the use of TLS between the SSP and the SIP-PBX.
1383 REQ15 - The mechanism MUST support authentication of the SIP-PBX by
1384 the SSP and vice versa, e.g., using SIP digest authentication plus
1385 TLS server authentication as specified in [4].
1387 The requirement is satisfied; SIP-PBXes may employ either SIP
1388 digest authentication or mutually-authenticated TLS for
1389 authentication purposes.
1391 REQ16 - The mechanism MUST allow the SIP-PBX to provide its UAs with
1392 public or temporary Globally Routable UA URIs (GRUUs) [17].
1394 The requirement is satisfied via the mechanisms detailed in
1395 Section 7.1.
1397 REQ17 - The mechanism MUST work over any existing transport specified
1398 for SIP, including UDP.
1400 The requirement is satisfied to the extent that UDP can be used
1401 for REGISTER requests in general. The application of certain
1402 extensions and/or network topologies may exceed UDP MTU sizes, but
1403 such issues arise both with and without the mechanism described in
1404 this document. This document does not exacerbate such issues.
1406 DES1 - The mechanism SHOULD allow an SSP to exploit its mechanisms
1407 for providing SIP service to ordinary subscribers in order to provide
1408 a SIP trunking service to SIP-PBXes.
1410 The desired property is satisfied; the routing mechanism described
1411 in this document is identical to the routing performed for singly-
1412 registered AORs.
1414 DES2 - The mechanism SHOULD scale to SIP-PBX's of several thousand
1415 assigned telephone numbers.
1417 The desired property is satisfied; nothing in this document
1418 precludes DID pools of arbitrary size.
1420 DES3 - The mechanism SHOULD scale to support several thousand SIP-
1421 PBX's on a single SSP.
1423 The desired property is satisfied; nothing in this document
1424 precludes an arbitrary number of SIP-PBXes from attaching to a
1425 single SSP.
1427 Author's Address
1429 Adam Roach
1430 Tekelec
1431 17210 Campbell Rd.
1432 Suite 250
1433 Dallas, TX 75252
1434 US
1436 Email: adam@nostrum.com