idnits 2.17.1
draft-ietf-martini-gin-13.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 (January 20, 2011) is 4844 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. '1')
** Obsolete normative reference: RFC 3265 (ref. '5') (Obsoleted by RFC 6665)
-- Obsolete informational reference (is this intentional?): RFC 5246 (ref.
'18') (Obsoleted by RFC 8446)
Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 4 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) January 20, 2011
5 Intended status: Standards Track
6 Expires: July 24, 2011
8 Registration for Multiple Phone Numbers in the Session Initiation
9 Protocol (SIP)
10 draft-ietf-martini-gin-13
12 Abstract
14 This document defines a mechanism by which a Session Initiation
15 Protocol (SIP) server acting as a traditional Private Branch Exchange
16 (SIP-PBX) can register with a SIP Service Provider (SSP) to receive
17 phone calls for SIP User Agents (UAs). In order to function
18 properly, this mechanism requires that each of the Addresses of
19 Record (AORs) registered in bulk map to a unique set of contacts.
20 This requirement is satisfied by AORs representing phone numbers
21 regardless of the domain, since phone numbers are fully qualified and
22 globally unique. This document therefore focuses on this use case.
24 Status of this Memo
26 This Internet-Draft is submitted in full conformance with the
27 provisions of BCP 78 and BCP 79.
29 Internet-Drafts are working documents of the Internet Engineering
30 Task Force (IETF). Note that other groups may also distribute
31 working documents as Internet-Drafts. The list of current Internet-
32 Drafts is at http://datatracker.ietf.org/drafts/current/.
34 Internet-Drafts are draft documents valid for a maximum of six months
35 and may be updated, replaced, or obsoleted by other documents at any
36 time. It is inappropriate to use Internet-Drafts as reference
37 material or to cite them other than as "work in progress."
39 This Internet-Draft will expire on July 24, 2011.
41 Copyright Notice
43 Copyright (c) 2011 IETF Trust and the persons identified as the
44 document authors. All rights reserved.
46 This document is subject to BCP 78 and the IETF Trust's Legal
47 Provisions Relating to IETF Documents
48 (http://trustee.ietf.org/license-info) in effect on the date of
49 publication of this document. Please review these documents
50 carefully, as they describe your rights and restrictions with respect
51 to this document. Code Components extracted from this document must
52 include Simplified BSD License text as described in Section 4.e of
53 the Trust Legal Provisions and are provided without warranty as
54 described in the Simplified BSD License.
56 Table of Contents
58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
59 2. Constraints . . . . . . . . . . . . . . . . . . . . . . . . . 3
60 3. Terminology and Conventions . . . . . . . . . . . . . . . . . 4
61 4. Mechanism Overview . . . . . . . . . . . . . . . . . . . . . . 5
62 5. Registering for Multiple Phone Numbers . . . . . . . . . . . . 5
63 5.1. SIP-PBX Behavior . . . . . . . . . . . . . . . . . . . . . 5
64 5.2. Registrar Behavior . . . . . . . . . . . . . . . . . . . . 6
65 5.3. SIP URI "user" Parameter Handling . . . . . . . . . . . . 8
66 6. SSP Processing of Inbound Requests . . . . . . . . . . . . . . 8
67 7. Interaction with Other Mechanisms . . . . . . . . . . . . . . 9
68 7.1. Globally Routable User-Agent URIs (GRUU) . . . . . . . . . 9
69 7.1.1. Public GRUUs . . . . . . . . . . . . . . . . . . . . . 9
70 7.1.2. Temporary GRUUs . . . . . . . . . . . . . . . . . . . 11
71 7.2. Registration Event Package . . . . . . . . . . . . . . . . 15
72 7.2.1. SIP-PBX Aggregate Registration State . . . . . . . . . 16
73 7.2.2. Individual AOR Registration State . . . . . . . . . . 16
74 7.3. Client-Initiated (Outbound) Connections . . . . . . . . . 18
75 7.4. Non-Adjacent Contact Registration (Path) and Service
76 Route Discovery . . . . . . . . . . . . . . . . . . . . . 18
77 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
78 8.1. Usage Scenario: Basic Registration . . . . . . . . . . . . 20
79 8.2. Usage Scenario: Using Path to Control Request URI . . . . 22
80 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
81 9.1. New SIP Option Tag . . . . . . . . . . . . . . . . . . . . 24
82 9.2. New SIP URI Parameters . . . . . . . . . . . . . . . . . . 24
83 9.2.1. 'bnc' SIP URI parameter . . . . . . . . . . . . . . . 25
84 9.2.2. 'sg' SIP URI parameter . . . . . . . . . . . . . . . . 25
85 9.3. New SIP Header Field Parameter . . . . . . . . . . . . . . 25
86 10. Security Considerations . . . . . . . . . . . . . . . . . . . 25
87 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27
88 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
89 12.1. Normative References . . . . . . . . . . . . . . . . . . . 28
90 12.2. Informative References . . . . . . . . . . . . . . . . . . 28
91 Appendix A. Requirements Analysis . . . . . . . . . . . . . . . . 30
92 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 34
94 1. Introduction
96 The Session Initiation Protocol (SIP) is an application-layer control
97 (signaling) protocol for creating, modifying, and terminating
98 sessions with one or more participants. One of SIP's primary
99 functions is providing rendezvous between users. By design, this
100 rendezvous has been provided through a combination of the server
101 look-up procedures defined in RFC 3263 [4], and the registrar
102 procedures described in RFC 3261 [3].
104 The intention of the original protocol design was that any user's AOR
105 (Address of Record) would be handled by the authority indicated by
106 the hostport portion of the AOR. The users would register individual
107 reachability information with this authority, which would then route
108 incoming requests accordingly.
110 In actual deployments, some SIP servers have been deployed in
111 architectures that, for various reasons, have requirements to provide
112 dynamic routing information for large blocks of AORs, where all of
113 the AORs in the block were to be handled by the same server. For
114 purposes of efficiency, many of these deployments do not wish to
115 maintain separate registrations for each of the AORs in the block.
116 This leads to the desire for an alternate mechanism for providing
117 dynamic routing information for blocks of AORs.
119 Although the use of SIP REGISTER request messages to update
120 reachability information for multiple users simultaneously is
121 somewhat beyond the original semantics defined for REGISTER requests
122 by RFC 3261 [3], this approach has seen significant deployment in
123 certain environments. In particular, deployments in which small to
124 medium SIP-PBX servers are addressed using E.164 numbers have used
125 this mechanism to avoid the need to maintain DNS entries or static IP
126 addresses for the SIP-PBX servers.
128 In recognition of the momentum that REGISTER-based approaches have
129 seen in deployments, this document defines a REGISTER-based approach.
130 Since E.164-addressed UAs are very common today in SIP-PBX
131 environments, and since SIP URIs in which the user portion is an
132 E.164 number are always globally unique regardless of the domain,
133 this document focuses on registration of SIP URIs in which the user
134 portion is an E.164 number.
136 2. Constraints
138 Within the problem space that has been established for this work,
139 several constraints shape our solution. These are defined in the
140 MARTINI requirements document [22], and analyzed in Appendix A. In
141 terms of impact to the solution at hand, the following two
142 constraints have the most profound effect: (1) The SIP-PBX cannot be
143 assumed to be assigned a static IP address; and (2) No DNS entry can
144 be relied upon to consistently resolve to the IP address of the SIP-
145 PBX.
147 3. Terminology and Conventions
149 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
150 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
151 document are to be interpreted as described in RFC 2119 [2].
153 Further, the term "SSP" is meant as an acronym for a "SIP Service
154 Provider," while the term "SIP-PBX" is used to indicate a SIP Private
155 Branch Exchange.
157 Indented portions of the document, such as this one, form non-
158 normative, explanatory sections of the document.
160 Although SIP is a text-based protocol, some of the examples in this
161 document cannot be unambiguously rendered without additional markup
162 due to the constraints placed on the formatting of RFCs. This
163 document uses the markup convention established in RFC
164 4475 [17] to avoid ambiguity and meet the RFC layout requirements.
165 For the sake of completeness, the text defining this markup from
166 Section 2.1 of RFC 4475 [17] is reproduced in its entirety below:
168 Several of these examples contain unfolded lines longer than 72
169 characters. These are captured between tags. The
170 single unfolded line is reconstructed by directly concatenating
171 all lines appearing between the tags (discarding any line feeds or
172 carriage returns). There will be no whitespace at the end of
173 lines. Any whitespace appearing at a fold-point will appear at
174 the beginning of a line.
176 The following represent the same string of bits:
178 Header-name: first value, reallylongsecondvalue, third value
180
181 Header-name: first value,
182 reallylongsecondvalue
183 , third value
184
185
186 Header-name: first value,
187 reallylong
188 second
189 value,
190 third value
191
193 Note that this is NOT SIP header-line folding, where different
194 strings of bits have equivalent meaning.
196 4. Mechanism Overview
198 The overall mechanism is achieved using a REGISTER request with a
199 specially-formatted Contact URI. This document also defines an
200 option tag that can be used to ensure a registrar and any
201 intermediaries understand the mechanism described herein.
203 The Contact URI itself is tagged with a URI parameter to indicate
204 that it actually represents multiple phone-number-associated
205 contacts.
207 We also define some lightweight extensions to the Globally Routable
208 UA URIs (GRUU) mechanism defined by RFC 5627 [20] to allow the use of
209 public and temporary GRUUs assigned by the SSP.
211 Aside from these extensions, the REGISTER request itself is processed
212 by a registrar in the same way as normal registrations: by updating
213 its location service with additional AOR-to-Contact bindings.
215 Note that the list of AORs associated with a SIP-PBX is a matter of
216 local provisioning at the SSP and at the SIP-PBX. The mechanism
217 defined in this document does not provide any means to detect or
218 recover from provisioning mismatches (although the registration event
219 package can be used as a standardized means for auditing such AORs;
220 see Section 7.2.1).
222 5. Registering for Multiple Phone Numbers
224 5.1. SIP-PBX Behavior
226 To register for multiple AORs, the SIP-PBX sends a REGISTER request
227 to the SSP. This REGISTER request varies from a typical REGISTER
228 request in two important ways. First, it MUST contain an option tag
229 of "gin" in both a "Require" header field and a "Proxy-Require"
230 header field. (The option tag "gin" is an acronym for "generate
231 implicit numbers".) Second, in at least one "Contact" header field,
232 it MUST include a Contact URI that contains the URI parameter "bnc"
233 (which stands for "bulk number contact"), and no user portion (hence
234 no "@" symbol). A URI with a "bnc" parameter MUST NOT contain a user
235 portion. Except for the SIP URI "user" parameter, this URI MAY
236 contain any other parameters that the SIP-PBX desires. These
237 parameters will be echoed back by the SSP in any requests bound for
238 the SIP-PBX.
240 Because of the constraints discussed in Section 2, the host portion
241 of the Contact URI will generally contain an IP address, although
242 nothing in this mechanism enforces or relies upon that fact. If the
243 SIP-PBX operator chooses to maintain DNS entries that resolve to the
244 IP address of his SIP-PBX via RFC 3263 resolution procedures, then
245 this mechanism works just fine with domain names in the Contact
246 header field.
248 The "bnc" URI parameter indicates that special interpretation of the
249 Contact URI is necessary: instead of indicating the insertion of a
250 single Contact URI into the location service, it indicates that
251 multiple URIs (one for each associated AOR) should be inserted.
253 Any SIP-PBX implementing the registration mechanism defined in this
254 document MUST also support the Path mechanism defined by RFC 3327
255 [10], and MUST include a 'path' option-tag in the Supported header
256 field of the REGISTER request (which is a stronger requirement than
257 imposed by the Path mechanism itself). This behavior is necessary
258 because proxies between the SIP-PBX and the Registrar may need to
259 insert Path header field values in the REGISTER request for this
260 document's mechanism to function properly, and per RFC 3327 [10],
261 they can only do so if the User Agent Client (UAC) inserted the
262 option-tag in the Supported header field. In accordance with the
263 procedures defined in RFC 3327 [10], the SIP-PBX is allowed to ignore
264 the Path header fields returned in the REGISTER response.
266 5.2. Registrar Behavior
268 The registrar, upon receipt of a REGISTER request containing at least
269 one Contact header field with a "bnc" parameter will use the value in
270 the "To" header field to identify the SIP-PBX for which registration
271 is being requested. It then authenticates the SIP-PBX (using, e.g.,
272 SIP Digest authentication, mutual TLS [18], or some other
273 authentication mechanism). After the SIP-PBX is authenticated, the
274 registrar updates its location service with a unique AOR-to-Contact
275 mapping for each of the AORs associated with the SIP-PBX.
276 Semantically, each of these mappings will be treated as a unique row
277 in the location service. The actual implementation may, of course,
278 perform internal optimizations to reduce the amount of memory used to
279 store such information.
281 For each of these unique rows, the AOR will be in the format that the
282 SSP expects to receive from external parties (e.g.
283 "sip:+12145550102@ssp.example.com"), and the corresponding Contact
284 will be formed by adding to the REGISTER request's Contact URI a user
285 portion containing the fully-qualified, E.164-formatted number
286 (including the preceding "+" symbol) and removing the "bnc"
287 parameter. Aside from the initial "+" symbol, this E.164-formatted
288 number MUST consist exclusively of digits from 0 through 9, and
289 explicitly MUST NOT contain any visual separator symbols (e.g., "-",
290 ".", "(", or ")"). For example, if the "Contact" header field
291 contains the URI , then the Contact value
292 associated with the aforementioned AOR will be
293 .
295 Although the SSP treats this registration as a number of discrete
296 rows for the purpose of re-targeting incoming requests, the renewal,
297 expiration, and removal of these rows is bound to the registered
298 contact. In particular, this means that REGISTER requests that
299 attempt to de-register a single AOR that has been implicitly
300 registered MUST NOT remove that AOR from the bulk registration. In
301 this circumstance, the registrar simply acts as if the UA attempted
302 to unregister a contact that wasn't actually registered (e.g., return
303 the list of presently registered contacts in a success response). A
304 further implication of this property is that an individual extension
305 that is implicitly registered may also be explicitly registered using
306 a normal, non-bulk registration (subject to SSP policy). If such a
307 registration exists, it is refreshed independently of the bulk
308 registration, and is not removed when the bulk registration is
309 removed.
311 A registrar that receives a REGISTER request containing a Contact URI
312 with both a "bnc" parameter and a user portion MUST NOT send a 200-
313 class (success) response. If no other error is applicable, the
314 registrar can use a 400 (Bad Request) response to indicate this error
315 condition.
317 Note that the preceding paragraph is talking about the user
318 portion of a URI:
320 sip:+12145550100@example.com
321 ^^^^^^^^^^^^
323 A Registrar compliant with this document MUST support the Path
324 mechanism defined in RFC 3327 [10]. The rationale for support of
325 this mechanism is given in section Section 5.1.
327 Aside from the "bnc" parameter, all URI parameters present on the
328 "Contact" URI in the REGISTER request MUST be copied to the Contact
329 value stored in the location service.
331 If the SSP servers perform processing based on User Agent
332 Capabilities (as defined in RFC 3840 [13]), they will treat any
333 feature tags present on a Contact header field with a "bnc" parameter
334 in its URI as applicable to all of the resulting AOR-to-Contact
335 mappings. Similarly, any option tags present on the REGISTER request
336 that indicate special handling for any subsequent requests are also
337 applicable to all of the AOR-to-Contact mappings.
339 5.3. SIP URI "user" Parameter Handling
341 This document does not modify the behavior specified in RFC 3261 [3]
342 for inclusion of the "user" parameter on request URIs. However, to
343 avoid any ambiguity in handling at the SIP-PBX, the following
344 normative behavior is imposed on its interactions with the SSP.
346 When a SIP-PBX registers with an SSP using a contact containing a
347 "bnc" parameter, that contact MUST NOT include a "user" parameter. A
348 registrar that receives a REGISTER request containing a Contact URI
349 with both a "bnc" parameter and a "user" parameter MUST NOT send a
350 200-class (success) response. If no other error is applicable, the
351 registrar can use a 400 (Bad Request) response to indicate this error
352 condition.
354 Note that the preceding paragraph is talking about the "user"
355 parameter of a URI:
357 sip:+12145550100@example.com;user=phone
358 ^^^^^^^^^^
360 When a SIP-PBX receives a request from an SSP, and the Request-URI
361 contains a user portion corresponding to an AOR registered using a
362 contact containing a "bnc" parameter, then the SIP-PBX MUST NOT
363 reject the request (or otherwise cause the request to fail) due to
364 the absence, presence, or value of a "user" parameter on the Request-
365 URI.
367 6. SSP Processing of Inbound Requests
369 In general, after processing the AOR-to-Contact mapping described in
370 the preceding section, the SSP Proxy/Registrar (or equivalent entity)
371 performs traditional Proxy/Registrar behavior, based on the mapping.
372 For any inbound SIP requests whose AOR indicates an E.164 number
373 assigned to one of the SSP's customers, this will generally involve
374 setting the target set to the registered contacts associated with
375 that AOR, and performing request forwarding as described in section
376 16.6 of RFC 3261 [3]. An SSP using the mechanism defined in this
377 document MUST perform such processing for inbound INVITE requests and
378 SUBSCRIBE requests to the "reg" event package (see Section 7.2.2),
379 and SHOULD perform such processing for all other method types,
380 including unrecognized SIP methods.
382 7. Interaction with Other Mechanisms
384 The following sections describe the means by which this mechanism
385 interacts with relevant REGISTER-related extensions currently defined
386 by the IETF.
388 7.1. Globally Routable User-Agent URIs (GRUU)
390 To enable advanced services to work with UAs behind a SIP-PBX, it is
391 important that the GRUU mechanism defined by RFC 5627 [20] work
392 correctly with the mechanism defined by this document -- that is,
393 that User Agents served by the SIP-PBX can acquire and use GRUUs for
394 their own use.
396 7.1.1. Public GRUUs
398 Support of public GRUUs is OPTIONAL in SSPs and SIP-PBXes.
400 When a SIP-PBX registers a Bulk Number Contact (a Contact with a
401 "bnc" parameter), and also invokes GRUU procedures for that Contact
402 during registration, then the SSP will assign a public GRUU to the
403 SIP-PBX in the normal fashion. Because the URI being registered
404 contains a "bnc" parameter, the GRUU will also contain a "bnc"
405 parameter. In particular, this means that the GRUU will not contain
406 a user portion.
408 When a UA registers a contact with the SIP-PBX using GRUU procedures,
409 the SIP-PBX provides to the UA a public GRUU formed by adding an "sg"
410 parameter to the GRUU parameter it received from the SSP. This "sg"
411 parameter contains a disambiguation token that the SIP-PBX can use to
412 route inbound requests to the proper UA.
414 So, for example, when the SIP-PBX registers with the following
415 contact header field:
417 Contact: ;
418 +sip.instance=""
420 Then the SSP may choose to respond with a Contact header field that
421 looks like this:
423
424 Contact: ;
425 pub-gruu="sip:ssp.example.com;bnc;gr=urn:
426 uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6";
427 +sip.instance=""
428 ;expires=7200
429
431 When its own UAs register using GRUU procedures, the SIP-PBX can then
432 add whatever device identifier it feels appropriate in an "sg"
433 parameter, and present this value to its own UAs. For example,
434 assume the UA associated with the AOR "+12145550102" sent the
435 following Contact header field in its REGISTER request:
437 Contact: ;
438 +sip.instance=""
440 The SIP-PBX will add an "sg" parameter to the pub-gruu it received
441 from the SSP with a token that uniquely identifies the device
442 (possibly the URN itself; possibly some other identifier); insert a
443 user portion containing the fully-qualified E.164 number associated
444 with the UA; and return the result to the UA as its public GRUU. The
445 resulting Contact header field sent from the SIP-PBX to the
446 registering UA would look something like this:
448
449 Contact: ;
450 pub-gruu="sip:+12145550102@ssp.example.com;gr=urn:
451 uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6;sg=00:05:03:5e:70:a6";
452 +sip.instance=""
453 ;expires=3600
454
456 When an incoming request arrives at the SSP for a GRUU corresponding
457 to a bulk number contact ("bnc"), the SSP performs slightly different
458 processing for the GRUU than it would for a URI without a "bnc"
459 parameter. When the GRUU is re-targeted to the registered bulk
460 number contact, the SSP MUST copy the "sg" parameter from the GRUU to
461 the new target. The SIP-PBX can then use this "sg" parameter to
462 determine which user agent the request should be routed to. For
463 example, the first line of an INVITE request that has been re-
464 targeted to the SIP-PBX for the UA shown above would look like this:
466 INVITE sip:+12145550102@198.51.100.3;sg=00:05:03:5e:70:a6 SIP/2.0
468 7.1.2. Temporary GRUUs
470 In order to provide support for privacy, the SSP SHOULD implement the
471 temporary GRUU mechanism described in this section. Reasons for not
472 doing so would include systems with an alternative privacy mechanism
473 which maintains the integrity of public GRUUs (i.e., if public GRUUs
474 are anonymized then the anonymizer function would need to be capable
475 of providing as the anonymized URI a globally routable URI that
476 routes back only to the target identified by the original public
477 GRUU).
479 Temporary GRUUs are used to provide anonymity for the party creating
480 and sharing the GRUU. Being able to correlate two temporary GRUUs as
481 having originated from behind the same SIP-PBX violates this
482 principle of anonymity. Consequently, rather than relying upon a
483 single, invariant identifier for the SIP-PBX in its UA's temporary
484 GRUUs, we define a mechanism whereby the SSP provides the SIP-PBX
485 with sufficient information for the SIP-PBX to mint unique temporary
486 GRUUs. These GRUUs have the property that the SSP can correlate them
487 to the proper SIP-PBX, but no other party can do so. To achieve this
488 goal, we use a slight modification of the procedure described in
489 appendix A.2 of RFC 5627 [20].
491 The SIP-PBX needs to be able to construct a temp-gruu in a way that
492 the SSP can decode. In order to ensure that the SSP can decode
493 GRUUs, we need to standardize the algorithm for creation of temp-
494 gruus at the SIP-PBX. This allows the SSP to reverse the algorithm
495 to identify the registration entry that corresponds to the GRUU.
497 It is equally important that no party other than the SSP is capable
498 of decoding a temporary GRUU, including other SIP-PBXes serviced by
499 the SSP. To achieve this property, an SSP that supports temporary
500 GRUUs MUST create and store an asymmetric key pair, {K_e1,K_e2}.
501 K_e1 is kept secret by the SSP, while K_e2 is shared with the SIP-
502 PBXes via provisioning.
504 All base64 encoding discussed in the following sections MUST use the
505 character set and encoding defined in Section 4 of RFC 4648 [8],
506 except that any trailing "=" characters are discarded on encoding,
507 and added as necessary to decode.
509 The following sections make use of the term "HMAC-SHA256-80" to
510 describe a particular HMAC algorithm. In this document,
511 HMAC-SHA256-80 is defined to mean the application of the SHA-256 [24]
512 secure hashing algorithm, and truncating the results to 80 bits by
513 discarding the trailing (least significant) bits.
515 7.1.2.1. Generation of temp-gruu-cookie by the SSP
517 An SSP that supports temporary GRUUs MUST include a "temp-gruu-
518 cookie" parameter on all Contact header fields containing a "bnc"
519 parameter in a 200-class REGISTER response. This "temp-gruu-cookie"
520 MUST have the following properties:
522 1. It can be used by the SSP to uniquely identify the registration
523 to which it corresponds.
524 2. It is encoded using base64. This allows the SIP-PBX to decode it
525 into as compact a form as possible for use in its calculations.
526 3. It is of a fixed length. This allows for extraction of it once
527 the SIP-PBX has concatenated a distinguisher onto it.
528 4. The temp-gruu-cookie MUST NOT be forgeable by any party. In
529 other words, the SSP needs to be able to examine the cookie and
530 validate that it was generated by the SSP.
531 5. The temp-gruu-cookie MUST be invariant during the course of a
532 registration, including any refreshes to that registration. This
533 property is important, as it allows the SIP-PBX to examine the
534 temp-gruu-cookie to determine whether the temp-gruus it has
535 issued to its UAs are still valid.
537 The above properties can be met using the following algorithm, which
538 is non-normative. Implementors may chose to implement any algorithm
539 of their choosing for generation of the temp-gruu-cookie, as long as
540 it fulfills the five properties listed above.
542 The registrar maintains a counter, I. This counter is 48 bits
543 long, and initialized to zero. This counter is persistently
544 stored, using a back-end database or similar technique. When the
545 registrar creates the first temporary GRUU for a particular SIP-
546 PBX and instance ID (as defined by [20]), the registrar notes the
547 current value of the counter, I_i, and increments the counter in
548 the database. The registrar then maps I_i to the Contact and
549 instance ID using the database, a persistent hash-map or similar
550 technology. If the registration expires such that there are no
551 longer any contacts with that particular instance ID bound to the
552 GRUU, the registrar removes the mapping. Similarly, if the
553 temporary GRUUs are invalidated due to a change in Call-ID, the
554 registrar removes the current mapping from I_i to the AOR and
555 instance ID, notes the current value of the counter I_j, and
556 stores a mapping from I_j to the contact containing a "bnc"
557 parameter and instance ID. Based on these rules, the hash-map
558 will contain a single mapping for each contact containing a "bnc"
559 parameter and instance ID for which there is a currently valid
560 registration.
562 The registrar maintains a symmetric key SK_a, which is regenerated
563 every time the counter rolls over or is is reset. When the
564 counter rolls over or is reset, the registrar remembers the old
565 value of SK_a for a while. To generate a temp-gruu-cookie, the
566 registrar computes:
568 SA = HMAC(SK_a, I_i)
569 temp-gruu-cookie = base64enc(I_i || SA)
571 where || denotes concatenation. "HMAC" represents any suitably
572 strong HMAC algorithm; see RFC 2104 [1] for a discussion of HMAC
573 algorithms. One suitable HMAC algorithm for this purpose is HMAC-
574 SHA256-80.
576 7.1.2.2. Generation of temp-gruu by the SIP-PBX
578 According to RFC5627 [20] section 3.2, every registration refresh
579 generates a new temp-gruu that is valid for as long as the contact
580 remains registered. This property is both critical for the privacy
581 properties of temp-gruu and is expected by UAs that implement the
582 temp-gruu procedures. Nothing in this document should be construed
583 as changing this fundamental temp-gruu property in any way. SIP-
584 PBXes that implement temporary GRUUs MUST generate a new temp-gruu
585 according to the procedures in this section for every registration or
586 registration refresh from GRUU-supporting UAs attached to the SIP-
587 PBX.
589 Similarly, if the registration that a SIP-PBX has with its SSP
590 expires or is terminated, then the temp-gruu cookie it maintains with
591 the SSP will change. This change will invalidate all the temp-gruus
592 the SIP-PBX has issued to its UAs. If the SIP-PBX tracks this
593 information (e.g., to include elements in registration
594 event bodies, as described in RFC 5628 [9]), it can determine that
595 previously issued temp-gruus are invalid by observing a change in the
596 temp-gruu-cookie provided to it by the SSP.
598 A SIP-PBX that issues temporary GRUUs to its UAs MUST maintain an
599 HMAC key, PK_a. This value is used to validate that incoming GRUUs
600 were generated by the SIP-PBX.
602 To generate a new temporary GRUU for use by its own UAs, the SIP-PBX
603 MUST generate a random distinguisher value D. The length of this
604 value is up to implementors, but MUST be long enough to prevent
605 collisions among all the temporary GRUUs issued by the SIP-PBX. A
606 size of 80 bits or longer is RECOMMENDED. See RFC 4086 [16] for
607 further considerations on the generation of random numbers in a
608 security context. After generating the distinguisher D, the SIP-PBX
609 then MUST calculate:
611 M = base64dec(SSP-cookie) || D
612 E = RSA-Encrypt(K_e2, M)
613 PA = HMAC(PK_a, E)
615 Temp-Gruu-userpart = "tgruu." || base64(E) || "." || base64(PA)
617 where || denotes concatenation. "HMAC" represents any suitably
618 strong HMAC algorithm; see RFC 2104 [1] for a discussion of HMAC
619 algorithms. One suitable HMAC algorithm for this purpose is HMAC-
620 SHA256-80.
622 Finally, the SIP-PBX adds a "gr" parameter to the temporary GRUU that
623 can be used to uniquely identify the UA registration record to which
624 the GRUU corresponds. The means of generation of the "gr" parameter
625 are left to the implementor, as long as they satisfy the properties
626 of a GRUU as described in RFC 5627 [20].
628 One valid approach for generation of the "gr" parameter is
629 calculation of "E" and "A" as described in Appendix A.2 of RFC
630 5627 [20], and forming the "gr" parameter as:
632 gr = base64enc(E) || base64enc(A)
634 Using this procedure may result in a temporary GRUU returned to the
635 registering UA by the SIP-PBX that looks similar to this:
637
638 Contact:
639 ;temp-gruu="sip:tgruu.MQyaRiLEd78RtaWkcP7N8Q.5qVbsasdo2pkKw@
640 ssp.example.com;gr=YZGSCjKD42ccxO08pA7HwAM4XNDIlMSL0HlA"
641 ;+sip.instance=""
642 ;expires=3600
643
645 7.1.2.3. Decoding of temp-gruu by the SSP
647 When the SSP proxy receives a request in which the user part begins
648 with "tgruu.", it extracts the remaining portion, and splits it at
649 the "." character into E' and PA'. It discards PA'. It then
650 computes E by performing a base64 decode of E'. Next, it computes:
652 M = RSA-Decrypt(K_e1, E)
654 The SSP proxy extracts the fixed-length temp-gruu-cookie information
655 from the beginning of this M, and discards the remainder (which will
656 be the distinguisher added by the SIP-PBX). It then validates this
657 temp-gruu-cookie. If valid, it uses it to locate the corresponding
658 SIP-PBX registration record, and routes the message appropriately.
660 If the non-normative, exemplary algorithm described in
661 Section 7.1.2.1 is used to generate the temp-gruu-cookie, then
662 this identification is performed by splitting the temp-gruu-cookie
663 information into its 48-bit counter I and 80-bit HMAC. It
664 validates that the HMAC matches the counter I, and then uses
665 counter I to locate the SIP-PBX registration record in its map.
666 If the counter has rolled over or reset, this computation is
667 performed with the current and previous SK_a.
669 7.1.2.4. Decoding of temp-gruu by the SIP-PBX
671 When the SIP-PBX receives a request in which the user part begins
672 with "tgruu.", it extracts the remaining portion, and splits it at
673 the "." character into E' and PA'. It then computes E and PA by
674 performing a base64 decode of E' and PA' respectively. Next, it
675 computes:
677 PAc = HMAC(PK_a, E)
679 where HMAC is the HMAC algorithm used for the steps in
680 Section 7.1.2.2. If this computed value for PAc does not match the
681 value of PA extracted from the GRUU, then the GRUU is rejected as
682 invalid.
684 The SIP-PBX then uses the value of the "gr" parameter to locate the
685 UA registration to which the GRUU corresponds, and routes the message
686 accordingly.
688 7.2. Registration Event Package
690 Neither the SSP nor the SIP-PBX is required to support the
691 Registration event package defined by RFC 3680 [12]. However, if
692 they do support the Registration event package, they MUST conform to
693 the behavior described in this section and its subsections.
695 As this mechanism inherently deals with REGISTER transaction
696 behavior, it is imperative to consider its impact on the Registration
697 Event Package defined by RFC 3680 [12]. In practice, there will be
698 two main use cases for subscribing to registration data: learning
699 about the overall registration state for the SIP-PBX, and learning
700 about the registration state for a single SIP-PBX AOR.
702 7.2.1. SIP-PBX Aggregate Registration State
704 If the SIP-PBX (or another interested and authorized party) wishes to
705 monitor or audit the registration state for all of the AORs currently
706 registered to that SIP-PBX, it can subscribe to the SIP registration
707 event package at the SIP-PBX's main URI -- that is, the URI used in
708 the "To" header field of the REGISTER request.
710 The NOTIFY messages for such a subscription will contain a body that
711 contains one record for each AOR associated with the SIP-PBX. The
712 AORs will be in the format expected to be received by the SSP (e.g.,
713 "sip:+12145550105@ssp.example.com"), and the Contacts will correspond
714 to the mapped Contact created by the registration (e.g.,
715 "sip:+12145550105@98.51.100.3").
717 In particular, the "bnc" parameter is forbidden from appearing in the
718 body of a reg-event NOTIFY request unless the subscriber has
719 indicated knowledge of the semantics of the "bnc" parameter. The
720 means for indicating this support are out of scope of this document.
722 Because the SSP does not necessarily know which GRUUs have been
723 issued by the SIP-PBX to its associated UAs, these records will not
724 generally the contain or elements defined in
725 RFC 5628 [9]. This information can be learned, if necessary, by
726 subscribing to the individual AOR registration state, as described in
727 Section 7.2.2.
729 7.2.2. Individual AOR Registration State
731 As described in Section 6, the SSP will generally retarget all
732 requests addressed to an AOR owned by a SIP-PBX to that SIP-PBX
733 according to the mapping established at registration time. Although
734 policy at the SSP may override this generally expected behavior,
735 proper behavior of the registration event package requires that all
736 "reg" event SUBSCRIBE requests are processed by the SIP-PBX. As a
737 consequence, the requirements on an SSP for processing registration
738 event package SUBSCRIBE requests are not left to policy.
740 If the SSP receives a SUBSCRIBE request for the registration event
741 package with a Request-URI that indicates an AOR registered via the
742 "Bulk Number Contact" mechanism defined in this document, then the
743 SSP MUST proxy that SUBSCRIBE to the SIP-PBX in the same way that it
744 would proxy an INVITE bound for that AOR, unless the SSP has and can
745 maintain a copy of complete, accurate, and up-to-date information
746 from the SIP-PBX (e.g., through an active back-end subscription).
748 If the Request-URI in a SUBSCRIBE request for the registration event
749 package indicates a contact that is registered by more than one SIP-
750 PBX, then the SSP proxy will fork the SUBSCRIBE request to all the
751 applicable SIP-PBXes. Similarly, if the Request-URI corresponds to a
752 contact that is both implicitly registered by a SIP-PBX and
753 explicitly registered directly with the SSP proxy, then the SSP proxy
754 will semantically fork the SUBSCRIBE request to the applicable SIP-
755 PBX or SIP-PBXes and to the registrar function (which will respond
756 with registration data corresponding to the explicit registrations at
757 the SSP). The forking in both of these cases can be avoided if the
758 SSP has and can maintain a copy of up-to-date information from the
759 PBXes.
761 Section 4.9 of RFC 3680 [12] indicates that "a subscriber MUST NOT
762 create multiple dialogs as a result of a single [registration event]
763 subscription request." Consequently, subscribers who are not aware
764 of the extension described by this document will accept only one
765 dialog in response to such requests. In the case described in the
766 preceding paragraph, this behavior will result in such client
767 receiving accurate but incomplete information about the registration
768 state of an AOR. As an explicit change to the normative behavior of
769 RFC 3680, this document stipulates that subscribers to the
770 registration event package MAY create multiple dialogs as the result
771 of a single subscription request. This will allow subscribers to
772 create a complete view of an AOR's registration state.
774 Defining the behavior as described above is important, since the reg-
775 event subscriber is interested in finding out about the comprehensive
776 list of devices associated with the AOR. Only the SIP-PBX will have
777 authoritative access to this information. For example, if the user
778 has registered multiple UAs with differing capabilities, the SSP will
779 not know about the devices or their capabilities. By contrast, the
780 SIP-PBX will.
782 If the SIP-PBX is not registered with the SSP when a registration
783 event subscription for a contact that would be implicitly registered
784 if the SIP-PBX were registered, then the SSP SHOULD accept the
785 subscription and indicate that the user is not currently registered.
786 Once the associated SIP-PBX is registered, the SSP SHOULD use the
787 subscription migration mechanism defined in RFC 3265 [5] to migrate
788 the subscription to the SIP-PBX.
790 When a SIP-PBX receives a registration event subscription addressed
791 to an AOR that has been registered using the bulk registration
792 mechanism described in this document, then each resulting
793 registration information document SHOULD contain an 'aor' attribute
794 in its element that corresponds to the AOR at the
795 SSP.
797 For example, consider a SIP-PBX that has registered with an SSP
798 that has a domain of "ssp.example.com" The SIP-PBX used a contact
799 of "sip:198.51.100.3:5060;bnc". After such registration is
800 complete, a registration event subscription arriving at the SSP
801 with a Request-URI of "sip:+12145550102@ssp.example.com" will be
802 re-targeted to the SIP-PBX, with a Request-URI of
803 "sip:+12145550102@198.51.100.3:5060". The resulting registration
804 document created by the SIP-PBX would contain a
805 element with an "aor" attribute of
806 "sip:+12145550102@ssp.example.com".
808 This behavior ensures that subscribers external to the system (and
809 unaware of GIN procedures) will be able to find the relevant
810 information in the registration document (since they will be
811 looking for the publicly-visible AOR, not the address used for
812 sending information from the SSP to the SIP-PBX).
814 A SIP-PBX that supports both GRUU procedures and the registration
815 event packages SHOULD implement the extension defined in RFC 5628
816 [9].
818 7.3. Client-Initiated (Outbound) Connections
820 RFC 5626 [19] defines a mechanism that allows UAs to establish long-
821 lived TCP connections or UDP associations with a proxy in a way that
822 allows bidirectional traffic between the proxy and the UA. This
823 behavior is particularly important in the presence of NATs, and
824 whenever TLS [18] security is required. Neither the SSP nor the SIP-
825 PBX is required to support client-initiated connections.
827 The outbound mechanism generally works with the solution defined in
828 this document without any modifications. Implementors should note
829 that the instance ID used between the SIP-PBX and the SSP's registrar
830 identifies the SIP-PBX itself, and not any of the UAs registered with
831 the SIP-PBX. As a consequence, any attempts to use caller
832 preferences (defined in RFC 3841[14]) to target a specific instance
833 are likely to fail. This shouldn't be an issue, as the preferred
834 mechanism for targeting specific instances of a user agent is GRUU
835 (see Section 7.1).
837 7.4. Non-Adjacent Contact Registration (Path) and Service Route
838 Discovery
840 RFC 3327 [10] defines a means by which a registrar and its associated
841 proxy can be informed of a route that is to be used between the proxy
842 and the registered user agent. The scope of the route created by a
843 "Path" header field is contact-specific; if an AOR has multiple
844 contacts associated with it, the routes associated with each contact
845 may be different from each other. Support for non-adjacent contact
846 registration is required in all SSPs and SIP-PBXes implementing the
847 multiple-AOR-registration protocol described in this document.
849 At registration time, any proxies between the user agent and the
850 registrar may add themselves to the Path. By doing so, they request
851 that any requests destined to the user agent as a result of the
852 associated registration include them as part of the Route towards the
853 User Agent. Although the Path mechanism does deliver the final Path
854 value to the registering UA, UAs typically ignore the value of the
855 Path.
857 To provide similar functionality in the opposite direction -- that
858 is, to establish a route for requests sent by a registering UA -- RFC
859 3608 [11] defines a means by which a UA can be informed of a route
860 that is to be used by the UA to route all outbound requests
861 associated with the AOR used in the registration. This information
862 is scoped to the AOR within the UA, and is not specific to the
863 Contact (or Contacts) in the REGISTER request. Support of service
864 route discovery is OPTIONAL in SSPs and SIP-PBXes.
866 The registrar unilaterally generates the values of the service route
867 using whatever local policy it wishes to apply. Although it is
868 common to use the Path and/or Route information in the request in
869 composing the Service-Route, registrar behavior is not constrained in
870 any way that requires it to do so.
872 In considering the interaction between these mechanisms and the
873 registration of multiple AORs in a single request, implementors of
874 proxies, registrars, and intermediaries must keep in mind the
875 following issues, which stem from the fact that GIN effectively
876 registers multiple AORs and multiple Contacts.
878 First, all location service records that result from expanding a
879 single Contact containing a "bnc" parameter will necessarily share a
880 single path. Proxies will be unable to make policy decisions on a
881 contact-by-contact basis regarding whether to include themselves in
882 the path. Second, and similarly, all AORs on the SIP-PBX that are
883 registered with a common REGISTER request will be forced to share a
884 common Service-Route.
886 One interesting technique that Path and Service-Route enable is the
887 inclusion of a token or cookie in the user portion of the Service-
888 Route or Path entries. This token or cookie may convey information
889 to proxies about the identity, capabilities, and/or policies
890 associated with the user. Since this information will be shared
891 among several AORs and several Contacts when multiple AOR
892 registration is employed, care should be taken to ensure that doing
893 so is acceptable for all AORs and all Contacts registered in a single
894 REGISTER request.
896 8. Examples
898 Note that the following examples elide any steps related to
899 authentication. This is done for the sake of clarity. Actual
900 deployments will need to provide a level of authentication
901 appropriate to their system.
903 8.1. Usage Scenario: Basic Registration
905 This example shows the message flows for a basic bulk REGISTER
906 transaction, followed by an INVITE addressed to one of the registered
907 UAs. Example messages are shown after the sequence diagram.
909 Internet SSP SIP-PBX
910 | | |
911 | |(1) REGISTER |
912 | |Contact: |
913 | |<--------------------------------|
914 | | |
915 | |(2) 200 OK |
916 | |-------------------------------->|
917 | | |
918 |(3) INVITE | |
919 |sip:+12145550105@ssp.example.com| |
920 |------------------------------->| |
921 | | |
922 | |(4) INVITE |
923 | |sip:+12145550105@198.51.100.3 |
924 | |-------------------------------->|
925 (1) The SIP-PBX registers with the SSP for a range of AORs.
927 REGISTER sip:ssp.example.com SIP/2.0
928 Via: SIP/2.0/UDP 198.51.100.3:5060;branch=z9hG4bKnashds7
929 Max-Forwards: 70
930 To:
931 From: ;tag=a23589
932 Call-ID: 843817637684230@998sdasdh09
933 CSeq: 1826 REGISTER
934 Proxy-Require: gin
935 Require: gin
936 Supported: path
937 Contact:
938 Expires: 7200
939 Content-Length: 0
941 (3) The SSP receives a request for an AOR assigned
942 to the SIP-PBX.
944 INVITE sip:+12145550105@ssp.example.com SIP/2.0
945 Via: SIP/2.0/UDP foo.example;branch=z9hG4bKa0bc7a0131f0ad
946 Max-Forwards: 69
947 To:
948 From: ;tag=456248
949 Call-ID: f7aecbfc374d557baf72d6352e1fbcd4
950 CSeq: 24762 INVITE
951 Contact:
952 Content-Type: application/sdp
953 Content-Length: ...
955
956 (4) The SSP retargets the incoming request according to the
957 information received from the SIP-PBX at registration time.
959 INVITE sip:+12145550105@198.51.100.3 SIP/2.0
960 Via: SIP/2.0/UDP ssp.example.com;branch=z9hG4bKa45cd5c52a6dd50
961 Via: SIP/2.0/UDP foo.example;branch=z9hG4bKa0bc7a0131f0ad
962 Max-Forwards: 68
963 To:
964 From: ;tag=456248
965 Call-ID: f7aecbfc374d557baf72d6352e1fbcd4
966 CSeq: 24762 INVITE
967 Contact:
968 Content-Type: application/sdp
969 Content-Length: ...
971
973 8.2. Usage Scenario: Using Path to Control Request URI
975 This example shows a bulk REGISTER transaction with the SSP making
976 use of the "Path" header field extension [10]. This allows the SSP
977 to designate a domain on the incoming Request URI that does not
978 necessarily resolve to the SIP-PBX when the SSP applies RFC 3263
979 procedures to it.
981 Internet SSP SIP-PBX
982 | | |
983 | |(1) REGISTER |
984 | |Path: |
985 | |Contact: |
986 | |<--------------------------------|
987 | | |
988 | |(2) 200 OK |
989 | |-------------------------------->|
990 | | |
991 |(3) INVITE | |
992 |sip:+12145550105@ssp.example.com| |
993 |------------------------------->| |
994 | | |
995 | |(4) INVITE |
996 | |sip:+12145550105@pbx.example |
997 | |Route: |
998 | |-------------------------------->|
999 (1) The SIP-PBX registers with the SSP for a range of AORs.
1000 It includes the form of the URI it expects to receive in the
1001 Request-URI in its "Contact" header field, and includes
1002 information that routes to the SIP-PBX in the "Path" header
1003 field.
1005 REGISTER sip:ssp.example.com SIP/2.0
1006 Via: SIP/2.0/UDP 198.51.100.3:5060;branch=z9hG4bKnashds7
1007 Max-Forwards: 70
1008 To:
1009 From: ;tag=a23589
1010 Call-ID: 326983936836068@998sdasdh09
1011 CSeq: 1826 REGISTER
1012 Proxy-Require: gin
1013 Require: gin
1014 Supported: path
1015 Path:
1016 Contact:
1017 Expires: 7200
1018 Content-Length: 0
1020 (3) The SSP receives a request for an AOR assigned
1021 to the SIP-PBX.
1023 INVITE sip:+12145550105@ssp.example.com SIP/2.0
1024 Via: SIP/2.0/UDP foo.example;branch=z9hG4bKa0bc7a0131f0ad
1025 Max-Forwards: 69
1026 To:
1027 From: ;tag=456248
1028 Call-ID: 7ca24b9679ffe9aff87036a105e30d9b
1029 CSeq: 24762 INVITE
1030 Contact:
1031 Content-Type: application/sdp
1032 Content-Length: ...
1034
1035 (4) The SSP retargets the incoming request according to the
1036 information received from the SIP-PBX at registration time.
1037 Per the normal processing associated with "Path," it
1038 will insert the "Path" value indicated by the SIP-PBX at
1039 registration time in a "Route" header field, and
1040 set the request URI to the registered Contact.
1042 INVITE sip:+12145550105@pbx.example SIP/2.0
1043 Via: SIP/2.0/UDP ssp.example.com;branch=z9hG4bKa45cd5c52a6dd50
1044 Via: SIP/2.0/UDP foo.example;branch=z9hG4bKa0bc7a0131f0ad
1045 Route:
1046 Max-Forwards: 68
1047 To:
1048 From: ;tag=456248
1049 Call-ID: 7ca24b9679ffe9aff87036a105e30d9b
1050 CSeq: 24762 INVITE
1051 Contact:
1052 Content-Type: application/sdp
1053 Content-Length: ...
1055
1057 9. IANA Considerations
1059 This document registers a new SIP option tag to indicate support for
1060 the mechanism it defines, two new SIP URI parameters, and a "Contact"
1061 header field parameter. The process governing registration of these
1062 protocol elements is outlined in RFC5727 [21].
1064 9.1. New SIP Option Tag
1066 This section defines a new SIP option tag per the guidelines in
1067 Section 27.1 of RFC 3261 [3].
1068 Name: gin
1069 Description: This option tag is used to identify the extension that
1070 provides Registration for Multiple Phone Numbers in SIP. When
1071 present in a Require or Proxy-Require header field of a REGISTER
1072 request, it indicates that support for this extension is required
1073 of registrars and proxies, respectively, that are a party to the
1074 registration transaction.
1075 Reference: RFCXXXX (this document)
1077 9.2. New SIP URI Parameters
1079 This specification defines two new SIP URI parameters, as per the
1080 registry created by RFC 3969 [7].
1082 9.2.1. 'bnc' SIP URI parameter
1084 Parameter Name: bnc
1085 Predefined Values: No (no values are allowed)
1086 Reference: RFCXXXX (this document)
1088 9.2.2. 'sg' SIP URI parameter
1090 Parameter Name: sg
1091 Predefined Values: No
1092 Reference: RFCXXXX (this document)
1094 9.3. New SIP Header Field Parameter
1096 This section defines a new SIP header field parameter per the
1097 registry created by RFC3968 [6].
1099 Header field: Contact
1100 Parameter name: temp-gruu-cookie
1101 Predefined values: none
1102 Reference: RFCXXXX (this document)
1104 10. Security Considerations
1106 The change proposed for the mechanism described in this document
1107 takes the unprecedented step of extending the previously-defined
1108 REGISTER method to apply to more than one AOR. In general, this kind
1109 of change has the potential to cause problems at intermediaries --
1110 such as proxies -- that are party to the REGISTER transaction. In
1111 particular, such intermediaries may attempt to apply policy to the
1112 user indicated in the "To" header field (i.e. the SIP-PBX's
1113 identity), without any knowledge of the multiple AORs that are being
1114 implicitly registered.
1116 The mechanism defined by this document solves this issue by adding an
1117 option tag to a "Proxy-Require" header field in such REGISTER
1118 requests. Proxies that are unaware of this mechanism will not
1119 process the requests, preventing them from mis-applying policy.
1120 Proxies that process requests with this option tag are clearly aware
1121 of the nature of the REGISTER request, and can make reasonable policy
1122 decisions.
1124 As noted in Section 7.4, intermediaries need to take care if they use
1125 a policy token in the Path and Service-Route mechanisms, as doing so
1126 will cause them to apply the same policy to all users serviced by the
1127 same SIP-PBX. This may frequently be the correct behavior, but
1128 circumstances can arise in which differentiation of user policy is
1129 required.
1131 Section 7.4 also notes that techniques that use a token or cookie in
1132 the Path and/or Service-Route values, and that this value will be
1133 shared among all AORs associated with a single registration. Because
1134 this information will be visible to User Agents under certain
1135 conditions, proxy designers using this mechanism in conjunction with
1136 the techniques describe in this document need to take care that doing
1137 so does not leak sensitive information.
1139 One of the key properties of the outbound client connection mechanism
1140 discussed in Section 7.3 is assurances that a single connection is
1141 associated with a single user, and cannot be hijacked by other users.
1142 With the mechanism defined in this document, such connections
1143 necessarily become shared between users. However, the only entity in
1144 a position to hijack calls as a consequence is the SIP-PBX itself.
1145 Because the SIP-PBX acts as a registrar for all the potentially
1146 affected users, it already has the ability to redirect any such
1147 communications as it sees fit. In other words, the SIP-PBX must be
1148 trusted to handle calls in an appropriate fashion, and the use of the
1149 outbound connection mechanism introduces no additional
1150 vulnerabilities.
1152 The ability to learn the identity and registration state of every
1153 user on the PBX (as described in Section 7.2.1) is invaluable for
1154 diagnostic and administrative purposes. For example, this allows the
1155 SIP-PBX to determine whether all the its extensions are properly
1156 registered with the SSP. However, this information can also be
1157 highly sensitive, as many organizations may not wish to make their
1158 entire list of phone numbers available to external entities.
1159 Consequently, SSP servers are advised to use explicit (i.e. white-
1160 list) and configurable policies regarding who can access this
1161 information, with very conservative defaults (e.g., an empty access
1162 list or an access list consisting only of the PBX itself).
1164 The procedure for generation of temporary GRUUs requires the use of
1165 an HMAC to detect any tampering that external entities may attempt to
1166 perform on the contents of a temporary GRUU. The mention of HMAC-
1167 SHA256-80 in Section 7.1.2 is intended solely as an example of a
1168 suitable HMAC algorithm. Since all HMACs used in this document are
1169 generated and consumed by the same entity, the choice of an actual
1170 HMAC algorithm is entirely up to an implementation, provided that the
1171 cryptographic properties are sufficient to prevent third parties from
1172 spoofing GRUU-related information.
1174 The procedure for generation of temporary GRUUs also requires the use
1175 of RSA keys. The selection of the proper key length for such keys
1176 requires careful analysis, taking into consideration the current and
1177 foreseeable speed of processing for the period of time during which
1178 GRUUs must remain anonymous, as well as emerging cryptographic
1179 analysis methods. The most recent guidance from RSA Laboratories
1180 [25] suggests a key length of 2048 bits for data that needs
1181 protection through the year 2030, and a length of 3072 bits
1182 thereafter.
1184 Similarly, implementors are warned to take precautionary measures to
1185 prevent unauthorized disclosure of the private key used in GRUU
1186 generation. Any such disclosure would result in the ability to
1187 correlate temporary GRUUs to each other, and potentially to their
1188 associated PBXes.
1190 Further, the use of RSA decryption when processing GRUUs received
1191 from arbitrary parties can be exploited by DoS attackers to amplify
1192 the impact of an attack: because of the presence of a cryptographic
1193 operation in the processing of such messages, the CPU load may be
1194 marginally higher when the attacker uses (valid or invalid) temporary
1195 GRUUs in the messages employed by such an attack. Normal DoS
1196 mitigation techniques, such as rate-limiting processing of received
1197 messages, should help to reduce the impact of this issue as well.
1199 Finally, good security practices should be followed regarding the
1200 duration an RSA key is used. For implementors, this means that
1201 systems MUST include an easy way to update the public key provided to
1202 the SIP-PBX. To avoid immediately invalidating all currently issued
1203 temporary GRUUs, the SSP servers SHOULD keep the retired RSA key
1204 around for a grace period before discarding it. If decryption fails
1205 based on the new RSA key, then the SSP server can attempt to use the
1206 retired key instead. By contrast, the SIP-PBXes MUST discard the
1207 retired public key immediately, and exclusively use the new public
1208 key.
1210 11. Acknowledgements
1212 This document represents the hard work of many people in the IETF
1213 MARTINI working group and the IETF RAI community as a whole.
1214 Particular thanks are owed to John Elwell for his requirements
1215 analysis of the mechanism described in this document, to Dean Willis
1216 for his analysis of the interaction between this mechanism and the
1217 Path and Service-Route extensions, to Cullen Jennings for his
1218 analysis of the interaction between this mechanism and the SIP
1219 Outbound extension, and to to Richard Barnes for his detailed
1220 security analysis of the GRUU construction algorithm. Thanks to Eric
1221 Rescorla, whose text in the appendix of RFC5627 was lifted directly
1222 to provide substantial portions of Section 7.1.2. Finally, thanks to
1223 Bernard Aboba, Francois Audet, Brian Carpenter, John Elwell, David
1224 Hancock, Ted Hardie, Martien Huysmans, Cullen Jennings, Alan
1225 Johnston, Hadriel Kaplan, Paul Kyzivat, and Radia Perlman for their
1226 careful reviews of and constructive feedback on this document.
1228 12. References
1230 12.1. Normative References
1232 [1] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing
1233 for Message Authentication", RFC 2104, February 1997.
1235 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
1236 Levels", BCP 14, RFC 2119, March 1997.
1238 [3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
1239 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
1240 Session Initiation Protocol", RFC 3261, June 2002.
1242 [4] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol
1243 (SIP): Locating SIP Servers", RFC 3263, June 2002.
1245 [5] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
1246 Notification", RFC 3265, June 2002.
1248 [6] Camarillo, G., "The Internet Assigned Number Authority (IANA)
1249 Header Field Parameter Registry for the Session Initiation
1250 Protocol (SIP)", BCP 98, RFC 3968, December 2004.
1252 [7] Camarillo, G., "The Internet Assigned Number Authority (IANA)
1253 Uniform Resource Identifier (URI) Parameter Registry for the
1254 Session Initiation Protocol (SIP)", BCP 99, RFC 3969,
1255 December 2004.
1257 [8] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings",
1258 RFC 4648, October 2006.
1260 [9] Kyzivat, P., "Registration Event Package Extension for Session
1261 Initiation Protocol (SIP) Globally Routable User Agent URIs
1262 (GRUUs)", RFC 5628, October 2009.
1264 12.2. Informative References
1266 [10] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP)
1267 Extension Header Field for Registering Non-Adjacent Contacts",
1268 RFC 3327, December 2002.
1270 [11] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP)
1271 Extension Header Field for Service Route Discovery During
1272 Registration", RFC 3608, October 2003.
1274 [12] Rosenberg, J., "A Session Initiation Protocol (SIP) Event
1275 Package for Registrations", RFC 3680, March 2004.
1277 [13] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating
1278 User Agent Capabilities in the Session Initiation Protocol
1279 (SIP)", RFC 3840, August 2004.
1281 [14] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller
1282 Preferences for the Session Initiation Protocol (SIP)",
1283 RFC 3841, August 2004.
1285 [15] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966,
1286 December 2004.
1288 [16] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
1289 Requirements for Security", BCP 106, RFC 4086, June 2005.
1291 [17] Sparks, R., Hawrylyshen, A., Johnston, A., Rosenberg, J., and
1292 H. Schulzrinne, "Session Initiation Protocol (SIP) Torture Test
1293 Messages", RFC 4475, May 2006.
1295 [18] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)
1296 Protocol Version 1.2", RFC 5246, August 2008.
1298 [19] Jennings, C., Mahy, R., and F. Audet, "Managing Client-
1299 Initiated Connections in the Session Initiation Protocol
1300 (SIP)", RFC 5626, October 2009.
1302 [20] Rosenberg, J., "Obtaining and Using Globally Routable User
1303 Agent URIs (GRUUs) in the Session Initiation Protocol (SIP)",
1304 RFC 5627, October 2009.
1306 [21] Peterson, J., Jennings, C., and R. Sparks, "Change Process for
1307 the Session Initiation Protocol (SIP) and the Real-time
1308 Applications and Infrastructure Area", BCP 67, RFC 5727,
1309 March 2010.
1311 [22] Elwell, J. and H. Kaplan, "Requirements for Multiple Address of
1312 Record (AOR) Reachability Information in the Session Initiation
1313 Protocol (SIP)", RFC 5947, September 2010.
1315 [23] Kaplan, H., Enterprise, o., contact, R., URI, u., and o. URI,
1316 "GIN with Literal AoRs for SIP in SSPs (GLASS)",
1317 draft-kaplan-martini-glass-00 (work in progress),
1318 November 2010.
1320 [24] National Institute of Standards and Technology, "Secure Hash
1321 Standard (SHS)", FIPS PUB 180-3, October 2008, .
1324 [25] Kaliski, B., "TWIRL and RSA Key Size", May 2003.
1326 Appendix A. Requirements Analysis
1328 The document "Requirements for multiple address of record (AOR)
1329 reachability information in the Session Initiation Protocol (SIP)"
1330 [22] contains a list of requirements and desired properties for a
1331 mechanism to register multiple AORs with a single SIP transaction.
1332 This section evaluates those requirements against the mechanism
1333 described in this document.
1335 REQ1 - The mechanism MUST allow a SIP-PBX to enter into a trunking
1336 arrangement with an SSP whereby the two parties have agreed on a set
1337 of telephone numbers deemed to have been assigned to the SIP-PBX.
1339 The requirement is satisfied.
1341 REQ2 - The mechanism MUST allow a set of assigned telephone numbers
1342 to comprise E.164 numbers, which can be in contiguous ranges,
1343 discrete, or in any combination of the two.
1345 The requirement is satisfied; the DIDs associated with a
1346 registration is established by bilateral agreement between the SSP
1347 and the SIP-PBX, and is not part of the mechanism described in
1348 this document.
1350 REQ3 - The mechanism MUST allow a SIP-PBX to register reachability
1351 information with its SSP, in order to enable the SSP to route to the
1352 SIP-PBX inbound requests targeted at assigned telephone numbers.
1354 The requirement is satisfied.
1356 REQ4 - The mechanism MUST allow UAs attached to a SIP-PBX to register
1357 with the SIP-PBX for AORs based on assigned telephone numbers, in
1358 order to receive requests targeted at those telephone numbers,
1359 without needing to involve the SSP in the registration process.
1361 The requirement is satisfied; in the presumed architecture, SIP-
1362 PBX UAs register with the SIP-PBX, an require no interaction with
1363 the SSP.
1365 REQ5 - The mechanism MUST allow a SIP-PBX to handle requests
1366 originating at its own UAs and targeted at its assigned telephone
1367 numbers, without routing those requests to the SSP.
1369 The requirement is satisfied; SIP-PBXes may recognize their own
1370 DID and their own GRUUs, and perform on-SIP-PBX routing without
1371 sending the requests to the SSP.
1373 REQ6 - The mechanism MUST allow a SIP-PBX to receive requests to its
1374 assigned telephone numbers originating outside the SIP-PBX and
1375 arriving via the SSP, so that the SIP-PBX can route those requests
1376 onwards to its UAs, as it would for internal requests to those
1377 telephone numbers.
1379 The requirement is satisfied
1381 REQ7 - The mechanism MUST provide a means whereby a SIP-PBX knows
1382 which of its assigned telephone numbers an inbound request from its
1383 SSP is targeted at.
1385 The requirement is satisfied. For ordinary calls and calls using
1386 Public GRUUs, the DID is indicated in the user portion of the
1387 Request-URI. For calls using Temp GRUUs constructed with the
1388 mechanism described in Section 7.1.2, the "gr" parameter provides
1389 a correlation token the SIP-PBX can use to identify which UA the
1390 call should be routed to.
1392 REQ8 - The mechanism MUST provide a means of avoiding problems due to
1393 one side using the mechanism and the other side not.
1395 The requirement is satisfied through the 'gin' option tag and the
1396 'bnc' Contact parameter.
1398 REQ9 - The mechanism MUST observe SIP backwards compatibility
1399 principles.
1401 The requirement is satisfied through the 'gin' option tag.
1403 REQ10 - The mechanism MUST work in the presence of a sequence of
1404 intermediate SIP entities on the SIP-PBX-to-SSP interface (i.e.,
1405 between the SIP-PBX and the SSP's domain proxy), where those
1406 intermediate SIP entities indicated during registration a need to be
1407 on the path of inbound requests to the SIP-PBX.
1409 The requirement is satisfied through the use of the Path mechanism
1410 defined in RFC 3327 [10]
1412 REQ11 - The mechanism MUST work when a SIP-PBX obtains its IP address
1413 dynamically.
1415 The requirement is satisfied by allowing the SIP-PBX to use an IP
1416 address in the Bulk Number Contact URI contained in a REGISTER
1417 Contact header field.
1419 REQ12 - The mechanism MUST work without requiring the SIP-PBX to have
1420 a domain name or the ability to publish its domain name in the DNS.
1422 The requirement is satisfied by allowing the SIP-PBX to use an IP
1423 address in the Bulk Number Contact URI contained in a REGISTER
1424 Contact header field.
1426 REQ13 - For a given SIP-PBX and its SSP, there MUST be no impact on
1427 other domains, which are expected to be able to use normal RFC 3263
1428 procedures to route requests, including requests needing to be routed
1429 via the SSP in order to reach the SIP-PBX.
1431 The requirement is satisfied by allowing the domain name in the
1432 Request URI used by external entities to resolve to the SSP's
1433 servers via normal RFC 3263 resolution procedures.
1435 REQ14 - The mechanism MUST be able to operate over a transport that
1436 provides end-to-end integrity protection and confidentiality between
1437 the SIP-PBX and the SSP, e.g., using TLS as specified in [3].
1439 The requirement is satisfied; nothing in the proposed mechanism
1440 prevent the use of TLS between the SSP and the SIP-PBX.
1442 REQ15 - The mechanism MUST support authentication of the SIP-PBX by
1443 the SSP and vice versa, e.g., using SIP digest authentication plus
1444 TLS server authentication as specified in [3].
1446 The requirement is satisfied; SIP-PBXes may employ either SIP
1447 digest authentication or mutually-authenticated TLS for
1448 authentication purposes.
1450 REQ16 - The mechanism MUST allow the SIP-PBX to provide its UAs with
1451 public or temporary Globally Routable UA URIs (GRUUs) [20].
1453 The requirement is satisfied via the mechanisms detailed in
1454 Section 7.1.
1456 REQ17 - The mechanism MUST work over any existing transport specified
1457 for SIP, including UDP.
1459 The requirement is satisfied to the extent that UDP can be used
1460 for REGISTER requests in general. The application of certain
1461 extensions and/or network topologies may exceed UDP MTU sizes, but
1462 such issues arise both with and without the mechanism described in
1463 this document. This document does not exacerbate such issues.
1465 REQ18 - Documentation MUST give guidance or warnings about how
1466 authorization policies may be affected by the mechanism, to address
1467 the problems described in Section 3.3 (of RFC5947).
1469 These issues are addressed at length in Section 10, as well as
1470 summarized in Section 7.4.
1472 REQ19 - The mechanism MUST be extensible to allow a set of assigned
1473 telephone numbers to comprise local numbers as specified in RFC3966
1474 [15], which can be in contiguous ranges, discrete, or in any
1475 combination of the two.
1477 Assignment of telephone numbers to a registration is performed by
1478 the SSP's registrar, which is not precluded from assigning local
1479 numbers in any combination it desires.
1481 REQ20 - The mechanism MUST be extensible to allow a set of
1482 arbitrarily assigned SIP URI's as specified in RFC3261 [3], as
1483 opposed to just telephone numbers, without requiring a complete
1484 change of mechanism as compared to that used for telephone numbers.
1486 The mechanism is extensible in such a fashion, as demonstrated by
1487 the document "GIN with Literal AoRs for SIP in SSPs (GLASS)" [23].
1489 DES1 - The mechanism SHOULD allow an SSP to exploit its mechanisms
1490 for providing SIP service to ordinary subscribers in order to provide
1491 a SIP trunking service to SIP-PBXes.
1493 The desired property is satisfied; the routing mechanism described
1494 in this document is identical to the routing performed for singly-
1495 registered AORs.
1497 DES2 - The mechanism SHOULD scale to SIP-PBX's of several thousand
1498 assigned telephone numbers.
1500 The desired property is satisfied; nothing in this document
1501 precludes DID pools of arbitrary size.
1503 DES3 - The mechanism SHOULD scale to support several thousand SIP-
1504 PBX's on a single SSP.
1506 The desired property is satisfied; nothing in this document
1507 precludes an arbitrary number of SIP-PBXes from attaching to a
1508 single SSP.
1510 Author's Address
1512 Adam Roach
1513 Tekelec
1514 17210 Campbell Rd.
1515 Suite 250
1516 Dallas, TX 75252
1517 US
1519 Email: adam@nostrum.com