[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
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,
             <http://www.upnp.org/standardizeddcps/igd.asp>



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]