idnits 2.17.1 draft-vanelburg-dispatch-private-network-ind-07.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 20, 2014) is 3657 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC3427' is defined on line 637, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 3427 (Obsoleted by RFC 5727) -- Obsolete informational reference (is this intentional?): RFC 3455 (Obsoleted by RFC 7315) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DISPATCH Working Group J. van Elburg 3 Internet-Draft Detecon International Gmbh 4 Intended status: Informational K. Drage 5 Expires: October 22, 2014 Alcatel-Lucent 6 M. Ohsugi 7 S. Schubert 8 K. Arai 9 NTT 10 April 20, 2014 12 The Session Initiation Protocol (SIP) P-Private-Network-Indication 13 Private-Header (P-Header) 14 draft-vanelburg-dispatch-private-network-ind-07 16 Abstract 18 This document specifies the SIP P-Private-Network-Indication P-header 19 used by the 3rd-Generation Partnership Project (3GPP). The 20 P-Private-Network-Indication indicates that the message is part of 21 the message traffic of a private network, and identifies that private 22 network. A private network indication allows nodes to treat private 23 network traffic according to a different set of rules than the set 24 applicable to public network traffic. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on October 22, 2014. 43 Copyright Notice 45 Copyright (c) 2014 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 1.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 4 63 1.3. Background . . . . . . . . . . . . . . . . . . . . . . . . 4 64 1.4. Business communication . . . . . . . . . . . . . . . . . . 4 65 1.5. Indication types . . . . . . . . . . . . . . . . . . . . . 5 66 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 3.1. Traffic . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 3.2. Public network traffic . . . . . . . . . . . . . . . . . . 7 70 3.3. Private network traffic . . . . . . . . . . . . . . . . . 7 71 3.4. Break-in . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 3.5. Break-out . . . . . . . . . . . . . . . . . . . . . . . . 7 73 3.6. Trust domain . . . . . . . . . . . . . . . . . . . . . . . 7 74 4. Application of terminology . . . . . . . . . . . . . . . . . . 8 75 5. Overview of solution . . . . . . . . . . . . . . . . . . . . . 11 76 6. Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 77 6.1. Proxy behavior . . . . . . . . . . . . . . . . . . . . . . 12 78 6.1.1. P-Private-Network-Indication generation . . . . . . . 12 79 6.1.2. Private-Network-Indication consumption . . . . . . . . 12 80 6.1.3. P-Private-Network-Indication removal . . . . . . . . . 12 81 6.1.4. P-Private-Network-Indication verification . . . . . . 12 82 7. P-Private-Network-Indication header field definition . . . . . 13 83 8. Security considerations . . . . . . . . . . . . . . . . . . . 13 84 9. IANA considerations . . . . . . . . . . . . . . . . . . . . . 14 85 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 86 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 87 11.1. Normative references . . . . . . . . . . . . . . . . . . . 15 88 11.2. Informative references . . . . . . . . . . . . . . . . . . 15 89 Appendix A. Alternative solutions discussed . . . . . . . . . . . 16 90 A.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 16 91 A.2. Attribute on existing header field . . . . . . . . . . . . 17 92 A.3. Token value on existing header field . . . . . . . . . . . 17 93 A.4. Resource-Priority header field . . . . . . . . . . . . . . 17 94 A.5. P-Asserted-Service header field . . . . . . . . . . . . . 17 95 A.6. Request-Disposition header field . . . . . . . . . . . . . 17 96 A.7. P-Access-Network-Information . . . . . . . . . . . . . . . 17 97 A.8. URI parameter . . . . . . . . . . . . . . . . . . . . . . 18 98 A.9. New header field . . . . . . . . . . . . . . . . . . . . . 18 99 A.9.1. General . . . . . . . . . . . . . . . . . . . . . . . 18 100 A.9.2. Full SIP header field . . . . . . . . . . . . . . . . 18 101 A.9.3. New P-header field . . . . . . . . . . . . . . . . . . 18 102 Appendix B. Additional note . . . . . . . . . . . . . . . . . . . 18 103 B.1. Original requirements . . . . . . . . . . . . . . . . . . 18 104 Appendix C. Revision Information . . . . . . . . . . . . . . . . 19 105 C.1. version 00, SIPPING . . . . . . . . . . . . . . . . . . . 19 106 C.2. version 01, SIPPING . . . . . . . . . . . . . . . . . . . 19 107 C.3. version 02, SIPPING . . . . . . . . . . . . . . . . . . . 20 108 C.4. version 03, SIPPING . . . . . . . . . . . . . . . . . . . 20 109 C.5. version 00, DISPATCH . . . . . . . . . . . . . . . . . . . 20 110 C.6. version 01, DISPATCH . . . . . . . . . . . . . . . . . . . 20 111 C.7. version 02, DISPATCH . . . . . . . . . . . . . . . . . . . 20 112 C.8. version 03, DISPATCH . . . . . . . . . . . . . . . . . . . 20 113 C.9. version 04, DISPATCH . . . . . . . . . . . . . . . . . . . 20 114 C.10. version 05, DISPATCH . . . . . . . . . . . . . . . . . . . 20 115 C.11. version 06, DISPATCH . . . . . . . . . . . . . . . . . . . 21 116 C.12. version 07, DISPATCH . . . . . . . . . . . . . . . . . . . 21 117 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 119 1. Introduction 121 1.1. Overview 123 ETSI TISPAN defined Next Generation Networks (NGN) which uses the 124 3rd-Generation Partnership Project (3GPP) IMS (IP Multimedia 125 Subsystem) which in turn uses SIP (RFC3261 [RFC3261]) as its main 126 signaling protocol. For more information on the IMS, a detailed 127 description can be found in 3GPP TS 23.228 [3GPP.23.228] and 3GPP TS 128 24.229 [3GPP.24.229]. 3GPP and ETSI TISPAN have identified a set of 129 requirements that can be met by defining a new optional SIP header, 130 according to the procedures in RFC 5727 [RFC5727]. 132 1.2. Applicability 134 The P-Private-Network-Indication header field is intended to be used 135 in controlled closed networks like 3GPP IMS and ETSI TISPAN NGN 136 networks. The P-Private-Network-Indication header is not intended 137 for the general internet environment and is probably not suitable for 138 such an environment. 140 For example, there are no mechanisms defined to prevent spoofing of 141 this header. So if a network were to accept calls carrying this 142 header from the general Internet, an attacker would be able to inject 143 information into private networks. 145 1.3. Background 147 The P-Private-Network-Indication header field has been referred by 148 3GPP IMS specifications and has already been used in some networks as 149 an indicator for a specific capability. The header field has been 150 already implemented in some vendors' equipment in some countries. 151 RFC 5727 [RFC5727] prohibits the new proposal of P-header "unless 152 existing deployments or standards use the prefix already." The 153 P-Private-Network-Indication header field is already used by existing 154 deployments and 3GPP standards, therefore, this is exactly the case 155 where the P-header is allowed as an exception. 157 1.4. Business communication 159 ETSI TISPAN has identified a framework [ETSI.181.019] for the support 160 of business communication capabilities by the NGN. As well as the 161 direct attachment of Next Generation Corporate Network (NGCN) 162 equipment, this includes the capability to "host" functionality 163 relating to an enterprise within the NGN itself. 165 These hosting arrangements are: 167 a) virtual leased line, where NGCN sites are interconnected through 168 the NGN; 170 b) business trunking application, where the NGN hosts transit 171 capabilities between NGCN's, break-in capabilities where the NGN 172 converts public network traffic to private network traffic for 173 delivery at a served NGCN and break-out capabilities where the 174 NGN converts private network traffic from a served NGCN to public 175 network traffic; and 177 c) hosted enterprise services, where an NGN hosts originating and/or 178 terminating business communication capabilities for business 179 communication users that are directly attached to an NGN. 181 ETSI TISPAN has requirements that can be met by the introduction of 182 an explicit indication for private network traffic. 184 The traffic generated or received by a public NGN on behalf of a 185 private network can be either: 187 1) public network traffic: traffic sent to or received from an NGN 188 for processing according to the rules for ordinary subscribers of 189 a public telecommunication network. This type of traffic is 190 known as public network traffic; or 192 2) private network traffic: traffic sent to the NGN for processing 193 according to an agreed set of rules specific to an enterprise. 194 This type of traffic is known as private network traffic. 195 Private network traffic is normally exchanged within a single 196 enterprise, but private network traffic can also be exchanged 197 between two or more different enterprises, based on some prior 198 arrangements, if not precluded for regulatory reasons. 200 1.5. Indication types 202 A private network indication as proposed by this document indicates 203 to the receiving network element (supporting this specification) that 204 this request is related to a private network traffic as opposed to a 205 public network traffic. This indication does not identify an end 206 user on a private network and is not for delivery to an end user on 207 the private network. It is an indication that special service 208 arrangements apply (if such service is configured based on private 209 network traffic) for an enterprise, and therefore it is an indication 210 of service on behalf of an enterprise, not an indication of service 211 to a private network's end user. 213 In order to allow NGN IMS nodes to perform different processing, ETSI 214 TISPAN formulated the following requirements on NGN. The NGN shall: 216 a) distinguish public network traffic from private network traffic; 217 and 219 b) distinguish private network traffic belonging to one enterprise 220 from that belonging to another enterprise. 222 To summarize a few example reasons for a public NGN to make the 223 distinction between the two types of traffic: 225 1) Different regulations apply to two types of traffic, for example 226 emergency calls may be handled differently depending on the type 227 of traffic. 229 2) Different charging regimes may apply. 231 3) Call recording for business reasons (e.g. quality control, 232 training, non-repudiation) might apply only to a specific type of 233 traffic; and 235 4) Different levels of signaling and/or media transparency may apply 236 to the different types of traffic. 238 There are several reasons why there is a need for an explicit 239 indication in the signaling: 241 a) Caller and callee addresses can not always be used to determine 242 whether a certain call is to be treated as private or public 243 network traffic. 245 b) Nodes spanning multiple networks often need to have different 246 behavior depending upon the type of traffic. When this is done 247 using implicit schemes, enterprise specific logic must be 248 distributed across multiple nodes in multiple operator's 249 networks. That is clearly not a manageable architecture and 250 solution; and 252 c) There may be cases where treating the call as a public network 253 call although both participants are from the same enterprise is 254 advantageous to the enterprise. 256 Based on the background provided, this document formulates 257 requirements for SIP to support an explicit private network 258 indication and defines a P-header, P-Private-Network-Indication, to 259 support those requirements. 261 2. Conventions 263 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 264 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 265 document are to be interpreted as described in BCP 14, RFC 2119 266 [RFC2119]. 268 3. Definitions 270 3.1. Traffic 272 In the context of this document the term traffic is understood as all 273 communication pertaining to and/or controlled by a SIP transaction or 274 dialog. 276 3.2. Public network traffic 278 Traffic sent to or received from a public telecommunication network 279 for processing according to the rules for ordinary subscribers of a 280 public telecommunication network. 282 3.3. Private network traffic 284 Traffic sent to or received from a public telecommunication network 285 for processing according to an agreed set of rules specific to an 286 enterprise or a community of closely related enterprises. 288 3.4. Break-in 290 Act of converting public network traffic to private network traffic. 291 The header defined in this specification will be added to indicate 292 the traffic is a private network traffic after conversion. 294 3.5. Break-out 296 Act of converting private network traffic to public network traffic. 297 The header defined in this specification will be removed to indicate 298 the traffic is a public network traffic after conversion 300 3.6. Trust domain 302 The term Trust Domain in this document is taken from P-Asserted- 303 Identity [RFC3324]. A trust domain applies to the private network 304 indication. The rules for specifying such a trust domain are 305 specified in P-Asserted-Identity [RFC3324] which require the 306 specification of a Spec(T) covered in section 2.4 of [RFC3324]. 308 The same information is required to specify a Spec(T) for purposes of 309 P-Private-Network-Indication as for P-Asserted-Identity [RFC3324]. 310 However, if a network is using P-Private-Network-Indication as well 311 as other header fields subject to Spec(T) (such as P-Asserted- 312 Identity), the Spec(T) for each header field will probably be 313 different from the others. 315 4. Application of terminology 317 Figure 1 shows the interconnection of sites belonging to two private 318 networks using the public network. Traffic in the public network 319 relating to the interconnection of the two sites of enterprise 1 are 320 tagged as private network traffic relating to enterprise 1. In 321 certain cases an enterprise can also choose to send traffic from one 322 enterprise site to another enterprise site as public network traffic 323 when this is beneficial to the enterprise. Traffic in the public 324 network relating to the interconnection of the two sites of 325 enterprise 2 are tagged as private network traffic relating to 326 enterprise 2. Enterprise 1 also generates traffic to public phones 327 and this is public network traffic (untagged in the public network). 328 There may be circumstances where traffic in the public network 329 between two different private networks is tagged as private network 330 traffic using a pre- arranged domain name agreed by the two involved 331 enterprises. This is illustrated by the interconnection of the site 332 from enterprise 3 and the site from enterprise 4. 334 +------------------------------+ 335 | private network | 336 +------------+ |<===========traffic==========>| +------------+ 337 | enterprise | | (enterprise 1) | | enterprise | 338 | 1 +-----+------------------------------+-----+ 1 ! 339 | site 1 | | | | site 2 | 340 +------------+ | +---+-----| | 341 | public | | | | 342 /--\ |<=========network========>| | +------------+ 343 o /\ o | traffic | | 344 / \----------+--------------------------+ | 345 +----+ | | 346 public | | 347 phone | | 348 | private network | 349 +------------+ |<===========traffic==========>| +------------+ 350 | enterprise | | (enterprise 2) | | enterprise | 351 | 2 +-----+------------------------------+-----+ 2 ! 352 | site 1 | | | | site 2 | 353 +------------+ | | +------------+ 354 | | 355 | private network | 356 +------------+ |<===========traffic==========>| +------------+ 357 | enterprise | | (pre-arranged domain name) | | enterprise | 358 | 3 +-----+------------------------------+-----+ 4 ! 359 | site 1 | | | | site 1 | 360 +------------+ | | +------------+ 361 | | 362 +------------------------------+ 364 Figure 1 : Two Private Networks 366 Figure 2 shows the interconnection of sites belonging to a private 367 network using the public network, and supported in the public network 368 by a server providing a business trunking application. The business 369 trunking application provides routing capabilities for the enterprise 370 traffic, and supports the identification of calls to and from public 371 network users and routing of break-in and break-out of that traffic. 372 (Note that the business trunking application may consist of a 373 concatenation of application logic provided to the originating 374 enterprise site and application logic that is provided to the 375 terminating enterprise site.) Traffic in the public network relating 376 to the interconnection of the two sites of enterprise 1 is tagged as 377 private network traffic relating to enterprise 1. The business 378 trunking application also routes traffic to public phones and this is 379 public network traffic (untagged in the public network). 381 +-------------------------------------------------+ 382 | private network | 383 +------------+ |<===========traffic============>+------------+ | 384 | enterprise | | (enterprise 1) | | | 385 | 1 +-----+--------------------------------+ | | 386 | site 1 | | | business | | 387 +------------+ | +-----+ trunking | | 388 | public | | application| | 389 /--\ |<=========network========>| +--+ | | 390 o /\ o | traffic | | | | | 391 / \----------+--------------------------+ | | | | 392 +----+ | | +------------+ | 393 public | | | 394 phone | | | 395 | private network | | 396 +------------+ |<===========traffic=========>| | 397 | enterprise | | (enterprise 1) | | 398 | 1 +-----+-----------------------------+ | 399 | site 2 | | | 400 +------------+ | | 401 | | 402 +-------------------------------------------------+ 404 Figure 2 : Private Network and Business Trunking 406 Figure 3 shows the interconnection of sites belonging to a private 407 network on a server providing a hosted enterprise service application 408 (also known as Centrex). The hosted enterprise service application 409 supports phones belonging to the enterprise and is also able to route 410 traffic to and from public network phones using break-in or break-out 411 functionality. Traffic in the public network relating to the 412 interconnection of the site of enterprise 1 and the hosted enterprise 413 service belonging to enterprise 1 is tagged as private network 414 traffic relating to enterprise 1. The hosted enterprise service 415 application also routes traffic to public phones and this is public 416 network traffic (untagged in the public network). Traffic from the 417 enterprise phones would not normally be tagged, but it can be tagged 418 as private network traffic. (Note that the hosted enterprise service 419 logic may precede or succeed a business trunking application that 420 offers services on behalf of an enterprise site.) 421 +-------------------------------------------------+ 422 | private network | 423 +------------+ |<===========traffic============>+------------+ | 424 | enterprise | | (enterprise 1) | | | 425 | 1 +-----+--------------------------------+ hosted | | 426 | site 1 | | | enterprise | | 427 +------------+ | +-----+ service | | 428 | public | | enterprise | | 429 /--\ |<=========network========>| +--+ 1 | | 430 o /\ o | traffic | | | | | 431 / \----------+--------------------------+ | | | | 432 +----+ | | +------------+ | 433 public | | | 434 phone | | | 435 | private network | | 436 /--\ |<===========traffic=========>| | 437 o /\ o | (enterprise 1) | | 438 / \----------+-----------------------------+ | 439 +----+ | | 440 enterprise | | 441 phone | | 442 +-------------------------------------------------+ 444 Figure 3 : Hosted Service and Private Network 446 5. Overview of solution 448 The mechanism proposed in this document relies on a new header field 449 called 'P-Private-Network-Indication' that contains a private network 450 identifier expressed as a domain name, for example: 452 P-Private-Network-Indication: example.com 454 A proxy server which handles a message MAY insert such a P-Private- 455 Network-Indication header field into the message based on 456 authentication of the source of a message, configuration or local 457 policy. A proxy server MAY forward the message to other proxies in 458 the same administrative domain or proxies in a trusted domain to be 459 handled as private network traffic. A proxy that forwards a message 460 to a proxy server or UA that it does not trust MUST remove the 461 P-Private-Network-Indication header field before forwarding the 462 message. 464 The private network identifier expressed as a domain name allows it 465 to be a globally unique identifier, associated with the originating 466 and/or terminating enterprise(s). Domain name is used, as it allows 467 reuse of a company owned internet domain name, without requiring an 468 additional private network identifier registry. When the enterprise 469 needs more than one identifier it can freely add subdomains under its 470 own control. 472 The formal syntax for the P-Private-Network-Indication header is 473 presented in Section 7. 475 6. Behavior 477 6.1. Proxy behavior 479 6.1.1. P-Private-Network-Indication generation 481 Proxies that are responsible for determining certain traffic to be 482 treated as private network traffic or contain a break-in function 483 that converts incoming public network traffic to private network 484 traffic MUST insert a P-Private-Network-Indication header field into 485 incoming or outgoing requests for a dialog or for a standalone 486 transaction. The value MUST be set to the private network identifier 487 corresponding to the enterprise(s) to which the traffic belongs. 489 6.1.2. Private-Network-Indication consumption 491 Proxies that are responsible for applying different processing 492 behaviors to specific private network traffic MUST support this 493 extension. The P-Private-Network-Indication header field MUST NOT be 494 used by a proxy in case it is received in a request from an entity 495 that it does not trust, in such a case it MUST be removed before the 496 request is forwarded. 498 6.1.3. P-Private-Network-Indication removal 500 Proxies that are at the edge of the trust domain or contain a break- 501 out function that converts incoming private network traffic to public 502 network traffic MUST remove the P-Private-Network-Indication header 503 field before forwarding a request that contains such a header field. 505 6.1.4. P-Private-Network-Indication verification 507 When proxies supporting this specification receive a P-Private- 508 Network-Indication header field in a SIP request from a trusted node, 509 proxies MUST check whether the received domain name in the request is 510 the same as the domain name associated with the provisioned domain 511 name. If the received domain name does not match, proxies MUST 512 remove the P-Private-Network-Indication header field. 514 7. P-Private-Network-Indication header field definition 516 This document defines the SIP P-Private-Network-Indication header 517 field. This header field can be added by a proxy to initial requests 518 for a dialog or standalone requests. The presence of the P-Private- 519 Network-Indication header field signifies to proxies that understand 520 the header field that the request is to be treated as private network 521 traffic. The P-Private-Network-Indication header field contains a 522 domain name value, that allows the private network traffic to be 523 associated with an enterprise, to which it belongs and that allows 524 proxies that understand this header field to process the request 525 according to the local policy configured for a specific 526 enterprise(s). 528 The augmented Backus-Naur Form (BNF) (RFC5234 [RFC5234]) syntax of 529 the P-Private-Network-Indication header field is described below: 531 P-Private-Network-Indication = 532 "P-Private-Network-Indication" HCOLON PNI-value 533 *(SEMI PNI-param) 534 PNI-param = generic-param 535 PNI-value = hostname 537 EQUAL, HCOLON, SEMI, hostname and generic-param are defined in 538 RFC3261 [RFC3261]. 540 The following is an example of a P-Private-Network-Indication header 541 field: 543 P-Private-Network-Indication: example.com 545 8. Security considerations 547 The private network indication defined in this document MUST only be 548 used in the traffic transported between the network elements which 549 are mutually trusted. Traffic protection between network elements 550 can be achieved by using the security protocols such as IPsec ESP 551 [RFC4303], SIP/TLS or sometimes by physical protection of the 552 network. In any case, the environment where the private network 553 indication will be used needs to ensure the integrity and the 554 confidentiality of the contents of this header field. 556 A private network indication received from an untrusted node MUST NOT 557 be used and the information MUST be removed from a request or 558 response before it is forwarded to entities in the trust domain. 559 Additionally local policies may be in place that ensure that all 560 requests entering the trust domain for private network indication 561 from untrusted nodes with a private network indication will be 562 discarded. 564 There is a security risk if a private network indication is allowed 565 to propagate out of the trust domain where it was generated. The 566 indication may reveal information about the identity of the caller, 567 i,e, the organisation that he belongs to. That is sensitive 568 information. It also reveals to the outside world that there is a 569 set of rules that this call is subject to that is different then the 570 rules that apply to public traffic. That is sensitive information 571 too. To prevent such a breach from happening, proxies MUST NOT 572 insert the information when forwarding requests to a next hop located 573 outside the trust domain. When forwarding the request to a trusted 574 node, proxies MUST NOT insert the header field unless they have 575 sufficient knowledge that the route set includes another proxy in the 576 trust domain that understands this header field. However, how to 577 learn such knowledge is out of scope. Proxies MUST remove the 578 information when forwarding requests to untrusted nodes or when the 579 proxy does not have knowledge of any other proxy in the route set 580 that is able to understand this header field. 582 9. IANA considerations 584 This document defines a new SIP header field: P-Private-Network- 585 Indication. This header field needs to be registered by the IANA in 586 the SIP Parameters registry under the Header Fields subregistry. 588 RFC Number: [This document] 590 Header Field Name: P-Private-Network-Indication 592 Compact Form: none 594 10. Acknowledgments 596 The authors would like to thank Richard Barnes, Mary Barnes, Atle 597 Monrad, Bruno Chatras, John Elwell and Salvatore Loreto for providing 598 comments on an early version of this draft. Further we thank John 599 Elwell for performing the expert review. 601 11. References 603 11.1. Normative references 605 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 606 Requirement Levels", BCP 14, RFC 2119, March 1997. 608 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 609 A., Peterson, J., Sparks, R., Handley, M., and E. 610 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 611 June 2002. 613 [RFC3324] Watson, M., "Short Term Requirements for Network Asserted 614 Identity", RFC 3324, November 2002. 616 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 617 Specifications: ABNF", STD 68, RFC 5234, January 2008. 619 11.2. Informative references 621 [ETSI.181.019] 622 ETSI, "Telecommunication and Internet converged Services 623 and Protocols for Advanced Networking (TISPAN); Business 624 Communication Requirements", ETSI TS 181 019 V2, 625 July 2007. 627 [3GPP.23.228] 628 3GPP, "IP Multimedia Subsystem (IMS); Stage 2", 3GPP 629 TS 23.228 V8, July 2007. 631 [3GPP.24.229] 632 3GPP, "Internet Protocol (IP) multimedia call control 633 protocol based on Session Initiation Protocol (SIP) and 634 Session Description Protocol (SDP); Stage 3", 3GPP 635 TS 24.229 V8, July 2007. 637 [RFC3427] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J., 638 and B. Rosen, "Change Process for the Session Initiation 639 Protocol (SIP)", RFC 3427, December 2002. 641 [RFC3455] Garcia-Martin, M., Henrikson, E., and D. Mills, "Private 642 Header (P-Header) Extensions to the Session Initiation 643 Protocol (SIP) for the 3rd-Generation Partnership Project 644 (3GPP)", RFC 3455, January 2003. 646 [RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller 647 Preferences for the Session Initiation Protocol (SIP)", 648 RFC 3841, August 2004. 650 [RFC5727] Peterson, J., Jennings, C., and R. Sparks, "Change Process 651 for the Session Initiation Protocol (SIP) and the Real- 652 time Applications and Infrastructure Area", BCP 67, 653 RFC 5727, March 2010. 655 [RFC6050] Drage, K., "A Session Initiation Protocol (SIP) Extension 656 for the Identification of Services", RFC 6050, 657 November 2010. 659 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 660 RFC 4303, December 2005. 662 Appendix A. Alternative solutions discussed 664 Note: The RFC Editor will remove these Appendixes. 666 A.1. General 668 It would be technical possible, but extremely complex to perform this 669 function without an explicit indication. For example, a logical 670 distinction of proxies to handle private network traffic relating to 671 enterprise 1, enterprise 2 and the public network traffic could be 672 made by assigning different SIP URIs to these logical entities. This 673 is not regarded as a viable solution. 675 Several solutions have been raised and whether or not they are 676 suitable and fulfill the requirements need to be discussed: 678 o Attribute on existing header? 680 o Token on some existing header? 682 o Resource-Priority header? 684 o P-Asserted-Service header? 686 o Request-Disposition header? 688 o P-Access-Network-Information header? 690 o URI parameter? 692 o New P-header? 694 o New header? 696 A.2. Attribute on existing header field 698 A.3. Token value on existing header field 700 A.4. Resource-Priority header field 702 Some of the distinctive functions are already provided for in this 703 header field. A potential mechanism would be to define a namespace 704 for private network traffic. It would however be impossible to 705 define a namespace for each enterprise, and therefore some additional 706 parameter would need to be defined to carry the unique identifier of 707 the particular enterprise to which the private network traffic 708 relates. Successful usage may also require a tightening of the 709 procedures for use of the Resource-Priority header field (much at the 710 moment is left to the particular application of this header field). 712 Private network traffic may, but is not necessarily handled with a 713 different priority then public network traffic. Use of the Resource- 714 Priority header field however seems to imply that the main focus of 715 the indication is on prioritizing private network traffic. This may 716 render use of the Resource-Priority header field as less appropriate 717 for our particular purpose. 719 A.5. P-Asserted-Service header field 721 The services envisaged by the P-Asserted-Service header field 722 (RFC6050 [RFC6050]) are those applied to the end user. The end user 723 in these cases is the end user of the enterprise or NGCN, not the 724 enterprise itself. Therefore this header field is not considered 725 suitable for this problem. 727 A.6. Request-Disposition header field 729 The Request-Disposition header field (RFC3841 [RFC3841]) specifies 730 caller preferences for how a server should process a request. The 731 caller in these cases is the end user of the enterprise or NGCN, not 732 the enterprise itself. Therefore this header field is not considered 733 suitable for this problem. Further RFC3841 explicitly states that 734 the set of request disposition directives is not extensible. 736 A.7. P-Access-Network-Information 738 The P-Access-Network-Info header field (RFC3455 [RFC3455]) contains 739 information about the access network that a UA uses to get IP 740 connectivity. However the access that one uses does not define the 741 private network that a call that one sets up is to be part of. 743 Particular examples that illustrate this: 745 o A Hosted Enterprise Services user (i.e. Centrex) uses the access 746 of the operator while still being able to setup calls that will 747 turn out to be private network traffic. 749 o A corporate network UE that attaches to an operator network, but 750 receives services from its home corporate network. 752 A.8. URI parameter 754 A marking on the entities within the Via header field that are 755 treating this as private network traffic. Potential marking on the 756 route header field of entities that are expected to treat it as 757 private network traffic. 759 A.9. New header field 761 A.9.1. General 763 If none of the existing header fields is appropriate a logical step 764 is to define a new header field for the private network indication. 766 A.9.2. Full SIP header field 768 A full SIP header field is appropriate when the usage of this 769 information element is more general then closed networks like ETSI 770 TISPAN NGN or 3GPP IMS. 772 A.9.3. New P-header field 774 In case no general usage is foreseen other then usage in closed 775 networks like those specified by ETSI TISPAN NGN or 3GPP IMS a 776 P-header field seems the appropriate choice. 778 Appendix B. Additional note 780 B.1. Original requirements 782 These requirements were used to develop this specification, but do 783 not in themselves form part of that specification.: 785 R1: It is REQUIRED that an indication can be sent in SIP initial 786 requests for a dialog or SIP standalone requests to indicate 787 that the request or associated session is to be treated 788 according to the rules of private network traffic. 790 R2: The indication from R1 can be inserted by a SIP proxy belonging 791 to an administrative domain for onward routing and for the 792 traffic within that administrative domain, that needs to be so 793 distinguished. The indication is not needed where the traffic 794 is assumed to be all public, or where the traffic is assumed to 795 be all private (contained within the closed network, not 796 crossing any public network). 798 R3: The indication from R1 can be removed by a SIP proxy belonging 799 to an administrative domain for onward routing where the traffic 800 no longer needs to be so distinguished. An example exists where 801 the traffic reaches an NGCN site where the traffic is assumed to 802 be all private network traffic. Another example is on the final 803 hop to the UA. 805 R4: It is REQUIRED that the indication from R1 allows entities to 806 determine the set of rules that are applicable, these rules may 807 be enterprise specific. 809 R5: It is REQUIRED that the indication from R1 allows entities 810 receiving it to distinguish private network traffic from 811 different enterprises. 813 R6: The identifier to distinguish private network traffic belonging 814 to one enterprise from that belonging to another enterprise MUST 815 be globally unique. Business communication arrangements for any 816 particular enterprise can be expected to span multiple NGN 817 operators potentially in multiple countries. 819 Note: The indication from R1 relates primarily to the SIP signaling. 820 Applying the same concept to media may be possible, but is not 821 necessarily meaningful where media is routed differently from 822 signaling. 824 Appendix C. Revision Information 826 The RFC Editor will remove these Appendixes. 828 C.1. version 00, SIPPING 830 1. 2008-02-18, Initial version 832 C.2. version 01, SIPPING 834 1. 2008-02-23, Added a solution based on a new header field. Added 835 Overview, Behavior and Header Definition sections. Updated the 836 trust domain definition. Improved some of the existing text 837 based on comments from John Elwell. 839 C.3. version 02, SIPPING 841 1. 2008-07-11, Changed to a P-header field. Changed title. Added 842 Terminology application and Applicability sections. Moved the 843 Potential solutions section to appendix Alternative solutions 844 discussed. 846 C.4. version 03, SIPPING 848 1. 2009-02-19, Updated boilerplate. 850 C.5. version 00, DISPATCH 852 1. 2009-07-06, Updates as result of Expert review. Moved to 853 DISPATCH. 855 C.6. version 01, DISPATCH 857 1. 2010-06-15, Resubmission. Authors address changed. No content 858 changes. Moved reference to RFC3427 to informative section as it 859 is deprecated by RFC5727 [RFC5727]. 861 C.7. version 02, DISPATCH 863 1. 2013-07-12, Updates according to the comments after Expert 864 review. Some changes for the consistency with other RFCs that 865 specify P-headers. Some editorial changes. 867 C.8. version 03, DISPATCH 869 1. 2013-09-12, Updates according to the discussion in DISPATCH list. 871 C.9. version 04, DISPATCH 873 1. 2013-12-03, Updates according to the discussion in DISPATCH list. 875 C.10. version 05, DISPATCH 877 1. 2013-01-29, Updates according to the discussion in DISPATCH list 878 and moved the original requirements that drove this draft to an 879 appendix. 881 C.11. version 06, DISPATCH 883 1. 2013-03-19, Updates reflecting AD's comment and SEC-DIR's 884 comments. 886 C.12. version 07, DISPATCH 888 1. 2013-04-20, Updates based on IESG's comments. 890 Authors' Addresses 892 Hans Erik van Elburg 893 Detecon International Gmbh 894 Oberkasselerstrasse 2 895 Bonn 53227 896 Germany 898 Email: ietf.hanserik@gmail.com 900 Keith Drage 901 Alcatel-Lucent 902 The Quadrant, Stonehill Green, Westlea 903 Swindon SN5 7DJ 904 UK 906 Email: drage@alcatel-lucent.com 908 Mayumi Ohsugi 909 NTT Corporation 911 Phone: +81 422 36 7502 912 Email: mayumi.ohsugi@ntt-at.co.jp 914 Shida Schubert 915 NTT Corporation 917 Phone: +1 415 323 9942 918 Email: shida@ntt-at.com 919 Kenjiro Arai 920 NTT Corporation 921 9-11, Midori-cho 3-Chome 922 Musashino-shi, Tokyo 180-8585 923 Japan 925 Phone: +81 422 59 3518 926 Email: arai.kenjiro@lab.ntt.co.jp 927 URI: http://www.ntt.co.jp