idnits 2.17.00 (12 Aug 2021) /tmp/idnits5949/draft-stucker-sip-guid-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 103 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 276 has weird spacing: '...r field where...' -- 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 (February 2004) is 6670 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) == Unused Reference: '2' is defined on line 328, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (ref. '3') (Obsoleted by RFC 4234) == Outdated reference: draft-ietf-sip-gruu has been published as RFC 5627 ** Obsolete normative reference: RFC 3265 (ref. '7') (Obsoleted by RFC 6665) ** Obsolete normative reference: RFC 2976 (ref. '8') (Obsoleted by RFC 6086) ** Obsolete normative reference: RFC 2362 (ref. '10') (Obsoleted by RFC 4601, RFC 5059) == Outdated reference: draft-ietf-sip-publish has been published as RFC 3903 Summary: 7 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Session Initiation Protocol (SIP) 2 Internet Draft B. Stucker 3 Document: draft-stucker-sip-guid-00.txt Nortel Networks 4 Expires: July 2004 February 2004 6 Client Globally Unique ID for SIP 8 Status of this Memo 10 This document is an Internet-Draft and is subject to all provisions 11 of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Abstract 30 A number of applications using the Session Initiation Protocol (SIP) 31 protocol require or can be enhanced by being able to uniquely 32 identify a particular user agent (UA) instance in the network. This 33 document describes an extension to SIP that allows clients to 34 generate globally unique identifiers (GUID) for use within SIP based 35 applications, providing an example of their use. 37 Table of Contents 39 1. Introduction...................................................2 40 2. Terminology ...................................................2 41 3. Creating a GUID................................................3 42 3.1 Characteristics of a GUID...................................3 43 3.2 Construction of a SIP GUID..................................4 44 3.2.1 Time Component........................................4 45 3.2.2 Space Component.......................................5 46 3.3 Comparing SIP GUIDs.........................................6 47 3.4 The GUID Header.............................................6 48 3.4.1 Syntax................................................6 49 3.5 Proxy Behavior..............................................7 50 4. Security Considerations........................................7 51 5. IANA Considerations............................................7 52 5.1 Registration of the "GUID" SIP header.......................7 53 6. References ...................................................7 54 7. Acknowledgements...............................................8 55 Author's Addresses................................................8 57 1. Introduction 59 Within SIP, there arise situations where it is necessary to ensure 60 that an action is applied to a particular user agent (UA) instance, 61 but the existing mechanisms within SIP are not always reliable. For 62 example, although registrations identify a routable address and port 63 of a particular UA, in an environment that uses dynamically assigned 64 IP addresses (NATs, VPNs, short-lease DHCP networks) there is no 65 ready way of always tying registrations together across time for a 66 particular UA instance. In these environments, the usual IP/port 67 combination that defines a particular routing location of a UA is 68 unreliable over time as an identifier of that UA. 70 As a result, an identifier that UAs can use as a "finger-printing" 71 mechanism to identify themselves is useful. Whereas the Globally 72 Routable UA URIs (GRUU) draft [4] seeks to address a server-generated 73 identifier for the UA, this draft seeks to define a client-generated 74 approach to a similar problem. 76 The mechanism defined in this document allows a particular UA 77 instance to construct a globally unique identifier which can be used 78 by SIP services to process requests that require, or are enhanced by, 79 the ability to identify a particular UA instance in the network over 80 a long period of time. 82 2. Terminology 84 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 85 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 86 document are to be interpreted as described in RFC-2119 [ii]. 88 3. Creating a GUID 90 This section covers the details of creating a GUID on the client UA. 92 3.1 Characteristics of a GUID 94 The idea of a globally unique ID is hardly a new concept. Designers 95 and developers of all sorts of applications in the physical world and 96 the Internet have required the ability to uniquely identify a 97 particular entity from a larger set. This is especially true when 98 every other property of the entity is subject to substantial changes 99 over time that would render it difficult or impossible to uniquely 100 identify over time. 102 For example, governments frequently assign us a number (or other 103 identifying string) when we are born because they have a need to 104 identify us as taxpayers throughout our lives. There are several 105 other examples of unique IDs, such as vehicle identification numbers 106 and serial numbers on items we buy from large manufacturers. 108 A common characteristic of these identification numbers is that they 109 have two basic properties: 111 - They are unique to the entity they are associated with. 113 - A central authority coordinates the assignment of IDs to ensure 114 that no two entities are given the same identifier. 116 Note, that there is no requirement that there be any sort of registry 117 that knows which entity has what identifier. This would be needed if 118 the identifier were to be used for non-repudiation purposes, but that 119 is not always a goal that needs to be fulfilled depending on the 120 application. 122 Sometimes entities need to be able to be identified uniquely, but to 123 have a central authority assign an identifier would be difficult or 124 impossible. In these situations, it is still possible for the entity 125 to assign itself a unique identifier. This can be achieved by using a 126 mechanism that ensures that the odds of any two entities having the 127 same identifier are statistically insignificant. 129 An example of this mechanism would be human fingerprints. 130 Fingerprints can be used as a globally unique identifier of who you 131 are, and the odds of two people having the same fingerprints are 132 statistically insignificant (even twins have a different set). No 133 central authority coordinates the assignment of who gets what 134 fingerprints, and yet they can be used to uniquely identify a 135 particular person. If they are registered with a central authority, 136 they can be used for purposes of non-repudiation. In either case, 137 they are very useful, as other characteristics of people may change 138 wildly over time. 140 3.2 Construction of a SIP GUID 142 Constructing an identifier that describes a UA is trivialquite 143 straightforward. SIP TAGs are frequently generated to identify a 144 particular UA session within SIP. Ensuring that the identifier is 145 unique within a small, controlled set of UAs is more difficult, but 146 still manageable by simply assigning them directly to the UA upon 147 creation (like assigning a static IP address to a machine on a LAN). 148 However, making that identifier unique across very large sets could 149 be very difficult by simple assignment through sheer logistics (think 150 about your experiences trying to get a driver's license). 152 Because a straightforward assignment of a GUID is problematic at best 153 (and impossible at worst) this approach is ruled out in favor of 154 using a standard mechanism: use time and space to your advantage. All 155 SIP GUIDs MUST be generated based off the time that they were 156 generated, and the "space" in which they were generated. 158 Obviously, generating a SIP GUID that is composed of a three-digit 159 number would not satisfy most reasonable definitions of "unique" 160 within a SIP network. Therefore, SIP GUIDs MUST be at least 128-bits 161 in length. 163 3.2.1 Time Component 165 Time can be used to create uniqueness because each instant in time 166 only occurs once. This can be used to constrain the set of all UAs 167 that wish to create a GUID at that instant from the set of all UAs 168 that will ever exist (ie. all of the UAs that wish to create a GUID 169 on February 6th, 2004 at 10:45pm as opposed to all UAs that will ever 170 exist from now to eternity). This means that a component of a GUID 171 should be based on the current local time. It is not necessary that 172 every UA generating a GUID need to have synchronized clocks with 173 every other UA. This is because we're not interested in being able to 174 tell the exact moment a GUID is created. It's used simply as a 175 component of the GUID in order to constrain the larger set. 177 Many computers and development platforms vary in the scale at which 178 time can be measured. Because we are using time to constrain the set 179 of all UAs that may ever wish to generate a GUID, it is important 180 that the smallest available unit be used by the UA generating the 181 GUID. Additionally, a large random number from a cryptographically- 182 strong random number generator can be appended to the current time to 183 create a pseudo-timestamp with very fine resolution. 185 Here's an example: 187 - A computer's clock can be resolved down to 1 millisecond. 189 - The computer's random number generator can produce a random 190 integer up to (2^31)-1. 192 - From this a "pseudo-clock" can then be constructed that resolves 193 time down to the order of a pico-second (10^-12 seconds, or 194 trillionths of a second). 196 Friday, February 6th, 2004 at 21:30:54 CST can be expressed as 197 1076124654957 milliseconds since January 1, 1970, 00:00:00 GMT. 199 A possible random number generated by a cryptographically-strong 200 random number generator: 190182543. 202 Taken together, it is possible to create a "pseudo-time" of 203 1076124654957190182543 pico-seconds since January 1, 1970 00:00:00 204 GMT. 206 This is a very powerful notion, and if further resolution is 207 required, successive random numbers can be appended to further 208 resolve the "pseudo-clock" to fantastically small instants of time. 209 It is critical, however, that an actual clock source be used as the 210 most-significant digits of the "pseudo-clock". 212 In the example given, even if 1 billion SIP UAs decided to generate a 213 new GUID at the same time, it is still a 1 in a trillion chance that 214 they come up with the same "pseudo-clock" time. 216 SIP GUIDs MUST use a "psuedo-clock" that resolves to a minimum of 217 10^-12 seconds. 219 3.2.2 Space Component 221 The other component to a well-formed globally unique identifier that 222 is not assigned by a central authority is to use space (or an 223 approximation of it) as a component. It can obviously be the same 224 time in multiple places, but no two UAs can ultimately occupy the 225 same position in "space". 227 Because we are dealing with the electronic world, the notion of space 228 is used somewhat conceptually; depending on the application, what 229 constitutes "space" may vary. The MAC address of the device that the 230 UA instance runs upon would be a good way to denote its position in 231 space, where space is given as the network. However, there are 232 security implications involved with handing out a MAC address at the 233 application level. For one, it can be used to discover the 234 manufacturer of the device, which may help an attacker determine a 235 method of attack. 237 Therefore, MAC addresses SHOULD NOT be used as an identifier of space 238 for the purposes of a SIP GUID. 240 Additionally, there may be multiple UA instances executing on the 241 same CPU. For this reason, it is RECOMMENDED that the space component 242 of a SIP GUID be a location in memory that is uniquely held by that 243 UA instance, as well as the IP address of the UA. Taken together with 244 the time component, this still provides a high level of uniqueness 245 within the network. It is extremely unlikely that two UA instances 246 would be stored in the same location in memory, on two computers with 247 the exact same IP address, at the exact same "pseudo-clock" time. 249 SIP GUIDs MUST contain a space component that provides no fewer than 250 64 bits of uniqueness. 252 3.3 Comparing SIP GUIDs 254 When comparing two SIP GUIDs, their values SHOULD be considered a 255 unique identifier for the UA instance associated with the party that 256 sent the SIP request, including any aliases of the user or entity 257 identified by the sending party. 259 3.4 The GUID Header 261 The GUID header identifies a UA GUID. This header denotes the GUID 262 for that UA instance. The GUID header MUST NOT appear in a SIP 263 response, and if present MUST be ignored by the recipient. The GUID 264 header MAY appear in any SIP request type. It is RECOMMENDED that 265 user agents include their GUID in any REGISTER request sent. 267 3.4.1 Syntax 269 This document adds the following entry to Table 2 of [1]. Additions 270 to this table are also provided for extension methods defined at the 271 time of publication of this document. This is provided as a courtesy 272 to the reader and is not normative in any way. MESSAGE, SUBSCRIBE and 273 NOTIFY, REFER, INFO, UPDATE, PRACK, and PUBLISH are defined 274 respectively in [6], [7], [5], [8], [9], [10], and [11]. 276 Header field where proxy ACK BYE CAN INV OPT REG MSG 277 ------------ ----- ----- --- --- --- --- --- --- --- 278 GUID R o o o o o o o 280 SUB NOT REF INF UPD PRA PUB 281 --- --- --- --- --- --- --- 282 GUID R o o o o o o o 284 The following syntax specification uses the augmented Backus-Naur 285 Form (BNF) as described in RFC-2234 [3]. 287 GUID = "GUID" HCOLON token 289 A SIP request MUST contain no more than one GUID. 291 Examples: 293 GUID: f7ca930e2412f1bf016eb4940441672d3c26b17 295 GUID: 1076124654957190182543+47bfc83e+10.33.15.8 297 3.5 Proxy Behavior 299 Proxies MUST NOT modify the contents of the GUID header during 300 processing. It MAY be stripped according to the privacy policies of 301 the system should header privacy have been requested by the UA 302 sending the request in accordance with RFC-3323. 304 4. Security Considerations 306 The extension defined in this document may impact the security of a 307 particular SIP application. Depending on the use of the GUID in a 308 given application, considerations may need to be made to use a secure 309 transport mechanism such as TLS for sending SIP requests containing a 310 GUID. 312 5. IANA Considerations 314 5.1 Registration of the "GUID" SIP header 316 Name of Header: GUID 318 Short form: none 320 Normative description: section 3.4 of this document. 322 6. References 324 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 325 Peterson, J., Sparks, R. Handley, M. and E. Schooler, "SIP: Session 326 Initiation Protocol", RFC 3261, June 2002. 328 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 329 Levels", BCP 14, RFC 2119, March 1997. 331 [3] Crocker, D. and P. Overell, "Augmented BNF for Syntax 332 Specifications: ABNF", RFC 2234, November 1997. 334 [4] Rosenberg, J., "Obtaining and Using Globally Routable User Agent 335 (UA) URIs (GRUU) in the Session Initiation Protocol (SIP)", draft- 336 ietf-sip-gruu-00 (work in progress), January 2004. 338 [5] Sparks, R., "The Session Initiation Protocol (SIP) Refer 339 Method", RFC 3515, April 2003. 341 [6] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C. and D. 342 Gurle, "Session Initiation Protocol (SIP) Extension for Instant 343 Messaging", RFC 3428, December 2002. 345 [7] Roach, A., "Session Initiation Protocol (SIP)-Specific Event 346 Notification", RFC 3265, June 2002. 348 [8] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000. 350 [9] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE 351 Method", RFC 3311, October 2002. 353 [10] Rosenberg, J. and Schulzrinne, H., "Reliability of Provisional 354 Responses in Session Initiation Protocol (SIP)", RFC 2362, June 2002. 356 [11] Niemi, A., "SIMPLE Presence Publication Mechanism", draft-ietf- 357 sip-publish-02 (work in progress), January 2004. 359 7. Acknowledgements 361 Thanks to Jennifer Beckman, Mary Barnes, Alberto Villarica, Trip 362 Ingle, and William Janning for comments and helping to create the 363 foundation for this document. Additionally, thanks is given to 364 Jonathan Rosenberg for introduction of the GRUU draft which describes 365 the server-side generation of unique identifiers within SIP. 367 Author's Addresses 369 Brian Stucker 370 Nortel Networks 371 2380 Performance Drive 372 Richardson, Texas 373 Email: bstucker@nortelnetworks.com