| Network Working Group | M. Boucadair |
| Internet-Draft | France Telecom |
| Intended status: Informational | March 5, 2015 |
| Expires: September 6, 2015 |
PCP for SIP Deployments in Managed Networks
draft-boucadair-pcp-sip-ipv6-05
This document discusses how PCP (Port Control Protocol) can be used in SIP deployments in managed networks. This document applies for both IPv4 and IPv6.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
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 to cite them other than as "work in progress."
This Internet-Draft will expire on September 6, 2015.
Copyright (c) 2015 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.
The base PCP specification allows to retrieve the external IP address and external port to be conveyed in the SIP signaling messages [RFC3261]. Therefore SIP Proxy Servers do not need to support means to ease the NAT traversal of SIP messages (e.g., [RFC5626], [RFC6223], etc.). Another advantage of using the external IP address and port is this provides a hint to the proxy server there is no need to return a small expire timer (e.g., 60s). In addition, the outbound proxy does not need any further feature to be supported in order to assist the remote endpoint to successfully establish media sessions. In particular, ALGs are not required in the NAT for this purpose and no dedicated functions at the media gateway are needed.
This document discusses how PCP can be used in SIP deployments (including IPv6 considerations).
The benefits of using PCP for SIP deployments are listed below:
Experimentation results, including SIP flow examples, are documented in [I-D.boucadair-pcp-nat64-experiments].
In deployments where ICE [RFC5245] is required, PCP can be of great help as discussed in [I-D.penno-rtcweb-pcp] for the WebRTC case. ICE can be used in the context of SIP over WebSocket [RFC7118] and WebRTC when deployed within managed networks. Because TURN suffers from limitations in traversing NAT and firewalls over UDP, PCP is a promising solution that can complement ICE in those deployment contexts to soften the experienced high failure rate [ICEFailure].
The document targets SIP deployments in managed networks. It can also be used as part of SIP-based services delivery in the context of network-located residential gateway effort [WT-317]. Typical deployment scenarios are shown in Figure 1.
(a) SIP UA behind a NAT/FW communicating with a Proxy Server
__________
+----------+ +----------+ / \ +------------+
| SIP UA |___| NAT/FW |____| Network |___| SIP Proxy |
|PCP Client| |PCP Server| | | | Server |
+----------+ +----------+ \__________/ +------------+
(b) SIP UA behind a NAT/FW communicating with a remote SIP UA
__________
+----------+ +----------+ / \ +------------+
| SIP UA |___| NAT/FW |____| Network |___| SIP UA |
|PCP Client| |PCP Server| | | | |
+----------+ +----------+ \__________/ +------------+
(c) SIP UAs behind a NATs/FWs
__________
+----------+ +----------+ / \ +----------+ +----------+
| SIP UA |__| NAT/FW |__| Network |__| NAT/FW |__| SIP UA |
|PCP Client| |PCP Server| | | |PCP Server| |PCP Client|
+----------+ +----------+ \__________/ +----------+ +----------+
(d) SIP UA behind a CPE: PCP Proxy
+----------+ +---------+ +----------+
| SIP UA |____| CPE |__________| CGN/FW |
|PCP Client| |PCP Proxy| |PCP Server|
+----------+ +---------+ +----------+
Figure 1: Typical deployment scenarios
The PCP server can be provisioned using a variety of means (e.g., [RFC7291]) or rely on the discovery method specified in [RFC6887].
This document does not make any assumption whether the PCP client is implemented as an OS service or whether it is integrated in the SIP User Agent (UA). Those considerations are implementation-service.
The PCP base specification allows to create mappings in PCP-controlled devices and therefore prepare for receiving incoming packets. A SIP UA can use PCP to create one mapping for SIP signalling messages and other mappings for media session purposes.
The SIP UA uses the external IP address and port number to build SIP headers. In particular, this information is used to build the VIA and CONTACT headers.
Figure 2 shows an example of the flow exchange that occurs to retrieve the external IP address and an external IP address assigned by the NAT, while Figure 2 provides an excerpt of the SIP REGISTER message issued by the SIP UA; only the assigned IP address and port number are present in the SIP headers.
+---------+ +-------+ +------------+
| SIP UA | | NAT | | IPv4 SIP |
| PCP | |+ PCP | |Proxy Server|
| Client | |Server | | "Mysip.fr" |
+---------+ +-------+ +------------+
| (a) PCP MAP | |
|Suggested External IP@ | |
| ::ffff:0.0.0.0| |
|Suggested External Port| |
| 5060| |
|======================>| |
| (b) PCP MAP | |
|Suggested External IP@ | |
| ::ffff:192.0.2.1| |
|Suggested External Port| |
| 3938| |
|<======================| |
| (1)SIP REGISTER |(2)SIP REGISTER |
|======================>|===============>|
| (4) SIP 200 OK | (3) SIP 200 OK |
|<======================|<===============|
| | |
Figure 2: SIP REGISTER Call Flow
SIP Message:
REGISTER sip:mysip.fr SIP/2.0
Via: SIP/2.0/UDP 192.0.2.1:3938;branch=z9hG4bK1572043597
From: <sip:client4@mysip.fr:5070>;tag=893886783
To: <sip:client4@mysip.fr:5070>
Call-ID: 1271173454
CSeq: 2 REGISTER
Contact: <sip:client4@192.0.2.1:3938;line=b3433a7df33282d>
Authorization: Digest username="client4", realm="asterisk",
nonce="09f75e47", uri="sip:mysip.fr",
response="826fcff4c6e84ee45fbfa52c351e6316", algorithm=MD5
Max-Forwards: 70
User-Agent: Linphone/3.4.0 (eXosip2/unknown)
Expires: 3600
Figure 3: Example of REGISTER messager
The external IP address and port(s) instantiated for media streams, are used to build the SDP offer/answer. In particular, the "c" line and "m" lines.
PCP allows to discover and to set the lifetime of mapping instantiated in intermediate middleboxes.
The discovery of the lifetime of a mapping avoids overloading the network and SIP servers with frequent messages. This is in particular important for cellular devices. According to [Power], the consumption of a cellular device with a keep-alive interval equal to 20 seconds (that is the default value in [RFC3948] for example) is 29 mA (2G)/34 mA (3G). This consumption is reduced to 16 mA (2G)/24 mA (3G) when the interval is increased to 40 seconds, to 9.1 mA (2G)/16 mA (3G) if the interval is equal to 150 seconds, and to 7.3 mA (2G)/14 mA (3G) if the interval is equal to 180 seconds. When no keep-alive is issued, the consumption would be 5.2 mA (2G)/6.1 mA (3G). The impact of keepalive messages would be more severe if multiple applications are issuing those messages (e.g., SIP, IPsec, etc.).
As a consequence of instantiating mappings for media/session flows, incoming packets can be successfully forwarded to the appropriate SIP UA. Particularly, unidirectional media flows (e.g., announcement server) will be forwarded accordingly.
For deployments relying on classic RTP/RTCP odd/even port numbers assignment scheme, PORT_SET option [I-D.ietf-pcp-port-set] can be used by a SIP UA to request port parity be preserved by the PCP server.
An example is depicted in Figure 4.
For deployments assuming RTCP port number can be deduced from the RTP port number, PORT_SET option [I-D.ietf-pcp-port-set] can be used by a SIP UA to retrieve a pair of contiguous ports from the PCP server.
A flow example is shown in Figure 4.
+---------+ +-------+ +------------+
| SIP UA | | NAT | | IPv4 SIP |
| PCP | |+ PCP | |Proxy Server|
| Client | |Server | | "Mysip.fr" |
+---------+ +-------+ +------------+
| (a) PCP MAP | |
|Suggested External IP@ | |
| ::ffff:192.0.2.1| |
|Suggested External Port| |
| 6000| |
| PORT_SET: | |
| "P" bit set to 1 | |
| Port Set Size=2 | |
|======================>| |
| (b) PCP MAP | |
|Assigned External IP@ | |
| ::ffff:192.0.2.1| |
|Assigned External Port | |
| 7076| |
| PORT_SET: | |
| "P" bit set to 1 | |
| Port Set Size=2 | |
|<======================| |
| | |
Figure 4: Retrieve a pair of ports that preserves port parity
If the SIP UA is located behind a NAT64 device [RFC6146], the option defined in [RFC7225] can be used to retrieve the PREFIX64 used by that NAT64 device.
The retrieved prefix will be used to locally build an IPv6-converted IPv4 address ([RFC6052]) corresponding to the IPv4 address included in the SDP message received from a remote IPv4-enabled SIP UA; the SDP message can be an SDP offer or an answer.
+---------+ +-----+ +------------+ +---------+
|IPv6-only| |NAT64| | IPv4 SIP | |IPv4-only|
| SIP UA | | | |Proxy Server| | SIP UA |
+---------+ +-----+ +------------+ +---------+
| (a) PCP MAP Request | | |
|Suggested External IP@ | | |
| ::ffff:192.0.2.1| | |
|Suggested External Port| | |
| 6000| | |
| PORT_SET | | |
| PREFIX64 | | |
|======================>| | |
| (b) PCP MAP Response | | |
|Assigned External IP@ | | |
| ::ffff:192.0.2.1| | |
|Assigned External Port | | |
| 7076| | |
| PORT_SET | | |
| PREFIX64: | | |
| 2001:db8:122::/48 | | |
|<======================| | |
| (1) SIP INVITE | (2) SIP INVITE | (3) SIP INVITE |
|======================>|===============>|================>|
| (6) SIP 200 OK | (5) SIP 200 OK | (4) SIP 200 OK |
|<======================|<===============|<================|
| (7) SIP ACK | (8) SIP ACK | (9) SIP ACK |
|======================>|===============>|================>|
| | | |
|src port: dst port:|src port: dst port:|
|6000 port_B|7076 port_B|
|<======IPv6 RTP=======>|<============IPv4 RTP============>|
|<===== IPv6 RTCP======>|<============IPv4 RTCP===========>|
|src port: dst port:|src port: dst port:|
|6001 port_B+1|7077 port_B+1|
| | |
Figure 5: Example of IPv6 to IPv4 SIP-Initiated Session
Figure 6 shows the content of the SIP INVITE message sent by the IPv6-only SIP UA. This message uses the retrieved external IP address and external port numbers in SIP headers and SDP lines. This message is translated by the NAT64 without altering the SIP/SDP content.
INVITE sip:13@mysip.fr:5070 SIP/2.0 Via: SIP/2.0/UDP 192.0.2.1:56252;branch=z9hG4bK1876803184 From: <sip:client4@mysip.fr:5070>;tag=631384602 To: <sip:13@mysip.fr:5070> Call-ID: 1377792765 CSeq: 21 INVITE Contact: <sip:client4@192.0.2.1:56252> Authorization: Digest username="client4", realm="asterisk", nonce="3358d80b", uri="sip:13@mysip.fr:5070", response="41442e94f6610e6f383a355a1bdf3e48", algorithm=MD5 Content-Type: application/sdp Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO Max-Forwards: 70 User-Agent: Linphone/3.4.0 (eXosip2/unknown) Subject: Phone call Content-Length: 443 v=0 o=client4 2487 2487 IN IP4 192.0.2.1 s=Talk c=IN IP4 192.0.2.1 b=AS:256 t=0 0 m=audio 7076 RTP/AVP 111 110 3 101 a=rtpmap:111 speex/16000 a=fmtp:111 vbr=on a=rtpmap:110 speex/8000 a=fmtp:110 vbr=on a=rtpmap:3 GSM/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-11 m=video 9076 RTP/AVP 102 99 a=rtpmap:102 H264/90000 a=fmtp:102 profile-level-id=428014 a=rtpmap:99 MP4V-ES/90000 a=fmtp:99 profile-level-id=3
Figure 6: Content of the INVITE message
The base PCP specification can be used to retrieve the port number to be singled if "a=rtcp" attribute is in use [RFC3550].
PCP can be used to discover the DSCP value to be used when sending real-time flows or to create a mapping that matches a DSCP marking. This can be achieved using the DSCP option defined in [I-D.boucadair-pcp-extensions]. DSCP setting value is configured by the network and not the SIP UA.
This feature can be used as an input for DSCP marking in some deployments such as [I-D.ietf-tsvwg-rtcweb-qos].
Because an IPv6-only SIP UA is not aware of the connectivity capabilities of the remote UA, the IPv6-only SIP UA uses the ALTC attribute [RFC6947] to signal the assigned IPv6 address and the IPv4 address learned via PCP.
If the remote SIP UA is IPv6-enabled, IPv6 transfer capabilities will be used to place the session. If the remote SIP UA is IPv4-only, IPv4 transfer capabilities will be used. NAT64 devices will be crossed only if the remote UA is IPv4-only.
Figure 7 provides an except of a SIP INVITE message that encloses both the local IPv6 address and the IPv4 address/port number assigned by a NAT64 device.
INVITE sip:13@mysip.fr:5070 SIP/2.0
Via: SIP/2.0/UDP 192.0.2.1:35011;branch=z9hG4bK702695557
From: <sip:client4@mysip.fr:5070>;tag=641336337
To: <sip:13@mysip.fr:5070>
Call-ID: 1532307201
CSeq: 20 INVITE
Contact: <sip:client4@192.0.2.1:35011>
Content-Type: application/sdp
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY,
MESSAGE, SUBSCRIBE, INFO
Max-Forwards: 70
User-Agent: Linphone/3.4.0 (eXosip2/unknown)
Subject: Phone call
Content-Length: 538
v=0
o=client4 3867 3867 IN IP4 192.0.2.1
s=Talk
c=IN IP4 192.0.2.1
b=AS:256
t=0 0
m=audio 7056 RTP/AVP 111 110 3 101
a=altc:1 IP6 2001:db8:1f94:3000:6c73:ea54:cef:2730 45678
a=altc:2 IP4 192.0.2.1 7056
Figure 7: Content of the INVITE message (with ALTC Attribute)
SIP UAs co-located with the B4 [RFC6333] or located behind the CPE can behave as dual-stack UAs:
To avoid unnecessary invocation of AFTR resources, ALTC attribute is used to signal both IPv4 and IPv6 addresses. If the remote SIP UA is IPv6-enabled, IPv6 transfer capabilities will be used to place the session (i.e., the flows will avoid crossing the DS-Lite AFTR device). If the remote SIP UA is IPv4-only, IPv4 transfer capabilities will be used. AFTR devices will be crossed only if the remote UA is IPv4-only.
PCP-related security considerations are discussed in [RFC6887].
An attacker that wants to intercept media flows, without requiring intercepting SIP signalling message, can insert a fake PCP server that will influence the content of SIP messages so that an illegitimate node is inserted in the media path. Such behavior is not desirable. Means to prevent the PCP client from discovering illegitimate PCP servers must be enforced. Within the context of this document, the network on which the PCP messages are to be sent is fully trusted. For example, access control lists (ACLs) can be installed on the PCP client, PCP server, and the network between them, so those ACLs allow only communications from a trusted PCP client to the PCP server.
This document does not require any action from IANA.
Many thanks for T. Reddy, S. Kiesel, and R. Parthasarathi for their review.
| [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. |
| [RFC3581] | Rosenberg, J. and H. Schulzrinne, "An Extension to the Session Initiation Protocol (SIP) for Symmetric Response Routing", RFC 3581, August 2003. |
| [RFC6887] | Wing, D., Cheshire, S., Boucadair, M., Penno, R. and P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, April 2013. |