involved in a SIP dialog or transaction outside a dialog. There may
an IOI generated from each side of the dialog to identify the network
associated with each side.
There is also expected to be access network charging information,
which consists of network specific identifiers for the access level
(e.g., UMTS radio access network or IEEE 802.11b). The details of
the information for each type of network are not described in this
memo.
We define the SIP private header P-Charging-Vector. A proxy MAY
include this header, if not already present, in either the initial
request or response for a dialog, or in the request and response of a
standalone transaction outside a dialog. Only one instance of the
header MUST be present in a particular request or response.
The mechanisms by which a SIP proxy collects the values to populate
in the P-Charging-Vector are outside the scope of this document.
4.6.1 Applicability Statement for the P-Charging-Vector header
The P-Charging-Vector header is applicable within a single private
administrative domain or between different administrative domains
where there is a trust relationship between the domains.
The P-Charging-Vector header is not included in a SIP message sent to
another network if there is no trust relationship. The header is not
applicable if the administrative domain manages charging in a way
that does not require correlation of records from multiple network
entities (e.g., SIP proxies).
The P-Charging-Vector header is applicable whenever the following
circumstances are met:
1. A UA sends a REGISTER or dialog-initiating request (e.g., INVITE)
or a standalone transaction request outside a dialog to a proxy
located in the administrative domain of a private network.
2. A registrar, proxy or UA that is located in the administrative
domain of the private network wants to generate charging records.
3. A proxy or UA that is located in the administrative domain of the
private network has access to the charging correlation information
for that network.
4. Optionally, a registrar, proxy or UA that is part of a second
administrative domain in another private network, whose SIP
request and responses are traversed through, en-route to the first
private network, wants to generate charging records and correlate
those records with those of the first private network. This
assumes that there is a trust relationship between both private
networks.
4.6.2 Usage of the P-Charging-Vector header
The P-Charging-Vector header is used to convey charging related
information, such as the globally unique IMS charging identifier
(ICID) value.
Typically, a SIP proxy that receives a SIP request that does not
contain a P-Charging-Vector header may insert it, with those
parameters that are available at the SIP proxy.
A SIP proxy that receives a SIP request that contains a
P-Charging-Vector header may use the values, such as the globally
unique ICID, to produce charging records.
4.6.2.1 Procedures at the UA
This document does not specify any procedure at the UA, with regard
to the P-Charging-Vector header. UAs need not understand this
header.
4.6.2.2 Procedures at the Proxy
A SIP proxy that supports this extension and receives a request or
response without the P-Charging-Vector header MAY insert a
P-Charging-Vector header prior to forwarding the message. The header
is populated with one ore more parameters, as described in the
syntax, including but not limited to, a globally unique charging
identifier.
If a proxy that supports this extension receives a request or
response with the P-Charging-Vector header, it may retrieve the
information from the header value to use with application specific
logic, i.e., charging. If the next hop for the message is within the
trusted domain, then the proxy SHOULD include the P-Charging-Vector
header in the outbound message. If the next hop for the message is
outside the trusted domain, then the proxy MAY remove the
P-Charging-Function-Addresses header.
Per local application specific logic, the proxy MAY modify the
contents of the P-Charging-Vector header prior to sending the
message.
4.6.2.3 Examples of Usage
We present example in the context of the scenario presented in the
following network diagram:
Scenario UA1 --- P1 --- P2 --- UA2
This example shows the message sequence for an INVITE transaction
originating from UA1 eventually arriving at UA2. P1 is an outbound
proxy for UA1. In this case P1 also inserts charging information.
P1 then routes the call via P2 to UA2.
Message sequence for INVITE using P-Charging-Vector:
F1 Invite UA1 -> P1
INVITE sip:joe@example.com SIP/2.0
Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7
To: sip:joe@example.com
From: sip:ua1@home1.net;tag=456248
Call-ID: 843817637684230998sdasdh09
CSeq: 18 INVITE
Contact: sip:ua1@192.0
F2 Invite P1 -> P2
INVITE sip:joe@example.com SIP/2.0
Via: SIP/2.0/UDP P1.home1.net:5060;branch=z9hG4bK34ghi7a
Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7
To: sip:joe@example.com
From: sip:ua1@home1.net;tag=456248
Call-ID: 843817637684230998sdasdh09
CSeq: 18 INVITE
Contact: sip:ua1@192.0.2.4
P-Charging-Vector: icid-value=1234bc9876e;
icid-generated-at=192.0.6.8;
orig-ioi=home1.net
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
2234 [3]. 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 [1] and RFC2234 [3] to understand this
document.
5.1 P-Associated-URI header syntax
The syntax of the P-Associated-URI header 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-param
5.2 P-Called-Party-ID header syntax
The syntax of the P-Called-Party-ID header 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-param
5.3 P-Visited-Network-ID header syntax
The syntax of the P-Visited-Network-ID header 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-param
5.4 P-Access-Network-Info header syntax
The syntax of the P-Access-Network-Info header is described as
follows:
P-Access-Network-Info = "P-Access-Network-Info" HCOLON
access-net-spec
access-net-spec = access-type *(SEMI access-info)
access-type = "IEEE-802.11a" / "IEEE-802.11b" /
"3GPP-GERAN" / "3GPP-UTRAN-FDD" /
"3GPP-UTRAN-TDD" /
"3GPP-CDMA2000" / token
access-info = cgi-3gpp / utran-cell-id-3gpp /
extension-access-info
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)
The access-info may contain additional information relating to the
access network. The values for "cgi-3gpp" and "utran-cell-id-3gpp"
are defined in 3GPP TS 24.229 [15].
5.5 P-Charging-Function-Addresses header syntax
The syntax for the P-Charging-Function-Addresses header is described
as follows:
P-Charging-Addr = "P-Charging-Function-Addresses" HCOLON
charge-addr-params
*(SEMI charge-addr-params)
charge-addr-params = ccf / ecf / generic-param
ccf = "ccf" EQUAL gen-value
ecf = "ecf" EQUAL gen-value
5.6 P-Charging-Vector header syntax
The syntax for the P-Charging-Vector header 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 / 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
The P-Charging-Vector contains icid-value 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 host name or IP address of
the proxy that generated the icid-value.
The orig-ioi and term-ioi parameters represent, respectively, the
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.
5.7 Table of new headers
Table 1 extends the headers defined in this document to Table 2 in
SIP [1], section 7.1 of the SIP-specific event notification [6],
tables 1 and 2 in the SIP INFO method [8], tables 1 and 2 in
Reliability of provisional responses in SIP [7], tables 1 and 2 in
the SIP UPDATE method [9], tables 1 and 2 in the SIP extension for
Instant Messaging [10], and table 1 in the SIP REFER method [11]:
Header field where proxy ACK BYE CAN INV OPT REG
___________________________________________________________
P-Associated-URI 2xx - - - - - o
P-Called-Party-ID R amr - - - o o -
P-Visited-Network-ID R ad - - - o o o
P-Access-Network-Info dr - o - o o o
P-Charging-Vector admr - o - o o o
P-Charging-Function- adr - o - o o o
Addresses
Header field SUB NOT PRA INF UPD MSG REF
___________________________________________________________
P-Associated-URI - - - - - - -
P-Called-Party-ID o - - - - o o
P-Visited-Network-ID o - - - - o o
P-Access-Network-Info o o o o o o o
P-Charging-Vector o o o o o o o
P-Charging-Function- o o o o o o o
Addresses
Table 1: Header field support
6. Security Considerations
6.1 P-Associated-URI
The information returned in the P-Associated-URI header 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.
This attack, while potentially annoying, should not have significant
impacts.
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
value. An eavesdropper could collect this information. If the user
does not want to disclose the associated URIs, the eavesdropper could
have gain access to private URIs. Therefore it is RECOMMENDED that
this extension is used in a secured environment, where encryption of
SIP messages is provided either end-to-end or hop-by-hop.
6.2 P-Called-Party-ID
Due to the nature of the P-Called-Party-ID header, 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 may collect the list of identities a user is
registered. This may 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.
6.3 P-Visited-Network-ID
The P-Visited-Network-ID header 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.
Therefore intermediaries participating in this mechanism MUST apply a
hop-by-hop integrity protection mechanism such us IPsec or other
available mechanisms in order to prevent such attacks.
6.4 P-Access-Network-Info
A Trust Domain is formally defined in the Short term requirements for
Network Asserted Identity [13] document. For the purpose 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 [15].
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 should 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 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 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 SHOULD 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 SHOULD NOT send sensitive information in the
P-Access-Network-Info header.
Any proxy that is operating in a private trust domain where the
P-Access-Network-Info header is supported is required to delete the
header, if it is present, from any message prior to forwarding it
outside of the trusted domain.
Therefore, a network that requires its UA to send information in the
P-Access-Network-Info header must ensure that either that information
is not of a sensitive nature or that the information is not sent
outside of the trust domain.
A proxy receiving a message containing the P-Access-Network-Info
header from a non-trusted entity is not able to guarantee the
validity of the contents.
6.5 P-Charging-Function-Addresses
It is expected as normal behavior that proxies within a closed
network will modify the values of the P-Charging-Function-Addresses
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 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, the protection
should be applied on a hop-by-hop basis.
6.6 P-Charging-Vector
It is expected as normal behavior that proxies within a closed
network will modify the values of the P-Charging-Vector 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, 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-" ).
These extension headers have been included in the registry of SIP
header fields defined in SIP [1]. Expert review as required for this
process was provided by the SIP Working Group.
The following extensions are registered as private extension header
fields:
RFCNumber: RFC3455
Header Field Name: P-Associated-URI
Compact Form: none
RFCNumber: RFC3455
Header Field Name: P-Called-Party-ID
Compact Form: none
RFCNumber: RFC3455
Header Field Name: P-Visited-Network-ID
Compact Form: none
RFCNumber: RFC3455
Header Field Name: P-Access-Network-Info
Compact Form: none
RFCNumber: RFC3455
Header Field Name: P-Charging-Function-Addresses
Compact Form: none
RFCNumber: RFC3455
Header Field Name: P-Charging-Vector
Compact Form: none
8. Contributors
The extensions described in this document were originally specified
in several documents. Miguel Garcia-Martin authored the
P-Associated-URI, P-Called-Party-ID, and P-Visited-Network-ID
headers. 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.
9. Acknowledgments
The authors would like to thank 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 this document.
10. Normative References
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
Session Initiation Protocol", RFC3261, June 2002.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC2119, March 1997.
[3] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC2234, November 1997.
11. Informative References
[4] Garcia-Martin, M., "3rd-Generation Partnership Project (3GPP)
Release 5 requirements on the Session Initiation Protocol
(SIP)", Work in Progress.
[5] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J. and B.
Rosen, "Change Process for the Session Initiation Protocol
(SIP)", BCP 67, RFC3427, December 2002.
[6] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC3265, June 2002.
[7] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional
Responses in Session Initiation Protocol (SIP)", RFC3262, June
2002.
[8] Donovan, S., "The SIP INFO Method", RFC2976, October 2000.
[9] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE
Method", RFC3311, October 2002.
[10] Campbell, B., Editor, Rosenberg, J., Schulzrinne, H., Huitema,
C. and D. Gurle, "Session Initiation Protocol (SIP) Extension
for Instant Messaging", RFC3428, December 2002.
[11] Sparks, R., "The SIP Refer Method", Work in Progress.
[12] Barnes, M., "SIP Generic Request History Capability
Requirements", Work in Progress.
[13] Watson, M., "Short Term Requirements for Network Asserted
Identity", RFC3324, November 2002.
[14] 3GPP, "TS 23.228: IP Multimedia Subsystem (IMS); Stage 2
(Release 5)", 3GPP 23.228, September 2002, <ftp://ftp.3gpp.org/
Specs/archive/23_series/23.228/>.
[15] 3GPP, "TS 24.229: IP Multimedia Call Control Protocol based on
SIP and SDP; Stage 3 (Release 5)", 3GPP 24.229, September 2002,
<ftp://ftp.3gpp.org/Specs/archive/24_series/24.229/>.
[16] 3GPP, "TS 32.200: Telecommunication Management; Charging
management; Charging principles (Release 5)", 3GPP 32.200, June
2002, <ftp://ftp.3gpp.org/Specs/archive/32_series/32.200/>.
[17] 3GPP, "TS 32.225: Telecommunication Management; Charging
management; Charging Data Description for IP Multimedia
Subsystem (Release 5)", 3GPP 32.225, September 2002, <ftp://
ftp.3gpp.org/Specs/archive/32_series/32.225/>.
Authors' Addresses
Miguel A. Garcia-Martin
Ericsson
Hirsalantie 11
Jorvas FIN-02420
Finland
EMail: miguel.a.garcia@ericsson.com
Eric Henrikson
Lucent
11601 Willows Rd, Suite 100
Redmond, WA 98052
USA
EMail: ehenrikson@lucent.com
Duncan Mills
Vodafone
The Courtyard, 2-4 London Road
Newbury, Berkshire RG14 1JX
UK
EMail: duncan.mills@vf.vodafone.co.uk
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Acknowledgement
Funding for the RFCEditor function is currently provided by the
Internet Society.