One document matched: draft-reddy-pcp-optimize-keepalives-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-reddy-pcp-optimize-keepalives-00"
ipr="trust200902">
<front>
<title abbrev="Optimize Keepalive with PCP">Optimizing NAT and Firewall
Keepalives Using Port Control Protocol (PCP)</title>
<author fullname="Tirumaleswar Reddy" initials="T." surname="Reddy">
<organization abbrev="Cisco">Cisco Systems, Inc.</organization>
<address>
<postal>
<street>Cessna Business Park, Varthur Hobli</street>
<street>Sarjapur Marathalli Outer Ring Road</street>
<city>Bangalore</city>
<region>Karnataka</region>
<code>560103</code>
<country>India</country>
</postal>
<email>tireddy@cisco.com</email>
</address>
</author>
<author fullname="Markus Isomaki" initials="M." surname="Isomaki">
<organization>Nokia</organization>
<address>
<postal>
<street>Keilalahdentie 2-4</street>
<city>FI-02150 Espoo</city>
<country>Finland</country>
</postal>
<email>markus.isomaki@nokia.com</email>
</address>
</author>
<author fullname="Dan Wing" initials="D." surname="Wing">
<organization abbrev="Cisco">Cisco Systems, Inc.</organization>
<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>California</region>
<code>95134</code>
<country>USA</country>
</postal>
<email>dwing@cisco.com</email>
</address>
</author>
<author fullname="Prashanth Patil" initials="P." surname="Patil">
<organization abbrev="Cisco">Cisco Systems, Inc.</organization>
<address>
<postal>
<street>Cessna Business Park, Varthur Hobli</street>
<street>Sarjapur Marthalli Outer Ring Road</street>
<city>Bangalore</city>
<region>Karnataka</region>
<code>560103</code>
<country>India</country>
</postal>
<email>praspati@cisco.com</email>
</address>
</author>
<date />
<workgroup>PCP</workgroup>
<abstract>
<t>This document describes how Port Control Protocol is useful to reduce
NAT and firewall keepalive messages for a variety of applications.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>Many types of applications need to keep their Network Address
Translator (NAT) and Firewall (FW) mappings alive for long periods of
time, even when they are otherwise not sending or receiving any traffic.
This is typically done by sending periodic keep-alive messages just to
prevent the mappings from expiring. As NAT/FW mapping timers may be
short and unknown to the endpoint, the frequency of these keep-alives
may be high. An IPv4 or IPv6 host can use the Port Control Protocol
(PCP)<xref target="I-D.ietf-pcp-base"></xref> to flexibly manage the IP
address and port mapping information on NATs and FWs to facilitate
communications with remote hosts. This document describes how PCP can be
used to reduce keep-alive messages for both client-server and
peer-to-peer type of communication.</t>
<t>The mechanism described in this document is especially useful in
cellular mobile networks, where frequent keep-alive messages make the
radio transition between active and power-save states causing signaling
congestion. The excessive time spent on the active state due to
keep-alives also greatly reduces the battery life of the cellular
connected devices such as smartphones or tablets.</t>
</section>
<section anchor="notation" title="Notational 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 <xref
target="RFC2119"></xref>.</t>
<t>This note uses terminology defined in <xref target="RFC5245"></xref>
and <xref target="I-D.ietf-pcp-base"></xref> .</t>
</section>
<section title="Overview of Operation">
<section title="Application Scenarios">
<t>PCP can help both client-server and peer-to-peer applications to
reduce their keep-alive rate. The relevant applications are the ones
that need to keep their NAT/FW mappings alive for long periods of
time, for instance to be able to send or receive application messages
to both directions at any time.</t>
<t>A typical client-server scenario is described in <xref
target="figure1"></xref>. A client, who may reside behind one or
multiple layers of NATs/FWs, opens a connection to a globally
reachable server, and keeps it open to be able to receive messages
from the server at any time. The connection may be a real transport
connection using TCP or SCTP, or just an flow of UDP packets.
Protocols operating in this manner include Session Initiation Protocol
(SIP), Extensible Messaging and Presence Protocol (XMPP), Internet
Mail Application Protocol (IMAP) with its IDLE command, the WebSocket
protocol and the various HTTP long-polling protocols. There are also a
number of proprietary instant messaging, Voice over IP, e-mail and
notification delivery protocols that belong in this category. All of
these protocols aim to keep the client-server connection alive for as
long as the application is running. When the application has otherwise
no traffic to send, specific keep-alive messages are sent periodically
to ensure that the NAT/FW state in the middle does not expire. Instead
of application keep-alives, the client can use PCP to keep up the
required mapping at the NAT/FW.</t>
<t><figure anchor="figure1"
title="PCP with Client-Server applications">
<artwork><![CDATA[
PCP PCP
Client Server __________
+-----------+ +------+ / \ +-----------+
|Application|___| NAT/ |____| Internet |___|Application|
| Client | | FW | | | | Server |
+-----------+ +------+ \__________/ +-----------+
(multiple
layers)
------------> PCP
----------------------------------------->
Application keep-alive
]]></artwork>
</figure></t>
<t>There are also scenarios where the long-term communication
association is between two peers, both of whom may reside behind a
(layers of) NAT/FW. This is depicted in <xref
target="figure2"></xref>. The initiation of the association may have
happened using mechanisms such as Interactive Communications
Establishment (ICE), perhaps first triggered by a "signaling" protocol
such as SIP or XMPP or RTCWeb. Examples of the peer-to-peer protocols
include RTP and RTCWeb data channel. A number of proprietary VoIP or
video call or streaming or file transfer protocols also exist in this
category. Typically the communication is based on UDP, but TCP or SCTP
may be used. Unless there is no traffic flowing otherwise, the peers
have to inject periodic keep-alive packets to keep the NAT/FW mappings
on both sides of the communication active. Instead of application
keep-alives, both peers can use PCP to control the mappings on the
NAT/FWs in front of them.</t>
<t><figure anchor="figure2" title="PCP with Peer-to-Peer applications">
<artwork><![CDATA[
PCP PCP PCP PCP
Client Server __________ Server Client
+-----------+ +------+ / \ +------+ +-----------+
|Application|___| NAT/ |____| Internet |___| NAT/ |___|Application|
| Peer | | FW | | | | FW | | Peer |
+-----------+ +------+ \__________/ +------+ +-----------+
(multiple (multiple
layers) layers)
------------> PCP PCP <------------
<--------------------------------------------------->
Application keep-alive
]]></artwork>
</figure></t>
</section>
<section title="NAT and Firewall Topologies and Detection">
<t>Before an application can reduce its keep-alive rate, it has to
make sure it has all of the NATs and Firewalls on its path under
control. This means it has to detect the presence of any PCP-unaware
NATs and Firewalls on its path. PCP itself is able to detect
unexpected NATs between the PCP client and server as depicted in <xref
target="figure3"></xref>. The PCP client includes its own IP address
and UDP port within the PCP request. The PCP server compares them to
the source IP address and UDP port it sees on the packet. If they are
differ, there are one or more additional NATs between the PCP client
and server, and the server will return an error. Unless the
application has some other means to control these PCP unaware NATs, it
has to fall back to its default keep-alive mechanism.</t>
<t><figure anchor="figure3"
title="PCP unaware NAT between PCP client and server">
<artwork><![CDATA[
PCP PCP PCP
Client Unaware Aware __________
+-----------+ +------+ +------+ / \ +-----------+
|Application|___| NAT |___| NAT/ |____| Internet |___|Application|
| Client | | | | FW | | | | Server |
+-----------+ +------+ +------+ \__________/ +-----------+
<-----------///---------->
PCP based detection
]]></artwork>
</figure></t>
<t><xref target="figure4"></xref> shows a topology where one or more
PCP unaware NATs are deployed on the exterior of the PCP capable
NAT/FWs. To detect this, the application must have the capability to
request from its server or peer what IP and transport address it sees.
If those differ from the IP and transport address given to the
application by the out most PCP aware NAT/FW, the application can
detect that there is at least one more PCP unaware NAT on the path. In
this case, the application has to fall back to its default keep-alive
mechanism.</t>
<t><figure anchor="figure4"
title="PCP unaware NAT external to the last PCP aware NAT">
<artwork><![CDATA[
PCP PCP PCP
Client Aware Unaware __________
+-----------+ +------+ +------+ / \ +-----------+
|Application|___| NAT/ |___| NAT |____| Internet |___|Application|
| Client | | FW | | | | | | Server |
+-----------+ +------+ +------+ \__________/ +-----------+
<------------>
PCP
<---------------------///--------------------------->
Application based detection
]]></artwork>
</figure></t>
<t><xref target="apps"></xref> describes how the detection works in a
number of real application protocols.</t>
<t>The caveat is that Firewalls can not be detected this way.</t>
</section>
<section anchor="optimize" title="Keepalive Optimization">
<t>If the application determines that all NATs and Firewalls on its
path support PCP, it can start using PCP instead of its default
keep-alives to maintain the NAT/FW state. It can use PCP PEER Request
with Requested Lifetime set to appropriate value. The application may
still send some application specific heartbeat messages
end-to-end.</t>
</section>
</section>
<section anchor="apps" title="Application-Specific Operation">
<t>This section describes how PCP is used with specific application
protocols.</t>
<section title="SIP">
<t>For connection-less transports the User Agent (UA) sends STUN
Binding Request over the SIP flow as described in section 4.4.2 of
<xref target="RFC5626"></xref>. The UA then learns External IP Address
and Port using PEER request/response. If the XOR-MAPPED-ADDRESS in the
STUN Binding Response matches the external address and port provided
by PCP PEER response then the UA optimizes the keepalive traffic as
described in <xref target="optimize"></xref>. There is no further need
to send STUN Binding Requests over the SIP flow to keep the NAT
binding alive.</t>
<t>If the XOR-MAPPED-ADDRESS in the STUN Binding Response does not
match the external address and port provided by PCP PEER response then
PCP will not be used to keep the NAT bindings alive for the flow that
is being used for the SIP traffic. This means that multiple layers of
NAT are involved and intermediate NATs are not PCP aware. In this case
UA will continue to use the technique in section 4.4.2 of <xref
target="RFC5626"></xref>.</t>
<t>For connection-oriented transport, the UA sends STUN Binding
Request multiplexed with SIP over the TCP connection. STUN multiplexed
with other data over a TCP or TLS-over-TCP connection is explained in
section 7.2.2 of <xref target="RFC5389"></xref>. UA then learns the
External IP address and port using PEER request/response. If the
XOR-MAPPED-ADDRESS in the STUN Binding Response matches the external
address and port provided by PCP PEER response then the UA optimizes
the keepalive traffic as described in <xref
target="optimize"></xref>.</t>
<t>If the XOR-MAPPED-ADDRESS in the STUN Binding Response does not
match the external address and port provided by PCP PEER response then
PCP will not be used to keep the NAT bindings alive. In this case UA
performs keep-alive check by sending a double-CRLF (the "ping") then
waits to receive a single CRLF (the "pong") using the technique in
section 4.4.1 of <xref target="RFC5626"></xref>.</t>
</section>
<section title="HTTP">
<t>Web Applications that require persistent connections use techniques
such as HTTP long polling and Websockets for session keep alive as
explained in section 3.1 of <xref
target="I-D.isomaki-rtcweb-mobile"></xref>. In such scenarios, after
the client establishes a connection with the HTTP server, it can
execute server side scripts such as PHP residing on the server to
provide the transport address and port of the HTTP client seen at the
HTTP server. In addition, the HTTP client also learns the external IP
Address and port using PCP PEER request/response.</t>
<t>If the IP address and port learned from the server matches the
external address and port provided by PCP PEER response then the HTTP
client optimizes keepalive traffic as described in <xref
target="optimize"></xref>.</t>
<t>If the IP address and port do not match then PCP will not be used
to keep the NAT bindings alive for the flow that is being used for the
HTTP traffic. This means that there are NATs between the PCP server
and the HTTP server. The HTTP client will have to resort to use
existing techniques for keep alive.</t>
<t>Please see <xref target="example"></xref> for an example server
side PHP script to obtain client source IP address.</t>
</section>
<section title="Media and data channels with ICE">
<t>ICE agent learns the External IP Address and Port using MAP
request/response. This candidate learnt through PCP is encoded in the
ICE offer and answer just like the server reflexive candidate, If the
server reflexive candidate and External IP address learnt using PCP
are different. When using the Recommended Formula in section 4.1.2.1
of <xref target="RFC5245"></xref> to compute priority for the
candidates learnt through PCP, ICE agent can use preference value
greater than or equal to the server reflexive candidates.</t>
<t>The ICE agent in addition to ICE connectivity checks and performs
the following :</t>
<t>The ICE agent checks if the XOR-MAPPED-ADDRESS from the STUN <xref
target="RFC5389"></xref> Binding response received as part of ICE
connectivity check matches the external address and port provided by
PCP MAP response.</t>
<t><list style="numbers">
<t>If the match is successful then PCP will be used to keep the
NAT bindings alive. The ICE agent optimizes keepalive traffic by
refreshing the mapping via new PCP MAP request containing
information from the earlier PCP response.</t>
<t>If the match is not successful then PCP will not be used for
keep NAT binding alive. ICE agent will use technique in section
4..4 of <xref target="RFC6263"></xref> to keep NAT bindings alive.
This means that multiple layers of NAT are involved and
intermediate NATs are not PCP aware.</t>
</list></t>
<t>Some network operators deploying a PCP Server may allow PEER but
not MAP. In such cases the ICE agent learns the external IP address
and port using STUN binding request/response during ICE connectivity
checks. The ICE agent also learns the external IP Address and port
using PCP PEER request/response. If the IP address and port learned
from STUN binding response matches the external address and port
provided by PCP PEER response then the ICE agent optimizes keepalive
traffic as described in <xref target="optimize"></xref>.</t>
</section>
<section title="Detecting Flow Failure">
<t>Using the Rapid Recovery technique in section 14 of <xref
target="I-D.ietf-pcp-base"></xref> PCP client upon receiving PCP
ANNOUNCE from NAT device becomes aware that NAT has rebooted or lost
its mapping state. PCP client issues new PCP requests to recreate any
lost mapping state and thus reconstruct lost mapping fast enough that
existing media, HTTP and SIP flows do not break. If the NAT state
cannot be recovered the endpoint will find the new external address
and port as part of Rapid Recovery technique in PCP itself and
reestablish connection with the peer.</t>
<t>In lieu of this mechanism if NAT reboots and loses its mapping
state or when a NAT gateway has its external IP address changed so
that its current mapping state becomes invalid, it may take several
seconds before the endpoints realize that the connectivity is
lost.</t>
</section>
<section title="Firewall">
<t>PCP allows applications to communicate with Firewall devices with
PCP functionality to create mappings for incoming connections. In such
cases PCP can be used by the endpoint to create explicit mapping on
Firewall to permit inbound traffic and further use PCP to avoid
sending keep-alives to keep the Firewall mappings alive.</t>
<section title="IPv6 Network with Firewalls">
<t>As part of the call setup, the endpoint would gather its host
candidates and relayed candidate from a TURN server, send the
candidates in the offer to the peer endpoint. On receiving the
answer from the peer endpoint, PCP client sends PCP MAP request to
create dynamic mapping in Firewall to permit ICE connectivity checks
and subsequent media traffic from remote peer.</t>
</section>
<section title="Mobile Network with Firewalls">
<t>Mobile Networks are also making use of a Firewall to protect
their customers from various attacks like downloading malicious
content. The Firewall is usually configured to block all unknown
inbound connections as explained in section 2.1 of <xref
target="I-D.chen-pcp-mobile-deployment"></xref> . In such cases PCP
can be used by Mobile devices to create explicit mapping on Firewall
to permit inbound traffic and optimize the keepalive traffic as
described in <xref target="optimize"></xref>. This would result in
saving of radio and power consumption of the Mobile device while
protecting it from attacks.</t>
</section>
</section>
</section>
<section title="IANA Considerations">
<t>None</t>
</section>
<section title="Security Considerations">
<t>Security considerations in <xref target="RFC5245"></xref><xref
target="I-D.ietf-pcp-base"> and </xref> apply to this use.</t>
</section>
<section anchor="ack" title="Acknowledgements">
<t>The authors would like to thank Basavaraj Patil for valuable input to
the document.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"
?>
<?rfc include="reference.RFC.5245"?>
<?rfc include="reference.RFC.5389"?>
<?rfc include='reference.I-D.ietf-pcp-base'?>
<?rfc include="reference.RFC.6263"?>
<?rfc include="reference.RFC.5626"?>
</references>
<references title="Informative References">
<?rfc ?>
<?rfc include='reference.I-D.chen-pcp-mobile-deployment'
?>
<?rfc include='reference.I-D.isomaki-rtcweb-mobile'?>
<!---->
</references>
<section anchor="example" title="Example PHP script">
<figure>
<artwork><![CDATA[<html>
Connected to <?PHP echo gethostname(); ?> on port <?PHP echo
getenv(SERVER_PORT) ?> on <?PHP echo date("d-M-Y H:i:s"); ?> Pacific Time
<p>
Your IP address is: <?PHP echo getenv(REMOTE_ADDR); ?>,
port <?PHP echo getenv(REMOTE_PORT); ?>
<?PHP if (getenv(SERVER_PORT) == 80) {
??echo "<p>Click <a href=\"http://";
??echo getenv(SERVER_NAME);
??echo ":81\">here</a> to also obtain information when connecting to port
81.</p>";
??}
?>]]></artwork>
</figure>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 10:04:37 |