idnits 2.17.1 draft-drage-sipping-service-identification-05.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: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 249 has weird spacing: '... where proxy...' == Line 292 has weird spacing: '... where proxy...' -- 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 (September 9, 2010) is 4949 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFCxxxx' is mentioned on line 669, but not defined ** Obsolete normative reference: RFC 3406 (Obsoleted by RFC 8141) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 2976 (Obsoleted by RFC 6086) -- Obsolete informational reference (is this intentional?): RFC 3265 (Obsoleted by RFC 6665) Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Drage 3 Internet-Draft Alcatel-Lucent 4 Intended status: Informational September 9, 2010 5 Expires: March 13, 2011 7 A Session Initiation Protocol (SIP) Extension for the Identification of 8 Services 9 draft-drage-sipping-service-identification-05 11 Abstract 13 This document describes private extensions to the Session Initiation 14 Protocol (SIP) that enable a network of trusted SIP servers to assert 15 the service of authenticated users. The use of these extensions is 16 only applicable inside an administrative domain with previously 17 agreed-upon policies for generation, transport and usage of such 18 information. This document does NOT offer a general service 19 identification model suitable for use between different trust 20 domains, or use in the Internet at large. 22 The document also defines a URN to identify both services and UA 23 applications. This URN can be used within the SIP header fields 24 defined in this document to identify services, and also within the 25 framework defined for caller preferences and callee capabilities to 26 identify usage of both services and applications between end UAs. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on March 13, 2011. 45 Copyright Notice 47 Copyright (c) 2010 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 1. Introduction 62 This document describes private extensions to the Session Initiation 63 Protocol (SIP) that enable a network of trusted SIP servers to assert 64 the service possibly subject to the user being entitled to that 65 service. The use of these extensions is only applicable inside an 66 administrative domain with previously agreed-upon policies for 67 generation, transport and usage of such information. This document 68 does NOT offer a general service model suitable for use between 69 different trust domains, or use in the Internet at large. 71 The concept of "service" within SIP has no hard and fast rules. RFC 72 5897 [RFC5897] provides general guidance on what constitutes a 73 service within SIP and what does not. 75 This document also makes use of the terms "derived service 76 identification" and "declarative service identification" as defined 77 in RFC 5897 [RFC5897]. 79 It should be noted that RFC 5897 [RFC5897] clearly states that 80 declarative service identification -- the process by which a user 81 agent inserts a moniker into a message that defines the desired 82 service, separate from explicit and well-defined protocol mechanisms 83 -- is harmful. 85 During a session setup proxies may need to understand what service 86 the request is related to in order to know what application server to 87 contact or other service logic to invoke. The SIP INVITE request 88 contains all of the information necessary to determine the service. 89 However, the calculation of the service may be computational and 90 database intensive. For example, a given trust domain's definition 91 of a service might include request authorization. Moreover the 92 analysis may require examination of the SDP. 94 For example, an INVITE request with video SDP directed to a video-on- 95 demand Request-URI could be marked as an IPTV session. An INVITE 96 request with push-to-talk over cellular (PoC) routes could be marked 97 as a PoC session. An INVITE request with a Require header field 98 containing an option tag of "foogame" could be marked as a foogame 99 session. 101 NOTE: If the information contained within the SIP INVITE request is 102 not sufficient to uniquely identify a service, the remedy is to 103 extend the SIP signalling to capture the missing element. RFC 5897 104 [RFC5897] provides further explanation. 106 By providing a mechanism to compute and store the results of the 107 domain specific service calculation, i.e. the derived service 108 identification, this optimization allows a single trusted proxy to 109 perform an analysis of the request and authorize the requestor's 110 permission to request such a service. The proxy may then include a 111 service identifier that relieves other trusted proxies and trusted 112 UAs from performing further duplicate analysis of the request for 113 their service identification purposes. In addition, this extension 114 allows user agent clients outside the trust domain to provide a hint 115 of the requested service. 117 This extension does not provide for the dialog or transaction to be 118 rejected if the service is not supported end-to-end. SIP provides 119 other mechanisms, such as the option-tag and use of the Require and 120 Proxy-Require header fields, where such functionality is required. 121 No explicitly signalled service identification exists and the session 122 proceeds for each nodes definition of the service in use, on the 123 basis of information contained in SDP and in other SIP header fields. 125 This mechanism is specifically a mechanism to manage the information 126 needs of intermediate routeing devices between the calling user and 127 the user represented by the Request-URI. In support of this 128 mechanism, a URN is defined to identify the services. This URN has 129 wider applicability to additionally identify services and terminal 130 applications. Between end users, caller preferences and callee 131 capabilities as specified in RFC 3840 [RFC3840] and RFC 3841 132 [RFC3841] provide an appropriate mechanism for indicating such 133 service and application identification. These mechanisms have been 134 extended by RFC 5688 [RFC5688] to provide further capabilities in 135 this area. 137 The mechanism proposed in this document relies on a new header field 138 called 'P-Asserted-Service' that contains a URN. This is supported 139 by a further new header field called 'P-Preferred-Service' that also 140 contains a URN, and which allows the UA to express a preferences to 141 the decisions made on service within the trust domain. 143 P-Asserted-Service: urn:urn-7:3gpp-service.exampletelephony.version1 145 A proxy server which handles a request can, after authenticating the 146 originating user in some way (for example: Digest authentication), to 147 ensure that the user is entitled to that service, insert such a 148 P-Asserted-Service header field into the request and forward it to 149 other trusted proxies. A proxy that is about to forward a request to 150 a proxy server or UA that it does not trust removes all the 151 P-Asserted-Service header field values. 153 This document labels services by means of an informal URN. This 154 provides a hierarchical structure for defining services and 155 subservices, and provides an address that can be resolvable for 156 various purposes outside the scope of this document, e.g. to obtain 157 information about the service so described. 159 2. Applicability Statement 161 This document describes private extensions to SIP (see RFC 3261 162 [RFC3261]) that enable a network of trusted SIP servers to assert the 163 service of end users or end systems. The use of these extensions is 164 only applicable inside a 'Trust Domain' as defined in Short term 165 requirements for Network Asserted Identity (see RFC 3324 [RFC3324]). 166 Nodes in such a Trust Domain are explicitly trusted by its users and 167 end-systems to publicly assert the service of each party, and that 168 they have common and agreed upon definitions of services and 169 homogeneous service offerings. The means by which the network 170 determines the service to assert is outside the scope of this 171 document (though it commonly entails some form of authentication). 173 The mechanism for defining a trust domain is to provide a certain set 174 of specifications known as 'Spec(T)', and they specify compliance to 175 that set of specifications. Spec(T) MUST specify behavior as 176 documented in RFC 3324 [RFC3324]. 178 This document does NOT offer a general service model suitable for 179 inter-domain use or use in the Internet at large. Its assumptions 180 about the trust relationship between the user and the network may not 181 apply in many applications. For example, these extensions do not 182 accommodate a model whereby end users can independently assert their 183 service by use of the extensions defined here. End users assert 184 their service by including the SIP and SDP parameters that correspond 185 to the service they require. Furthermore, since the asserted 186 services are not cryptographically certified, they are subject to 187 forgery, replay, and falsification in any architecture that does not 188 meet the requirements of RFC 3324 [RFC3324]. 190 The asserted services also lack an indication of who specifically is 191 asserting the service, and so it must be assumed that a member of the 192 Trust Domain is asserting the service. Therefore, the information is 193 only meaningful when securely received from a node known to be a 194 member of the Trust Domain. 196 Despite these limitations, there are sufficiently useful specialized 197 deployments that meet the assumptions described above, and can accept 198 the limitations that result, to warrant informational publication of 199 this mechanism. 201 3. Conventions 203 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 204 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 205 document are to be interpreted as described in BCP 14, RFC 2119 206 [RFC2119]. 208 Throughout this document requirements for or references to proxy 209 servers or proxy behavior apply similarly to other intermediaries 210 within a Trust Domain (ex: B2BUAs). 212 The term Trust Domain in this document has the meaning as defined in 213 RFC 3324 [RFC3324]. 215 4. Syntax of the Header Fields 217 The following syntax specification uses the augmented Backus-Naur 218 Form (BNF) as described in RFC 5234 [RFC5234]. 220 4.1. The P-Asserted-Service Header 222 The P-Asserted-Service header field is used among trusted SIP 223 entities (typically intermediaries) to carry the service information 224 of the user sending a SIP message. 226 The P-Asserted-Service header field carries information that is 227 derived service identification. While a declarative service 228 identification can assist in deriving the value transferred in this 229 header field, this should be in the form of streamlining the correct 230 derived service identification. 232 PAssertedService = "P-Asserted-Service" 233 HCOLON PAssertedService-value 234 PAssertedService-value = Service-ID *(COMMA Service-ID) 236 See Section 4.4 for the definition of Service-ID in ABNF. 238 Proxies can (and will) add and remove this header field. 240 Table 1 adds the header fields defined in this document to Table 2 in 241 SIP [RFC3261], Section 7.1 of the SIP-specific event notification 242 [RFC3265], tables 1 and 2 in the SIP INFO method [RFC2976], tables 1 243 and 2 in Reliability of provisional responses in SIP [RFC3262], 244 tables 1 and 2 in the SIP UPDATE method [RFC3311], tables 1 and 2 in 245 the SIP extension for Instant Messaging [RFC3428], table 1 in the SIP 246 REFER method [RFC3515] and tables 2 and 3 in the SIP PUBLISH method 247 [RFC3903]: 249 Header field where proxy ACK BYE CAN INV OPT REG SUB 250 _______________________________________________________________ 251 P-Asserted-Service R admr - - - o o - o 253 Header field NOT PRA INF UPD MSG REF PUB 254 _______________________________________________________________ 255 P-Asserted-Service - - - - o o o 257 Table 1 259 Syntactically, there may be multiple P-Asserted-Service header fields 260 in a request. The semantics of multiple P-Asserted-Service header 261 fields appearing in the same request is not defined at this time. 262 Implementations of this specification MUST only provide one 263 P-Asserted-Service header field value. 265 4.2. The P-Preferred-Service Header 267 The P-Preferred-Service header field is used by a user agent sending 268 the SIP request to provide a hint to a trusted proxy of the preferred 269 service that the user wishes to be used for the P-Asserted-Service 270 field value that the trusted element will insert. 272 The P-Preferred-Service header field carries information that is 273 declarative service identification. Such information should only be 274 used to assist in deriving a derived service identification at the 275 recipient entity. 277 PPreferredService = "P-Preferred-Service" 278 HCOLON PPreferredService-value 279 PPreferredService-value = Service-ID *(COMMA Service-ID) 281 See Section 4.4 for the definition of Service-ID in ABNF. 283 Table 2 adds the header fields defined in this document to Table 2 in 284 SIP [RFC3261], Section 7.1 of the SIP-specific event notification 285 [RFC3265], tables 1 and 2 in the SIP INFO method [RFC2976], tables 1 286 and 2 in Reliability of provisional responses in SIP [RFC3262], 287 tables 1 and 2 in the SIP UPDATE method [RFC3311], tables 1 and 2 in 288 the SIP extension for Instant Messaging [RFC3428], table 1 in the SIP 289 REFER method [RFC3515] and tables 2 and 3 in the SIP PUBLISH method 290 [RFC3903]: 292 Header field where proxy ACK BYE CAN INV OPT REG SUB 293 _______________________________________________________________ 294 P-Preferred-Service R dr - - - o o - o 296 Header field NOT PRA INF UPD MSG REF PUB 297 _______________________________________________________________ 298 P-Preferred-Service - - - - o o o 300 Table 2 302 Syntactically, there may be multiple P-Preferred-Service header 303 fields in a request. The semantics of multiple P-Preferred-Service 304 header fields appearing in the same request is not defined at this 305 time. Implementations of this specification MUST only provide one 306 P-Preferred-Service header field value. 308 4.3. Service and Application Definition 310 Definition of services and their characteristics is outside the scope 311 of this document. Other standards organizations, vendors and 312 operators may define their own services and register them. 314 A hierarchical structure is defined consisting of service identifiers 315 or application identitifiers, subservice identifiers. 317 The service and subservice identifiers identify the service as 318 described in Section 1. The URN may also be used to identify a 319 service or an application between end users for use within the 320 context of RFC 3841 [RFC3841] and RFC 3840 [RFC3840]. 322 IANA maintains a registry of service identifier values that have been 323 assigned. This registry is created by the actions of Section 8.2 of 324 this document. 326 Subservice identifiers are not managed by IANA. It is the 327 responsibility of the organisation that registered the service to 328 manage the subservices. 330 4.4. Registration Template 332 Below, we include the registration template for the URN scheme 333 according to RFC 3406 [RFC3406]. The URN scheme is defined as an 334 informal NID. 336 Namespace ID: urn-7 338 Registration Information: Registration version: 1; registration 339 date: 2009-03-22 341 Declared registrant of the namespace: 3GPP Specifications Manager 342 (3gppContact@etsi.org) (+33 (0)492944200) 344 Declaration of syntactic structure: The URN consists of a 345 hierarchical service identifier or application identifier, with a 346 sequence of labels separated by periods. The left-most label is 347 the most significant one and is called 'top-level service 348 identifier', while names to the right are called 'sub-services' or 349 'sub-applications'. The set of allowable characters is the same 350 as that for domain names (see RFC 1123 [RFC1123]) and a subset of 351 the labels allowed in RFC 3958 [RFC3958]. Labels are case- 352 insensitive and MUST be specified in all lower-case. For any 353 given service identifier, labels can be removed right-to-left and 354 the resulting URN is still valid, referring a more generic 355 service, with the exception of the top-level service identifier 356 and possibly the first sub-service or sub-application identifier. 357 Labels cannot be removed beyond a defined basic service, for 358 example, the label w.x may define a service, but the label w may 359 only define an assignment authority for assigning subsequent 360 values and not define a service in its own right. In other words, 361 if a service identifier 'w.x.y.z' exists, the URNs 'w.x' and 362 'w.x.y' are also valid service identifiers, but w may not be a 363 valid service identifier if it merely defines who is responsible 364 for defining x. 366 Service-ID = "urn:urn-7:" urn-service-id 367 urn-service-id = top-level *("." sub-service-id) 368 top-level = let-dig [ *26let-dig ] 369 sub-service-id = let-dig [ *let-dig ] 370 let-dig = ALPHA / DIGIT / "-" 372 While the naming convention above uses the term "service" all the 373 constructs are equally applicable to identifying applications 374 within the UA. 376 Note to RFC editor: the value above has been preassigned by IANA. 378 Relevant ancillary documentation: None 380 Identifier uniqueness considerations: A service identifier 381 identifies a service, and an application identifier an application 382 indicated in the service or application registration (see IANA 383 Considerations (Section 8)). Uniqueness is guaranteed by the IANA 384 registration. 386 Identifier persistence considerations: The service or application 387 identifier for the same service is or application expected to be 388 persistent, although there naturally cannot be a guarantee that a 389 particular service will continue to be available globally or at 390 all times. 392 Process of identifier assignment: The process of identifier 393 assignment is described in the IANA Considerations (Section 8). 395 Process for identifier resolution: There is no single global 396 resolution service for service identifiers or application 397 identifiers. 399 Rules for Lexical Equivalence: 'service' identifiers are compared 400 according to case-insensitive string equality. 402 Conformance with URN Syntax: The BNF in the 'Declaration of 403 syntactic structure' above constrains the syntax for this URN 404 scheme. 406 Validation mechanism: Validation determines whether a given string 407 is currently a validly-assigned URN (see RFC 3406 [RFC3406]). Due 408 to the distributed nature of usage and since not all services are 409 available everywhere, validation in this sense is not possible 411 Scope: The scope for this URN can be local to a single domain, or 412 may be more widely used. 414 5. Usage of the P-Preferred-Service and P-Asserted-Service header 415 fields 417 5.1. Usage of the P-Preferred-Service and P-Asserted-Service header 418 fields in Requests 420 5.1.1. Procedures at User Agent Clients (UAC) 422 The UAC MAY insert a P-Preferred-Service in a request that creates a 423 dialog, or a request outside of a dialog. This information can 424 assist the proxies in identifying appropriate service capabilities to 425 apply to the call. This information MUST NOT conflict with other SIP 426 or SDP information included in the request. Furthermore, the SIP or 427 SDP information needed to signal functionality of this service MUST 428 be present. Thus if a service requires a video component, then the 429 SDP has to include the media line associated with that video 430 component; it cannot be assumed from the P-Preferred-Service header 431 field value. Similarly if the service requires particular SIP 432 functionality for which a SIP extension and a Require header field 433 value is defined, then the request has to include that SIP signalling 434 as well as the P-Preferred-Service header field value. 436 A UAC that is within the same trust domain as the proxy it sends a 437 request to, (e.g a media gateway or application server) MAY insert a 438 P-Asserted-Service header field in a request that creates a dialog, 439 or a request outside of a dialog. This information MUST NOT conflict 440 with other SIP or SDP information included in the request. 441 Furthermore, the SIP or SDP information needed to signal 442 functionality of this service MUST be present. 444 5.1.2. Procedures at Intermediate Proxies 446 A proxy in a Trust Domain can receive a request from a node that it 447 trusts, or a node that it does not trust. When a proxy receives a 448 request from a node it does not trust and it wishes to add a 449 P-Asserted-Service header field, the proxy MUST identify the service 450 appropriate to the capabilities (e.g. SDP) in the request, MAY 451 authenticate the originator of the request (in order to determine 452 whether the user is subscribed for that service), and use the 453 identity which results from this checking and authentication to 454 insert a P-Asserted-Service header field into the request. 456 When a proxy receives a request containing a P-Preferred-Service 457 header field the Proxy MAY use the contents of that header field to 458 assist in determining the service to be included in a P-Asserted- 459 Service header field, (for instance to prioritize the order of 460 comparison of filter criteria for potential services that the request 461 could match). The proxy MUST NOT use the contents of the 462 P-Preferred-Service header field to identify the service without 463 first checking against the capabilities (e.g. SDP) contained in the 464 request. If the proxy inserts a P-Asserted-Service header field in 465 the request the proxy MUST remove the P-Preferred-Service header 466 field before forwarding the request, otherwise the Proxy SHOULD 467 include the P-Preferred-Service header field when forwarding the 468 request. 470 If the proxy receives a request from a node that it trusts, it can 471 use the information in the P-Asserted-Service header field, if any, 472 as if it had authenticated the user itself. 474 If there is no P-Asserted-Service header field present, or it is not 475 possible to match the request to a specific service as identified by 476 the service identifier, a proxy MAY add one containing it using its 477 own analysis of the information contained in the SIP request. If the 478 proxy received the request from an element that it does not trust and 479 there is a P-Asserted-Service header present, the proxy MUST replace 480 that header field contents with a new analysis or remove this header 481 field. 483 The analysis performed to identify such service identifiers is 484 outside the scope of this document. However, it is perfectly valid 485 as a result of the analysis to not include any service identifier in 486 the forwarded required, and thus not include a P-Asserted-Service 487 header field. 489 If a proxy forwards a request to a node outside the proxy's trust 490 domain, there MUST NOT be a P-Asserted-Service header field in the 491 forwarded request. 493 5.1.3. Procedures at User Agent Servers (UAS) 495 For a UAS outside the trust domain, the P-Asserted-Service header is 496 removed before it reaches this entity, therefore there are no 497 procedures for such a device. 499 However, if a User Agent Server receives a request from a previous 500 element that it does not trust, it MUST NOT use the P-Asserted- 501 Service header field in any way. 503 If a UA is part of the Trust Domain from which it received a request 504 containing a P-Asserted-Service header field, then it can use the 505 value freely but it MUST ensure that it does not forward the 506 information to any element that is not part of the Trust Domain. 508 5.2. Usage of the P-Preferred-Service and P-Asserted-Service header 509 fields in Responses 511 There is no usage of these header field in responses. 513 6. Examples of Usage 515 In this example, proxy.example.com creates a P-Asserted-Service 516 header field from the user identity it discovered from SIP Digest 517 authentication, and the list of services appropriate to that user, 518 and the services that correspond to the SDP information included in 519 the request. Note that F1 and F2 are about identifying the user and 520 do not directly form part of the capability provided in this 521 document. It forwards this information to a trusted proxy which 522 forwards it to a trusted gateway. Note that these examples consist 523 of partial SIP messages that illustrate only those header fields 524 relevant to the authenticated identity problem. 526 * F1 useragent.example.com -> proxy.example.com 528 INVITE sip:+14085551212@example.com SIP/2.0 529 Via: SIP/2.0/TCP useragent.example.com;branch=z9hG4bK-123 530 To: 531 From: "Anonymous" ;tag=9802748 532 Call-ID: 245780247857024504 533 CSeq: 1 INVITE 534 Max-Forwards: 70 536 v=0 537 o=- 2987933615 2987933615 IN IP6 5555::aaa:bbb:ccc:ddd 538 s=- 539 c=IN IP6 5555::aaa:bbb:ccc:ddd 540 t=0 0 541 m=audio 3456 RTP/AVPF 97 96 542 b=AS:25.4 543 a=curr:qos local sendrecv 544 a=curr:qos remote none 545 a=des:qos mandatory local sendrecv 546 a=des:qos mandatory remote sendrecv 547 a=sendrecv 548 a=rtpmap:97 AMR 549 a=fmtp:97 mode-set=0,2,5,7; maxframes 551 * F2 proxy.example.com -> useragent.example.com 553 SIP/2.0 407 Proxy Authorization 554 Via: SIP/2.0/TCP useragent.example.com;branch=z9hG4bK-123 555 To: ;tag=123456 556 From: "Anonymous" ;tag=9802748 557 Call-ID: 245780247857024504 558 CSeq: 1 INVITE 559 Proxy-Authenticate: .... realm="sip.example.com" 560 * F3 useragent.example.com -> proxy.example.com 562 INVITE sip:+14085551212@example.com SIP/2.0 563 Via: SIP/2.0/TCP useragent.example.com;branch=z9hG4bK-124 564 To: 565 From: "Anonymous" ;tag=9802748 566 Call-ID: 245780247857024504 567 CSeq: 2 INVITE 568 Max-Forwards: 70 569 Proxy-Authorization: realm="sip.example.com" user="fluffy" 571 v=0 572 o=- 2987933615 2987933615 IN IP6 5555::aaa:bbb:ccc:ddd 573 s=- 574 c=IN IP6 5555::aaa:bbb:ccc:ddd 575 t=0 0 576 m=audio 3456 RTP/AVPF 97 96 577 b=AS:25.4 578 a=curr:qos local sendrecv 579 a=curr:qos remote none 580 a=des:qos mandatory local sendrecv 581 a=des:qos mandatory remote sendrecv 582 a=sendrecv 583 a=rtpmap:97 AMR 584 a=fmtp:97 mode-set=0,2,5,7; maxframes 586 * F4 proxy.example.com -> proxy.pstn.example (trusted) 588 INVITE sip:+14085551212@proxy. pstn.example SIP/2.0 589 Via: SIP/2.0/TCP useragent.example.com;branch=z9hG4bK-124 590 Via: SIP/2.0/TCP proxy.example.com;branch=z9hG4bK-abc 591 To: 592 From: "Anonymous" ;tag=9802748 593 Call-ID: 245780247857024504 594 CSeq: 2 INVITE 595 Max-Forwards: 69 596 P-Asserted-Service: urn:urn-7:3gpp-service.exampletelephony.version1 598 v=0 599 o=- 2987933615 2987933615 IN IP6 5555::aaa:bbb:ccc:ddd 600 s=- 601 c=IN IP6 5555::aaa:bbb:ccc:ddd 602 t=0 0 603 m=audio 3456 RTP/AVPF 97 96 604 b=AS:25.4 605 a=curr:qos local sendrecv 606 a=curr:qos remote none 607 a=des:qos mandatory local sendrecv 608 a=des:qos mandatory remote sendrecv 609 a=sendrecv 610 a=rtpmap:97 AMR 611 a=fmtp:97 mode-set=0,2,5,7; maxframes 612 * F5 proxy.pstn.example -> gw.pstn.example (trusted) 614 INVITE sip:+14085551212@gw.pstn.example SIP/2.0 615 Via: SIP/2.0/TCP useragent.example.com;branch=z9hG4bK-124 616 Via: SIP/2.0/TCP proxy.example.com;branch=z9hG4bK-abc 617 Via: SIP/2.0/TCP proxy.pstn.example;branch=z9hG4bK-a1b2 618 To: 619 From: "Anonymous" ;tag=9802748 620 Call-ID: 245780247857024504 621 CSeq: 2 INVITE 622 Max-Forwards: 68 623 P-Asserted-Service: urn:urn-7:3gpp-service.exampletelephony.version1 625 v=0 626 o=- 2987933615 2987933615 IN IP6 5555::aaa:bbb:ccc:ddd 627 s=- 628 c=IN IP6 5555::aaa:bbb:ccc:ddd 629 t=0 0 630 m=audio 3456 RTP/AVPF 97 96 631 b=AS:25.4 632 a=curr:qos local sendrecv 633 a=curr:qos remote none 634 a=des:qos mandatory local sendrecv 635 a=des:qos mandatory remote sendrecv 636 a=sendrecv 637 a=rtpmap:97 AMR 638 a=fmtp:97 mode-set=0,2,5,7; maxframes 640 7. Security considerations 642 The mechanism provided in this document is a partial consideration of 643 the problem of service identification in SIP. For example, these 644 mechanisms provide no means by which end users can securely share 645 service information end-to-end without a trusted service provider. 646 This information is secured by transitive trust, which is only as 647 reliable as the weakest link in the chain of trust. 649 The trust domain provides a set of servers where the characteristics 650 of the service are agreed for that service identifier value, and that 651 the calling user is entitled to use that service. RFC 5897 [RFC5897] 652 identifies the impact of allowing such service identifier values to 653 "leak" outside of the trust domain, including implications on fraud, 654 interoperability and stifling of service innovation. 656 8. IANA considerations 658 8.1. P-Asserted-Service and P-Preferred-Service header fields 660 This document specifies two new SIP header fields: P-Asserted-Service 661 and P-Preferred-Service. Their syntax is given in Section 3. These 662 header fields are defined by the following information, which has 663 been added to the header sub-registry under 664 http://www.iana.org/assignments/sip-parameters. 666 Header Name compact Reference 667 ----------------- ------- --------- 668 P-Asserted-Service [RFCxxxx] 669 P-Preferred-Service [RFCxxxx] 671 Note to the RFC editor: substitute xxxx with the RFC number of this 672 document. 674 8.2. Definition of Service-ID values 676 top-level identifiers are identified by labels managed by IANA, 677 according to the processes outlined in RFC 5226 [RFC5226] in a new 678 registry called "Service-ID/Application-ID Labels". Thus, creating a 679 new service at the top-level requires IANA action. The policy for 680 adding service labels is 'specification required'. The following two 681 identifiers are initially defined: 683 3gpp-service 685 3gpp-application 687 Subservice identifiers are not managed by IANA. It is the 688 responsibility of the organisation that registered the service to 689 manage the subservices. 691 Application identifiers are not managed by IANA. It is the 692 responsibility of the organisation that registered the service to 693 manage the applicable applications. 695 Entries in the registration table have the following format: 697 Service/Application Reference Description 698 -------------------------------------------------------------------- 699 3gpp-service RFCxxxx Communication services defined by 700 3GPP for use by the IM CN subsystem 701 and its attached UAs. This value 702 in itself does not define a service 703 and requires subsequent labels to 704 define the service. 706 3gpp-application RFCxxxx Applications defined by 3GPP for 707 use by UAs attached to the IM CN 708 subsystem. This value in itself 709 does not define a service and 710 requires subsequent labels to define 711 the service. 713 Note to the RFC editor: substitute xxxx with the RFC number of this 714 document. 716 9. APPENDIX: Changes history 718 Note to RFC Editor: Please remove this entire appendix before 719 publication 721 9.1. Changes between version -01 and version -02 723 1. Incorporation of terms "derived service identification" and 724 "declarative service identification" from 725 draft-ietf-sipping-service-identification. 727 2. Correction of the URN syntax in examples. 729 3. Appropriate introduction to table 1 and table 2 placing these in 730 a normative context to those in other tables in other RFCs. 732 4. Addition to security considerations section to clarify trust 733 domain concept. 735 5. References to RFC 3325 changed to RFC 3324 for definition of 736 trust domain. 738 6. Reference to RFC 2234 updated to RFC 5234 because the later 739 revision applies. No consequential technical change. 741 7. Reference to RFC 2434 updated to RFC 5226 because the later 742 revision applies. No consequential technical change. 744 8. References updated to symbolic. Remove of reference identifiers 745 from abstract. 747 9. Numerous editorial changes and minor clarifications. 749 9.2. Changes between version -02 and version -03 751 1. The URN value has been preassigned by IANA. This valye 752 substituted into document. 754 2. service-id is extended to include "urn:" within the expansion to 755 conform to usage. 757 3. Procedures inserted where the UAS is inside the trust domain, 758 e.g. gateway. 760 4. Procedures inserted for the proxy handling of a P-Preferred- 761 Service header field. 763 5. A number of editorial corrections. 765 9.3. Changes between version -03 and version -04 767 1. Addition of a paragraph to the introduction stating the position 768 of RFC 5897 on declarative service identification. 770 2. Update of a number of references that have since become RFCs. 772 3. A number of editorial corrections. 774 10. References 776 10.1. Normative References 778 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application 779 and Support", STD 3, RFC 1123, October 1989. 781 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 782 Requirement Levels", BCP 14, RFC 2119, March 1997. 784 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 785 A., Peterson, J., Sparks, R., Handley, M., and E. 786 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 787 June 2002. 789 [RFC3324] Watson, M., "Short Term Requirements for Network Asserted 790 Identity", RFC 3324, November 2002. 792 [RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, 793 "Uniform Resource Names (URN) Namespace Definition 794 Mechanisms", BCP 66, RFC 3406, October 2002. 796 [RFC3958] Daigle, L. and A. Newton, "Domain-Based Application 797 Service Location Using SRV RRs and the Dynamic Delegation 798 Discovery Service (DDDS)", RFC 3958, January 2005. 800 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 801 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 802 May 2008. 804 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 805 Specifications: ABNF", STD 68, RFC 5234, January 2008. 807 10.2. Informative References 809 [RFC2976] Donovan, S., "The SIP INFO Method", RFC 2976, 810 October 2000. 812 [RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of 813 Provisional Responses in Session Initiation Protocol 814 (SIP)", RFC 3262, June 2002. 816 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific 817 Event Notification", RFC 3265, June 2002. 819 [RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) 820 UPDATE Method", RFC 3311, October 2002. 822 [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., 823 and D. Gurle, "Session Initiation Protocol (SIP) Extension 824 for Instant Messaging", RFC 3428, December 2002. 826 [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer 827 Method", RFC 3515, April 2003. 829 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 830 "Indicating User Agent Capabilities in the Session 831 Initiation Protocol (SIP)", RFC 3840, August 2004. 833 [RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller 834 Preferences for the Session Initiation Protocol (SIP)", 835 RFC 3841, August 2004. 837 [RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension 838 for Event State Publication", RFC 3903, October 2004. 840 [RFC5688] Rosenberg, J., "A Session Initiation Protocol (SIP) Media 841 Feature Tag for MIME Application Subtypes", RFC 5688, 842 January 2010. 844 [RFC5897] Rosenberg, J., "Identification of Communications Services 845 in the Session Initiation Protocol (SIP)", RFC 5897, 846 June 2010. 848 Author's Address 850 Keith Drage 851 Alcatel-Lucent 852 Quadrant, Stonehill Green, Westlea 853 Swindon, Wilts 854 UK 856 Email: drage@alcatel-lucent.com