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.

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.

Table of Contents

1.  Introduction
    1.1.  Special Language
2.  Overview
3.  Detailed Recommendations
    3.1.  Response Code
    3.2.  Relay Service
        3.2.1.  The Simple Case
        3.2.2.  The NAT444 Case
4.  Contributors
5.  IANA Considerations
6.  Security Considerations
7.  References
    7.1.  Normative References
    7.2.  Informative References
Appendix A.  Open Issues
Appendix B.  Change Log
    B.1.  Starting Point
§  Author's Address
§  Intellectual Property and Copyright Statements

1.  Introduction

Some service providers are finding it necessary to conserve their global scope IPv4 address allocations by assigning private addresses [RFC1918] (Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, “Address Allocation for Private Internets,” February 1996.) 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 (Klensin, J., “Terminology for Describing Internet Connectivity,” May 2005.) [RFC4084]) are invited to consider deploying the Network Address Translator Port Mapping Protocol (Cheshire, S., “NAT Port Mapping Protocol (NAT-PMP),” April 2008.) [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 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [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 public addresses and most service providers offer either "full Internet connectivity" or "firewalled Internet connectivity" [RFC4084] (Klensin, J., “Terminology for Describing Internet Connectivity,” May 2005.). 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] (Cheshire, S., “NAT Port Mapping Protocol (NAT-PMP),” April 2008.) 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-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 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] (Rescorla, E. and B. Korver, “Guidelines for Writing RFC Text on Security Considerations,” July 2003.) 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

7.1. Normative References

7.2. Informative References

Appendix A.  Open Issues

• [EDITOR: Insert open issues here.]

Appendix B.  Change Log

B.1.  Starting Point

• Initial revision.

Author's Address

Full Copyright Statement

Copyright © 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.