One document matched: draft-gundavelli-ipsecme-3gpp-ims-options-05.xml
<?xml version="1.0"?>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc tocappendix="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC ''
'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY rfc4303 PUBLIC ''
'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4303.xml'>
<!ENTITY rfc7296 PUBLIC ''
'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7296.xml'>
<!ENTITY rfc5739 PUBLIC ''
'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5739.xml'>
<!ENTITY rfc5213 PUBLIC ''
'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5213.xml'>
<!ENTITY rfc5844 PUBLIC ''
'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5844.xml'>
]>
<rfc category="info" ipr="trust200902" docName="draft-gundavelli-ipsecme-3gpp-ims-options-05.txt">
<front>
<title abbrev="3GPP IMS Option for IKEv2">
3GPP IMS Option for IKEv2
</title>
<author initials="A" surname="Dodd-Noble" fullname="Aeneas Noble">
<organization abbrev="">Cisco</organization>
<address>
<postal>
<street>30 International Pl</street>
<city>TEWKSBURY</city>
<region>MASSACHUSETTS</region>
<code>95134</code>
<country>USA</country>
</postal>
<email>noblea@cisco.com</email>
</address>
</author>
<author initials="S" surname="Gundavelli" fullname="Sri Gundavelli">
<organization abbrev="">Cisco</organization>
<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>USA</country>
</postal>
<email>sgundave@cisco.com</email>
</address>
</author>
<author initials="J" surname="Korhonen" fullname="Jouni Korhonen">
<organization abbrev="">Broadcom Corporation</organization>
<address>
<postal>
<street>Porkkalankatu 24</street>
<city>Helsinki</city>
<code>FIN-00180</code>
<country>Finland</country>
</postal>
<email>jouni.nospam@gmail.com</email>
</address>
</author>
<author initials="F" surname="Baboescu" fullname="Florin Baboescu">
<organization abbrev="">Broadcom Corporation</organization>
<address>
<postal>
<street>100 Mathilda Place</street>
<city>Sunnyvale</city>
<region>CA</region>
<code>94086</code>
<country>USA</country>
</postal>
<email>baboescu@broadcom.com></email>
</address>
</author>
<author initials="B" surname="Weis" fullname="Brian Weis">
<organization abbrev="">Cisco</organization>
<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>USA</country>
</postal>
<email>bew@cisco.com</email>
</address>
</author>
<date year="2015" />
<area>Internet</area>
<workgroup>IPSECME WG</workgroup>
<!------------------------------------------------>
<!-- SECTION 0: Abstract -->
<!------------------------------------------------>
<abstract>
<t>
This document defines two new configuration attributes for Internet Key Exchange Protocol version 2
(IKEv2). These attributes can be used for carrying the IPv4 address and IPv6 address of the Proxy-Call
Session Control Function (P-CSCF). When an IPsec gateway delivers these attributes to an IPsec client,
the IPsec client can obtain the IPv4 and/or IPv6 address of the P-CSCF server located in the 3GPP network.
</t>
</abstract>
</front>
<middle>
<!------------------------------------------------>
<!-- SECTION 1: Introduction -->
<!------------------------------------------------>
<section anchor="sec:introduction" title="Introduction">
<t>
The Third Generation Partnership Project (3GPP) S2b reference point <xref target="TS23402"></xref>, specified by
the 3GPP system architecture defines a mechanism for allowing a mobile node (MN) attached in an untrusted non-3GPP
IP Access Network to securely connect to a 3GPP network and access IP services. In this scenario, the mobile node
establishes an IPsec ESP tunnel <xref target="RFC4303"></xref> to the security gateway called evolved packet
data gateway (ePDG) and which in turn establishes a Proxy Mobile IPv6 (PMIPv6) <xref target="RFC5213"></xref> or
GPRS Tunneling Protocol (GTP) <xref target="TS23402"></xref> tunnel to the packet data gateway (PGW) <xref target="TS23402"></xref>
where the mobile node's session is anchored.
</t>
<t>
The below figure shows the interworking option for non-3GPP access over an untrusted-access network. The mobile access gateway (MAG)
and the local mobility anchor (LMA) functions are defined in <xref target="RFC5213"></xref>. The ePDG and PGW functions are
defined in <xref target="TS23402"></xref>. IPsec ESP tunnel is between the MN and the ePDG and PMIP or GTP tunnel between the ePDG and
the PGW.
</t>
<figure anchor="fig1" title="Exchange of IPv4 Traffic Offload Selectors">
<artwork>
<![CDATA[
+------------+
| ePDG |
| +--------+ |
+------+ _----_ | | IPsec | | _----_ +-----+
| MN | _( )_ | | Module | | _( )_ | LMA |
| |<====( Internet )=====| +--------+ |===( Operator )===|(PGW)|
+------+ (_ _) | : | (_Network_) +-----+
'----' | +--------+ | '----'
IPsec Tunnel | | PMIPv6 | | PMIPv6/GTP Tunnel
| | MAG | |
| +--------+ |
+------------+
|<------------ IKEv2/IPsec ------> | <------ PMIPv6/GTP ----->|
]]>
</artwork>
</figure>
<t>
A mobile node in this scenario may potentially need to access the IP Multimedia Subsystem (IMS) services in the 3GPP network <xref target="TS23228"></xref> and <xref target="TS24229"></xref>. Currently,
there are no attributes in IKEv2 <xref target="RFC7296"></xref> that can be used for carrying these information elements. In the absence of
these attributes the mobile node needs to be statically configured with this information and this is proving
to be an operational challenge. Any other approaches such as using DNS, or DHCP for discovering these functions would result in obtaining configuration
in the access network and not in the home network. Given that the above referenced 3GPP interface is primarily for allowing the mobile node to
connect to the 3GPP network through an untrusted-access network, the access network may not have any relation with the home network provider and may
be unable to deliver the mobile node's home network configuration.
</t>
<t>
This specification therefore defines two new IKEv2 attributes <xref target="RFC7296"></xref> that allows an
IPsec gateway to provide the IPv4 and/or IPv6 address of the P-CSCF server. These attributes can be exchanged
by IKEv2 peers as part of the configuration payload exchange. The attributes follow the configuration attribute format defined in Section 3.15.1
of <xref target="RFC7296"></xref>. Furthermore, providing the P-CSCF server address(es) in IKEv2 as standard attribute(s) enables clients to directly
access IMS services behind a VPN gateway without going through the 3GPP specific interfaces.
</t>
</section>
<!-------------------------------------------------------------------------------->
<!-- SECTION 2: CONVENTIONS & TERMINOLOGY -->
<!-------------------------------------------------------------------------------->
<section anchor="sec:conventions_terminology" title="Conventions and Terminology">
<!--vspace blankLines="1" /-->
<!-------------------------------------------------------------------------------->
<!-- SECTION 2.1: CONVENTIONS --->
<!-------------------------------------------------------------------------------->
<section anchor="sec:conventions" title="Conventions">
<t>
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 RFC 2119 <xref target="RFC2119"/>.
</t>
</section> <!-- conventions -->
<!-------------------------------------------------------------------------------->
<!-- SECTION 2.2: TERMINOLOGY --->
<!-------------------------------------------------------------------------------->
<section anchor="sec:terminology" title="Terminology">
<t>
All the IKEv2 related terms used in this document are to be interpreted as defined in
<xref target="RFC7296"/> and <xref target="RFC5739"/>. All the mobility related terms are
to interpreted as defined in <xref target="RFC5213"/> and <xref target="RFC5844"/>.
Additionally, this document uses the following terms:
</t>
<t>
Proxy-Call Session Control Function (P-CSCF)
</t>
<t>
<list style="hanging">
<t>
The P-CSCF is the entry point to the 3GPP IMS (IP Multimedia Subsystem) and serves as the
SIP outbound proxy for the mobile node. The mobile node performs SIP registration to 3GPP
IMS and initiates SIP sessions via a P-CSCF.
</t>
</list>
</t>
<t>
Evolved Packet Data Gateway (ePDG)
</t>
<t>
<list style="hanging">
<t>
Its is a security gateway defined by the 3GPP system architecture. The protocol interfaces
it supports include IKEv2 <xref target="RFC7296"></xref>.
</t>
</list>
</t>
</section> <!-- Terminology -->
</section> <!-- Conventions & Terminology -->
<!----------------------------------------------------------------------->
<!-- SECTION 3: P_CSCF_IP4_ADDRESS Configuration Attribute -->
<!----------------------------------------------------------------------->
<section title="P_CSCF_IP4_ADDRESS Configuration Attribute" anchor="sec:att-1">
<t>
The P_CSCF_IP4_ADDRESS configuration attribute is formatted as follows:
</t>
<figure anchor='fig2' title="IPv4 Address of P-CSCF" >
<artwork>
<![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| Attribute Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]>
</artwork>
</figure>
<t>
<list style="hanging">
<t hangText="Reserved (1 bit)"><vspace blankLines="0" />
Refer to IKEv2 specification
</t>
<t hangText="Attribute Type (15 bits)"><vspace blankLines="0" /><IANA-1></t>
<t hangText="Length (2 octets)"><vspace blankLines="0" />
Length of the IPv4 address field that follows. Possible values are (0) and (4).
A value of (4) indicates the size of the 4-octet IPv4 address that follows.
A value of (0) indicates that its a empty attribute with zero-length IPv4 address
field, primarily used as a request indicator.
</t>
<t hangText="IPv4 Address (4 octets)"><vspace blankLines="0" />
An IPv4 address of the P-CSCF server.
</t>
</list>
</t>
<t>
The P_CSCF_IP4_ADDRESS configuration attribute provides an IPv4 address of a P-CSCF server within
the network. If an instance of an empty P_CSCF_IP4_ADDRESS attribute with zero-length IPv4 Address field
is included by mobile node, the responder MAY respond with zero, one or more P_CSCF_IP4_ADDRESS attributes.
If several P_CSCF_IP4_ADDRESS attributes are provided in one IKEv2 message, there is no implied order
among the P_CSCF_IP4_ADDRESS attributes. However, a system architecture using this specification may be able
to enforce some order at both the peers.
</t>
</section>
<!----------------------------------------------------------------------->
<!-- SECTION 4: P_CSCF_IP6_ADDRESS Configuration Attribute -->
<!----------------------------------------------------------------------->
<section title="P_CSCF_IP6_ADDRESS Configuration Attribute" anchor="sec:att-2">
<t>
The P_CSCF_IP6_ADDRESS configuration attribute is formatted as follows:
</t>
<figure anchor='fig3' title="IPv6 Address of P-CSCF" >
<artwork>
<![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| Attribute Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
| IPv6 Address |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]>
</artwork>
</figure>
<t>
<list style="hanging">
<t hangText="Reserved (1 bit)"><vspace blankLines="0" />
Refer to IKEv2 specification
</t>
<t hangText="Attribute Type (15 bits)"><vspace blankLines="0" /><IANA-1></t>
<t hangText="Length (2 octets)"><vspace blankLines="0" />
Length of the IPv6 address field that follows. Possible values are (0) and (16).
A value is (16) indicates the size of the 16-octet IPv6 address that follows.
A value of (0) indicates that its a empty attribute with zero-length IPv6 address
field, primarily used as a request indicator.
</t>
<t hangText="IPv6 Address (16 octets)"><vspace blankLines="0" />
An IPv6 address of the P-CSCF server.
</t>
</list>
</t>
<t>
The P_CSCF_IP6_ADDRESS configuration attribute provides an IPv6 address of a P-CSCF server within
the network. If an instance of an empty P_CSCF_IP6_ADDRESS attribute with zero-length IPv6 Address
field is included by mobile node, the responder MAY respond with zero, one or more P_CSCF_IP6_ADDRESS
attributes. If several P_CSCF_IP6_ADDRESS attributes are provided in one IKEv2 message, there is
no implied order among the P_CSCF_IP6_ADDRESS attributes. However, a system architecture using this
specification may be able to enforce some order at both the peers.
</t>
</section>
<!----------------------------------------------------------------------->
<!-- SECTION 4: Overview -->
<!----------------------------------------------------------------------->
<section title="Example Scenario" anchor="sec:example">
<t>
The mobile node MAY request the IP address of an P-CSCF server as shown
below.
</t>
<figure anchor='fig4' title="P-CSCF Attribute Exchange" >
<artwork>
<![CDATA[
Client Gateway
-------- ---------
HDR(IKE_SA_INIT), SAi1, KEi, Ni -->
<-- HDR(IKE_SA_INIT), SAr1, KEr, Nr, [CERTREQ]
HDR(IKE_AUTH),
SK { IDi, CERT, [CERTREQ], AUTH, [IDr],
CP(CFG_REQUEST) =
{ INTERNAL_IP4_ADDRESS(),
INTERNAL_IP4_DNS(),
P_CSCF_IP4_ADDRESS() }, SAi2,
TSi = (0, 0-65535, 0.0.0.0-255.255.255.255),
TSr = (0, 0-65535, 0.0.0.0-255.255.255.255) } -->
<-- HDR(IKE_AUTH),
SK { IDr, CERT, AUTH,
CP(CFG_REPLY) =
{ INTERNAL_IP4_ADDRESS(192.0.2.234),
P_CSCF_IP4_ADDRESS(192.0.2.1),
P_CSCF_IP4_ADDRESS(192.0.2.4),
INTERNAL_IP4_DNS(198.51.100.33) },
SAr2,
TSi = (0, 0-65535, 192.0.2.234-192.0.2.234),
TSr = (0, 0-65535, 0.0.0.0-255.255.255.255) }
]]>
</artwork>
</figure>
</section>
<!------------------------------------------------>
<!-- SECTION 6: IANA Considerations -->
<!------------------------------------------------>
<section anchor="sec:iana" title="IANA Considerations">
<t>
This document requires the following two IANA actions.
</t>
<t>
<list style="symbols">
<t>
Action-1: This specification defines a new IKEv2 attribute for carrying the IPv4
address of P-CSCF server. This attribute is defined in <xref target="sec:att-1"/>.
The Type value for this Attribute needs to be assigned from the IKEv2 Configuration Payload
Attribute Types namespace defined in <xref target="RFC7296"/>.
</t>
<t>
Action-2: This specification defines a new IKEv2 attribute for carrying the IPv6
address of P-CSCF server. This attribute is defined in <xref target="sec:att-2"/>.
The Type value for this Attribute needs to be assigned from the IKEv2 Configuration Payload
Attribute Types namespace defined in <xref target="RFC7296"/>.
</t>
</list>
</t>
</section>
<!------------------------------------------------>
<!-- SECTION 7: Security Considerations -->
<!------------------------------------------------>
<section anchor="sec:secons" title="Security Considerations">
<t>
This document is an extension to IKEv2 <xref target="RFC7296"/> and therefore it inherits all
the security properties of IKEv2.
</t>
<t>
The two new IKEv2 attributes defined in this specification are for carrying the IPv4 and IPv6
address of the P-CSCF server. These attributes can be exchanged by IKE peers as part of the
configuration payload and the currently defined IKEv2 security framework provides the needed
integrity and privacy protection for these attributes. Therefore this specification does
not introduce any new security vulnerabilities.
</t>
</section>
<!------------------------------------------------>
<!-- SECTION 8: Acknowledgements -->
<!------------------------------------------------>
<section anchor="sec:ack" title="Acknowledgements">
<t>
The Authors would like to specially thank Tero Kivinen for the detailed reviews. Authors would also like to thank
Vojislav Vucetic, Heather Sze, Sebastian Speicher, Maulik Vaidya, Ivo Sedlacek, Pierrick Siete and Hui Deng for
all the discussions related to this topic.
</t>
</section>
</middle>
<back>
<!------------------------------------------------>
<!-- SECTION 9: Normative References -->
<!------------------------------------------------>
<references title="Normative References">
&rfc2119;
&rfc7296;
&rfc4303;
</references>
<!------------------------------------------------>
<!-- SECTION 10: Informative References -->
<!------------------------------------------------>
<references title="Informative References">
&rfc5739;
&rfc5213;
&rfc5844;
<reference anchor="TS23402">
<front>
<title>
Architecture enhancements for non-3GPP accesses
</title>
<author fullname="3GPP TS 23.402">
<organization>3GPP</organization>
</author>
<date year="2014" />
</front>
</reference>
<reference anchor="TS23228">
<front>
<title>
Service requirements for the Internet Protocol (IP) multimedia core network subsystem (IMS); Stage 1
</title>
<author fullname="3GPP TS 23.228">
<organization>3GPP</organization>
</author>
<date year="2014" />
</front>
</reference>
<reference anchor="TS24229">
<front>
<title>
IP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3
</title>
<author fullname="3GPP TS 24.229">
<organization>3GPP</organization>
</author>
<date year="2014" />
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 10:40:13 |