Behavior Engineering for Hindrance j. woodyatt Avoidance Apple Internet-Draft November 18, 2008 Intended status: Informational Expires: May 22, 2009 Applicability of NAT-PMP with Service Provider Deployments of Network Address Translation draft-woodyatt-spnatpmp-appl-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 22, 2009. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract In an effort to conserve global scope IPv4 address allocations, service providers are deploying network address/port translators in their interior routing domain and assigning private addresses to residential and small office subscriber sites. This document discusses the applicability of NAT-PMP is such networks to support application requiring dynamic TCP and UDP port forwarding. woodyatt Expires May 22, 2009 [Page 1]
Internet-Draft NAT-PMP for Service Providers November 2008 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Special Language . . . . . . . . . . . . . . . . . . . . . 3 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Detailed Recommendations . . . . . . . . . . . . . . . . . . . 4 3.1. Response Code . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Relay Service . . . . . . . . . . . . . . . . . . . . . . . 4 3.2.1. The Simple Case . . . . . . . . . . . . . . . . . . . . 5 3.2.2. The NAT444 Case . . . . . . . . . . . . . . . . . . . . 5 4. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 7.1. Normative References . . . . . . . . . . . . . . . . . . . 7 7.2. Informative References . . . . . . . . . . . . . . . . . . 7 Appendix A. Open Issues . . . . . . . . . . . . . . . . . . . . . 7 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . . 7 B.1. Starting Point . . . . . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 Intellectual Property and Copyright Statements . . . . . . . . . . 8 woodyatt Expires May 22, 2009 [Page 2]
Internet-Draft NAT-PMP for Service Providers November 2008 1. Introduction Some service providers are finding it necessary to conserve their global scope IPv4 address allocations by assigning private addresses [RFC1918] to subscribers and deploying network address and port translating (NAPT) routers in their interior routing domains. In doing so, providers may give up the option of relying on legal (contractual) restrictions alone to prohibit subscribers from operating servers or using peer-to-peer (P2P) functions. A natural side effect of using NAPT and private subscriber routing realms is to introduce a technical obstacle to A) the use of P2P communication with peers on the public Internet, and B) the advertisement and availability of servers to clients on the public Internet. Those providers wishing to offer more than "client connectivity only, without public addresses" service (as defined in Terminology for Describing Internet Connectivity [RFC4084]) are invited to consider deploying the Network Address Translator Port Mapping Protocol [I-D.cheshire-nat-pmp] in conjuction with their NAPT gateways in order to provide a dynamic port forwarding service and mitigate against the loss of application transparency caused by the placement of subscribers in private routing realms. This document discusses the applicability of NAT-PMP in such deployments and identifies the specific clarifications necessary to improve the existing draft of the protocol to improve its suitability. 1.1. Special Language 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 RFC 2119 [RFC2119]. 2. Overview The motivating usage scenario that drove the development of the NAT- PMP protocol was the case where a residential subscriber deploys NAPT in their CPE gateway as a method to provide Internet service to a home network of devices using a single service provider access point, and as a kind of "firewall" to protect their local network from unsolicited exterior traffic. In that usage scenario, the NAT-PMP service is in the same administrative domain as the residential gateway and the other nodes in the subscriber's network. When the protocol was first specified, the normal expectation was that subscribers are generally assigned woodyatt Expires May 22, 2009 [Page 3]
Internet-Draft NAT-PMP for Service Providers November 2008 public addresses and most service providers offer either "full Internet connectivity" or "firewalled Internet connectivity" [RFC4084]. However, by virtue of its minimal and simple design, NAT- PMP is easily adapted for use with service provider NAPT gateways. In general, the aspects of NAT-PMP that need revision for the scenario at hand are those having to do with the division of the clients from the administrative domain of the NAPT gateway. To that end, the protocol should be extended by adding a result code for mapping requests to indicate that the per-subscriber resource limit would be exceeded. Additionally, a definition is required for a so- called NAT-PMP "relay" service, which mediates between the clients in the CPE routing realm and the service provider NAPT gateway. Also, some consideration in the server must be given to admission control and denial of service attack. 3. Detailed Recommendations This section enumerates the specific recommendations specific changes to the NAT-PMP specification [I-D.cheshire-nat-pmp] to adapt for use with service provider NAPT gateways. 3.1. Response Code A new response code should be defined. 6 - Per-subscriber resource limit would be exceeded. Some discussion is warranted. The NAT-PMP specification currently defines response code 2 as "Not Authorized/Refused," but this code is inappropriate because it indicates that the NAPT gateway is not allowing any mapping requests from the current user to succeed as a matter of policy. (The server is expected to answer requests to determine the exterior address.) The NAT-PMP specification also currently defines response code 4 as "Out of resources (cannot create any more mappings at this time)" but this code is also inappropriate because it indicates that the hard limit of the whole NAPT gateway would be exceeded. This limit is not the same as a per-subscriber limit, and the distinction is important for traffic engineering purposes. 3.2. Relay Service Subscribers with routers at their demarcation point will need a relay for NAT-PMP from the provider's NAPT gateway to the dynamic port- woodyatt Expires May 22, 2009 [Page 4]
Internet-Draft NAT-PMP for Service Providers November 2008 forwarding protocol(s) in use on the subscriber's network, e.g. UPnP IGD and/or NAT-PMP. The relay service for NAT-PMP to NAT-PMP is described here, and the corresponding relay for UPnP-IGD to NAT-PMP is left unspecified. A NAT-PMP relay service acts in all respects as a NAT-PMP server from the perspective of its downstream clients. However, from the perspective of the upstream service, there are two important subclasses of NAT-PMP relay to discuss: A) the case where the relay is controlling its own NAPT, as in the NAT444 architecture; and, B) the case where the relay is not controlling its own NAPT, as in the DS-Lite architecture. 3.2.1. The Simple Case In the simple case, the NAT-PMP clients in the subscriber realm initiate port mapping requests to a relay on the subscriber's gateway router, which forwards them to the service provider NAPT gateway. The subscriber router does not also have a NAPT function, so the relay doesn't have to translate requests. The only minor complications for the relay are that the public address of the service provider NAPT gateway must be propagated to the subscriber NAT-PMP clients in the relay announcements and the responses to the exterior address requests, and the relay must synchronize the start of its epoch to the upstream service. Synchronizing the start of the epoch is straightforward. So long as the upstream server is sending a monotonically increasing value for its start of the epoch, the relay simply copies the counter into its own counter, which it uses when sending announcements to subscriber clients. A simple NAT-PMP relay, i.e. one without a NAPT function attached, need not attempt to cache the state of the upstream NAT-PMP server. All requests can be forwarded directly, and the expense and difficulty of maintaining a cache is unnecessary. 3.2.2. The NAT444 Case In the NAT444 case, the NAT-PMP clients in the subscriber realm initiate port mapping requests that involve a distributed transaction on both the subscriber NAPT gateway and the service provider NAPT gateway. As in the simple case, the NAT-PMP relay in the NAT444 case needs to synchronize the start of the epoch with the service provider NAT-PMP server. It also needs to propagate the exterior public address from woodyatt Expires May 22, 2009 [Page 5]
Internet-Draft NAT-PMP for Service Providers November 2008 the NAT-PMP server to the subscriber clients. However, it also must recursively forward NAT-PMP requests from subscribers to the server by translating ports from realm to realm. A brief word about how to do that. When the NAT-PMP relay receives a locally satisfiable request, then it inserts the redirection mapping into its NAPT ruleset and forwards the request to the server with the interior port replaced by the locally assigned exterior port, i.e. the one allocated in the service provider address realm. Likewise, when the NAT-PMP relay receives a response from its server, the relay translates the interior port from the service provider realm to the subscriber realm and forwards the response to the client. If the response code from the server is non-zero, then the corresponding port mapping needs to be removed from the NAPT ruleset in order to abort the distributed transaction. The technical matters revolving around handling renewals and drops are straightforward variations as in the insertion case. 4. Contributors Comments and criticisms during the development of this document were received from the following IETF participants: Stuart Cheshire 5. IANA Considerations This document has no IANA actions. 6. Security Considerations [EDITOR: See [RFC3552] for guidelines to writing this section. Preliminary note: concerns about authorization of subscriber clients and relays to use the NAT-PMP service at the service provider address realm boundary might arise. These should be resisted, but if they cannot be dismissed, then it would seem that IPsec w/ IKE would be the appropriate cryptographic protocol for that purpose.] 7. References woodyatt Expires May 22, 2009 [Page 6]
Internet-Draft NAT-PMP for Service Providers November 2008 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 7.2. Informative References [I-D.cheshire-nat-pmp] Cheshire, S., "NAT Port Mapping Protocol (NAT-PMP)", draft-cheshire-nat-pmp-03 (work in progress), April 2008. [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003. [RFC4084] Klensin, J., "Terminology for Describing Internet Connectivity", BCP 104, RFC 4084, May 2005. Appendix A. Open Issues o [EDITOR: Insert open issues here.] Appendix B. Change Log B.1. Starting Point o Initial revision. Author's Address james woodyatt Apple Inc. 1 Infinite Loop Cupertino, CA 95014 US Email: jhw@apple.com woodyatt Expires May 22, 2009 [Page 7]
Internet-Draft NAT-PMP for Service Providers November 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). woodyatt Expires May 22, 2009 [Page 8]