From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc7316.txt | 843 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 843 insertions(+) create mode 100644 doc/rfc/rfc7316.txt (limited to 'doc/rfc/rfc7316.txt') diff --git a/doc/rfc/rfc7316.txt b/doc/rfc/rfc7316.txt new file mode 100644 index 0000000..6d2fbe9 --- /dev/null +++ b/doc/rfc/rfc7316.txt @@ -0,0 +1,843 @@ + + + + + + +Internet Engineering Task Force (IETF) J. van Elburg +Request for Comments: 7316 Detecon International Gmbh +Category: Informational K. Drage +ISSN: 2070-1721 Alcatel-Lucent + M. Ohsugi + S. Schubert + K. Arai + NTT + July 2014 + + + The Session Initiation Protocol (SIP) P-Private-Network-Indication + Private Header (P-Header) + +Abstract + + This document specifies the SIP P-Private-Network-Indication P-header + used by the 3GPP. The P-Private-Network-Indication indicates that + the message is part of the message traffic of a private network and + identifies that private network. A private network indication allows + nodes to treat private network traffic according to a different set + of rules than the set applicable to public network traffic. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Not all documents + approved by the IESG are a candidate for any level of Internet + Standard; see Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7316. + + + + + + + + + + + + + +van Elburg, et al. Informational [Page 1] + +RFC 7316 Private Network Indication July 2014 + + +Copyright Notice + + Copyright (c) 2014 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction ....................................................3 + 1.1. Overview ...................................................3 + 1.2. Applicability ..............................................3 + 1.3. Background .................................................3 + 1.4. Business Communication .....................................3 + 1.5. Indication Types ...........................................4 + 2. Conventions .....................................................6 + 3. Definitions .....................................................6 + 3.1. Traffic ....................................................6 + 3.2. Public Network Traffic .....................................6 + 3.3. Private Network Traffic ....................................6 + 3.4. Break-In ...................................................6 + 3.5. Break-Out ..................................................6 + 3.6. Trust Domain ...............................................6 + 4. Application of Terminology ......................................7 + 5. Overview of Solution ...........................................10 + 6. Proxy Behavior .................................................11 + 6.1. P-Private-Network-Indication Generation ...................11 + 6.2. P-Private-Network-Indication Consumption ..................11 + 6.3. P-Private-Network-Indication Removal ......................11 + 6.4. P-Private-Network-Indication Verification .................11 + 7. P-Private-Network-Indication Header Field Definition ...........12 + 8. Security Considerations ........................................12 + 9. IANA Considerations ............................................13 + 10. Acknowledgments ...............................................13 + 11. References ....................................................13 + 11.1. Normative References .....................................13 + 11.2. Informative References ...................................14 + + + + + + +van Elburg, et al. Informational [Page 2] + +RFC 7316 Private Network Indication July 2014 + + +1. Introduction + +1.1. Overview + + ETSI TISPAN (Telecommunications and Internet converged Services and + Protocols for Advanced Networking) defined Next Generation Networks + (NGNs), which use the 3GPP IP Multimedia Subsystem (IMS), 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 [3GPP.23.228] and 3GPP TS 24.229 [3GPP.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 [RFC5727]. + +1.2. Applicability + + The P-Private-Network-Indication header field is intended to be used + in controlled closed networks like 3GPP IMS and ETSI TISPAN NGNs. + The P-Private-Network-Indication header is not intended for the + general Internet environment and is probably not suitable for such an + environment. + + For example, there are no mechanisms defined to prevent spoofing of + this header. So, if a network were to accept calls carrying this + header from the general Internet, an attacker would be able to inject + information into private networks. + +1.3. Background + + The P-Private-Network-Indication header field has been referred to in + 3GPP IMS specifications and has already been used in some networks as + an indicator for a specific capability. The header field has already + been implemented in some vendors' equipment in some countries. RFC + 5727 [RFC5727] 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. + +1.4. Business Communication + + ETSI TISPAN has identified a framework, which was adopted by 3GPP as + [3GPP.22.519], for the support of business communication capabilities + by the NGN. In addition to 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. + + + + + +van Elburg, et al. Informational [Page 3] + +RFC 7316 Private Network Indication July 2014 + + + 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, 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 + + 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 a public NGN on behalf of a + private network can be either: + + 1) 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. + + 2) 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. + +1.5. Indication Types + + A private network indication as proposed by this document indicates + to the receiving network element (supporting this specification) that + this request is related to private network traffic as opposed to + 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; therefore, it is an indication of + service on behalf of an enterprise, not an indication of service to a + private network's end user. + + + + +van Elburg, et al. Informational [Page 4] + +RFC 7316 Private Network Indication July 2014 + + + In order to allow NGN IMS nodes to perform different processing, ETSI + TISPAN formulated the following requirements for NGN. The NGN shall: + + a) distinguish public network traffic from private network traffic; + and + + b) 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 include: + + 1) Different regulations apply to two types of traffic, for example, + emergency calls may be handled differently depending on the type + of traffic. + + 2) Different charging regimes may apply. + + 3) Call recording for business reasons (e.g., quality control, + training, non-repudiation) might apply only to a specific type of + traffic. + + 4) 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: + + a) Caller and callee addresses cannot always be used to determine + whether a certain call is to be treated as private or public + network traffic. + + b) Nodes spanning multiple networks often need to have different + behavior depending upon the type of traffic. When this is done + using implicit schemes, enterprise-specific logic must be + distributed across multiple nodes in multiple operators' + networks. That is clearly not a manageable architecture and + solution. + + c) 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. + + Based on the background provided, this document formulates + requirements for SIP to support an explicit private network + indication and defines a P-header, P-Private-Network-Indication, to + support those requirements. + + + + +van Elburg, et al. Informational [Page 5] + +RFC 7316 Private Network Indication July 2014 + + +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]. + +3. Definitions + +3.1. Traffic + + 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. + +3.2. Public Network Traffic + + Traffic sent to or received from a public telecommunication network + for processing according to the rules for ordinary subscribers of a + public telecommunication network. + +3.3. Private Network Traffic + + 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. + +3.4. Break-In + + Act of converting public network traffic to private network traffic. + The header defined in this specification will be added to indicate + the traffic is a private network traffic after conversion. + +3.5. Break-Out + + Act of converting private network traffic to public network traffic. + The header defined in this specification will be removed to indicate + the traffic is a public network traffic after conversion. + +3.6. Trust Domain + + The term "trust domain" in this document is taken from P-Asserted- + Identity [RFC3324]. A trust domain applies to the private network + indication. The rules for specifying such a trust domain are + specified in P-Asserted-Identity [RFC3324] and require the + specification of a Spec(T) as covered in Section 2.4 of [RFC3324]. + + + + + +van Elburg, et al. Informational [Page 6] + +RFC 7316 Private Network Indication July 2014 + + + The same information is required to specify a Spec(T) for purposes of + P-Private-Network-Indication as for P-Asserted-Identity [RFC3324]. + However, if a network is using P-Private-Network-Indication as well + as other header fields subject to Spec(T) (such as P-Asserted- + Identity), the Spec(T) for each header field will probably be + different from the others. + +4. Application of Terminology + + 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 in the public network + between two different private networks is tagged as private network + traffic using a pre-arranged domain name agreed by the two involved + enterprises. This is illustrated by the interconnection of the site + from enterprise 3 and the site from enterprise 4. + + + + + + + + + + + + + + + + + + + + + + + + + + +van Elburg, et al. Informational [Page 7] + +RFC 7316 Private Network Indication July 2014 + + + +------------------------------+ + | private network | + +------------+ |<===========traffic==========>| +------------+ + | 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 | | (pre-arranged domain name) | | enterprise | + | 3 +-----+------------------------------+-----+ 4 ! + | site 1 | | | | site 1 | + +------------+ | | +------------+ + | | + +------------------------------+ + + Figure 1: Two Private Networks + + 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 and routing of 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 is 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). + + + + + +van Elburg, et al. Informational [Page 8] + +RFC 7316 Private Network Indication July 2014 + + + +-------------------------------------------------+ + | private network | + +------------+ |<===========traffic============>+------------+ | + | 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: Private Network and Business Trunking + + 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 is 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, but it can be tagged + as private network traffic. (Note that the hosted enterprise service + logic may precede or succeed a business trunking application that + offers services on behalf of an enterprise site.) + + + + + + + + + + + +van Elburg, et al. Informational [Page 9] + +RFC 7316 Private Network Indication July 2014 + + + +-------------------------------------------------+ + | private network | + +------------+ |<===========traffic============>+------------+ | + | 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: Hosted Service and Private Network + +5. Overview of Solution + + 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: + + P-Private-Network-Indication: example.com + + A proxy server that handles a message MAY 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. A proxy server MAY forward the message to other proxies in + the same administrative domain or proxies in a trusted domain to be + handled as private network traffic. A proxy that forwards a message + to a proxy server or user agent (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 a globally unique identifier, associated with the originating + and/or terminating enterprise(s). Domain name is used, as it allows + reuse of a company-owned Internet domain name without requiring an + + + + +van Elburg, et al. Informational [Page 10] + +RFC 7316 Private Network Indication July 2014 + + + 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 Section 7. + +6. Proxy Behavior + +6.1. P-Private-Network-Indication Generation + + Proxies that are responsible for determining certain traffic to be + treated as private network traffic or contain a break-in 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(s) to which the traffic belongs. + +6.2. P-Private-Network-Indication Consumption + + 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 in a request from an entity + that it does not trust; in such a case, it MUST be removed before the + request is forwarded. + +6.3. P-Private-Network-Indication Removal + + Proxies that are at the edge of the trust domain or contain a break- + out 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. + +6.4. P-Private-Network-Indication Verification + + When proxies supporting this specification receive a P-Private- + Network-Indication header field in a SIP request from a trusted node, + proxies MUST check whether the received domain name in the request is + the same as the domain name associated with the provisioned domain + name. If the received domain name does not match, proxies MUST + remove the P-Private-Network-Indication header field. + + + + + + + + +van Elburg, et al. Informational [Page 11] + +RFC 7316 Private Network Indication July 2014 + + +7. P-Private-Network-Indication Header Field Definition + + 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 + the 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 allows proxies + that understand this header field to process the request according to + the local policy configured for a specific enterprise(s). + + The Augmented Backus-Naur Form (ABNF) [RFC5234] syntax of the + P-Private-Network-Indication header field is described below: + + 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 RFC + 3261 [RFC3261]. + + The following is an example of a P-Private-Network-Indication header + field: + + P-Private-Network-Indication: example.com + +8. Security Considerations + + The private network indication defined in this document MUST only be + used in the traffic transported between network elements that are + mutually trusted. Traffic protection between network elements can be + achieved by using security protocols such as IP Encapsulating + Security Payload (ESP) [RFC4303] or SIP / Transport Layer Security + (SIP/TLS) or sometimes by physical protection of the network. In any + case, the environment where the private network indication will be + used needs to ensure 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. + Additionally, local policies may be in place that ensure that all + requests entering the trust domain for private network indication + from untrusted nodes with a private network indication will be + discarded. + + + +van Elburg, et al. Informational [Page 12] + +RFC 7316 Private Network Indication July 2014 + + + There is a security risk if a private network indication is allowed + to propagate out of the trust domain where it was generated. The + indication may reveal information about the identity of the caller, + i.e., the organization that he belongs to. That is sensitive + information. It also reveals to the outside world that there is a + set of rules that this call is subject to that is different then the + rules that apply to public traffic. That is sensitive information + too. 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 this header field. However, how to + learn such knowledge is out of the scope of this document. 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 this header field. + +9. IANA Considerations + + This document defines a new SIP header field: P-Private-Network- + Indication. This header field has been registered by the IANA in the + "SIP Parameters" registry under the "Header Fields" subregistry. + + RFC Number: [RFC7316] + + Header Field Name: P-Private-Network-Indication + + Compact Form: none + +10. Acknowledgments + + The authors would like to thank Richard Barnes, Mary Barnes, Atle + Monrad, Bruno Chatras, John Elwell, and Salvatore Loreto for + providing comments on an early version of this document. Further, we + thank John Elwell for performing the expert review. + +11. References + +11.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, + A., Peterson, J., Sparks, R., Handley, M., and E. + Schooler, "SIP: Session Initiation Protocol", RFC 3261, + June 2002. + + + +van Elburg, et al. Informational [Page 13] + +RFC 7316 Private Network Indication July 2014 + + + [RFC3324] Watson, M., "Short Term Requirements for Network Asserted + Identity", RFC 3324, November 2002. + + [RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for + Syntax Specifications: ABNF", STD 68, RFC 5234, January + 2008. + +11.2. Informative References + + [3GPP.22.519] + 3GPP, "Business Communication Requirements", TS 22.519. + + [3GPP.23.228] + 3GPP, "IP Multimedia Subsystem (IMS); Stage 2", 3GPP TS + 23.228 V8, July 2007. + + [3GPP.24.229] 3GPP, "Internet Protocol (IP) multimedia call control + protocol based on Session Initiation Protocol (SIP) and + Session Description Protocol (SDP); Stage 3", 3GPP TS + 24.229 V8, July 2007. + + [RFC5727] Peterson, J., Jennings, C., and R. Sparks, "Change Process + for the Session Initiation Protocol (SIP) and the Real- + time Applications and Infrastructure Area", BCP 67, RFC + 5727, March 2010. + + [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC + 4303, December 2005. + + + + + + + + + + + + + + + + + + + + + + + +van Elburg, et al. Informational [Page 14] + +RFC 7316 Private Network Indication July 2014 + + +Authors' Addresses + + Hans Erik van Elburg + Detecon International Gmbh + Oberkasselerstrasse 2 + Bonn 53227 + Germany + + EMail: ietf.hanserik@gmail.com + + + Keith Drage + Alcatel-Lucent + The Quadrant, Stonehill Green, Westlea + Swindon SN5 7DJ + UK + + EMail: drage@alcatel-lucent.com + + + Mayumi Ohsugi + NTT Corporation + + Phone: +81 422 36 7502 + EMail: mayumi.ohsugi@ntt-at.co.jp + + + Shida Schubert + NTT Corporation + + Phone: +1 415 323 9942 + EMail: shida@ntt-at.com + + + Kenjiro Arai + NTT Corporation + 9-11, Midori-cho 3-Chome + Musashino-shi, Tokyo 180-8585 + Japan + + Phone: +81 422 59 3518 + EMail: arai.kenjiro@lab.ntt.co.jp + URI: http://www.ntt.co.jp + + + + + + + + +van Elburg, et al. Informational [Page 15] + -- cgit v1.2.3