]> Detecon International Gmbh

Oberkasselerstrasse 2 53227 Bonn Germany ietf.hanserik@gmail.com

Alcatel-Lucent

The Quadrant, Stonehill Green, Westlea SN5 7DJ Swindon UK drage@alcatel-lucent.com

NTT Corporation

+81 422 36 7502 mayumi.ohsugi@ntt-at.co.jp

NTT Corporation

+1 415 323 9942 shida@ntt-at.com

NTT Corporation

9-11, Midori-cho 3-Chome Musashino-shi Tokyo 180-8585 Japan +81 422 59 3518 arai.kenjiro@lab.ntt.co.jp http://www.ntt.co.jp

Transport DISPATCH Working Group SIP enterprise corporate private network business communication This document specifies the SIP P-Private-Network-Indication P-header used by the 3rd-Generation Partnership Project (3GPP). The use of this private network indication extension is only applicable inside an administrative domain with previously agreed-upon policies for generation, transport and usage of such information. A private network indication allows nodes in such a domain to treat private network traffic according to a different set of rules than the set applicable to public network traffic. The indication also distinguishes traffic from one private network from another private network.

ETSI TISPAN defined Next Generation Networks (NGN) which uses the 3rd-Generqation Partnership Project (3GPP) IMS (IP Multimedia Subsystem) which in turn uses SIP (RFC3261 ) as its main signaling protocol. (For more information on the IMS, a detailed description can be found in 3GPP TS 23.228 and 3GPP TS 24.229 .) 3GPP and ETSI TISPAN have identified a set of requirements that can be met by defining a new optional SIP header, according to the procedures in RFC 5727 .

According to RFC 3427 , P-headers have a limited applicability. Specifications of P-headers such as this RFC need to clearly document the useful scope of the proposal, and explain its limitations and why it is not suitable for the general use of SIP on the Internet. The P-Private-Network-Indication header field is intended to be used in controlled closed networks like 3GPP IMS and ETSI TISPAN NGN networks. The P-Private-Network-Indication header is not intended for the general internet environment and is probably not suitable for such an environment.

The P-Private-Network-Indication header field has been referred by 3GPP IMS specifications and has already been used in some networks as an indicator for a specific capability. The header field has been already implemented in some vendors' equipment in some countries. RFC 5727 prohibits the new proposal of P-header "unless existing deployments or standards use the prefix already." The P-Private-Network-Indication header field is already used by existing deployments and 3GPP standards, therefore, this is exactly the case where the P-header is allowed as an exception.

ETSI TISPAN has identified a framework for the support of business communication capabilities by the NGN. As well as the direct attachment of Next Generation Corporate Network (NGCN) equipment, this includes the capability to "host" functionality relating to an enterprise within the NGN itself. These hosting arrangements are: virtual leased line, where NGCN sites are interconnected through the NGN; business trunking application, where the NGN hosts transit capabilities between NGCN's, break-in capabilities where the NGN converts public network traffic to private network traffic for delivery at a served NGCN and break-out capabilities where the NGN converts private network traffic from a served NGCN to public network traffic; and hosted enterprise services, where an NGN hosts originating and/or terminating business communication capabilities for business communication users that are directly attached to an NGN. ETSI TISPAN has requirements that can be met by the introduction of an explicit indication for private network traffic. The traffic generated or received by a public NGN on behalf of a private network can be either: public network traffic: traffic sent to or received from an NGN for processing according to the rules for ordinary subscribers of a public telecommunication network. This type of traffic is known as public network traffic; private network traffic: traffic sent to the NGN for processing according to an agreed set of rules specific to an enterprise. This type of traffic is known as private network traffic. Private network traffic is normally exchanged within a single enterprise, but private network traffic can also be exchanged between two or more different enterprises, based on some prior arrangements, if not precluded for regulatory reasons.

A private network indication as proposed by this document is an indication to network element (supporting this specification) traversed that this is a private network traffic as opposed to a public network traffic. This indication does not identify an end user on a private network and is not for delivery to an end user on the private network. It is an indication that special service arrangements apply (if such service is configured based on private network traffic) for an enterprise, and therefore it is an indication of service on behalf to an enterprise, not an indication of service to a private network's end user. In order to allow NGN IMS nodes to perform different processing, ETSI TISPAN formulated the following requirements on NGN: The NGN shall distinguish public network traffic from private network traffic. The NGN shall distinguish private network traffic belonging to one enterprise from that belonging to another enterprise. To summarize a few example reasons for a public NGN to make the distinction between the two types of traffic: Different regulations apply to two types of traffic, most notably lawful intercept requirements. Another example is that emergency calls may be handled differently depending on the type of traffic. Different charging regimes may apply. Call recording for business reasons (e.g. quality control, training, non-repudiation) might apply only to a specific type of traffic. Different levels of signaling and/or media transparency may apply to the different types of traffic. There are several reasons why there is a need for an explicit indication in the signaling: As caller and callee addresses can not always be used to determine whether a certain call is to be treated as private or public network traffic. Different nodes spanning over different network may need to be able to act differently on type of traffic, when implicit schemes is used, it would require distribution of such enterprise specific logic over multiple nodes in multiple operators. That is clearly not a manageable architecture and solution. There may be cases where treating the call as a public network call although both participants are from the same enterprise is advantageous to the enterprise. Given the above background this document will formulate requirements for SIP to support an explicit private network indication.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 .

In the context of this document the term traffic is understood as all communication pertaining to and/or controlled by a SIP transaction or dialog.

Traffic sent to or received from a public telecommunication network for processing according to the rules for ordinary subscribers of a public telecommunication network.

Traffic sent to or received from a public telecommunication network for processing according to an agreed set of rules specific to an enterprise or a community of closely related enterprises.

The term Trust Domain in this document is taken from RFC3324 . A trust domain applies to the private network indication. The rules for specifying such a trust domain are specified in RFC3324 which require the filling out a Spec (T). The Spec (T) need not specify the same contents and trust domain boundaries that are used for other header fields like for example the P-Asserted-Identity.

Figure 1 shows the interconnection of sites belonging to two private networks using the public network. Traffic in the public network relating to the interconnection of the two sites of enterprise 1 are tagged as private network traffic relating to enterprise 1. In certain cases an enterprise can also choose to send traffic from one enterprise site to another enterprise site as public network traffic when this is beneficial to the enterprise. Traffic in the public network relating to the interconnection of the two sites of enterprise 2 are tagged as private network traffic relating to enterprise 2. Enterprise 1 also generates traffic to public phones and this is public network traffic (untagged in the public network). There may be circumstances where traffic between two different enterprises are tagged as private network traffic relating to the common domain that is pre-agreed between the two enterprises. | +------------+ | enterprise | | (enterprise 1) | | enterprise | | 1 +-----+------------------------------+-----+ 1 ! | site 1 | | | | site 2 | +------------+ | +---+-----| | | public | | | | /--\ |<=========network========>| | +------------+ o /\ o | traffic | | / \----------+--------------------------+ | +----+ | | public | | phone | | | private network | +------------+ |<===========traffic==========>| +------------+ | enterprise | | (enterprise 2) | | enterprise | | 2 +-----+------------------------------+-----+ 2 ! | site 1 | | | | site 2 | +------------+ | | +------------+ | | | private network | +------------+ |<===========traffic==========>| +------------+ | enterprise | | (common domain) | | enterprise | | 3 +-----+------------------------------+-----+ 4 ! | site 1 | | | | site 1 | +------------+ | | +------------+ | | +------------------------------+ Figure 1 ]]> Figure 2 shows the interconnection of sites belonging to a private network using the public network, and supported in the public network by a server providing a business trunking application. The business trunking application provides routing capabilities for the enterprise traffic, and supports the identification of calls to and from public network users, break-in and break out of that traffic. (Note that the business trunking application may consist of a concatenation of application logic provided to the originating enterprise site and application logic that is provided to the terminating enterprise site.) Traffic in the public network relating to the interconnection of the two sites of enterprise 1 are tagged as private network traffic relating to enterprise 1. The business trunking application also routes traffic to public phones and this is public network traffic (untagged in the public network). +------------+ | | enterprise | | (enterprise 1) | | | | 1 +-----+--------------------------------+ | | | site 1 | | | business | | +------------+ | +-----+ trunking | | | public | | application| | /--\ |<=========network========>| +--+ | | o /\ o | traffic | | | | | / \----------+--------------------------+ | | | | +----+ | | +------------+ | public | | | phone | | | | private network | | +------------+ |<===========traffic=========>| | | enterprise | | (enterprise 1) | | | 1 +-----+-----------------------------+ | | site 2 | | | +------------+ | | | | +-------------------------------------------------+ Figure 2 ]]> Figure 3 shows the interconnection of sites belonging to a private network on a server providing a hosted enterprise service application (also known as Centrex). The hosted enterprise service application supports phones belonging to the enterprise and is also able to route traffic to and from public network phones using break-in or break-out functionality. Traffic in the public network relating to the interconnection of the site of enterprise 1 and the hosted enterprise service belonging to enterprise 1 are tagged as private network traffic relating to enterprise 1. The hosted enterprise service application also routes traffic to public phones and this is public network traffic (untagged in the public network). Traffic from the enterprise phones would not normally be tagged (such tag is added at the server providing the hosted enterprise services application. (Note that the hosted enterprise service logic may precede or succeed a business trunking application that offers services on behalf of an enterprise site.) +------------+ | | enterprise | | (enterprise 1) | | | | 1 +-----+--------------------------------+ hosted | | | site 1 | | | enterprise | | +------------+ | +-----+ service | | | public | | enterprise | | /--\ |<=========network========>| +--+ 1 | | o /\ o | traffic | | | | | / \----------+--------------------------+ | | | | +----+ | | +------------+ | public | | | phone | | | | private network | | /--\ |<===========traffic=========>| | o /\ o | (enterprise 1) | | / \----------+-----------------------------+ | +----+ | | enterprise | | phone | | +-------------------------------------------------+ Figure 3 ]]>

This section lists the requirements on SIP derived from the considerations in : It is REQUIRED that an indication can be sent in SIP initial requests for a dialog or SIP standalone requests that indicates that the request or associated session is to be treated according to the rules of private network traffic. The indication from R1 can be inserted by a SIP proxy belonging to an administrative domain for onward routing and for the traffic within that administrative domain, that needs to be so distinguished. The indication is not needed where the traffic is assumed to be all public, or where the traffic is assumed to be all private (contained within the closed network, not crossing any public network). The indication from R can be removed by a SIP proxy belonging to an administrative domain for onward routing where the traffic no longer needs to be so distinguished. An example exists where the traffic reaches an NGCN site where the traffic is assumed to be all private network traffic. Another example is on the final hop to the UA. It is REQUIRED that the indication from R allows entities to determine the set of rules that are applicable, these rules may be enterprise specific. It is REQUIRED that the indication from R allows entities receiving it to distinguish private network traffic from different enterprises. The identifier to distinguish private network traffic belonging to one enterprise from that belonging to another enterprise must be globally unique. Business communication arrangements for any particular enterprise can be expected to span multiple NGN operators potentially in multiple countries. The indication from R relates primarily to the SIP signaling. Applying the same concept to media may be possible, but is not necessarily meaningful where media is routed differently from signaling.

The mechanism proposed in this document relies on a new header field called 'P-Private-Network-Indication' that contains a private network identifier expressed as a domain name, for example: A proxy server which handles a message can insert such a P-Private-Network-Indication header field into the message based on authentication of the source of a message, configuration or local policy, and forward it to other proxies in the same administrative domain or proxies in trusted domain to be handled as private network traffic. A proxy that forwards a message to a proxy server or UA that it does not trust MUST remove the P-Private-Network-Indication header field before forwarding the message. The private network identifier expressed as a domain name allows it to be globally unique identifier, associated with the originating enterprise. Domain name is used, as it allows reuse of a company owned internet domain name, without requiring an additional private network identifier registry. When the enterprise needs more than one identifier it can freely add subdomains under its own control. The formal syntax for the P-Private-Network-Indication header is presented in .

Proxies that are responsible for determining certain traffic to be treated as private network traffic or contain a breaking function that converts incoming public network traffic to private network traffic MUST insert a P-Private-Network-Indication header field into incoming or outgoing requests for a dialog or for a standalone transaction. The value MUST be set to the private network identifier corresponding to the enterprise to which the traffic belongs.

Proxies that are responsible for applying different processing behaviors to specific private network traffic MUST support this extension. The P-Private-Network-Indication header field MUST NOT be used by a proxy in case it is received on a request from an entity that it does not trust, in such case it MUST be removed before the request is forwarded.

Proxies that are at the edge of the trust domain or contain a breakout function that converts incoming private network traffic to public network traffic MUST remove the P-Private-Network-Indication header field before forwarding a request that contains such a header field with a value.

This document defines the SIP P-Private-Network-Indication header field. This header field can be added by a proxy to initial requests for a dialog or standalone requests. The presence of the P-Private-Network-Indication header field signifies to proxies that understand this header field that the request is to be treated as private network traffic. The P-Private-Network-Indication header field contains a domain name value, that allows the private network traffic to be associated with an enterprise, to which it belongs and that allows proxies that understand this header field to process the request according to the local policy configured for a specific enterprise. The augmented Backus-Naur Form (BNF) (RFC5234 ) syntax of the P-Private-Network-Indication header field is the following: P-Private-Network-Indication = "P-Private-Network-Indication" HCOLON PNI-value *(SEMI PNI-param) PNI-param = generic-param PNI-value = hostname EQUAL, HCOLON, SEMI, hostname and generic-param are defined in RFC3261 . The following is an example of a P-Private-Network-Indication header field:

The private network indication defined in this document is to be used in an environment where elements are trusted and where attackers are not supposed to have access to the protocol messages between those elements. Traffic protection between network elements is sometimes achieved by using IPsec and sometimes by physically protection of the network. In any case, the environment where the private network indication will be used ensures the integrity and the confidentiality of the contents of this header field. A private network indication received from an untrusted node MUST NOT be used and the information MUST be removed from a request or response before it is forwarded to entities in the trust domain. There is a security risk if a private network indication is allowed to propagate out of the trust domain where it was generated. In that case sensitive information would be revealed by such a breach. To prevent such a breach from happening, proxies MUST NOT insert the information when forwarding requests to a next hop located outside the trust domain. When forwarding the request to a trusted node, proxies MUST NOT insert the header field unless they have sufficient knowledge that the route set includes another proxy in the trust domain that understands the header field, such as the own proxy. There is no automatic mechanism to learn the support for this specification. Proxies MUST remove the information when forwarding requests to untrusted nodes or when the proxy does not have knowledge of any other proxy in the route set that is able to understand the header field.

This document defines a new SIP header field: P-Private-Network-Indication. This header field needs to be registered by the IANA in the SIP Parameters registry under the Header Fields subregistry.

The authors thank Bruno Chatras, John Elwell and Salvatore Loreto for providing comments on an early version of this draft. Further we thank John Elwell for performing the expert review.

&rfc2119; &rfc3261; &rfc3324; &rfc5234; ETSI 3GPP 3GPP &rfc3427; &rfc3455; &rfc3841; &rfc5727; &rfc6050; The RFC Editor will remove these Appendixes.

It would be technical possible, but extremely complex to perform this function without an explicit indication. For example, a logical distinction of proxies to handle private network traffic relating to enterprise 1, enterprise 2 and the public network traffic could be made by assigning different SIP URIs to these logical entities. This is not regarded as a viable solution. Several solutions have been raised and whether or not they are suitable and fulfill the requirements need to be discussed: Attribute on existing header? Token on some existing header? Resource-Priority header? P-Asserted-Service header? Request-Disposition header? P-Access-Network-Information header? URI parameter? New P-header? New header?

Some of the distinctive functions are already provided for in this header field. A potential mechanism would be to define a namespace for private network traffic. It would however be impossible to define a namespace for each enterprise, and therefore some additional parameter would need to be defined to carry the unique identifier of the particular enterprise to which the private network traffic relates. Successful usage may also require a tightening of the procedures for use of the Resource-Priority header field (much at the moment is left to the particular application of this header field). Private network traffic may, but is not necessarily handled with a different priority then public network traffic. Use of the Resource-Priority header field however seems to imply that the main focus of the indication is on prioritizing private network traffic. This may render use of the Resource-Priority header field as less appropriate for our particular purpose.

The services envisaged by the P-Asserted-Service header field (RFC6050 ) are those applied to the end user. The end user in these cases is the end user of the enterprise or NGCN, not the enterprise itself. Therefore this header field is not considered suitable for this problem.

The Request-Disposition header field (RFC3841 ) specifies caller preferences for how a server should process a request. The caller in these cases is the end user of the enterprise or NGCN, not the enterprise itself. Therefore this header field is not considered suitable for this problem. Further RFC3841 explicitly states that the set of request disposition directives is not extensible.

The P-Access-Network-Info header field (RFC3455 ) contains information about the access network that a UA uses to get IP connectivity. However the access that one uses does not define the private network that a call that one sets up is to be part of. Particular examples that illustrate this: A Hosted Enterprise Services user (i.e. Centrex) uses the access of the operator while still being able to setup calls that will turn out to be private network traffic. A corporate network UE that attaches to an operator network, but receives services from its home corporate network.

A marking on the entities within the Via header field that are treating this as private network traffic. Potential marking on the route header field of entities that are expected to treat it as private network traffic.

If none of the existing header fields is appropriate a logical step is to define a new header field for the private network indication.

A full SIP header field is appropriate when the usage of this information element is more general then closed networks like ETSI TISPAN NGN or 3GPP IMS.

In case no general usage is foreseen other then usage in closed networks like those specified by ETSI TISPAN NGN or 3GPP IMS a P-header field seems the appropriate choice.

2008-02-18, Initial version

2008-02-23, Added a solution based on a new header field. Added Overview, Behavior and Header Definition sections. Updated the trust domain definition. Improved some of the existing text based on comments from John Elwell.

2008-07-11, Changed to a P-header field. Changed title. Added Terminology application and Applicability sections. Moved the Potential solutions section to appendix Alternative solutions discussed.

2009-02-19, Updated boilerplate.

2009-07-06, Updates as result of Expert review. Moved to DISPATCH.

2010-06-15, Resubmission. Authors address changed. No content changes. Moved reference to RFC3427 to informative section as it is deprecated by RFC5727 .

2013-07-12, Updates according to the comments after Expert review. Some changes for the consistency with other RFCs that specify P-headers. Some editorial changes.