Requirements for explicit private network indication
draft-vanelburg-sipping-private-network-indication-00.txt

Status of this Memo

By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on August 21, 2008.

Abstract

This document describes why a private network indication is needed. A private network indication allows other nodes in a network to treat private network traffic to a different set of rules then public network traffic. The indication also distinguishes one private network from another private network.

Table of Contents

1.  Introduction
    1.1.  General
    1.2.  Business communication
    1.3.  Indication types
2.  Conventions
3.  Definitions
    3.1.  Public Network Traffic
    3.2.  Private Network Traffic
    3.3.  Trust Domain
4.  Requirements
5.  Potential Solutions
    5.1.  General
    5.2.  Attribute on existing header
    5.3.  Token value on existing header
    5.4.  Resource-Priority header
    5.5.  P-Asserted-Service header
    5.6.  Request-Disposition header
    5.7.  P-Access-Network-Information
    5.8.  New P-header
    5.9.  URI parameter
    5.10.  New header?
6.  Security Considerations
7.  IANA Considerations
8.  Acknowledgments
9.  References
    9.1.  Normative References
    9.2.  Informative References
Appendix A.  Revision Information
    A.1.  version 00
§  Authors' Addresses
§  Intellectual Property and Copyright Statements

1.  Introduction

1.1.  General

ETSI TISPAN defines Next Generation Networks (NGN) which uses the 3rd-Generation Partnership Project (3GPP) IMS (IP Multimedia Subsystem) which in turn uses SIP (RFC3261 [RFC3261] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.)) as its main signalling protocol. (For more information on the IMS, a detailed description can be found in 3GPP TS 23.228 [3GPP.23.228] (3GPP, “IP Multimedia Subsystem (IMS); Stage 2,” .) and 3GPP TS 24.229 [3GPP.24.229] (3GPP, “Internet Protocol (IP) multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3,” .).)

1.2.  Business communication

In the context of its work on business communiction support in public next generation networks (NGN), ETSI TISPAN has identified a framework [ETSI.181.019] (ETSI, “Telecommunication and Internet converged Services and Protocols for Advanced Networking (TISPAN); Business Communication Requirements,” July 2007.) 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 the enterprise network within the NGN itself.

These hosting arrangements are:

a)

virtual leased line, where NGCN sites are interconnected through the NGN;

b)

business trunking application, where the NGN hosts transit capabilities between NGCN's, break-in capabilities from NGN to NGCN and break-out capabilities from NGCN to NGN; and

c)

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 an NGN on behalf of a private network can be either:

• public network traffic: traffic sent to the NGN for processing according to normal rules of the NGN. 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 within a single enterprise, but private network traffic can also exist between two different enterprises if not precluded for regulatory reasons.

1.3.  Indication types

A private network indication as proposed by this document should not be confused with an indication to the local user that the remote user is in the same private network. This has traditionally resulted in PBXs providing distinctive ringing on incoming calls, but has also been used as input to services provided to the end user, e.g. different forwarding conditions and so on. Traditionally, this has only been applied where the call does not enter the public network at all, but we regard that limitation as a technical limitation rather than as one precluded by the desires of the service (i.e. traditionally there has been no special indication of this and it has relied on calling line identity, and for calls coming in over the public network, one would both need reliable transfer of calling line identity, and the authentication that it really was that calling line identity, as the end user would not like a false indication that this is a private network internal call when it is in fact someone wishing to use that indication for fraudulent purposes. There may be a need for such a explicit indication, but that is not covered by this document.

Rather private network indication as proposed by this document is an indication to each and every network element traversed that this is private network traffic as opposed to public network traffic. This indication is not for the end user on the private network. It is an indication that special service arrangements apply for an enterprise, and therefore it is an indication of service on behalf of an enterprise, not an indication of service to an end private network (NGCN) user.

In order to allow NGN IMS nodes to perform different processing ETSI TISPAN formulated the following requirements on NGN:

1. The NGN shall distinguish public network traffic from private network traffic.
2. The NGN shall distinguish private network traffic belonging to one enterprise from that belonging to another enterprise.

To sumarize a few example reasons for a public telecommunication network to make the distinction between the two types of traffic:

• Different regulations apply to the two types of traffic, most notably lawfull intercept regquirements. Another example is 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 signalling and/or media transparency may apply to the different types of traffic.

The indication is not regarded as appropriate as an indication from the end UA attached to an NGCN or hosted enterprise service equipment in the NGN. In this case any mixture of traffic relates to two or more distinct users, one belonging to the enterprise network and receiving service from that enterprise network, and one belonging to the NGN and receiving service from that network. Any distinction between the traffic to such a UA should be based on the authentication arrangements performed with each of the service networks.

There are several reasons why there is a need for an explicit indication in the signalling:

1. As calling and target addresses can not in all cases be used to determine whether a certain call is to be treated as private or public network traffic.
2. Separate nodes in the network need to be able to act on the type of traffic being handled, when implicit schemes would be used it would require distribution of such enterprise specific logic over multiple nodes of multiple operators. That is clearly not a manageable architecture.
3. There may be cases where treating the call as a public network call allthough both participants are from the same enterprise is advantegous to the enterprise.

Given the above background this document will formulate requirements on SIP for support of an explicit private network indicator.

2.  Conventions

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 [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

3.  Definitions

3.1.  Public Network Traffic

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

3.2.  Private Network Traffic

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

3.3.  Trust Domain

The term Trust Domain in this document is taken from RFC3324 [RFC3324] (Watson, M., “Short Term Requirements for Network Asserted Identity,” November 2002.). In the context of this document it is assumed that a trust domain for the purpose of private network indication contains the same set of SIP nodes as the trust domain for the purpose of network asserted identity.

4.  Requirements

This section lists the requirements on SIP derived from consideration in Section 1 (Introduction):

R1:

It is REQUIRED that an indication can be send in SIP initial requests for a dialog or SIP standalone requests and or SIP responses to those that indicate that the request or associated session is to be treated according to the rules of private network traffic.

R2:

The indication from R1 can be inserted by a SIP proxy belonging to an administrative entity where for onward routeing, the traffic within that administrative entity 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.

R3:

The indication from R1 can be removed by a SIP proxy belonging to an administrative entity where for onward routeing, the traffic no longer needs to be so distinguished. An example exists where the traffic reaches an NGCN site where the traffic is now assumed to all private network traffic.

R4:

It is REQUIRED that the indication from R1 allows entities to determine the set of rules that are applicable, these rules may be enterprise specific.

R5:

It is REQUIRED that the indication from R1 allows entities receiving it to distinguish private network traffic from different enterprises.

R6:

This distinction R5 of traffic belonging to one private network can be inserted by SIP proxies where for administrative reasons it becomes important. This insertion may be by a different entity to that which inserted the indicator between private network traffic. For example, an NGCN site inserts the indicator to distinguish public network traffic from private network traffic, but all private network traffic belongs to this enterprise so an explicit indication to distinguish the traffic from that belonging to other enterprises is not needed. However the request is then routed to the NGN, which is handling private network traffic relating to multiple enterprises, so an additional identifier needs to be added at this time.

R7:

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.

R8:

The indication from R1 relates primarily to the SIP signaling. There may be an association of the concent with media, but only where the limitations of such an association can be applied due to the potential different routeing of media.

5.  Potential Solutions

5.1.  General

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?

5.2.  Attribute on existing header

5.3.  Token value on existing header

5.4.  Resource-Priority header

Some of the distinctive functions are already provided for in this header. 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 (much at the moment is left to the particular application of this header).

5.5.  P-Asserted-Service header

The services envisaged by the P-Asserted-Service header field (draft-drage-sipping-service-identification) 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. There fore this header is not considered suitable for this problem.

5.6.  Request-Disposition header

The Request-Disposition header field (RFC3841 [RFC3841] (Rosenberg, J., Schulzrinne, H., and P. Kyzivat, “Caller Preferences for the Session Initiation Protocol (SIP),” August 2004.)) 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. There fore this header is not considered suitable for this problem. Further RFC3841 explicitly states that the set of request disposition directives is not extensible.

5.7.  P-Access-Network-Information

The P-Access-Network-Info header field (RFC3455 [RFC3455] (Garcia-Martin, M., Henrikson, E., and D. Mills, “Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3rd-Generation Partnership Project (3GPP),” January 2003.)) 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.

5.8.  New P-header

Possible usage is more general than that envisaged for a P-header.

5.9.  URI parameter

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

5.10.  New header?

If none of the existing headers is appropriate a new header might need to be defined.

6.  Security Considerations

The private network indication being 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 protecting 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 unless they have sufficient knowledge that the route set includes another proxy in the trust domain that understands the header, 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.

7.  IANA Considerations

This document defines ... This ... needs to be registered by the IANA in the ... registry under the ... subregistry.

8.  Acknowledgments

The authors thank Bruno Chatras, John Ellwell and Salvatore Loreto for providing comments on an early version of this draft.

9.  References

9.1. Normative References

9.2. Informative References

Appendix A.  Revision Information

A.1.  version 00

1. 2008-02-18, Initial version

Authors' Addresses

Full Copyright Statement

Copyright © The IETF Trust (2008).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.