Network Working Group M. Garcia
Internet Draft Ericsson
Expires: December 2002 June 2002
Private Session Initiation Protocol (SIP) extension for
Visited Network Identifier
<draft-garcia-sip-visited-network-id-04.txt>
Status of this memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC 2026.
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 cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/lid-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This document is an individual submission to the IETF. Comments should
be directed to the authors.
Abstract
This memo describes a private extension to SIP in the form of a
P-Visited-Network-ID header. The contents of the header identify each
of the visited networks the message traversed en-route to the home
network.
Table of contents
1. Introduction......................................................2
2. Applicability statement...........................................2
Network Working Group Expiration 12/04/02 [Page 1]
Garcia The SIP Visited Network ID header June 2002
3. The Visited Network Identifier header.............................3
4. P-Visited-Network-ID syntax and definition........................3
5. Usage.............................................................5
5.1 Procedures at the UA.............................................5
5.2 Procedures at the registrar and proxy............................5
6. Security Considerations...........................................5
7. IANA Considerations...............................................5
8. Author's Addresses................................................6
9. Acknowledgements..................................................6
10. References.......................................................6
10.1 Normative references............................................6
10.2 Informative references..........................................6
1. Introduction
The 3rd Generation Partnership Project (3GPP) has chosen SIP [1] as
the signaling protocol for the IP Multimedia Subsystem (IMS). A
collection of 3GPP requirements related to SIP are stated in the "3GPP
requirements to SIP" [2].
3GPP networks are composed of a collection of so called home networks,
visited networks and subscribers. A particular home network may have
roaming agreements with one or more visited networks. This has the
effect that when a mobile terminal is roaming, it can use resources
provided by the visited network in a transparent fashion.
One of the conditions for a home network to accept a mobile roaming to
a particular visited network is the presence of a roaming agreement
between the home and the visited network. There is a need to indicate
to the home network which is the visited network that the terminal is
using.
3GPP terminals always register to the home network. The REGISTER
request is proxied by the visited network to the home network. In the
sake of a simple approach, it seems sensible that the visited network
includes an identification that is known at the home network. This
identification takes the form of a quoted text string or a token. The
home network may use this identification to verify the existence of a
roaming agreement with the visited network, and to authorize the
registration through that visited network.
2. Applicability statement
The P-Visited-Network-ID is applicable whenever the following
circumstances are met:
1. There is transitive trust in intermediate proxies between the
UA and the home network proxy via established relationships
between the home network and the visited network, and
generally supported by the use of standard security
mechanisms, e.g. IPsec, AKA, or TLS.
Network Working Group Expiration 12/05/02 [Page 2]
Garcia The SIP Visited Network ID header June 2002
2. An endpoint is using resources provided by one or more
visited networks (a network to which the user does not have a
direct business relationship).
3. A proxy that is located in one of the visited networks wants
to be identified at the user's home network.
4. There is no requirement that every visited network needs to
be identified at the home network. Those networks that want to
be identified make use of the extension defined in this
document. Those networks that do not want to be identified do
nothing.
5. A commonly pre-agreed text string or token identifies the
visited network at the home network.
6. The UAC sends a REGISTER or dialog initiating request (e.g.,
INVITE) or a standalone request outside a dialog (e.g.,
MESSAGE [8]) to a proxy in a visited network.
7. The request traverses, en route to its destination, a proxy
in the home network, or its destination is the registrar in
the home network.
8. The registrar or home proxy verifies and authorizes the usage
of resources (e.g., proxies) in the visited network.
3. The Visited Network Identifier header
The P-Visited-Network-ID header field is used to convey to the
registrar or home proxy in the home network the identifier of a
visited network. The identifier is a text string or token that is
known by both the registrar or the home proxy at the home network and
the proxies in the visited network.
Typically, the home network authorizes the UA to roam to a particular
visited network. This action requires an existing roaming agreement
between the home and the visited network.
The Visited Network Identifier header is populated with a quoted text
string or token that identifies the proxy network at the home network.
Someone could argue that it is possible for a home network to identify
one or more visited networks by inspecting the domain name in the Via
header fields. However, this solution is not reliable, as it has a
heavy dependency on DNS. It is an option for a proxy to populate the
via header with an IP address, for example, and in the absence of a
reverse DNS entry, the IP address will not convey the desired
information.
4. P-Visited-Network-ID syntax and definition
This document defines a new SIP header field named P-Visited-Network-
ID. The syntax of the P-Visited-Network-ID header is based on the ABNF
of SIP [1] and its syntax described as follows:
P-Visited-Network-ID = "P-Visited-Network-ID" HCOLON
vnetwork *(COMMA vnetwork)
Network Working Group Expiration 12/05/02 [Page 3]
Garcia The SIP Visited Network ID header June 2002
vnetwork = (token / quoted-string) *(SEMI vnetwork-param)
vnetwork-param = generic-param
Example:
P-Visited-Network-ID = "Network number 1", Other-Network
Any SIP proxy that receives a REGISTER request, a standalone request
outside a dialog (e.g., MESSAGE [8]), or a request that initiates a
dialog, MAY insert a P-Visited-Network-ID header when it forwards the
request. In case a REGISTER or other request is traversing different
administrative domains (e.g., different visited networks), a SIP proxy
may insert a new P-Visited-Network-ID header if the request does not
contain a P-Visited-Network-ID header with the same network identifier
as its own network identifier (e.g., if the request has traversed
other different administrative domains).
Note also that, there is not requirement for the header to be readable
in the proxies. Therefore, a first proxy may insert an encrypted
header that only the registrar can decrypt. If the request traverses
another proxy (e.g., a second proxy) located in the same
administrative domain as the first proxy, the second proxy will not be
able to read the contents of the P-Visited-Network-ID header. In this
situation, the second proxy will consider that its visited network
identifier is not already present in the value of the header, and
therefore, it will insert a new P-Visited-Network-ID header value
(hopefully with the same visited network identifier). When the request
arrives at the registrar, it will notice that the header value is
repeated (both the first and the second proxy inserted it). The
decrypted values should be the same, because both proxies where part
of the same administrative domain. While this situation is not
desirable, it does not create any harm at the registrar.
The P-Visited-Network-ID is normally used at registration. However,
this extension does not preclude other usages. For instance, a proxy
in a visited network that does not maintain registration state may
insert a P-Visited-Network-ID header into any standalone request
outside a dialog or a request that creates a dialog. At the time of
writing this document, the only requests that create dialogs are
INVITE [1], SUBSCRIBE [2] and REFER [9].
Table 1 below is an addition of the P-Visited-Network-ID to the Table
2 in SIP [1], section 4.1 of the SIP-specific event notification [4],
tables 1 and 2 in the SIP INFO method [5], tables 1 and 2 in
Reliability of provisional responses in SIP [6], tables 1 and 2 in the
SIP UPDATE method [7], tables 1 and 2 in the SIP extension for Instant
Messaging [8] and table 1 in the SIP REFER method [9]:
Header field where proxy ACK BYE CAN INV OPT REG
___________________________________________________________
P-Visited-Network-ID R ad - - - o o o
Network Working Group Expiration 12/05/02 [Page 4]
Garcia The SIP Visited Network ID header June 2002
Header field SUB NOT PRA INF UPD MES REF
_______________________________________________________________
P-Visited-Network-ID o - - - - o o
Table 1: Header field support
5. Usage
5.1 Procedures at the UA
This memo does not define any procedure at the UA. The UA MUST NOT
insert the P-Visited-Network-ID header.
5.2 Procedures at the registrar and proxy
A proxy that is located in a visited network MAY insert a P-Visited-
Network-ID header field in any of the requests indicated in the Table
1. The header is populated with the contents of a text string or a
token that identifies the administrative domain of the network where
the proxy is operating at the user's home network.
The home proxy or registrar in the home network may use the contents
of the P-Visited-Network-ID as an identifier of one or more visited
networks that the request traversed. The home proxy or registrar may
take local policy driven actions based on the existence or not of a
roaming agreement between the home and the visited networks. This
means, for instance, authorize the actions of the request based on the
contents of the P-Visited-Network-ID header.
A home proxy MUST delete this header when forwarding the message
outside the home network administrative domain, in order to retain the
user's privacy.
A home proxy SHOULD delete this header, even when the request is not
forwarded outside the home network administrative domain, when the
home proxy has used the contents of the header or the request is
routed based on the called party.
6. Security Considerations
For this mechanism to work, it is assumed 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. It is therefore
desirable to apply an integrity protection mechanism such us IPsec or
other available mechanisms in order to prevent such attacks.
7. IANA Considerations
Network Working Group Expiration 12/05/02 [Page 5]
Garcia The SIP Visited Network ID header June 2002
This document defines the SIP extension header "P-Visited-Network-ID"
which should be included in the registry of SIP headers defined in SIP
[1]. As required by the SIP change process [4] the SIP extension
header name "Visited-Network-ID" should also be registered in
association with this extension.
The following is the registration for the P-Visited-Network-ID header
field:
RFC Number: RFC XXXX [Note to IANA: Fill in with the RFC number
of this specification.]
Header Field Name: P-Visited-Network-ID
Compact Form: none
The following is the registration for the Visited-Network-ID header
field:
RFC Number: RFC XXXX [Note to IANA: Fill in with the RFC number
of this specification.] (not yet specified, only reserved)
Header Field Name: Visited-Network-ID
Compact Form: none
8. Author's Addresses
Miguel A. Garcia
Ericsson
FIN-02420, Jorvas, Finland
Tel: +358 9299 3553
e-mail: miguel.a.garcia@ericsson.com
9. Acknowledgements
The author would like to thank Andrew Allen, Gabor Bajko, Gonzalo
Camarillo, Keith Drage, Georg Mayer, Dean Willis, Rohan Mahy, Ya-Ching
Tan and the 3GPP CN1 WG members for the comments on this document.
10. References
10.1 Normative references
1.
J. Rosenberg, H. Schulzrinne, G. Camarillo et al, Session
Initiation Protocol, RFC 3261, March 2002.
10.2 Informative references
2. M. Garcia et al, 3GPP requirements on SIP, draft-garcia-sipping-
3gpp-reqs-03.txt, work in progress. A. Roach, SIP-Specific Event
Notification, RFC 3265, March 2002.
Network Working Group Expiration 12/05/02 [Page 6]
Garcia The SIP Visited Network ID header June 2002
3. S. Bradner, R. Mahy, A. Mankin, J. Ott, B. Rosen, D. Willis, SIP
change process, draft-tsvarea-sipchange-01.txt, February 2002,
work in progress.
4. A. Roach, SIP-Specific Event Notification, RFC 3265, March 2002.
5. S. Donovan, The SIP INFO method, RFC 2976, October 2000.
6. J. Rosenberg, H. Schulzrinne, Reliability of Provisional
Responses in SIP, RFC 3262, March 2002.
7. J. Rosenberg, The Session Initiation Protocol UPDATE Method,
draft-ietf-sip-update-02.txt, April 2002, work in progress.
8. B. Campbell, J. Rosenberg, H. Schulzrinne, C. Huitema, D. Gurle,
Session Initiation Protocol Extension for Instant Messaging,
draft-ietf-sip-message-04.txt, May 2002, work in progress.
9. R. Sparks, The SIP Refer method, draft-ietf-sip-refer-05.txt,
June 2002, work in progress.
Full Copyright Statement
Copyright (C) The Internet Society (2002). 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."
Expiration Date
This memo is filed as <draft-garcia-sip-visited-network-id-04.txt> and
expires December 5, 2002.
Network Working Group Expiration 12/05/02 [Page 7]