Internet Engineering Task Force T. Tsou, Ed. Internet-Draft T. Taylor Intended status: Standards Track Huawei Technologies Expires: April 19, 2011 S. Ding China Telecom October 16, 2010 Ensuring Address Reuse In the Pinhole Control Protocol (PCP) draft-tsou-pcp-address-modify-00 Abstract This document proposes that a field be added to the PIN-REQUEST message in the Pinhole Control Protocol to ask that the new mapping being requested reuse the same external address already assigned to the requesting device. The actual form of this new field is discussed within the document. 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 April 19, 2011. Copyright Notice Copyright (c) 2010 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 Tsou, et al. Expires April 19, 2011 [Page 1] Internet-Draft Requesting External Address In PCP October 2010 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Possible Solutions and Proposal . . . . . . . . . . . . . . . . 3 3. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. PIN-REQUEST . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. PIN-RESPONSE . . . . . . . . . . . . . . . . . . . . . . . 5 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 6.1. Normative References . . . . . . . . . . . . . . . . . . . 5 6.2. informative References . . . . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 Tsou, et al. Expires April 19, 2011 [Page 2] Internet-Draft Requesting External Address In PCP October 2010 1. Introduction The Pinhole Control Protocol (PCP) [ID.port_control_protocol] allows applications to learn their external IP address and also to instantiate mappings in the PCP-controlled devices. Currently the application can request a mapping from a given internal port to a given external port, but it has no control over the external address that is assigned to it. A number of applications, for example, RTP/RTCP [RFC3550] or FTP [RFC0959], require the allocation of multiple ports. However, if these ports are assigned with different IP addresses, the applications will fail. The recommendations for NAT behaviour for UDP [RFC4787] include a recommendation for the Paired address mapping behaviour when IP address pooling is being used. However, this is only a recommendation, and could therefore fail at times. The recommendations for NAT behaviour for TCP [RFC5382] do not even address the topic. The conclusion is that a method is needed for the application to request that it be given the same external address for a new mapping request as for one that has already been mapped to it. 1.1. Terminology 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]. 2. Possible Solutions and Proposal The most straightforward solution to the problem just proposed is to provide a field in the PINHOLE-REQ message for the application to specify the external address that it wishes to use. If the client receives an error response to its request, it is obviously free to repeat the request with fewer constraints. This has a drawback: the lack of any constraint on what address the application specifies, so that could request an entirely new external address for the current assignment. Granting the unrestricted ability to request specific external addresses could result in fragmentation of the address-port space that the NAT has to work with, and will certainly increase the burden on the PCP server. To resolve this problem, the server and/or the client should follow the rules below: Tsou, et al. Expires April 19, 2011 [Page 3] Internet-Draft Requesting External Address In PCP October 2010 o Server Behavior When receiving a request message specifying an external address, the PCP server should check whether that address is now used by the user; if not, the PCP server should deny the request. o Client Behavior client should not specify the address in the initial request message and should let the server to choose one. In the subsequent request messages, the client can request the external IP address contained in the initial response message. 3. Message Format 3.1. PIN-REQUEST External IP address is added in the PIN-REQUEST message, so that a client can specify the external IP address in a request message. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Internal IP address (32 or 128 bits) : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : External IP address (32 or 128 bits) : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Proto |W|R| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Requested Pinhole Lifetime (seconds) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Internal Port | Requested External Port : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Internal Port : Requested External Port : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ PIN-REQUEST o External IP address: requested external IP address; when set to 0, the PCP server would be free to choose one out of the external IP addresses being used by the user. If there no active mappings for the user, then the PCP server can use any one of free external IP addresses. Tsou, et al. Expires April 19, 2011 [Page 4] Internet-Draft Requesting External Address In PCP October 2010 3.2. PIN-RESPONSE This memo does not change the PIN-RESPONSE message format. A new error code should be added in the response message, in case the PCP server can not allocate resource for the specified external IP address. code error subcode meaning ---- ------------- ----------------- 14(TBD) 0 unable to allocate resource for the specified external IP address 4. IANA Considerations IANA should add an error code for the new PCP error. 5. Security Considerations This memo does not in itself introduce any security issues. The client is unable to control whether new state is created on the server, and is thus not enabled by this feature to mount a DoS attack through resource consumption. 6. References 6.1. Normative References [ID.port_control_protocol] Wing, D., Penno, R., and M. Boucadair, "Pinhole Control Protocol (PCP) (Work in progress)", July 2010. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 6.2. informative References [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, October 1985. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. Tsou, et al. Expires April 19, 2011 [Page 5] Internet-Draft Requesting External Address In PCP October 2010 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007. [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, RFC 5382, October 2008. Authors' Addresses Tina Tsou (editor) Huawei Technologies Bantian, Longgang District Shenzhen 518129 P.R. China Phone: Email: tena@huawei.com Tom Taylor Huawei Technologies 1852 Lorraine Ave. Ottawa K1H 6Z8 Canada Phone: Email: tom111.taylor@bell.net Shengyong Ding China Telecom 109, Zhongshan Ave. West, Tianhe District Guangzhou 510630 P.R. China Phone: Email: dingsy@gsta.com Tsou, et al. Expires April 19, 2011 [Page 6]