Diameter Maintenance and Extensions F. Brockners Internet Draft S. Bhandari S. Vikram P. Mishra Cisco Systems Intended status: Informational July 3, 2009 Expires: December 5, 2009 Review of NAT Control Protocols draft-brockners-nat-control-protocols-review-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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 August 29, 2009. Copyright Notice Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Brockners, et al. Expires September 3, 2009 [Page 1] Internet-Draft Review of NAT Control Protocols July 2009 This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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. Abstract This document reviews NAT control capabilities of a set of protocols and evaluates their applicability to per endpoint control of a Large Scale NAT device. Table of Contents Copyright Notice ................................... 1 Abstract .......................................... 2 1. Introduction ....................................... 3 2. Terminology ........................................ 3 3. Protocol capabilities for NAT Control .............. 4 3.1. Outline of control capabilities ............... 4 3.2. Control Capabilities for a Large Scale NAT .... 7 4. Review of protocols for NAT control ................ 8 4.1. Protocols for control by the SP ............... 8 4.1.1. MIDCOM ................................... 8 4.1.2. SIMCO .................................... 9 4.1.3. ETSI Ia ................................. 10 4.1.4. ETSI Gq' ................................ 11 4.1.5. ITU Rs .................................. 11 4.1.6. ITU Rw .................................. 12 4.2. Protocols for control by the End-User ........ 13 4.2.1. UPnP IGD ................................ 13 4.2.2. Bonjour NAT-PMP ......................... 14 4.3. Protocols for control by the End-User or SP .. 15 4.3.1. NAT-PMP relay ........................... 15 4.3.2. NSLP .................................... 16 4.3.3. NAT with explicit control (NAT-XC) ...... 17 5. Security Considerations ........................... 18 6. IANA Considerations ............................... 18 7. References ........................................ 18 7.1. Normative References ......................... 18 8. Author's Addresses ................................ 20 Brockners, et al. Expires December 5, 2009 [Page 2] Internet-Draft Review of NAT Control Protocols July 2009 1. Introduction With the foreseeable depletion of available IPv4 addresses from the IANA pool, service providers are starting to consider network designs which no longer assign unique global IPv4 addresses to their subscribers. One of the approaches considered, is the deployment of a provider-operated large scale NAT device between the end-users and the Internet. Nishitani et al. [I-D.nishitani-cgn] call this NAT device a "Large Scale NAT (LSN)". LSNs will be inserted into the existing subscriber access and aggregation networks which typically provide for per-endpoint service management and control as well as per-endpoint accounting. Per- endpoint rules include those which relate to service offerings of the SP (e.g. access bandwidth, time or volume based access restrictions) as well as rules which follow legal regulations of the "National Regulation Authorities (NRA)". The introduction of a LSN impacts the per-endpoint service offerings as well as the regulatory requirements and gives rise to new control requirements within the service provider network: Service providers need to dynamically manage the behavior of the LSN on a per-endpoint basis. This document reviews a set of protocols and protocol frameworks that offer capabilities for NAT control. Based on the review, the document assesses the applicability of the different protocols to per-endpoint management of a LSN. 2. Terminology Conventions used in this document 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]. Abbreviations are used in this document: Endpoint: Device representing a user, subscriber, server, or similar that requires the establishment of NAT-Bindings to communicate with other endpoints. AAA: Authentication, Authorization, Accounting AFT: Address Family Translation. LSN: Large Scale NAT device. Brockners, et al. Expires December 5, 2009 [Page 3] Internet-Draft Review of NAT Control Protocols July 2009 NAT: Network Address Translation. Additional NAT related terminology definitions are found in [RFC2663]. NAT-Binding or Binding: Association of two IP-address/port pairs (with one IP-address typically being private and the other one public) to facilitate NAT. NAT-Manager, NAT-Device: A protocol for NAT control is assumed to run between a "NAT-Manager" and a "NAT-Device". The NAT-Device is a transport network element which performs the actual NAT operations, whereas the NAT-Manager is a control entity, which controls the way the NAT-Device performs network address translation. NAS: Network Access Server. SP: Service Provider. 3. Protocol capabilities for NAT Control This section briefly outlines the set of capabilities used for evaluating NAT control protocols and puts those into perspective to the NAT control capabilities expected for controlling a "Large Scale NAT" device. The review includes control capabilities for IPv4 to IPv4 NAT as well as AFT between IPv6 and IPv4. 3.1. Outline of control capabilities Control of a NAT device can either be performed using manual configuration (e.g. using a command line or web interface to the NAT device) or through the use of a protocol. Deployment dependent, manual configuration can also be combined with a control protocol. An example for this case is, NAT-control through a web-portal where the user manually inputs parameters which are then transmitted to a NAT device using a control protocol. This document reviews the different protocols for NAT control using the following list of capabilities: Brockners, et al. Expires December 5, 2009 [Page 4] Internet-Draft Review of NAT Control Protocols July 2009 (C1) Endpoint awareness: An endpoint aware protocol associates NAT control with an endpoint. Endpoints can be identified through a "Global Endpoint ID": The global endpoint ID will allow for common identification of an endpoint on a LSN as well as other endpoints - or subscriber-aware devices such as a Network Access Server (NAS) or an AAA system. Endpoints are identified through a single or a set of classifiers such as IP address, VLAN identifier, or interface identifier which uniquely identify the traffic associated with a particular global endpoint. (C2) Configure NAT-Binding Limits: Define/restrict the maximum number of NAT-bindings on a per-endpoint basis. This enables service providers to offer differentiated services based on the number of bindings and hence optimize the consumption of IP-address/port-ranges. Per-endpoint NAT-binding limits also allow for protection against denial of service attacks. (C3) Configure full NAT-Binding: Request the allocation of a pre- defined NAT-binding. Both the internal as well as the external IP-address/port pair are specified within the request. Some deployment cases, such as access to a web-server within a user's home network with IP-address and port, could benefit from statically configured bindings. (C4) Configure half NAT-Binding: Request the allocation of an external IP-address for a given internal IP-address and report the allocated external IP-address back to the requestor. In some deployment scenarios, the application requires immediate knowledge of the allocated binding for a given internal IP- address but does not control the allocation of the external IP-address (e.g. SIP-proxy server deployments). (C5) Configure Address pools: Define the external address-pool(s) and port ranges to be used for allocating an external IP- address. External address-pools can either be pre-defined on the LSN, or specified within a request. If pre-defined address-pools are used, a request would just include a reference (e.g. name) to an already defined address pool on LSN. Otherwise, the request will contain a description of the IP-address pool(s) to be used (e.g. list of IP-subnets). Brockners, et al. Expires December 5, 2009 [Page 5] Internet-Draft Review of NAT Control Protocols July 2009 (C6) Accounting/Reporting: Report established bindings for a particular user. Accounting can either be done on a per- binding level (referred to as (C6a: Accounting - per NAT- binding)) or on a per IP-address/port-range level (referred to as (C6b: Accounting - per range)). The later assumes that the LSN reserves ranges of port to endpoints (i.e. a block of ports which corresponds to the maximum number of NAT-bindings allowed). With per port-range accounting, accounting records only indicate that some number of NAT-bindings is allocated to a particular endpoint. Details on the particular NAT-binding are omitted. Apart from statistical and charging purposes, binding reporting is also required for legal reasons. Most National Regulatory Authorities (NRA) require that service providers provide the identity of a user upon request. The service provider needs to be able to correlate a tuple (public IP- address, port, time) to a particular user or endpoint. (C7) NAT-Binding Information query: Report details and statistics of bindings for a single endpoint or a set of endpoints through an external interface which integrates with the overall per-endpoint management suite. A flexible information query can be used to retrieve information about a binding that was established through the control protocol as well as information about bindings which were allocated by the NAT device autonomously for a particular endpoint. (C8) Support address latching control: Latching describes the process of a NAT device correlating incoming data to a requested NAT-binding and as a result ignoring the remote IP address and port received in a NAT-binding request and replacing it with the incoming ("learned") addresses of the data. Details on address latching control can be found in [ITU-H.248.37]. Hosted NAT traversal solutions leverage support for address latching. (C9) Support Address Family Translation (AFT): Network address and protocol translation (i.e. translation between IPv4 and IPv6 addresses). Brockners, et al. Expires December 5, 2009 [Page 6] Internet-Draft Review of NAT Control Protocols July 2009 (C10) Support Twice-NAT: RFC 2663 defines Twice-NAT as a "variation of NAT in that both the source and destination addresses are modified by NAT as a datagram crosses address realms. This is in contrast to Traditional-NAT and Bi- Directional NAT, where only one of the addresses (either source or destination) is translate". See also [RFC2663], section 4.3. Firewalls or session border controllers typically require a translation of source and destination address. (C11) Support Soft-State Configs: Soft-state is a temporary state governed by periodic expiration. A NAT device supporting soft-state configuration via a dedicated NAT management protocol often leverages periodic messages to refresh the state. (C12) Connection initiation: The protocol association between the NAT-Manager and the NAT-Device can either be initiated by the NAT-Device or the NAT-Manager. Request initiation from the NAT-Device is typically referred to as "pull" mode, whereas request initiation from the NAT-Manager is referred to as "push" mode. (C13) Transport specific bindings: Some NAT control protocols are agnostic to the transport protocol used (e.g. they allow to refer to a protocol port number, but don't allow to differentiate between UDP or TCP), while other allow for a specific description of the layer 4 transport protocol; in which case the NAT-devices could support translation tables per transport protocol. 3.2. Control Capabilities for a Large Scale NAT A control protocol for Large Scale NAT does not necessarily need to incorporate all the protocol capabilities which are summarized in section 3.1. Capabilities C1 to C7 as well as C13 are expected to be typically supported by a LSN. C9 will be a requirement for those LSN deployments which include AFT between IPv4 and IPv6. Twice-NAT (C10) and Support for address latching (C8) are not necessarily required, as these capabilities refer to specific deployment environments such as that of a session border controller or firewall. Due to the fact that a LSN will be deployed within the SP domain, only protocols which support a deployment within the SP domain apply to a LSN. With this said, it should be noted that NAT-control for the user can be combined with NAT control protocols for the SP through the use of an appropriate protocol proxy. For example UPnP IGD, NAT- PmP, or NAT-PmP relay, initiated at the endpoint, can be used in Brockners, et al. Expires December 5, 2009 [Page 7] Internet-Draft Review of NAT Control Protocols July 2009 conjunction with SP focused NAT control protocols to provide a solution for NAT control. 4. Review of protocols for NAT control The protocol review will not only factor in the different capabilities a protocol offers for NAT control, but also how these capabilities are realized. Where applicable, the document notes how a specific capability can be achieved using the semantics that the protocol offers, and whether a capability can be offered efficiently (e.g. with regards to the number of message exchanges used). 4.1. Protocols for control by the SP 4.1.1. MIDCOM MIDCOM is not a protocol in its own right, but specifies a set of protocol semantics (see [RFC5189]) for middlebox communication. Middleboxes in the MIDCOM sense are intermediate devices (such as firewalls or NAT-gateways) which require application intelligence (see [RFC3303], [RFC3304]). MIDCOM defines the protocol semantics in terms of transactions. Those can be request transactions, or asynchronous transactions - used either for configuration or monitoring. The protocol semantics of MIDCOM can be implemented by any protocol which supports the required transaction types and procedures laid out. [RFC4097] evaluates a set of protocols (i.e. SNMP, RSIP, Megaco, Diameter, COPS) for MIDCOM compliance. [RFC5190] specifies a MIDCOM implementation using SNMP. +-------------------------------------------------+ | Capability | Supported | +-------------------------------------------------+ |C1: Endpoint awareness | (Note1) | |C2: Configure NAT-Binding Limits | No | |C3: Configure full NAT-Binding | Yes | |C4: Configure half NAT-Binding | Yes | |C5: Configure Address pools | Yes (Note2) | |C6a: Accounting - per NAT-binding | No (Note3) | |C6b: Accounting - per range | No (Note3) | |C7: NAT-Binding Information query | No (Note3) | |C8: Support address latching | No | |C9: Support AFT | Yes | |C10: Support Twice-NAT | Yes | |C11: Support Soft-State Configs | Yes | |C12: Connection initiation | Push | |C13: Transport specific bindings | Yes | |Base protocol | n/a | Brockners, et al. Expires December 5, 2009 [Page 8] Internet-Draft Review of NAT Control Protocols July 2009 +-------------------------------------------------+ Note 1: MIDCOM agents establish a session with middleboxes to facilitate configuration and monitoring of the middlebox. Both agents as well as middleboxes can maintain multiple sessions. While MIDCOM assumes only a single session between any pair of agent and middlebox (see [RFC5189], section 2.2), there are no explicit mechanisms put in place which would disallow multiple sessions between an agent and a middlebox. If an agent is endpoint aware, the session concept in MIDCOM could be leveraged for per-endpoint control of the middlebox. Note 2: Address pool configuration is supported through MIDCOM policy rules. Note 3: MIDCOM supports asynchronous communication from the middlebox to the agent, though this is limited to notifications about session termination, as well as notification on policy or group events. The scope of MIDCOM's transactions is at policy rule level. Hence MIDCOM offers no semantics for procedures which are specific to transient objects (i.e. NAT bindings allocated by the middlebox without explicit specification of the binding in a policy rule) controlled by a policy rule. 4.1.2. SIMCO SIMCO [RFC4540] is a protocol following the MIDCOM framework and protocol semantics. Consequently, the NAT control capabilities of SIMCO resemble those of MIDCOM. SIMCO is not an internet standard, but a protocol specified by NEC. +-------------------------------------------------+ | Capability | Supported | +-------------------------------------------------+ |C1: Endpoint awareness | No (Note 1) | |C2: Configure NAT-Binding Limits | No | |C3: Configure full NAT-Binding | Yes | |C4: Configure half NAT-Binding | Yes | |C5: Configure Address pools | Yes | |C6a: Accounting - per NAT-binding | No | |C6b: Accounting - per range | No | |C7: NAT-Binding Information query | No | |C8: Support address latching | No | |C9: Support AFT | Yes | |C10: Support Twice-NAT | Yes | Brockners, et al. Expires December 5, 2009 [Page 9] Internet-Draft Review of NAT Control Protocols July 2009 |C11: Support Soft-State Configs | Yes | |C12: Connection initiation | Push | |C13: Transport specific bindings | Yes | |Base protocol | SIMCO | +-------------------------------------------------+ Note 1: MIDCOM, while not specifically designed for it, could support multiple sessions between an agent and a middlebox. With this, the session could be used to represent an endpoint. This approach can only be used if the protocol used to implement the MIDCOM protocol semantics incorporates a native session concept (such as for example DIAMETER). SIMCO also leverages a session model to associate agents and middleboxes, but does not supply a session model of its own. SIMCO messages do not incorporate session identification information, hence the session context would need to be supplied by the underlying transport protocol, e.g. TCP. This renders the approach of using a SIMCO session per endpoint as non feasible. 4.1.3. ETSI Ia ETSI Ia is a H.248 based protocol is defined in [ETSI-ES283018]. It is defined for use between the Service Policy Decision Function (SPDF) and the Border Gateway Function (BGF) within the ETSI TISPAN NGN architecture. Ia is a H.248-based control protocol which includes NAT control capabilities. In addition, it offers gate control (i.e. packets filtering depending on "IP address / port"), resource allocation and bandwidth reservation, usage metering as well as traffic policing capabilities. ETSI Ia offers the following capabilities for NAT control: +-------------------------------------------------+ | Capability | Supported | +-------------------------------------------------+ |C1: Endpoint awareness | No | |C2: Configure NAT-Binding Limits | No | |C3: Configure full NAT-Binding | Yes | |C4: Configure half NAT-Binding | Yes | |C5: Configure Address pools | No | |C6a: Accounting - per NAT-binding | No | |C6b: Accounting - per range | No | |C7: NAT-Binding Information query | No | |C8: Support address latching | Yes | |C9: Support AFT | Yes | |C10: Support Twice-NAT | Yes | |C11: Support Soft-State Configs | No | |C12: Connection initiation | Push | Brockners, et al. Expires December 5, 2009 [Page 10] Internet-Draft Review of NAT Control Protocols July 2009 |C13: Transport specific bindings | No | |Base protocol | H.248 | +-------------------------------------------------+ 4.1.4. ETSI Gq' ETSI Gq' is a Diameter application defined in [ETSI-TS183017]. The Gq' interface is the interface between the Application Function (AF) and the Service Policy Decision Function (SPDF) and is used for session based policy set-up information exchange between the SPDF and the AF. +-------------------------------------------------+ | Capability | Supported | +-------------------------------------------------+ |C1: Endpoint awareness | Yes (Note1) | |C2: Configure NAT-Binding Limits | No | |C3: Configure full NAT-Binding | Yes | |C4: Configure half NAT-Binding | Yes | |C5: Configure Address pools | No | |C6a: Accounting - per NAT-binding | No | |C6b: Accounting - per range | No | |C7: NAT-Binding Information query | No | |C8: Support address latching | Yes | |C9: Support AFT | Yes | |C10: Support Twice-NAT | No | |C11: Support Soft-State Configs | Yes | |C12: Connection initiation | Push | |C13: Transport specific bindings | No | |Base protocol | Diameter | +-------------------------------------------------+ Note 1: Gq' leverages the session concept of the Diameter base specification [RFC3588]. Within the typical Gq' deployment context, the session-id refers to a resource reservation initiated by an application function. Given that the Session-Id is globally unique and is meant to uniquely identify a user session without reference to any other information it can be leveraged to uniquely identify an endpoint. 4.1.5. ITU Rs ITU Rs is a Diameter application defined in [ITU-T-Q.3301.1]. Rs runs between service control entities (SCE) and the Policy Decision Physical Entity (PD-PE) in the Resource and Admission Control Brockners, et al. Expires December 5, 2009 [Page 11] Internet-Draft Review of NAT Control Protocols July 2009 Function block. Similar to Gq' the protocol includes capabilities for NAT control. In addition it can be used to request and commit transport resources, to retrieve address mapping information that can be used to modify application signaling, and to receive reports on transport resource usage for charging. +-------------------------------------------------+ | Capability | Supported | +-------------------------------------------------+ |C1: Endpoint awareness | Yes (Note1) | |C2: Configure NAT-Binding Limits | No | |C3: Configure full NAT-Binding | Yes | |C4: Configure half NAT-Binding | Yes | |C5: Configure Address pools | No | |C6a: Accounting - per NAT-binding | No | |C6b: Accounting - per range | No | |C7: NAT-Binding Information query | No | |C8: Support address latching | Yes | |C9: Support AFT | Yes | |C10: Support Twice-NAT | No | |C11: Support Soft-State Configs | Yes | |C12: Connection initiation | Push | |C13: Transport specific bindings | No | |Base protocol | Diameter | +-------------------------------------------------+ Note 1: The considerations related to the session-id made as part of the Gq' protocol discussion apply to Rs as well. 4.1.6. ITU Rw ITU Rw is a Diameter application defined in [ITU-T-Q.3303.3]. Rw is defined between policy decision and enforcement points for QoS resource control, gate control, and NAPT/NAT traversal control. +-------------------------------------------------+ | Capability | Supported | +-------------------------------------------------+ |C1: Endpoint awareness | Yes | |C2: Configure NAT-Binding Limits | No | |C3: Configure full NAT-Binding | Yes | |C4: Configure half NAT-Binding | Yes | |C5: Configure Address pools | No | |C6a: Accounting - per NAT-binding | No | |C6b: Accounting - per range | No | Brockners, et al. Expires December 5, 2009 [Page 12] Internet-Draft Review of NAT Control Protocols July 2009 |C7: NAT-Binding Information query | No | |C8: Support address latching | Yes | |C9: Support AFT | Yes | |C10: Support Twice-NAT | No | |C11: Support Soft-State Configs | Yes | |C12: Connection initiation | Push/Pull | |C13: Transport specific bindings | No | |Base protocol | Diameter | +-------------------------------------------------+ 4.2. Protocols for control by the End-User 4.2.1. UPnP IGD UPnP IGD (see [UPnP-IGD]) was designed to be used primarily for home NAT gateways. UPnP IGD provides methods for following: o Learning public IP address o Enumerating existing port mappings o Adding and removing port mappings o Assigning lease times to mappings +-------------------------------------------------+ | Capability | Supported | +-------------------------------------------------+ |C1: Endpoint awareness | No | |C2: Configure NAT-Binding Limits | No | |C3: Configure full NAT-Binding | No | |C4: Configure half NAT-Binding | Yes(Note1)| |C5: Configure Address pools | No | |C6a: Accounting - per NAT-binding | No | |C6b: Accounting - per range | No | |C7: NAT-Binding Information query | No | |C8: Support address latching | No | |C9: Support AFT | No | |C10: Support Twice-NAT | No | |C11: Support Soft-State Configs | Yes | |C12: Connection initiation | Push(Note2)| |C13: Transport specific bindings | Yes | |Base protocol | XML based | | | appln on UDP| +-------------------------------------------------+ Brockners, et al. Expires December 5, 2009 [Page 13] Internet-Draft Review of NAT Control Protocols July 2009 Note 1: UPnP IGD allows querying for public IP that will be used and port mappings created. Note 2: UPnP IGD is for home subscribers to request/query for NAT binding information with NAT device. 4.2.2. Bonjour NAT-PMP Bonjour NAT (see [I-D.cheshire-nat-pmp]) port mapping protocol was defined for automating the process of creating Network NAT port mappings. It includes a method for retrieving the external IP address of a NAT gateway, thus allowing a client to make this external IP address and port number known to peers that may wish to communicate with it. This protocol is designed for small home networks, with a single logical link (subnet) where the client's default gateway is also the NAT translator for that network. For more complicated networks where the NAT translator is some device other than the client's default gateway, this protocol is not appropriate. +-------------------------------------------------+ | Capability | Supported | +-------------------------------------------------+ |C1: Endpoint awareness | No | |C2: Configure NAT-Binding Limits | No | |C3: Configure full NAT-Binding | No | |C4: Configure half NAT-Binding | Yes(Note1)| |C5: Configure Address pools | No | |C6a: Accounting - per NAT-binding | No | |C6b: Accounting - per range | No | |C7: NAT-Binding Information query | No | |C8: Support address latching | No | |C9: Support AFT | No | |C10: Support Twice-NAT | No | |C11: Support Soft-State Configs | Yes | |C12: Connection initiation | Push(Note2)| |C13: Transport specific bindings | Yes | |Base protocol | New appln | | | over UDP | +-------------------------------------------------+ Brockners, et al. Expires December 5, 2009 [Page 14] Internet-Draft Review of NAT Control Protocols July 2009 Note 1: NAT-PmP allows querying for external IP that would be used without influencing it and allows requesting for actual port number to be mapped. Note 2: NAT-PmP is for home subscribers to request/query for NAT binding information with NAT device. 4.3. Protocols for control by the End-User or SP 4.3.1. NAT-PMP relay Applicability of NAT-PMP with Service Provider Deployments of Network Address Translation is studied in [I-D.woodyatt-spnatpmp-appl]. NAT-PMP relay extends Bonjour NAT-PMP to service provider deployments. The primary requestor for port mapping would be the subscriber end device. This specification describes a way to relay the NAT-PmP messages from subscriber home gateway to service provider NAT gateway. Though it adds a response code for port mapping request to indicate "Per-subscriber resource limit would be exceeded" it is unspecified as to how a subscriber is identified and this decision made. +-------------------------------------------------+ | Capability | Supported | +-------------------------------------------------+ |C1: Endpoint awareness | No | |C2: Configure NAT-Binding Limits | No | |C3: Configure full NAT-Binding | No | |C4: Configure half NAT-Binding | Yes(Note1)| |C5: Configure Address pools | No | |C6a: Accounting - per NAT-binding | No | |C6b: Accounting - per range | No | |C7: NAT-Binding Information query | No | |C8: Support address latching | No | |C9: Support AFT | No | |C10: Support Twice-NAT | No | |C11: Support Soft-State Configs | Yes | |C12: Connection initiation | Push | |C13: Transport specific bindings | Yes | |Base protocol | NAT-PmP | | | | +-------------------------------------------------+ Note 1: NAT-PmP allows querying for external IP that would be used Brockners, et al. Expires December 5, 2009 [Page 15] Internet-Draft Review of NAT Control Protocols July 2009 without influencing it and allows requesting for actual port number to be mapped. 4.3.2. NSLP NSLP (NAT/Firewall NSIS Signaling Layer Protocol) is specified in [I-D.ietf-nsis-nslp-natfw]. The NATFW NSLP is designed to request the dynamic configuration of NATs and/or firewalls along the data path. Dynamic configuration includes enabling data flows to traverse these devices without being obstructed, as well as blocking of particular data flows at inbound firewalls. +-------------------------------------------------+ | Capability | Supported | +-------------------------------------------------+ |C1: Endpoint awareness | Yes(Note1)| |C2: Configure NAT-Binding Limits | No | |C3: Configure full NAT-Binding | No | |C4: Configure half NAT-Binding | Yes | |C5: Configure Address pools | No | |C6a: Accounting - per NAT-binding | No | |C6b: Accounting - per range | No | |C7: NAT-Binding Information query | No | |C8: Support address latching | No | |C9: Support AFT | No | |C10: Support Twice-NAT | No | |C11: Support Soft-State Configs | Yes | |C12: Connection initiation | Push(Note2)| |C13: Transport specific bindings | Yes | |Base protocol | GIST(Note3)| +-------------------------------------------------+ Note 1: NATFW NSLP has signaling session concept. Signaling session is initiated by Data sender and created at every hop in the data path. Each NSIS node that supports NATFW NSLP can authenticate and authorize the signaling session before applying the policy requested. Thus there will be multiple NSLP sessions per endpoint based on every unique IP 5 tuple. Note 2: NSLP protocol defines dynamic configuration of NAT device by signaling messages initiated by Data sender towards Data receiver. NAT device is not capable of querying for NAT policy when it encounters data packets for which no policy is installed. Brockners, et al. Expires December 5, 2009 [Page 16] Internet-Draft Review of NAT Control Protocols July 2009 Note 3: General Internet Signaling Transport(GIST) - the implementation of the NTLP) defined in [I-D.ietf-nsis-ntlp]. 4.3.3. NAT with explicit control (NAT-XC) Details on NAT-XC can be found in [I-D.moore-nat-xc]. Although focused on IPv4/IPv6 NAT, NAT-XC could be applied to IPv4/IPv4 NAT as well. NAT-XC is designed to allow applications to be explicitly aware of, and control, their address bindings. By closely associating the NAT-Device (i.e. "translator") with the application it provides a predictable programming environment for applications. Consequently the typical operational model of the NAT-Device does not resemble the model of a default router, but the application clients will send packets directly to the NAT-Device - making the assumed operational model similar to for example that of a session border controller. The NAT-XC binding definition is also reflected by the operational model: A binding in the sense of NAT-XC is a 9-tuple consisting of transport protocol, local and remote address and port of the NAT-device(s), as well as the local and remote endpoint addresses. Note that NAT-XC was at draft state at the time this document was written. Several protocol details weren't fully defined. +-------------------------------------------------+ | Capability | Supported | +-------------------------------------------------+ |C1: Endpoint awareness | (Note1) | |C2: Configure NAT-Binding Limits | No (Note2) | |C3: Configure full NAT-Binding | Yes | |C4: Configure half NAT-Binding | No (Note2) | |C5: Configure Address pools | No (Note2) | |C6a: Accounting - per NAT-binding | Yes (Note3) | |C6b: Accounting - per range | No | |C7: NAT-Binding Information query | Yes (Note4) | |C8: Support address latching | No | |C9: Support AFT | Yes | |C10: Support Twice-NAT | Yes | |C11: Support Soft-State Configs | Yes | |C12: Connection initiation | push | |C13: Transport specific bindings | Yes | |Base protocol | NAT-XC | +-------------------------------------------------+ Note 1: Not fully applicable. Due to the tight integration of NAT- Device and NAT-Manager a concept of NAT-endpoint awareness at the NAT-device is not really applicable. Brockners, et al. Expires December 5, 2009 [Page 17] Internet-Draft Review of NAT Control Protocols July 2009 Note 2: Not applicable due to the operational model of NAT-XC, which assumes explicit control of the bindings created by the application. Note 3: "Binding Notification Messages" of NAT-XC (see [I-D.moore- nat-xc], section 3.7.6) could be leveraged to supply per NAT-binding accounting. Note 4: NAT-XC supplies a "Get Binding List" operation (see [I- D.moore-nat-xc], section 3.7.5) which allows a NAT-Manager to retrieve a list of all existing bindings. Note that the typical operational model for NAT-XC does not match the deployment context of a LSN, because NAT-XC assumes a close integration with the application and requires the application to control every binding on the LSN. This contradicts the default model of a LSN which autonomously creates bindings. NAT-XC includes autonomous operation of the a NAT-device as a corner case. Section 2.3 of the draft [I-D.moore-nat-xc] mentions a model where NAT- Manager and NAT-Device would be implemented on the same physical device. In this case, the NAT-Manager leverages traffic analysis and heuristics to control the NAT-Device. In case NAT-Manager and NAT- Device are co-located on the same physical device, remote management of the NAT-Device is naturally excluded. 5. Security Considerations This document studies the generic capabilities of several protocols as they apply to the control of a NAT device. Please refer to the specifications of the individual protocols for detailed information on the security solutions they provide. 6. IANA Considerations This document has no actions for IANA. 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999. Brockners, et al. Expires December 5, 2009 [Page 18] Internet-Draft Review of NAT Control Protocols July 2009 [RFC3303] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and A. Rayhan, "Middlebox communication architecture and framework", RFC 3303, August 2002. [RFC3304] Swale, R., Mart, P., Sijben, P., Brim, S., and M. Shore, "Middlebox Communications (midcom) Protocol Requirements", RFC 3304, August 2002. [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.[RFC4540] Stiemerling, M., Quittek, J., and C. Cadar, "NEC's Simple Middlebox Configuration (SIMCO) Protocol Version 3.0", RFC 4540, May 2006. [RFC4097] Barnes M., "Middlebox Communications (MIDCOM) Protocol Evaluation", RFC 4097, June 2005. [RFC5189] Stiemerling, M., Quittek, J., and T. Taylor, "Middlebox Communications (MIDCOM) Protocol Semantics", RFC 5189, March 2008. [RFC5190] Quittek, J., Stiemerling, M., Srisuresh, P., "Definitions of Managed Objects for Middlebox Communication", RFC 5190, March 2008. [I-D.ietf-nsis-nslp-natfw] M. Stiemerling,H. Tschofenig, C. Aoun and E. Davies, "NAT/Firewall NSIS Signaling Layer Protocol (NSLP)", draft-ietf-nsis-nslp-natfw-20.txt(work in progress), November 2008 [I-D.ietf-nsis-ntlp] Schulzrinne, H. and R. Hancock, "GIST: General Internet Signalling Transport", draft-ietf-nsis-ntlp-20 (work in progress), June 2009. [I-D.moore-nat-xc] Moore, K., "IPv4/v6 NAT With Explicit Control (NAT-XC)", draft-moore-nat-xc-02(work in progress), March 2009. [I-D.woodyatt-spnatpmp-appl] Woddyatt, J., "Applicability of NAT-PMP with Service Provider Deployments of Network Address Translation", draft-woodyatt-spnatpmp-appl-01 (work in progress), November 2008. [I-D.cheshire-nat-pmp] Cheshir, S., Krochmal, M., Sekar, K., "NAT Port Mapping Protocol (NAT-PMP)", draft-cheshire-nat-pmp (work in progress), April 2008. Brockners, et al. Expires December 5, 2009 [Page 19] Internet-Draft Review of NAT Control Protocols July 2009 [I-D.nishitani-cgn] Nishitani, T. and S. Miyakawa, "Common Functions of Large Scale NAT (LSN) ", draft-nishitani-cgn-02 (work in progress), May 2009. [ITU-H.248.37] "Gateway control protocol: IP NAPT traversal package", ITU-T H.248.37, September 2005. [ITU-T-Q.3303.3] "Resource control protocol no. 3 (rcp3): Protocol at the Rw interface between the Policy Decision Physical Entity (PD-PE) and the Policy Enforcement Physical Entity (PE-PE): Diameter", ITU-T Recommendation Q.3303.3, 2008. [ITU-T-Q.3301.1] "Resource control protocol No. 1 - Protocol at the Rs interface between service control entities and the policy decision physical entity", ITU-T Q.3301.1, March 2007. [ETSI-TS183017] Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN);Resource and Admission Control: DIAMETER protocol for session based policy set-up information exchange between the Application Function (AF) and the Service Policy Decision Function (SPDF);Protocol specification; ETSI TS 183017, Version 2.3.1, September 2008. [ETSI-ES283018] Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN);Resource and Admission Control: H.248 Profile for controlling Border Gateway Functions (BGF) in the Resource and Admission Control Subsystem (RACS);Protocol specification, ETSI ES 283 018, Version 2.3.1, June 2008. [UPnP-IGD] UPnP Forum, "Universal Plug and Play (UPnP) Internet Gateway Device (IGD)", November 2001, 8. Author's Addresses Frank Brockners Cisco Systems, Inc. Hansaallee 249 40549 Duesseldorf Germany Email: fbrockne@cisco.com Brockners, et al. Expires December 5, 2009 [Page 20] Internet-Draft Review of NAT Control Protocols July 2009 Shwetha Bhandari Cisco Systems, Inc. Cessna Business Park, Sarjapura Marathalli Outer Ring Road Bangalore, KARNATAKA 560 087 India Email: shwethab@cisco.com Shashank Vikram Cisco Systems, Inc. Cessna Business Park, Sarjapura Marathalli Outer Ring Road Bangalore, KARNATAKA 560 087 India Email: svikram@cisco.com Pallavi Mishra Cisco Systems, Inc. Cessna Business Park, Sarjapura Marathalli Outer Ring Road Bangalore, KARNATAKA 560 087 India Email: palmishr@cisco.com Brockners, et al. Expires December 5, 2009 [Page 21]