idnits 2.17.1 draft-ietf-pcp-optimize-keepalives-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 8 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 18, 2015) is 3266 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 5245 (Obsoleted by RFC 8445, RFC 8839) ** Obsolete normative reference: RFC 5389 (Obsoleted by RFC 8489) ** Downref: Normative reference to an Experimental RFC: RFC 5780 == Outdated reference: A later version (-19) exists of draft-ietf-rtcweb-overview-13 == Outdated reference: A later version (-24) exists of draft-ietf-v6ops-mobile-device-profile-21 -- Obsolete informational reference (is this intentional?): RFC 3921 (Obsoleted by RFC 6121) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCP T. Reddy 3 Internet-Draft P. Patil 4 Intended status: Standards Track Cisco 5 Expires: November 19, 2015 M. Isomaki 6 Nokia 7 D. Wing 8 Cisco 9 May 18, 2015 11 Optimizing NAT and Firewall Keepalives Using Port Control Protocol (PCP) 12 draft-ietf-pcp-optimize-keepalives-06 14 Abstract 16 This document describes how Port Control Protocol is useful in 17 reducing NAT and firewall keepalive messages for a variety of 18 applications. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on November 19, 2015. 37 Copyright Notice 39 Copyright (c) 2015 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Notational Conventions . . . . . . . . . . . . . . . . . . . 3 56 3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 3 57 3.1. Application Scenarios . . . . . . . . . . . . . . . . . . 3 58 3.2. NAT Topologies and Detection . . . . . . . . . . . . . . 5 59 3.2.1. PCP based detection . . . . . . . . . . . . . . . . . 5 60 3.2.2. Application based detection . . . . . . . . . . . . . 6 61 3.3. Detection of PCP unaware firewalls . . . . . . . . . . . 6 62 3.4. Keepalive Optimization . . . . . . . . . . . . . . . . . 7 63 4. Keepalive Interval Determination Procedure when PCP unaware 64 Firewall or NAT is detected . . . . . . . . . . . . . . . . . 8 65 5. Application-Specific Operation . . . . . . . . . . . . . . . 9 66 5.1. SIP . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 5.2. HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . 10 68 5.3. Media and data channels with ICE . . . . . . . . . . . . 11 69 5.4. Detecting Flow Failure . . . . . . . . . . . . . . . . . 11 70 5.5. Firewalls . . . . . . . . . . . . . . . . . . . . . . . . 12 71 5.5.1. IPv6 Network with Firewalls . . . . . . . . . . . . . 12 72 5.5.2. Mobile Network with Firewalls . . . . . . . . . . . . 12 73 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 74 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 75 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 76 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 77 9.1. Normative References . . . . . . . . . . . . . . . . . . 13 78 9.2. Informative References . . . . . . . . . . . . . . . . . 14 79 Appendix A. Example PHP script . . . . . . . . . . . . . . . . . 14 80 Appendix B. Savings with PCP . . . . . . . . . . . . . . . . . . 15 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 83 1. Introduction 85 Many types of applications need to keep their Network Address 86 Translator (NAT) and Firewall (FW) mappings alive for long periods of 87 time, even when they are otherwise not sending or receiving any 88 traffic. This is typically done by sending periodic keep-alive 89 messages just to prevent the mappings from expiring. As NAT/FW 90 mapping timers may be short and unknown to the endpoint, the 91 frequency of these keepalives may be high. An IPv4 or IPv6 host can 92 use the Port Control Protocol (PCP)[RFC6887] to flexibly manage the 93 IP address and port mapping information on NATs and Firewalls to 94 facilitate communications with remote hosts. This document describes 95 how PCP can be used to reduce keepalive messages for both client- 96 server and peer-to-peer type of communication. 98 The mechanism described in this document is especially useful in 99 cellular mobile networks, where frequent keepalive messages make the 100 radio transition between active and power-save states causing 101 congestion in the signaling path. The excessive time spent on the 102 active state due to keepalives also greatly reduces the battery life 103 of the cellular connected devices such as smartphones or tablets. 104 [I-D.ietf-v6ops-mobile-device-profile] recommends cellular hosts to 105 be PCP-compliant in order to save battery consumption exacerbated by 106 keepalive messages. 108 2. Notational Conventions 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in [RFC2119]. 114 This note uses terminology defined in [RFC5245] and [RFC6887]. 116 3. Overview of Operation 118 3.1. Application Scenarios 120 PCP can help both client-server and peer-to-peer applications to 121 reduce their keepalive rate. The relevant applications are the ones 122 that need to keep their NAT/FW mappings alive for long periods of 123 time, for instance to be able to send or receive application messages 124 in both directions at any time. 126 A typical client-server scenario is depicted in Figure 1. A client, 127 who may reside behind one or multiple layers of NATs/FWs, opens a 128 connection to a globally reachable server, and keeps it open to be 129 able to receive messages from the server at any time. The connection 130 may be a connection-oriented transport protocol such as TCP or SCTP 131 or connection-less transport protocol such as UDP. Protocols 132 operating in this manner include the Session Initiation Protocol 133 (SIP) [RFC3261], the Extensible Messaging and Presence Protocol 134 (XMPP) [RFC3921], the Internet Mail Application Protocol (IMAP) 135 [RFC2177] with its IDLE command, the WebSocket protocol [RFC6455] and 136 the various HTTP long-polling protocols. There are also a number of 137 proprietary instant messaging, Voice over IP, e-mail and notification 138 delivery protocols that belong in this category. All of these 139 protocols aim to keep the client-server connection alive for as long 140 as the application is running. When the application has otherwise no 141 traffic to send, specific keepalive messages are sent periodically to 142 ensure that the NAT/FW state in the middle does not expire. The 143 client can use PCP to keep the required mappings at the NAT/FWs and 144 use application keepalives to keep the state on the Application 145 Server/Peer as mentioned in Section 3.4. 147 PCP PCP 148 Client Server __________ 149 +-----------+ +------+ / \ +-----------+ 150 |Application|___| NAT/ |____| Internet |___|Application| 151 | Client | | FW | | | | Server | 152 +-----------+ +------+ \__________/ +-----------+ 153 (multiple 154 layers) 156 ------------> PCP 158 -----------------------------------------> 159 Application keepalive 161 Figure 1: PCP with Client-Server applications 163 There are also scenarios where the long-term communication 164 association is between two peers, both of whom may reside behind one 165 or more layers of NAT/FW. This is depicted in Figure 2. The 166 initiation of the association may have happened using mechanisms such 167 as Interactive Communications Establishment (ICE), perhaps first 168 triggered by a "signaling" protocol such as SIP or XMPP or WebRTC 169 [I-D.ietf-rtcweb-overview]. Examples of the peer-to-peer protocols 170 include RTP and WebRTC data channel. A number of proprietary VoIP or 171 video call or streaming or file transfer protocols also exist in this 172 category. Typically the communication is based on UDP, but TCP or 173 SCTP may be used. If there is no traffic flowing, the peers have to 174 inject periodic keepalive packets to keep the NAT/FW mappings on both 175 sides of the communication active. Instead of application 176 keepalives, both peers can use PCP to control the mappings on the 177 NAT/FWs to reduce the keepalive frequency as explained in 178 Section 3.4. 180 PCP PCP PCP PCP 181 Client Server __________ Server Client 182 +-----------+ +------+ / \ +------+ +-----------+ 183 |Application|___| NAT/ |____| Internet |___| NAT/ |___|Application| 184 | Peer | | FW | | | | FW | | Peer | 185 +-----------+ +------+ \__________/ +------+ +-----------+ 186 (multiple (multiple 187 layers) layers) 189 ------------> PCP PCP <------------ 191 <---------------------------------------------------> 192 Application keepalive 194 Figure 2: PCP with Peer-to-Peer applications 196 3.2. NAT Topologies and Detection 198 Before an application can reduce its keepalive rate, it has to make 199 sure it has all of the NATs and firewalls on its path under control. 200 This means it has to detect the presence of any PCP-unaware NATs and 201 firewalls on its path to the Internet. 203 3.2.1. PCP based detection 205 PCP itself is able to detect unexpected NATs between the PCP client 206 and PCP server as depicted in Figure 3. The PCP client includes its 207 own IP address and UDP port within the PCP request. The PCP server 208 compares them to the source IP address and UDP port it sees on the 209 packet. If they differ, there are one or more additional NATs 210 between the PCP client and PCP server, and the server will return an 211 error. Unless the application has some other means (like UPnP) to 212 control these PCP unaware NATs, it has to fall back to its default 213 keepalive mechanism. 215 PCP PCP PCP 216 Client Unaware Aware __________ 217 +-----------+ +------+ +------+ / \ +-----------+ 218 |Application|___| NAT |___| NAT/ |____| Internet |___|Application| 219 | Client | | | | FW | | | | Server | 220 +-----------+ +------+ +------+ \__________/ +-----------+ 222 <-----------///----------> 223 PCP based detection 225 Figure 3: PCP unaware NAT between PCP client and PCP server 227 3.2.2. Application based detection 229 Figure 4 shows a topology where one or more PCP unaware NATs are 230 deployed on the exterior of the PCP capable NAT/FWs. To detect this, 231 the application client must have the capability to request from its 232 application server or peer what IP and transport address it sees. If 233 those differ from the IP and transport address given by the PCP aware 234 NAT/FW then the application client can determine that there is at 235 least one PCP unaware NAT on the path. In this case, the application 236 client has to fall back to its default keepalive mechanism. 238 PCP PCP PCP 239 Client Aware Unaware __________ 240 +-----------+ +------+ +------+ / \ +-----------+ 241 |Application|___| NAT/ |___| NAT |____| Internet |___|Application| 242 | Client | | FW | | | | | | Server | 243 +-----------+ +------+ +------+ \__________/ +-----------+ 245 <------------> 246 PCP 248 <---------------------///---------------------------> 249 Application based detection 251 Figure 4: PCP unaware NAT external to the last PCP aware NAT 253 3.3. Detection of PCP unaware firewalls 255 PCP and application based detection mechanisms explained in 256 Section 3.2.1 and Section 3.2.2 are based on change in the address 257 and will not detect PCP unaware firewalls. In order to detect a PCP 258 unaware firewall, the application client sends a Session Traversal 259 Utilities for NAT (STUN) [RFC5389] Binding request to the STUN 260 server. If STUN server supports the STUN extensions defined in 261 [RFC5780] then it returns its alternate IP address and alternate port 262 in OTHER-ADDRESS attribute in the STUN Binding response. The client 263 then uses PCP to send MAP request with FILTER option to PCP server to 264 permit STUN server to reach the client using the STUN servers 265 alternate IP address and alternate port. The client then sends a 266 Binding request to the primary address of the STUN server with the 267 CHANGE-REQUEST attribute set to change-port and change-IP. This will 268 cause the server to send its response from its alternate IP address 269 and alternate port. If the client receives a response then the 270 client is aware that on path firewall devices are PCP aware. If the 271 client does not receive a response then the client is aware that 272 there could be one or more on path PCP unaware firewall devices. The 273 application client will perform the tests separately for each 274 transport protocol. If no response is received, the client will then 275 repeat the test at most three times for connectionless transport 276 protocols. 278 PCP PCP PCP 279 Client Aware Unaware __________ 280 +-----------+ +------+ +------+ / \ +-----------+ 281 |Application|___| NAT/ |___| FW |____| Internet |___| STUN | 282 | Client | | FW | | | | | | Server | 283 +-----------+ +------+ +------+ \__________/ +-----------+ 285 <---------------------------------------------------> 286 STUN 288 <------------> 289 PCP 290 X<--------------------------- 291 STUN based detection 293 Figure 5: PCP unaware firewall 295 This procedure can be adopted by other protocols to detect PCP 296 unaware firewalls. 298 3.4. Keepalive Optimization 300 If the application determines that all NATs and firewalls on its path 301 to the Internet support PCP, it can start using PCP instead of its 302 default keepalives to maintain the NAT/FW state. It can use PCP PEER 303 Request with the Requested Lifetime set to an appropriate value. The 304 application may still send some application-specific heartbeat 305 messages end-to-end to refresh state on the application server, which 306 typically requires keepalives far less frequently than NATs /FWs do. 308 Processing the lifetime value of the PEER Opcode is described in 309 Sections 10.3 and 15 of [RFC6887]. Sending a PEER request with a 310 very short Requested Lifetime can be used to query the lifetime of an 311 existing mapping. PCP recommends that lifetimes of mapping created 312 or lengthened with PEER be longer than the lifetimes of implicitly- 313 created NAT and firewall mappings. Thus PCP can be used to reduce 314 power consumption by making PCP PEER message interval longer than 315 what the application would normally use to the keep the middle box 316 state alive, and strictly shorter than the server state refresh 317 interval. 319 An example of savings with PCP is described in Appendix B. 321 4. Keepalive Interval Determination Procedure when PCP unaware Firewall 322 or NAT is detected 324 If a PCP unaware NAT/firewall is detected, then a client can use the 325 following heuristics method to determine the keepalive interval: 327 1. The client sends a STUN Binding request to the STUN server. This 328 connection is called the Primary Channel. STUN server will 329 return its alternate IP address and alternate port in OTHER- 330 ADDRESS in the Binding response [RFC5780]. 332 2. The client then sends a STUN Binding request to the STUN server 333 using alternate IP address and alternate port. This connection 334 is called the Secondary Channel. 336 3. The Client will initially set the default keepalive interval for 337 NAT/FW mappings to 60 seconds (FWa). 339 4. After FWa seconds the Client will send a Binding request to the 340 STUN server using the Primary Channel with the CHANGE-REQUEST 341 attribute set to change-port and change-IP. This will cause the 342 STUN server to send its response from the Secondary channel. 344 5. If the client receives response from the server then it will 345 increase the keepalive interval value FWa = (old FWa) + (old 346 FWa)/2. This indicates that NAT/FW mappings are alive. 348 6. Steps 4 and 5 will be repeated until there is no response from 349 the STUN server. If there is no response from the STUN server 350 then the client will use the old FWa value as Keepalive interval 351 to refresh FW/NAT mappings. 353 The above procedure will be done separately for each transport 354 protocol. For connectionless transport protocols such as UDP, if 2 355 seconds elapse without a response from the STUN server then the 356 client will repeat step 4 at most three times to handle packet loss. 358 This procedure can be adopted by other protocols to use Primary and 359 Secondary channels, so that the client can determine the keepalive 360 interval to refresh FW/NAT mapping. This procedure only serves as a 361 guideline and if applications already use some other heuristic to 362 determine the keepalive interval, they can continue with the existing 363 logic. For example Teredo determines the Refresh interval using the 364 procedure in "Optional Refresh Interval Determination Procedure" 365 (Section 5.2.7 of [RFC4380]). 367 Note: The keepalive interval learnt using the above method can be 368 inaccurate if a firewall is configured with an application-specific 369 inactivity timeout. 371 To improve reliability, applications SHOULD continue to use PCP to 372 lengthen the FW/NAT mappings even if the above mechanism is used to a 373 detect PCP unaware NAT/firewall. This ensures that PCP aware FW/NATs 374 do not close old mappings with no packet exchange when there is a 375 resource-scarcity situation. 377 5. Application-Specific Operation 379 This section describes how PCP is used with specific application 380 protocols. 382 5.1. SIP 384 For connection-less transports the User Agent (UA) sends a STUN 385 Binding request over the SIP flow as described in section 4.4.2 of 386 [RFC5626]. The UA then learns the External IP Address and Port using 387 a PCP PEER request/response. If the XOR-MAPPED-ADDRESS in the STUN 388 Binding response matches the external address and port provided by 389 PCP PEER response then the UA optimizes the keepalive traffic as 390 described in Section 3.4. There is no further need to send STUN 391 Binding requests over the SIP flow to keep the NAT Binding alive. 393 If the XOR-MAPPED-ADDRESS in the STUN Binding response does not match 394 the external address and port provided by the PCP PEER response then 395 PCP will not be used to keep the NAT bindings alive for the flow that 396 is being used for the SIP traffic. This means that multiple layers 397 of NAT are involved and intermediate NATs are not PCP aware. In this 398 case the UA will continue to use the technique in section 4.4.2 of 399 [RFC5626]. 401 For connection-oriented transports, the UA sends a STUN Binding 402 request multiplexed with SIP over the TCP connection. STUN 403 multiplexed with other data over a TCP or TLS-over-TCP connection is 404 explained in section 7.2.2 of [RFC5389]. The UA then learns the 405 External IP address and port using a PCP PEER request/response. If 406 the XOR-MAPPED-ADDRESS in the STUN Binding response matches the 407 external address and port provided by the PCP PEER response, then the 408 UA optimizes the keepalive traffic as described in Section 3.4. 410 If the XOR-MAPPED-ADDRESS in the STUN Binding response does not match 411 the external address and port provided by the PCP PEER response, then 412 PCP will not be used to keep the NAT bindings alive. In this case 413 the UA performs a keepalive check by sending a double-CRLF (the 414 "ping") then waits to receive a single CRLF (the "pong") using the 415 technique in section 4.4.1 of [RFC5626]. 417 5.2. HTTP 419 Web Applications that require persistent connections use techniques 420 such as HTTP long polling and Websockets for session keep alive as 421 explained in section 3.1 of [I-D.isomaki-rtcweb-mobile]. In such 422 scenarios, after the client establishes a connection with the HTTP 423 server, it can execute server side scripts such as PHP residing on 424 the server to provide the transport address and port of the HTTP 425 client seen at the HTTP server. In addition, the HTTP client also 426 learns the external IP Address and port using a PCP PEER request/ 427 response. 429 If the IP address and port learned from the server matches the 430 external address and port provided by the PCP PEER response then the 431 HTTP client optimizes keepalive traffic as described in Section 3.4. 433 If the IP address and port do not match, then PCP will not be used to 434 keep the NAT bindings alive for the flow that is being used for the 435 HTTP traffic. This means that there are NATs or HTTP proxies between 436 the PCP server and the HTTP server. The HTTP client will have to 437 resort to use existing techniques for keep alive. Please see 438 Appendix A for an example server side PHP script to obtain the client 439 source IP address. 441 The HTTP protocol allows intermediaries such as transparent proxies 442 to be involved and there is no way for the client to know that a 443 request/response is relayed through a proxy. 445 5.3. Media and data channels with ICE 447 The ICE agent learns the External IP Addresses and Ports using the 448 PCP MAP opcode. If server reflexive candidates learnt using STUN 449 [RFC5389] and external IP addresses learnt using PCP are different 450 then candidates learnt through both STUN and PCP are encoded in the 451 ICE offer and answer . When using the Recommended Formula explained 452 in section 4.1.2.1 of [RFC5245] to compute priority for the candidate 453 learnt through PCP, the ICE agent MUST use a preference value greater 454 than the server reflexive candidate and hence tested before the 455 server reflexive candidate. The recommended type preference value is 456 105 for candidates discovered using PCP and is explained in section 457 4.2 of [RFC6544]. 459 The ICE agent, in addition to the ICE connectivity checks, performs 460 the following: 462 1. The ICE agent checks if the XOR-MAPPED-ADDRESS from the STUN 463 Binding response received as part of ICE connectivity check 464 matches the External IP address and Port provided by PCP MAP 465 response. 467 2. If the match is successful then PCP will be used to keep the NAT 468 bindings alive. The ICE agent optimizes keepalive traffic by 469 refreshing the mapping via a new PCP MAP request containing 470 information from the earlier PCP response. 472 3. If the match is not successful then PCP will not be used for keep 473 NAT binding alive. The ICE agent will use the technique in 474 section 4.4 of [RFC6263] to keep NAT bindings alive. This means 475 that multiple layers of NAT are involved and intermediate NATs 476 are not PCP- aware. 478 Some network operators deploying a PCP Server may allow PEER but not 479 MAP. In such cases the ICE agent learns the external IP address and 480 port using a STUN Binding request/response during ICE connectivity 481 checks. The ICE agent also learns the external IP Address and port 482 using a PCP PEER request/response. If the IP address and port 483 learned from the STUN Binding response matches the external address 484 and port provided by the PCP PEER response then the ICE agent 485 optimizes keepalive traffic as described in Section 3.4. 487 5.4. Detecting Flow Failure 489 Using the Rapid Recovery technique in section 14 of [RFC6887] upon 490 receiving a PCP ANNOUNCE from a PCP server, a PCP client becomes 491 aware that the PCP server has rebooted or lost its mapping state. 492 The PCP client issues new PCP requests to recreate any lost mapping 493 state and thus reconstructs lost mappings fast enough that existing 494 media, HTTP and SIP flows do not break. If the NAT state cannot be 495 recovered the endpoint will find the new external address and port as 496 part of the Rapid Recovery technique in PCP itself and reestablish a 497 connection with the peer. 499 5.5. Firewalls 501 PCP allows applications to communicate with firewall devices with PCP 502 functionality to create mappings for incoming connections. In such 503 cases PCP can be used by the endpoint to create an explicit mapping 504 on firewall in order to permit inbound traffic. The endpoint can 505 further use PCP to send keepalives to keep the firewall mappings 506 alive. 508 5.5.1. IPv6 Network with Firewalls 510 For scenarios where the client uses the ICE Lite implementation 511 explained in section 2.7 of [RFC5245], the ICE Lite endpoint will not 512 generate its own ICE connectivity checks, by definition. As part of 513 the call setup, the ICE Lite endpoint would gather its host 514 candidates and relayed candidate from a TURN server and send the 515 candidates in the offer to the peer endpoint. On receiving the 516 answer from the peer endpoint, the ICE Lite endpoint sends a PCP MAP 517 request with FILTER opcode to create a dynamic mapping in the 518 firewall to permit ICE connectivity checks and subsequent media 519 traffic from the remote peer. This way, the ICE Lite endpoint and 520 its network are protected from unsolicited incoming UDP traffic, and 521 can still operate using ICE Lite (rather than full ICE). 523 5.5.2. Mobile Network with Firewalls 525 Some mobile networks are also making use of a firewall to protect 526 their customers from various attacks like downloading malicious 527 content. The firewall is usually configured to block all unknown 528 inbound connections as explained in section 2.1 of 529 [I-D.chen-pcp-mobile-deployment]. As described in Section 3.4, in 530 such cases, PCP can be used by mobile devices to create an explicit 531 mapping on the firewall to permit inbound traffic and optimize the 532 keepalive traffic. This would result in saving of radio and power 533 consumption of the mobile device while protecting it from attacks. 535 6. IANA Considerations 537 This document has no actions for IANA. 539 7. Security Considerations 541 The security considerations in [RFC5245] and [RFC6887] apply to this 542 use. 544 8. Acknowledgements 546 Authors would like to thank Dave Thaler, Basavaraj Patil, Anca 547 Zamfir, Reinaldo Penno, Suresh Kumar, Dilipan Janarthanan and Mohamed 548 Boucadair for their valuable inputs. 550 9. References 552 9.1. Normative References 554 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 555 Requirement Levels", BCP 14, RFC 2119, March 1997. 557 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 558 (ICE): A Protocol for Network Address Translator (NAT) 559 Traversal for Offer/Answer Protocols", RFC 5245, April 560 2010. 562 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 563 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 564 October 2008. 566 [RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client- 567 Initiated Connections in the Session Initiation Protocol 568 (SIP)", RFC 5626, October 2009. 570 [RFC5780] MacDonald, D. and B. Lowekamp, "NAT Behavior Discovery 571 Using Session Traversal Utilities for NAT (STUN)", RFC 572 5780, May 2010. 574 [RFC6263] Marjou, X. and A. Sollaud, "Application Mechanism for 575 Keeping Alive the NAT Mappings Associated with RTP / RTP 576 Control Protocol (RTCP) Flows", RFC 6263, June 2011. 578 [RFC6544] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach, 579 "TCP Candidates with Interactive Connectivity 580 Establishment (ICE)", RFC 6544, March 2012. 582 [RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 583 Selkirk, "Port Control Protocol (PCP)", RFC 6887, April 584 2013. 586 9.2. Informative References 588 [I-D.chen-pcp-mobile-deployment] 589 Chen, G., Cao, Z., Boucadair, M., Ales, V., and L. 590 Thiebaut, "Analysis of Port Control Protocol in Mobile 591 Network", draft-chen-pcp-mobile-deployment-04 (work in 592 progress), July 2013. 594 [I-D.ietf-rtcweb-overview] 595 Alvestrand, H., "Overview: Real Time Protocols for 596 Browser-based Applications", draft-ietf-rtcweb-overview-13 597 (work in progress), November 2014. 599 [I-D.ietf-v6ops-mobile-device-profile] 600 Binet, D., Boucadair, M., Ales, V., Chen, G., Heatley, N., 601 Chandler, R., Michaud, D., Lopez, D., and W. Haeffner, "An 602 Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile 603 Devices", draft-ietf-v6ops-mobile-device-profile-21 (work 604 in progress), March 2015. 606 [I-D.isomaki-rtcweb-mobile] 607 Isomaki, M., "RTCweb Considerations for Mobile Devices", 608 draft-isomaki-rtcweb-mobile-00 (work in progress), July 609 2012. 611 [RFC2177] Leiba, B., "IMAP4 IDLE command", RFC 2177, June 1997. 613 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 614 A., Peterson, J., Sparks, R., Handley, M., and E. 615 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 616 June 2002. 618 [RFC3921] Saint-Andre, P., Ed., "Extensible Messaging and Presence 619 Protocol (XMPP): Instant Messaging and Presence", RFC 620 3921, October 2004. 622 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 623 Network Address Translations (NATs)", RFC 4380, February 624 2006. 626 [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC 627 6455, December 2011. 629 Appendix A. Example PHP script 630 631 Connected to on port on 633 Pacific Time 634

635 Your IP address is: , 636 port 637

; 638 640 Appendix B. Savings with PCP 642 The following example illustrates the savings in keepalive messages 643 with PCP. 645 PCP PCP 646 Client Server __________ 647 +-----------+ +------+ / \ +-----------+ 648 |Application|________| NAT/ |_______| Internet |___|Application| 649 | Client | | FW | | | | Server | 650 +-----------+ +------+ \__________/ +-----------+ 652 With Application Heartbeat (without PCP): 654 <---------------------///---------------------------> 655 Application heartbeat (Max Interval = 30 seconds) 656 <---------------------///---------------------------> 657 Application heartbeat (Max Interval = 30 seconds) 658 <---------------------///---------------------------> 659 Application heartbeat (Max Interval = 30 seconds) 660 <---------------------///---------------------------> 661 Application heartbeat (Max Interval = 30 seconds) 662 .... 663 .... 664 .... 665 .... 667 With PCP: 668 <------------------> 669 PCP PEER request 670 (Max Lifetime = 3600 seconds) 671 .... 672 .... 673 <------------------> 674 PCP PEER request 675 (Max Lifetime = 3600 seconds) 677 Figure 6: Savings with PCP 679 In the example above, let's suppose normally an application would 680 need to send a heartbeat every 30s to keep mappings active on the 681 NAT/firewall device. In 24 hours, in the absence of PCP, the number 682 of packets sent by the application to keep those mappings active 683 would be (86400/30) = 2880 packets. 685 If the same application uses PCP PEER to create a mapping, with a 686 lifetime of 3600 seconds, on a PCP controlled NAT/firewall device, 687 the number of packets sent by the application to keep those mappings 688 active would be (86400/3600) = 24 packets. 690 With the above assumptions, using PCP saves 99.16% of keepalive 691 traffic. As the number of applications running on a host increase, 692 savings in cost of sending application heartbeats are significant 693 with the use of PCP. 695 PCP PCP PCP 696 Client Proxy/ Server 697 Server __________ 698 +-----------+ +------+ +------+ / \ +-----------+ 699 |Application|_________| NAT/ |_________| NAT/ |__| Internet |___|Application| 700 | Client | | FW | | FW | | | 701 +-----------+ +------+ +------+ \__________/ +-----------+ 702 <-multiple NAT/FW-> 704 <------------------> <------------------> 705 PCP PEER request PCP PEER request 707 If there are multiple PCP-aware NAT/firewall devices on a client's 708 path to the internet, e.g., PCP servers at a home gateway and also at 709 a CGN, the savings with PCP are the same. The PCP server at the home 710 gateway is a PCP proxy that can create associated mappings on the PCP 711 server at the CGN. The client will only have to communicate with the 712 PCP proxy, and receives a single mapping lifetime that needs to be 713 refreshed. 715 Authors' Addresses 717 Tirumaleswar Reddy 718 Cisco Systems, Inc. 719 Cessna Business Park, Varthur Hobli 720 Sarjapur Marathalli Outer Ring Road 721 Bangalore, Karnataka 560103 722 India 724 Email: tireddy@cisco.com 726 Prashanth Patil 727 Cisco Systems, Inc 728 Bangalore 729 India 731 Email: praspati@cisco.com 732 Markus Isomaki 733 Nokia 734 Keilalahdentie 2-4 735 FI-02150 Espoo 736 Finland 738 Email: markus.isomaki@nokia.com 740 Dan Wing 741 Cisco Systems, Inc. 742 170 West Tasman Drive 743 San Jose, California 95134 744 USA 746 Email: dwing@cisco.com