RFC 7315
Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3GPP
5. Formal Syntax
All of the mechanisms specified in this document are described in both prose and an augmented Backus-Naur Form (BNF) defined in RFC 5234 [RFC5234]. Further, several BNF definitions are inherited from SIP and are not repeated here. Implementors need to be familiar with the notation and contents of SIP [RFC3261] and [RFC5234] to understand this document.
5.1. P-Associated-URI Header Syntax
The syntax of the P-Associated-URI header field is described as follows: P-Associated-URI = "P-Associated-URI" HCOLON [p-aso-uri-spec] *(COMMA p-aso-uri-spec) p-aso-uri-spec = name-addr *(SEMI ai-param) ai-param = generic-param5.2. P-Called-Party-ID Header Syntax
The syntax of the P-Called-Party-ID header field is described as follows: P-Called-Party-ID = "P-Called-Party-ID" HCOLON called-pty-id-spec called-pty-id-spec = name-addr *(SEMI cpid-param) cpid-param = generic-param5.3. P-Visited-Network-ID Header Syntax
The syntax of the P-Visited-Network-ID header field is described as follows: P-Visited-Network-ID = "P-Visited-Network-ID" HCOLON vnetwork-spec *(COMMA vnetwork-spec) vnetwork-spec = (token / quoted-string) *(SEMI vnetwork-param) vnetwork-param = generic-param5.4. P-Access-Network-Info Header Syntax
The syntax of the P-Access-Network-Info header field is described as follows: P-Access-Network-Info = "P-Access-Network-Info" HCOLON access-net-spec *(COMMA access-net-spec) access-net-spec = (access-type / access-class) *(SEMI access-info) access-type = "IEEE-802.11" / "IEEE-802.11a" / "IEEE-802.11b" / "IEEE-802.11g" / "IEEE-802.11n" / "IEEE-802.3" / "IEEE-802.3a" / "IEEE-802.3ab" / "IEEE-802.3ae" / "IEEE-802.3ak" / "IEEE-802.3ah" /
"IEEE-802.3aq" / "IEEE-802.3an" /
"IEEE-802.3e" / "IEEE-802.3i" /
"IEEE-802.3j" / "IEEE-802.3u" /
"IEEE-802.3y" / "IEEE-802.3z" /
"3GPP-GERAN" /
"3GPP-UTRAN-FDD" / "3GPP-UTRAN-TDD" /
"3GPP-E-UTRAN-FDD" / "3GPP-E-UTRAN-TDD" /
"3GPP2-1X-Femto" / "3GPP2-UMB" /
"3GPP2-1X-HRPD" / "3GPP2-1X" /
"ADSL" / "ADSL2" / "ADSL2+" / "RADSL" /
"SDSL" / "HDSL" / "HDSL2" / "G.SHDSL" /
"VDSL" / "IDSL" /
"DOCSIS" / "GSTN" / "GPON" / " XGPON1" /
"DVB-RCS2" / token
access-class = "3GPP-GERAN" / "3GPP-UTRAN" /
"3GPP-E-UTRAN" / "3GPP-WLAN" /
"3GPP-GAN" / "3GPP-HSPA" /
"3GPP2" / token
access-info = cgi-3gpp / utran-cell-id-3gpp /
dsl-location / i-wlan-node-id /
ci-3gpp2 / eth-location /
ci-3gpp2-femto / fiber-location /
np / gstn-location /local-time-zone /
dvb-rcs2-node-id / extension-access-info
np = "network-provided"
extension-access-info = gen-value
cgi-3gpp = "cgi-3gpp" EQUAL
(token / quoted-string)
utran-cell-id-3gpp = "utran-cell-id-3gpp" EQUAL
(token / quoted-string)
i-wlan-node-id = "i-wlan-node-id" EQUAL
(token / quoted-string)
dsl-location = "dsl-location" EQUAL
(token / quoted-string)
eth-location = "eth-location" EQUAL
(token / quoted-string)
fiber-location = "fiber-location" EQUAL
(token / quoted-string)
ci-3gpp2 = "ci-3gpp2" EQUAL
(token / quoted-string)
ci-3gpp2-femto = "ci-3gpp2-femto" EQUAL
(token / quoted-string)
gstn-location = "gstn-location" EQUAL
(token / quoted-string)
dvb-rcs2-node-id = "dvb-rcs2-node-id" EQUAL
quoted-string
local-time-zone = "local-time-zone" EQUAL
quoted-string
operator-specific-GI = "operator-specific-GI" EQUAL
(token / quoted-string)
utran-sai-3gpp = "utran-sai-3gpp" EQUAL
(token / quoted-string)
The access-info MAY contain additional information relating to the
access network. The values for "cgi-3gpp", "utran-cell-id-3gpp",
"i-wlan-node-id", "dsl-location", "ci-3gpp2", "ci-3gpp2-femto", and
"gstn-location" are defined in 3GPP TS 24.229 [TS24.229].
5.5. P-Charging-Function-Addresses Header Syntax
The syntax for the P-Charging-Function-Addresses header field is
described as follows:
P-Charging-Addresses = "P-Charging-Function-Addresses" HCOLON
charge-addr-params *(COMMA charge-addr-params)
charge-addr-params = charge-addr-param *(SEMI charge-addr-param)
charge-addr-param = ccf / ecf / ccf-2 /ecf-2 / generic-param
ccf = "ccf" EQUAL gen-value
ecf = "ecf" EQUAL gen-value
ccf-2 = "ccf-2" EQUAL gen-value
ecf-2 = "ecf-2" EQUAL gen-value
The P-Charging-Function-Addresses header field contains one or two
addresses of the ECF (ecf and ecf-2) or CCF (ccf and ccf-2). The
first address of the sequence is ccf or ecf. If the first address of
the sequence is not available, then the next address (ccf-2 or ecf-2)
MUST be used if available.
5.6. P-Charging-Vector Header Syntax
The syntax for the P-Charging-Vector header field is described as follows: P-Charging-Vector = "P-Charging-Vector" HCOLON icid-value *(SEMI charge-params) charge-params = icid-gen-addr / orig-ioi / term-ioi / transit-ioi / related-icid / related-icid-gen-addr / generic-param icid-value = "icid-value" EQUAL gen-value icid-gen-addr = "icid-generated-at" EQUAL host orig-ioi = "orig-ioi" EQUAL gen-value term-ioi = "term-ioi" EQUAL gen-value transit-ioi = "transit-ioi" EQUAL transit-ioi-list transit-ioi-list = DQUOTE transit-ioi-param *(COMMA transit-ioi-param) DQUOTE transit-ioi-param = transit-ioi-indexed-value / transit-ioi-void-value transit-ioi-indexed-value = transit-ioi-name "." transit-ioi-index transit-ioi-name = ALPHA *(ALPHA / DIGIT) transit-ioi-index = 1*DIGIT transit-ioi-void-value = "void" related-icid = "related-icid" EQUAL gen-value related-icid-gen-addr = "related-icid-generated-at" EQUAL host The P-Charging-Vector header field contains icid-value as a mandatory parameter. The icid-value represents the IMS charging ID, and contains an identifier used for correlating charging records and events. The first proxy that receives the request generates this value. The icid-gen-addr parameter contains the hostname or IP address of the proxy that generated the icid-value. The orig-ioi and term-ioi parameters contain originating and terminating interoperator identifiers. They are used to correlate charging records between different operators. The originating IOI represents the network responsible for the charging records in the originating part of the session or standalone request. Similarly, the terminating IOI represents the network responsible for the charging records in the terminating part of the session or standalone request.
The transit-ioi parameter contains values with each of them, respectively, representing a transit interoperator identifier. It is used to correlate charging records between different networks. The transit-ioi represents the network responsible for the records in the transit part of the session or standalone request. The related-icid parameter contains the icid-value of a related charging record when more than one call leg is associated with one session. This optional parameter is used for correlation of charging information between two or more call legs related to the same remote- end dialog. The related-icid-gen-addr parameter contains the hostname or IP address of the proxy that generated the related-icid. Applications using the P-Charging-Vector header field within their own applicability are allowed to define generic-param extensions without further reference to the IETF specification process.5.7. New Headers
The P-Associated-URI header field can appear in SIP REGISTER method and 2xx resonses. The P-Called-Party-ID header field can appear in SIP INVITE, OPTIONS, PUBLISH, SUBSCRIBE, and MESSAGE methods and all responses. The P-Visited-Network-ID header field can appear in all SIP methods except ACK, BYE, and CANCEL and all responses. The P-Access-Network-Info header field can appear in all SIP methods except ACK and CANCEL. The P-Charging-Vector header field can appear in all SIP methods except CANCEL. The P-Charging-Function-Addresses header field can appear in all SIP methods except ACK and CANCEL.6. Security Considerations
6.1. P-Associated-URI Header Field
The information returned in the P-Associated-URI header field is not viewed as particularly sensitive. Rather, it is simply informational in nature, providing openness to the UAC with regard to the automatic association performed by the registrar. If end-to-end protection is not used at the SIP layer, it is possible for proxies between the registrar and the UA to modify the contents of the header value. The lack of encryption, either end-to-end or hop-by-hop, may lead to leak some privacy regarding the list of authorized identities. For instance, a user who registers an address-of-record of sip:user1@example.com may get another SIP URI associated as sip:first.last@example.com returned in the P-Associated-URI header field value.
An eavesdropper could possibly collect the list of identities a user is registered. This can have privacy implications. To mitigate this problem, this extension SHOULD only be used in a secured environment, where encryption of SIP messages is provided either end-to-end or hop-by-hop and where a trust relationship equivalent with that defined in RFC 3325 [RFC3325] between entities exists. That is, the privacy of the user relies on the other entities in the session not disclosing information that they have learned about the user. While the P-Associated-URI header field value allows the implicit registration of a bundle of URIs with one REGISTER Message, the impact of security using the P-Associated-URI header field is no higher than using separate REGISTER messages for each of the URIs.6.2. P-Called-Party-ID Header Field
Due to the nature of the P-Called-Party-ID header field, this header does not introduce any significant security concern. It is possible for an attacker to modify the contents of the header. However, this modification will not cause any harm to the session establishment. An eavesdropper could possibly collect the list of identities a user has registered. This can have privacy implications. To mitigate this problem, this extension SHOULD only be used in a secured environment, where encryption of SIP messages is provided either end- to-end or hop-by-hop. Normally, within a 3GPP environment, the P-Called-Party-ID is not sent towards end users but may be exchanged between carriers where other security mechanisms than SIP encryption are used.6.3. P-Visited-Network-ID Header Field
The P-Visited-Network-ID header field assumes that there is trust relationship between a home network and one or more transited visited networks. It is possible for other proxies between the proxy in the visited network that inserts the header, and the registrar or the home proxy, to modify the value of P-Visited-Network-ID header field. Therefore, intermediaries participating in this mechanism MUST apply a hop-by-hop integrity-protection mechanism such as IPsec or other available mechanisms in order to prevent such attacks.
6.4. P-Access-Network-Info Header Field
A Trust Domain is formally defined in RFC 3324 [RFC3324]. For the purposes of this document, we refer to the 3GPP trust domain as the collection of SIP proxies and application servers that are operated by a 3GPP network operator and are compliant with the requirements expressed in 3GPP TS 24.229 [TS24.229]. This extension assumes that the access network is trusted by the UA (because the UA's home network has a trust relationship with the access network), as described earlier in this document. This extension assumes that the information added to the header by the UAC should be sent only to trusted entities and MUST NOT be used outside of the trusted administrative network domain. The SIP proxy that provides services to the user, utilizes the information contained in this header to provide additional services and UAs are expected to provide correct information. However, there are no security problems resulting from a UA inserting incorrect information. Networks providing services based on the information carried in the P-Access-Network-Info header field will therefore need to trust the UA sending the information. A rogue UA sending false access network information will do no more harm than to restrict the user from using certain services. The mechanism provided in this document is designed primarily for private systems like 3GPP. Most security requirements are met by way of private standardized solutions. For instance, 3GPP will use the P-Access-Network-Info header field to carry relatively sensitive information like the cell ID. Therefore, the information MUST NOT be sent outside of the 3GPP domain. The UA is aware -- if it is a 3GPP UA -- that it is operating within a trusted domain. The 3GPP UA is aware of whether or not a secure association to the home network domain for transporting SIP signaling is currently available, and, as such, the sensitive information carried in the P-Access-Network-Info header field MUST NOT be sent in any initial unauthenticated and unprotected requests (e.g., REGISTER). Any UA that is using this extension and is not part of a private trusted domain should not consider the mechanism as secure, and, as such, MUST NOT send sensitive information in the P-Access-Network- Info header field.
Any proxy that is operating in a private trust domain where the P-Access-Network-Info header field is supported is REQUIRED to delete the header, if it is present, from any message prior to forwarding it outside of the trusted domain. A proxy receiving a message containing the P-Access-Network-Info header field from an untrusted entity is not able to guarantee the validity of the contents. Thus, this content SHOULD be deleted based on local policy.6.5. P-Charging-Function-Addresses Header Field
It is expected as normal behavior that proxies within a closed network will modify the values of the P-Charging-Function-Addresses header field and insert it into a SIP request or response. However, the proxies that share this information MUST have a trust relationship. If an untrusted entity were inserted between trusted entities, it could potentially substitute a different charging function address. Therefore, an integrity-protection mechanism such as IPsec or other available mechanisms MUST be applied in order to prevent such attacks. Since each trusted proxy MAY need to view or modify the values in the P-Charging-Function-Addresses header field, the protection should be applied on a hop-by-hop basis.6.6. P-Charging-Vector Header Field
It is expected as normal behavior that proxies within a closed network will modify the values of the P-Charging-Vector header field and insert it into a SIP request or response. However, these proxies that share this information MUST have a trust relationship. If an untrusted entity were inserted between trusted entities, it could potentially interfere with the charging correlation mechanism. Therefore, an integrity-protection mechanism such as IPsec or other available mechanisms MUST be applied in order to prevent such attacks. Since each trusted proxy MAY need to view or modify the values in the P-Charging-Vector header field, the protection should be applied on a hop-by-hop basis.
7. IANA Considerations
This document defines several private SIP extension header fields (beginning with the prefix "P-" ). This document obsoletes [RFC3455] but uses the same SIP header field names. The references in the "Header Fields" registry and "Header Field Parameters and Parameter Values" registry have been updated to [RFC3455] to this document. The following extensions are registered as private extension header fields: Header Field Name: P-Associated-URI Compact Form: none Reference: RFC 7315 Header Field Name: P-Called-Party-ID Compact Form: none Reference: RFC 7315 Header Field Name: P-Visited-Network-ID Compact Form: none Reference: RFC 7315 Header Field Name: P-Access-Network-Info Parameter Name: ci-3gpp Parameter Name: ci-3gpp2 Parameter Name: ci-3gpp2-femto Parameter Name: dsl-location Parameter Name: dvb-rcs2-node-id Parameter Name: eth-location Parameter Name: fiber-location Parameter Name: gstn-location Parameter Name: i-wlan-node-id Parameter Name: local-time-zone Parameter Name: operator-specific-GI Parameter Name: utran-cell-id-3gpp Parameter Name: utran-sai-3gpp Compact Form: none Reference: RFC 7315
Header Field Name: P-Charging-Function-Addresses
Parameter Name: ccf
Parameter Name: ccf-2
Parameter Name: ecf
Parameter Name: ecf-2
Compact Form: none
Reference: RFC 7315
Header Field Name: P-Charging-Vector
Parameter Name: icid-value
Parameter Name: icid-generated-at
Parameter Name: orig-ioi
Parameter Name: related-icid
Parameter Name: related-icid-generated-at
Parameter Name: term-ioi
Parameter Name: transit-ioi
Compact Form: none
Reference: RFC 7315
8. Contributors and Acknowledgements
The authors would like to thank James Yu and Atle Monrad for their
extensive review, Dean Willis for his expert review, and Mary Barnes
for the proto review. The authors would like to acknowledge the
constructive feedback and contributions provided by Peter Leis,
Joergen Axell, and Jan Holm.
The extensions described in [RFC3455] were originally specified in
several documents. Miguel Garcia-Martin authored the P-Associated-
URI, P-Called-Party-ID, and P-Visited-Network-ID header fields.
Duncan Mills authored the P-Access-Network-Info header. Eric
Henrikson authored the P-Charging-Function-Addresses and P-Charging-
Vector headers. Rohan Mahy assisted in the incorporation of these
extensions into a single document.
The listed authors of [RFC3455] were Miguel Garcia-Martin, Eric
Henrikson and Duncan Mills.
The [RFC3455] authors thanked Andrew Allen, Gabor Bajko, Gonzalo
Camarillo, Keith Drage, Georg Mayer, Dean Willis, Rohan Mahy,
Jonathan Rosenberg, Ya-Ching Tan, and the 3GPP CN1 WG members for
their comments on [RFC3455].
9. References
9.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. [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. [TS24.229] 3GPP, "IP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3", 3GPP TS 24.229 12.4.0, March 2014.9.2. Informative References
[RFC3324] Watson, M., "Short Term Requirements for Network Asserted Identity", RFC 3324, November 2002. [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, November 2002. [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)", RFC 3455, January 2003. [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003. [RFC4083] Garcia-Martin, M., "Input 3rd-Generation Partnership Project (3GPP) Release 5 Requirements on the Session Initiation Protocol (SIP)", RFC 4083, May 2005. [RFC6665] Roach, A., "SIP-Specific Event Notification", RFC 6665, July 2012.
[RFC7044] Barnes, M., Audet, F., Schubert, S., van Elburg, J., and C. Holmberg, "An Extension to the Session Initiation Protocol (SIP) for Request History Information", RFC 7044, February 2014. [TS23.228] 3GPP, "P Multimedia Subsystem (IMS); Stage 2", 3GPP TS 23.228 12.4.0, March 2014. [TS32.240] 3GPP, "Telecommunication management; Charging management; Charging architecture and principles", 3GPP TS 32.240 12.3.0, March 2013. [TS32.260] 3GPP, "Telecommunication management; Charging management; IP Multimedia Subsystem (IMS) charging", 3GPP TS 32.260 10.3.0, April 2011.
Appendix A. Changes from RFC 3455
1. Procedures for the P-Associated-URI header field at a proxy. RFC 3455 indicates that it defines no procedures for the P-Associated-URI header field at a proxy. What is implicitly meant here is that the proxy does not add, read, modify, or delete the header; therefore, RFC 3261 proxy procedures only apply to the header. 2. P-Called-Party-ID header field and the History-Info header field: At the time RFC 3455 was written, the History-Info header field was a long way from specification. This header has now been specified and approved in RFC 7044. It is acknowledged that the History-Info header field will provide equivalent coverage to that of the P-Called-Party-ID header field. However, the P-Called-Party-ID header field is used entirely within the 3GPP system and does not appear to SIP entities outside that of a single 3GPP operator. 3. Procedures at the UA for the P-Charging-Function Addresses header field: The text in Section 4.5.2.1 of RFC 3455 does not adequately take into account procedures for UAs located inside the private network, e.g., as gateways and such that may play a full part in network charging procedures. Section 4.5.2.1 is replaced with new text. 4. The text in Section 4.6.2.1 of RFC 3455 does not adequately take into account procedures for UAs located inside the private network, e.g., as gateways and such that may play a full part in network charging procedures. Section 4.6.2.1 is now replaced with new text. 5. Recognition of additional values of access technology in the P-Access-Network-Info header field (Section 4.4): A number of new access technologies are contemplated in 3GPP, and the reuse of IMS to support Next Generation Networks (NGN) is also resulting in new access technologies. Values for access technologies are defined explicitly in RFC 3455, and no IANA procedures are defined to maintain a separate registry. In particular, the new values: "IEEE 802.11", "IEEE-802.11g", "IEEE-802.11n", "ADSL" / "ADSL2", "ADSL2+", "RADSL", "SDSL", "HDSL", "HDSL2", "G.SHDSL", "VDSL", "IDSL", "IEEE-802.3", "IEEE-802.3a", "IEEE-802.3e", "IEEE-802.3i", "IEEE-802.3j", "IEEE-802.3u", "IEEE-802.3ab", "IEEE-802.3ae", "IEEE-802.3ak", "IEEE-802.3aq", "IEEE-802.3an", "IEEE-802.3y", "IEEE-802.3z", and "IEEE-802.3y" are defined.
6. Replacement of existing value of access technology in the
P-Access-Network-Info header field (Section 4.4): The value of
"3GPP-CDMA2000" was replaced long ago in 3GPP2 by three new
values: "3GPP2-1X", "3GPP2-1X-HRPD", and "3GPP2-UMB". It is not
believed that there was any deployment of the "3GPP-CDMA2000"
value.
7. Network-provided P-Access-Network-Info header field: The
P-Access-Network-Info header field may additionally be provided
by proxies within the network. This does not impact the values
provided by a UA; rather, the header is repeated. Such values
are identified by the string "network-provided". A special
class of values are defined for use here, as the same
granularity of values may not be possible as for those available
from the UA: "3GPP-GERAN", "3GPP-UTRAN", "3GPP-WLAN",
"3GPP-GAN", and "3GPP-HSPA". Outbound proxies remove P-Access-
Network-Info header fields containing the "network-provided"
value.
8. Definition of additional parameters to the P-Charging-Vector
header field: Section 5.6 of RFC 3455 defines the syntax of the
P-Charging-Vector header field. Additional parameters were
considered too application specific for specification in RFC
3455, but it was acknowledged that they would exist, and indeed
additional specification of such parameters, relating to
specific access technologies, has occurred in 3GPP. Therefore,
this update states that applications using the P-Charging-Vector
header field within their own applicability are allowed to
define generic-param extensions without further reference to the
IETF specification process.
9. In Section 5.7, it was added that the P-Called-Party-ID can
appear in the PUBLISH method.
10. Referencing: RFC 3427 was deleted from the References section as
it was not used within the document. Various informative
references have now been published as RFCs and have been updated
to include the appropriate RFC number. References to 3GPP TS
32.200 were replaced by references to 3GPP TS 32.240 [TS32.240],
which is the successor specification. References to 3GPP TS
32.225 were replaced by references to 3GPP TS 32.260 [TS32.260],
which is the successor specification. The referencing style was
changed to symbolic references. Dates have been removed from
all 3GPP references (i.e., latest version applies).
11. Various editorial changes in alignment with style used in RFC 3261 such as placing response code text in parentheses and using words "request" and "response" in association with method names have been applied.Authors' Addresses
Roland Jesske Deutsche Telekom Heinrich-Hertz-Strasse 3-7 Darmstadt 64307 Germany Phone: +4961515812766 EMail: r.jesske@telekom.de Keith Drage Alcatel-Lucent Quadrant, StoneHill Green, Westlea Swindon, Wilts UK EMail: drage@alcatel-lucent.com Christer Holmberg Ericsson Hirsalantie 11 Jorvas 02420 Finland EMail: christer.holmberg@ericsson.com