One document matched: draft-reddy-pcp-optimize-keepalives-00.txt
PCP T. Reddy
Internet-Draft Cisco
Intended status: Standards Track M. Isomaki
Expires: March 20, 2013 Nokia
D. Wing
P. Patil
Cisco
September 16, 2012
Optimizing NAT and Firewall Keepalives Using Port Control Protocol (PCP)
draft-reddy-pcp-optimize-keepalives-00
Abstract
This document describes how Port Control Protocol is useful to reduce
NAT and firewall keepalive messages for a variety of applications.
Status of this Memo
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 March 20, 2013.
Copyright Notice
Copyright (c) 2012 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
Reddy, et al. Expires March 20, 2013 [Page 1]
Internet-Draft Optimize Keepalive with PCP September 2012
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3
3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 3
3.1. Application Scenarios . . . . . . . . . . . . . . . . . . 3
3.2. NAT and Firewall Topologies and Detection . . . . . . . . 5
3.3. Keepalive Optimization . . . . . . . . . . . . . . . . . . 6
4. Application-Specific Operation . . . . . . . . . . . . . . . . 6
4.1. SIP . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.2. HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.3. Media and data channels with ICE . . . . . . . . . . . . . 8
4.4. Detecting Flow Failure . . . . . . . . . . . . . . . . . . 9
4.5. Firewall . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.5.1. IPv6 Network with Firewalls . . . . . . . . . . . . . 9
4.5.2. Mobile Network with Firewalls . . . . . . . . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . . 11
Appendix A. Example PHP script . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Reddy, et al. Expires March 20, 2013 [Page 2]
Internet-Draft Optimize Keepalive with PCP September 2012
1. Introduction
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)[I-D.ietf-pcp-base] 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.
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.
2. Notational Conventions
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 [RFC2119].
This note uses terminology defined in [RFC5245] and
[I-D.ietf-pcp-base] .
3. Overview of Operation
3.1. Application Scenarios
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.
A typical client-server scenario is described in Figure 1. 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
Reddy, et al. Expires March 20, 2013 [Page 3]
Internet-Draft Optimize Keepalive with PCP September 2012
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.
PCP PCP
Client Server __________
+-----------+ +------+ / \ +-----------+
|Application|___| NAT/ |____| Internet |___|Application|
| Client | | FW | | | | Server |
+-----------+ +------+ \__________/ +-----------+
(multiple
layers)
------------> PCP
----------------------------------------->
Application keep-alive
Figure 1: PCP with Client-Server applications
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 Figure 2. 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.
Reddy, et al. Expires March 20, 2013 [Page 4]
Internet-Draft Optimize Keepalive with PCP September 2012
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
Figure 2: PCP with Peer-to-Peer applications
3.2. NAT and Firewall Topologies and Detection
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 Figure 3. 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.
PCP PCP PCP
Client Unaware Aware __________
+-----------+ +------+ +------+ / \ +-----------+
|Application|___| NAT |___| NAT/ |____| Internet |___|Application|
| Client | | | | FW | | | | Server |
+-----------+ +------+ +------+ \__________/ +-----------+
<-----------///---------->
PCP based detection
Figure 3: PCP unaware NAT between PCP client and server
Reddy, et al. Expires March 20, 2013 [Page 5]
Internet-Draft Optimize Keepalive with PCP September 2012
Figure 4 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.
PCP PCP PCP
Client Aware Unaware __________
+-----------+ +------+ +------+ / \ +-----------+
|Application|___| NAT/ |___| NAT |____| Internet |___|Application|
| Client | | FW | | | | | | Server |
+-----------+ +------+ +------+ \__________/ +-----------+
<------------>
PCP
<---------------------///--------------------------->
Application based detection
Figure 4: PCP unaware NAT external to the last PCP aware NAT
Section 4 describes how the detection works in a number of real
application protocols.
The caveat is that Firewalls can not be detected this way.
3.3. Keepalive Optimization
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.
4. Application-Specific Operation
This section describes how PCP is used with specific application
protocols.
Reddy, et al. Expires March 20, 2013 [Page 6]
Internet-Draft Optimize Keepalive with PCP September 2012
4.1. SIP
For connection-less transports the User Agent (UA) sends STUN Binding
Request over the SIP flow as described in section 4.4.2 of [RFC5626].
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
Section 3.3. There is no further need to send STUN Binding Requests
over the SIP flow to keep the NAT binding alive.
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
[RFC5626].
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 [RFC5389]. 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 Section 3.3.
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 [RFC5626].
4.2. HTTP
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 [I-D.isomaki-rtcweb-mobile]. 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.
If the IP address and port learned from the server matches the
Reddy, et al. Expires March 20, 2013 [Page 7]
Internet-Draft Optimize Keepalive with PCP September 2012
external address and port provided by PCP PEER response then the HTTP
client optimizes keepalive traffic as described in Section 3.3.
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.
Please see Appendix A for an example server side PHP script to obtain
client source IP address.
4.3. Media and data channels with ICE
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 [RFC5245] to compute priority for the candidates learnt through
PCP, ICE agent can use preference value greater than or equal to the
server reflexive candidates.
The ICE agent in addition to ICE connectivity checks and performs the
following :
The ICE agent checks if the XOR-MAPPED-ADDRESS from the STUN
[RFC5389] Binding response received as part of ICE connectivity check
matches the external address and port provided by PCP MAP response.
1. 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.
2. 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 [RFC6263] to keep NAT bindings alive. This means that
multiple layers of NAT are involved and intermediate NATs are not
PCP aware.
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
Reddy, et al. Expires March 20, 2013 [Page 8]
Internet-Draft Optimize Keepalive with PCP September 2012
traffic as described in Section 3.3.
4.4. Detecting Flow Failure
Using the Rapid Recovery technique in section 14 of
[I-D.ietf-pcp-base] 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.
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.
4.5. Firewall
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.
4.5.1. IPv6 Network with Firewalls
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.
4.5.2. Mobile Network with Firewalls
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
[I-D.chen-pcp-mobile-deployment] . 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
Section 3.3. This would result in saving of radio and power
consumption of the Mobile device while protecting it from attacks.
Reddy, et al. Expires March 20, 2013 [Page 9]
Internet-Draft Optimize Keepalive with PCP September 2012
5. IANA Considerations
None
6. Security Considerations
Security considerations in [RFC5245]and [I-D.ietf-pcp-base] apply to
this use.
7. Acknowledgements
The authors would like to thank Basavaraj Patil for valuable input to
the document.
8. References
8.1. Normative References
[I-D.ietf-pcp-base]
Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P.
Selkirk, "Port Control Protocol (PCP)",
draft-ietf-pcp-base-26 (work in progress), June 2012.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245,
April 2010.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389,
October 2008.
[RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client-
Initiated Connections in the Session Initiation Protocol
(SIP)", RFC 5626, October 2009.
[RFC6263] Marjou, X. and A. Sollaud, "Application Mechanism for
Keeping Alive the NAT Mappings Associated with RTP / RTP
Control Protocol (RTCP) Flows", RFC 6263, June 2011.
Reddy, et al. Expires March 20, 2013 [Page 10]
Internet-Draft Optimize Keepalive with PCP September 2012
8.2. Informative References
[I-D.chen-pcp-mobile-deployment]
Chen, G., Cao, Z., Boucadair, M., Ales, V., and L.
Thiebaut, "Analysis of Port Control Protocol in Mobile
Network", draft-chen-pcp-mobile-deployment-01 (work in
progress), July 2012.
[I-D.isomaki-rtcweb-mobile]
Isomaki, M., "RTCweb Considerations for Mobile Devices",
draft-isomaki-rtcweb-mobile-00 (work in progress),
July 2012.
Appendix A. Example PHP script
<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>";
??}
?>
Authors' Addresses
Tirumaleswar Reddy
Cisco Systems, Inc.
Cessna Business Park, Varthur Hobli
Sarjapur Marathalli Outer Ring Road
Bangalore, Karnataka 560103
India
Email: tireddy@cisco.com
Reddy, et al. Expires March 20, 2013 [Page 11]
Internet-Draft Optimize Keepalive with PCP September 2012
Markus Isomaki
Nokia
Keilalahdentie 2-4
FI-02150 Espoo
Finland
Email: markus.isomaki@nokia.com
Dan Wing
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, California 95134
USA
Email: dwing@cisco.com
Prashanth Patil
Cisco Systems, Inc.
Cessna Business Park, Varthur Hobli
Sarjapur Marthalli Outer Ring Road
Bangalore, Karnataka 560103
India
Email: praspati@cisco.com
Reddy, et al. Expires March 20, 2013 [Page 12]
| PAFTECH AB 2003-2026 | 2026-04-24 09:03:02 |