Internet Engineering Task Force G. Chen Internet-Draft H. Deng Intended status: Standards Track China Mobile Expires: September 8, 2011 March 7, 2011 Didirectional Port Control for PCP draft-chen-pcp-bidirection-mapping-00 Abstract The memo has proposed a bi-directional option, along with which PCP could not only control PCP client pinhole, but also could manage port mapping status for communicating remote peers. The bi-directional port control mode will eliminate risks of connections interruption caused by remote peer pinhole timeout. 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 September 8, 2011. Copyright Notice Copyright (c) 2011 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. Chen & Deng Expires September 8, 2011 [Page 1] Internet-Draft bidirectional-mapping March 2011 This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Failure Scenarios Analysis . . . . . . . . . . . . . . . . . . 3 3. PCP Bidirectional Port Control . . . . . . . . . . . . . . . . 4 3.1. Bidirectional Port Control Overview . . . . . . . . . . . . 4 3.2. MAP_BIDIRECTION Options . . . . . . . . . . . . . . . . . . 4 3.3. MAP_BIDIRECTION Processing . . . . . . . . . . . . . . . . 6 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 6. Normative References . . . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 Chen & Deng Expires September 8, 2011 [Page 2] Internet-Draft bidirectional-mapping March 2011 1. Introduction Pinhole Control Protocol (PCP)[PCP] has proposed a mechanism which allows PCP client controls port mapping lifetime on NAT/FW for internal hosts. The explicit dynamic mappings give chances to incoming traffic are translated and forwarded to interanl hosts and also reduce keepalive signaling initiated by internal hosts. Currently, the controlled pinhole PCP targeted is exclusively to internal hosts. Remote peer port mapping still follows implicit dynamic mapping behaviors, including mapped address and timeout configuration. In this case, some failures might be happened in scenarios where there are long-lived TCP connections established. This memo has analyzed several failure scenarios and proposed a bi- directional option, along with which PCP could not only control NAT pinhole for internal hosts, but also could manage port mapping status for communicating remote peers. The bi-directional port control mode will eliminate risks of connections interruption caused by remote peer NAT mapping timeout. The document is structured as follows. Section 2 analyzes several failure cases. Section 3 elaborates the MAP_BIDIRECTION option format and processing. 2. Failure Scenarios Analysis Always-Online services are quickly developed these days, e.g. instance message services. Usually, these services has NAT-friendly mechanisms to keep long-lived TCP connection alive between the originators and remote peers. But frequent keepalive signaling might occupy significant network resources and make others service quality degradation, especially in mobile network scenarios. PCP is one way to optimize these keepalive applications. However, there are several failure cases might occur due to remote peers mapping expiration on the NAT/FW. There are three defined uses for the PCP OpCodes operation: a host operating a client, a host operating a server waiting an incoming connection and a host operating a client and server on the same port. When a host operating a client send PCP request to build a pinhole on NAT/FW, PCP server will hold mapping for required duration after successful processing. Let't assume the lifetime is T1. Afterwards, the host will initiate TCP communication with a remote peer. The remote peer will reply TCP SYN/ACK message to the internal host for TCP handshake. Meanwhile, NAT generates implicit dynamic mapping for the remote peer. Let't assume the lifetime is T2. Normally, T1 and T2 Chen & Deng Expires September 8, 2011 [Page 3] Internet-Draft bidirectional-mapping March 2011 is not identical. For reducing keepalive signaling, T1 is likely longer than T2.After TCP session is established, such remote peer NAT mapping will be expired when there is no traffic occurring in interval of T2. In this case, TCP session will be broken even if the mapping for internal host is still alive. For the host acting as server, same problems will occur. An internal host operating a server (e.g., a web server) listens for traffic on a specific port. PCP will reserve mapping information on NAT for required duration. Remote peers connect internal host through such pinhole and create mapping on the NAT for their-self. These remote peers also SHOULD periodically produce keepalive for maintaining states with such middlebox. Otherwise, expiration of remote peer will cause session interruption. For now, there is nothing to do with PCP to optimize such keepalive. Worse than that, such keepalive message is normally designed for Carrier-Grade NATs (CGN). In residential NATs case, it might be lack of such keepalive mechanism which leads to problematic in residential service scenarios. 3. PCP Bidirectional Port Control 3.1. Bidirectional Port Control Overview In order to fulfill long-lived TCP connection requirements, bidirectional port control option is proposed. It means PCP will control mapping information for both internal hosts and remote peers. Depending on that, applications could safely remove sending keepalive signaling. 3.2. MAP_BIDIRECTION Options The MAP_BIDIRECTION Option indicates both internal and remote hosts mapping control is desired. The remote peer port and remote peer IP address indicate the desired destination IP address and port with which internal host has long-lived TCP connection. The remote peer prefix length indicates the length of the remote peer's IP address. This allows a single option to take effect on an entire subnet. After processing this PCP request carrying such MAP_BIDIRECTION and generating a successful response, the PCP- controlled device will create or manage remote peer's mapping with a specific IP address, transport, and port that match these fields. The MAP_BIDIRECTION packet layout is described below: Chen & Deng Expires September 8, 2011 [Page 4] Internet-Draft bidirectional-mapping March 2011 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | prefix-length | Remote Peer Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : Remote Peer IP address (32 bits if MAP4, : : 128 bits if MAP6) : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: MAP_BIDIRECTION option layout These fields are described below: Reserved: 8 reserved bits, MUST be sent as 0 and MUST be ignored when received. Prefix-length: indicates how many bits of the IPv4 or IPv6 address are relevant for bi-directional mapping. The value 0 indicates "no bi-directional control", and will remove all previous activities. See below for detail. Remote Peer Port: the port number of the remote peer. The value 0 indicates "all ports" related to listed remote peer IP address. Remote Peer IP address: The IP address of the remote peer. The value 0 indicates "all remote peer address" related to internal host. This Option: name: MAP_BIDIRECTION number: 8 is valid for OpCodes: MAP4, MAP6, PEER4, PEER6 is included in responses: MUST, if it appeared in the request length: 0 may appear in: requests maximum occurrences: as many as fit within maximum PCP message size Chen & Deng Expires September 8, 2011 [Page 5] Internet-Draft bidirectional-mapping March 2011 3.3. MAP_BIDIRECTION Processing This Option could be used by a PCP client that is operating a application server or client. The MAP_BIDIRECTION allows PCP client to create, manage and delete remote peer mapping information on NAT. When this option has been carried with MAP opcode, that means PCP client would like to ask PCP server to create the pinhole for remote peer hosts. After PCP server finish successful processing, PCP- controlled NAT device will generate mapping information which matches remote peer address, port and protocol. To be specific, the remote peer mapping information will be created according to MAP_BIDIRECTION fields indications. When prefix-length is a specific value, which is 32 or 128, an specific remote peer mapping could be created. This is NOT RECOMMENDED to set prefix-length to a value, which is among 1 to 32 or 128. In another words, the PCP server can't to be asked to create pinhole for an entire subnet. When this option has been carried with PEER opcode, that means PCP client would like to ask PCP server to prolong the pinhole lifetime for remote peer hosts. After PCP server finish successful processing, PCP-controlled NAT device will set mapping information lifetime to desired values both for internal hosts and remote hosts. To be specific, the remote peer mapping information will be prolong according to MAP_BIDIRECTION fields indications. When prefix-length is a specific value, which is 32 or 128, a specific remote peer mapping could be managed. When prefix-length is a specific values, which is among 1 to 32 or 128, an entire subnet mapping can be impacted . When remote peer IP address is set to 0, all remote peer address mapping related to internal host could be prolonged. When PCP server isn't capable of processing MAP_BIDIRECTION option, UNABLE_TO_CONTROL_BIDIRECTION failure code should be returned. 4. IANA Considerations TBD 5. Security Considerations TBD 6. Normative References [PCP] Wing, D., "Pinhole Control Protocol (PCP)", Chen & Deng Expires September 8, 2011 [Page 6] Internet-Draft bidirectional-mapping March 2011 draft-ietf-pcp-base-06.txt (work in progress), February 2011. Authors' Addresses Gang Chen China Mobile 53A,Xibianmennei Ave., Xuanwu District, Beijing 100053 China Email: chengang@chinamobile.com Hui Deng China Mobile 53A,Xibianmennei Ave. Beijing 100053 P.R.China Phone: +86-13910750201 Email: denghui02@gmail.com Chen & Deng Expires September 8, 2011 [Page 7]