tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 6736

Proposed STD
Pages: 58
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: DIME

Diameter Network Address and Port Translation Control Application

Part 1 of 3, p. 1 to 12
None       Next RFC Part

 


Top       ToC       Page 1 
Internet Engineering Task Force (IETF)                      F. Brockners
Request for Comments: 6736                                   S. Bhandari
Category: Standards Track                                          Cisco
ISSN: 2070-1721                                                 V. Singh

                                                              V. Fajardo
                                                  Telcordia Technologies
                                                            October 2012

   Diameter Network Address and Port Translation Control Application

Abstract

   This document describes the framework, messages, and procedures for
   the Diameter Network address and port translation Control
   Application.  This Diameter application allows per-endpoint control
   of Network Address Translators and Network Address and Port
   Translators, which are added to networks to cope with IPv4 address
   space depletion.  This Diameter application allows external devices
   to configure and manage a Network Address Translator device --
   expanding the existing Diameter-based Authentication, Authorization,
   and Accounting (AAA) and policy control capabilities with a Network
   Address Translator and Network Address and Port Translator control
   component.  These external devices can be network elements in the
   data plane such as a Network Access Server, or can be more
   centralized control plane devices such as AAA-servers.  This Diameter
   application establishes a context to commonly identify and manage
   endpoints on a gateway or server and a Network Address Translator and
   Network Address and Port Translator device.  This includes, for
   example, the control of the total number of Network Address
   Translator bindings allowed or the allocation of a specific Network
   Address Translator binding for a particular endpoint.  In addition,
   it allows Network Address Translator devices to provide information
   relevant to accounting purposes.

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc6736.

Page 2 
Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1. Introduction ....................................................4
   2. Conventions .....................................................6
   3. Deployment Framework ............................................7
      3.1. Deployment Scenario ........................................7
      3.2. Diameter NAPT Control Application Overview .................9
      3.3. Deployment Scenarios for DNCA .............................10
   4. DNCA Session Establishment and Management ......................12
      4.1. Session Establishment .....................................13
      4.2. Session Update ............................................16
      4.3. Session and Binding Query .................................18
      4.4. Session Termination .......................................20
      4.5. Session Abort .............................................21
      4.6. Failure Cases of the DNCA Diameter Peers ..................22
   5. Use of the Diameter Base Protocol ..............................23
      5.1. Securing Diameter Messages ................................23
      5.2. Accounting Functionality ..................................24
      5.3. Use of Sessions ...........................................24
      5.4. Routing Considerations ....................................24
      5.5. Advertising Application Support ...........................24
   6. DNCA Commands ..................................................25
      6.1. NAT-Control-Request (NCR) Command .........................25
      6.2. NAT-Control-Answer (NCA) Command ..........................26
   7. NAT Control Application Session State Machine ..................26
   8. DNCA AVPs ......................................................29
      8.1. Reused Base Protocol AVPs .................................29
      8.2. Additional Result-Code AVP Values .........................30
           8.2.1. Success ............................................30
           8.2.2. Transient Failures .................................30
           8.2.3. Permanent Failures .................................31

Top      ToC       Page 3 
      8.3. Reused NASREQ Diameter Application AVPs ...................32
      8.4. Reused AVPs from RFC 4675 .................................33
      8.5. Reused AVPs from Diameter QoS Application .................33
      8.6. Reused AVPs from ETSI ES 283 034, e4 Diameter
           Application ...............................................34
      8.7. DNCA-Defined AVPs .........................................35
           8.7.1. NC-Request-Type AVP ................................36
           8.7.2. NAT-Control-Install AVP ............................36
           8.7.3. NAT-Control-Remove AVP .............................37
           8.7.4. NAT-Control-Definition AVP .........................37
           8.7.5. NAT-Internal-Address AVP ...........................38
           8.7.6. NAT-External-Address AVP ...........................38
           8.7.7. Max-NAT-Bindings ...................................39
           8.7.8. NAT-Control-Binding-Template AVP ...................39
           8.7.9. Duplicate-Session-Id AVP ...........................39
           8.7.10. NAT-External-Port-Style AVP .......................39
   9. Accounting Commands ............................................40
      9.1. NAT Control Accounting Messages ...........................40
      9.2. NAT Control Accounting AVPs ...............................40
           9.2.1. NAT-Control-Record .................................41
           9.2.2. NAT-Control-Binding-Status .........................41
           9.2.3. Current-NAT-Bindings ...............................41
   10. AVP Occurrence Tables .........................................41
      10.1. DNCA AVP Table for NAT Control Initial and Update
            Requests .................................................42
      10.2. DNCA AVP Table for Session Query Requests ................43
      10.3. DNCA AVP Table for Accounting Messages ...................43
   11. IANA Considerations ...........................................44
      11.1. Application Identifier ...................................44
      11.2. Command Codes ............................................44
      11.3. AVP Codes ................................................44
      11.4. Result-Code AVP Values ...................................44
      11.5. NC-Request-Type AVP ......................................44
      11.6. NAT-External-Port-Style AVP ..............................45
      11.7. NAT-Control-Binding-Status AVP ...........................45
   12. Security Considerations .......................................45
   13. Examples ......................................................47
      13.1. DNCA Session Establishment Example .......................47
      13.2. DNCA Session Update with Port Style Example ..............50
      13.3. DNCA Session Query Example ...............................51
      13.4. DNCA Session Termination Example .........................53
   14. Acknowledgements ..............................................55
   15. References ....................................................55
      15.1. Normative References .....................................55
      15.2. Informative References ...................................56

Top      ToC       Page 4 
1.  Introduction

   Internet service providers deploy Network Address Translators (NATs)
   and Network Address and Port Translators (NAPTs) [RFC3022] in their
   networks.  A key motivation for doing so is the depletion of
   available public IPv4 addresses.  This document defines a Diameter
   application allowing providers to control the behavior of NAT and
   NAPT devices that implement IPv4-to-IPv4 network address and port
   translation [RFC2663] as well as stateful IPv6-to-IPv4 address family
   translation as defined in [RFC2663], [RFC6145], and [RFC6146].  The
   use of a Diameter application allows for simple integration into the
   existing Authentication, Authorization, and Accounting (AAA)
   environment of a provider.

   The Diameter Network address and port translation Control Application
   (DNCA) offers the following capabilities:

   1.  Limits or defines the number of NAPT/NAT-bindings made available
       to an individual endpoint.  The main motivation for restricting
       the number of bindings on a per-endpoint basis is to protect the
       service of the service provider against denial-of-service (DoS)
       attacks.  If multiple endpoints share a single public IP address,
       these endpoints can share fate.  If one endpoint would (either
       intentionally, or due to misbehavior, misconfiguration, malware,
       etc.) be able to consume all available bindings for a given
       single public IP address, service would be hampered (or might
       even become unavailable) for those other endpoints sharing the
       same public IP address.  The efficiency of a NAPT deployment
       depends on the maximum number of bindings an endpoint could use.
       Given that the typical number of bindings an endpoint uses
       depends on the type of endpoint (e.g., a personal computer of a
       broadband user is expected to use a higher number of bindings
       than a simple mobile phone) and a NAPT device is often shared by
       different types of endpoints, it is desirable to actively manage
       the maximum number of bindings.  This requirement is specified in
       REQ-3 of [CGN-REQS].

   2.  Supports the allocation of specific NAPT/NAT-bindings.  Two types
       of specific bindings can be distinguished:

       *  Allocation of a predefined NAT-binding: The internal and
          external IP addresses as well as the 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, benefit from statically configured bindings.

Top      ToC       Page 5 
       *  Allocation of an external IP address for a given internal IP
          address: The allocated external IP address is reported back to
          the requester.  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; for example, SIP-proxy server
          deployments.

   3.  Defines the external address pool(s) to be used for allocating an
       external IP address: External address pools can be either pre-
       assigned at the NAPT/NAT device or specified within a request.
       If pre-assigned address pools are used, a request needs to
       include a reference to identify the pool.  Otherwise, the request
       contains a description of the IP address pool(s) to be used, for
       example, a list of IP-subnets.  Such external address pools can
       be used to select the external IP address in NAPT/NAT-bindings
       for multiple subscribers.

   4.  Generates reports and accounting records: Reports established
       bindings for a particular endpoint.  The collected information is
       used by accounting systems for statistical purposes.

   5.  Queries and retrieves details about bindings on demand: This
       feature complements the previously mentioned accounting
       functionality (see item 4).  This feature can be used by an
       entity to find NAT-bindings belonging to one or multiple
       endpoints on the NAT device.  The entity is not required to
       create a DNCA control session to perform the query but would,
       obviously, still need to create a Diameter session complying to
       the security requirements.

   6.  Identifies a subscriber or endpoint on multiple network devices
       (NAT/NAPT device, the AAA-server, or the Network Access Server
       (NAS)): Endpoint identification is facilitated through a Global
       Endpoint ID.  Endpoints are identified through a single
       classifier or a set of classifiers, such as IP address, Virtual
       Local Area Network (VLAN) identifier, or interface identifier
       that uniquely identify the traffic associated with a particular
       global endpoint.

   With the above capabilities, DNCA qualifies as a Middlebox
   Communications (MIDCOM) protocol [RFC3303], [RFC3304], [RFC5189] for
   middleboxes that perform NAT.  The MIDCOM protocol evaluation
   [RFC4097] evaluated Diameter as a candidate protocol for MIDCOM.
   DNCA provides the extensions to the Diameter base protocol [RFC6733]
   following the MIDCOM protocol requirements, such as the support of
   NAT-specific rule transport, support for oddity of mapped ports, as
   well as support for consecutive range port numbers.  DNCA adds to the

Top      ToC       Page 6 
   MIDCOM protocol capabilities in that it allows the maintenance of the
   reference to an endpoint representing a user or subscriber in the
   control operation, enabling the control of the behavior of a NAT
   device on a per-endpoint basis.  Following the requirements of
   different operators and deployments, different management protocols
   are employed.  Examples include, for example, Simple Network
   Management Protocol (SNMP) [RFC3411] and Network Configuration
   (NETCONF) [RFC6241], which can both be used for device configuration.
   Similarly, DNCA complements existing MIDCOM implementations, offering
   a MIDCOM protocol option for operators with an operational
   environment that is Diameter focused that desire the use of Diameter
   to perform per-endpoint NAT control.  Note that in case an operator
   uses multiple methods and protocols to configure a NAT device, such
   as, for example, command line interface (CLI), SNMP, NETCONF, or Port
   Control Protocol (PCP), along with DNCA specified in this document,
   the operator MUST ensure that the configurations performed using the
   different methods and protocols do not conflict in order to ensure a
   proper operation of the NAT service.

   This document is structured as follows: Section 2 lists terminology,
   while Section 3 provides an introduction to DNCA and its overall
   deployment framework.  Sections 3.2 to 8 cover DNCA specifics, with
   Section 3.2 describing session management, Section 5 the use of the
   Diameter base protocol, Section 6 new commands, Section 8 Attribute
   Value Pairs (AVPs) used, and Section 9 accounting aspects.
   Section 10 presents AVP occurrence tables.  IANA and security
   considerations are addressed in Sections 11 and 12, respectively.

2.  Conventions

   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 and terminology used in this document:

      AAA: Authentication, Authorization, Accounting

      DNCA: Diameter Network address and port translation Control
      Application

      Endpoint: Managed entity of the DNCA.  An endpoint represents a
      network element or device, associated with a subscriber, a user,
      or a group of users.  An endpoint is represented by a single
      access-session on a NAS.  DNCA assumes a 1:1 relationship between
      an endpoint, the access-session it represents, and the associated
      DNCA session.

Top      ToC       Page 7 
      NAPT: Network Address and Port Translation, see also [RFC3022].

      NAT: Network Address Translation (NAT and NAPT are used in this
      document interchangeably)

      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-binding predefined template: A policy template or
      configuration that is predefined at the NAT device.  It may
      contain NAT-bindings, IP address pools for allocating the external
      IP address of a NAT-binding, the maximum number of allowed NAT-
      bindings for endpoints, etc.

      NAT device: Network Address Translator or Network Address and Port
      Translator: An entity performing NAT or NAPT.

      NAT controller: Entity controlling the behavior of a NAT device.

      NAS: Network Access Server

      NCR: NAT-Control-Request

      NCA: NAT-Control-Answer

      NAT44: IPv4-to-IPv4 NAPT, see [RFC2663]

      NAT64: IPv6-to-IPv4 address family translation, see [RFC6145] and
      [RFC6146]

      PPP: Point-to-Point Protocol [RFC1661]

3.  Deployment Framework

3.1.  Deployment Scenario

   Figure 1 shows a typical network deployment for IPv4 Internet access.
   A user's IPv4 host (i.e., endpoint) gains access to the Internet
   though a NAS, which facilitates the authentication of the endpoint
   and configures the endpoint's connection according to the
   authorization and configuration data received from the AAA-server
   upon successful authentication.  Public IPv4 addresses are used
   throughout the network.  DNCA manages an endpoint that represents a
   network element or device or an IPv4 host, associated with a
   subscriber, a user or a group of users.  An endpoint is represented

Top      ToC       Page 8 
   by a single access-session on a NAS.  DNCA assumes a 1:1:1
   relationship between an endpoint, the access-session it represents,
   and the associated DNCA session.

                         +---------+
                         |         |
                         |   AAA   |
                         |         |
                         +---------+
                              |
                              |
                              |
                              |
    +---------+          +---------+             +----------+
    |  IPv4   |          |         |             |  IPv4    |
    |  Host   |----------|   NAS   |-------------| Internet |
    |         |          |         |             |          |
    +---------+          +---------+             +----------+

    <-------------------- Public IPv4 ---------------------->

         Figure 1: Typical Network Deployment for Internet Access

   Figure 2 depicts the deployment scenario where a service provider
   places a NAT between the host and the public Internet.  The objective
   is to provide the customer with connectivity to the public IPv4
   Internet.  The NAT device performs network address and port (and
   optionally address family) translation, depending on whether the
   access network uses private IPv4 addresses or public IPv6 addresses
   to public IPv4 addresses.  Note that there may be more than one NAS,
   NAT device, or AAA-entity in a deployment, although the figures only
   depict one entity each for clarity.

   If the NAT device would be put in place without any endpoint
   awareness, the service offerings of the service provider could be
   impacted as detailed in [CGN-REQS].  This includes cases like the
   following:

   o  Provisioning static NAT-bindings for particular endpoints

   o  Using different public IP address pools for a different set of
      endpoints (for example, residential or business customers)

   o  Reporting allocated bindings on a per-endpoint basis

   o  Integrate control of the NAT device into the already existing per-
      endpoint management infrastructure of the service provider

Top      ToC       Page 9 
                   +---------+
                   |         |
                   |   AAA   |
                   |         |
                   +---------+
                        |
                        |
                        |
                        |
     +--------+    +---------+    +--------+    +----------+
     |  IPv4  |----|         |----|  NAT-  |----| IPv4     |
     |  Host  |    |   NAS   |    | device |    | Internet |
     |        |    |         |    |        |    |          |
     +--------+    +---------+    +--------+    +----------+

   For NAT44 deployments (IPv4 host):
        <----- Private IPv4 ----------><--- Public IPv4 --->

   For NAT64 deployments (IPv6 host):
        <----- Public  IPv6 ----------><--- Public IPv4 --->

               Figure 2: Access Network Deployment with NAT

   Figure 2 shows a typical deployment for IPv4 Internet access
   involving a NAT device within the service provider network.  The
   figure describes two scenarios: one where an IPv4 host (with a
   private IPv4 address) accesses the IPv4 Internet, as well as one
   where an IPv6-host accesses the IPv4 Internet.

3.2.  Diameter NAPT Control Application Overview

   DNCA runs between two DNCA Diameter peers.  One DNCA Diameter peer
   resides within the NAT device, the other DNCA Diameter peer resides
   within a NAT controller (discussed in Section 3.3).  DNCA allows per-
   endpoint control and management of NAT within the NAT device.  Based
   on Diameter, DNCA integrates well with the suite of Diameter
   applications deployed for per-endpoint authentication, authorization,
   accounting, and policy control in service provider networks.

   DNCA offers:

   o  Request and answer commands to control the allowed number of NAT-
      bindings per endpoint, to request the allocation of specific
      bindings for an endpoint, to define the address pool to be used
      for an endpoint.

   o  Per-endpoint reporting of the allocated NAT-bindings.

Top      ToC       Page 10 
   o  Unique identification of an endpoint on a NAT device, AAA-server,
      and NAS to simplify correlation of accounting data streams.

   DNCA allows controlling the behavior of a NAT device on a per-
   endpoint basis during initial session establishment and at later
   stages by providing an update procedure for already established
   sessions.  Using DNCA, per-endpoint NAT-binding information can be
   retrieved using either accounting mechanisms or an explicit session
   query to the NAT.

3.3.  Deployment Scenarios for DNCA

   DNCA can be deployed in different ways.  DNCA supports deployments
   with "n" NAT controllers and "m" NAT devices, with n and m equal to
   or greater than 1.  From a DNCA perspective, an operator should
   ensure that the session representing a particular endpoint is atomic.
   Any deployment MUST ensure that, for any given endpoint, only a
   single DNCA NAT controller and is active at any point in time.  This
   is to ensure that NAT devices controlled by multiple NAT controllers
   do not receive conflicting control requests for a particular endpoint
   or that they would not be unclear about to which NAT controller to
   send accounting information.  Operational considerations MAY require
   an operator to use alternate control mechanisms or protocols such as
   SNMP or manual configuration via a CLI to apply per-endpoint NAT-
   specific configuration, for example, static NAT-bindings.  For these
   cases, the NAT device MUST allow the operator to configure a policy
   on how configuration conflicts are resolved.  Such a policy could
   specify, for example, that manually configured NAT-bindings using the
   CLI always take precedence over those configured using DNCA.

   Two common deployment scenarios are outlined in Figure 3 ("Integrated
   Deployment") and Figure 4 ("Autonomous Deployment").  Per the note
   above, multiple instances of NAT controllers and NAT devices could be
   deployed.  The figures only show single instances for reasons of
   clarity.  The two shown scenarios differ in which entity fulfills the
   role of the NAT controller.  Within the figures, (C) denotes the
   network element performing the role of the NAT controller.

   The integrated deployment approach hides the existence of the NAT
   device from external servers, such as the AAA-server.  It is suited
   for environments where minimal changes to the existing AAA deployment
   are desired.  The NAS and the NAT device are Diameter peers
   supporting the DNCA.  The Diameter peer within the NAS, performing
   the role of the NAT controller, initiates and manages sessions with
   the NAT device, exchanges NAT-specific configuration information, and
   handles reporting and accounting information.  The NAS receives
   reporting and accounting information from the NAT device.  With this

Top      ToC       Page 11 
   information, the NAS can provide a single accounting record for the
   endpoint.  A system correlating the accounting information received
   from the NAS and NAT device would not be needed.

   An example network attachment for an integrated NAT deployment can be
   described as follows: an endpoint connects to the network, with the
   NAS being the point of attachment.  After successful authentication,
   the NAS receives endpoint-related authorization data from the AAA-
   server.  A portion of the authorization data applies to per-endpoint
   configuration on the NAS itself, another portion describes
   authorization and configuration information for NAT control aimed at
   the NAT device.  The NAS initiates a DNCA session to the NAT device
   and sends relevant authorization and configuration information for
   the particular endpoint to the NAT device.  This can comprise NAT-
   bindings, which have to be pre-established for the endpoint, or
   management-related configuration, such as the maximum number of NAT-
   bindings allowed for the endpoint.  The NAT device sends its per-
   endpoint accounting information to the NAS, which aggregates the
   accounting information received from the NAT device with its local
   accounting information for the endpoint into a single accounting
   stream towards the AAA-server.

                   +---------+
                   |         |
                   |   AAA   |
                   |         |
                   +---------+
                        |
                        |
                        |
     +--------+    +---------+    +--------+    +----------+
     |        |    |   (C)   |    |        |    |          |
     |  Host  |----|   NAS   |----|  NAT-  |----| IPv4     |
     |        |    |         |    | device |    | Internet |
     +--------+    +---------+    +--------+    +----------+

   For NAT44 deployments (IPv4 host):
        <----- Private IPv4 ----------><--- Public IPv4 --->

   For NAT64 deployments (IPv6 host):
        <----- Public  IPv6 ----------><--- Public IPv4 --->

          Figure 3: NAT Control Deployment: Integrated Deployment

   Figure 3 shows examples of integrated deployments.  It illustrates
   two scenarios: one where an IPv4 host (with a private IPv4 address)
   accesses the IPv4 Internet and another where an IPv6 host accesses
   the IPv4 Internet.

Top      ToC       Page 12 
   The autonomous deployment approach decouples endpoint management on
   the NAS and NAT device.  In the autonomous deployment approach, the
   AAA-system and the NAT device are the Diameter peers running the
   DNCA.  The AAA-system also serves as NAT controller.  It manages the
   connection to the NAT device, controls the per-endpoint
   configuration, and receives accounting and reporting information from
   the NAT device.  Different from the integrated deployment scenario,
   the autonomous deployment scenario does not "hide" the existence of
   the NAT device from the AAA infrastructure.  Here, two accounting
   streams are received by the AAA-server for one particular endpoint:
   one from the NAS and one from the NAT device.

                   +---------+
                   |   (C)   |
                   |   AAA   |---------
                   |         |         |
                   +---------+         |
                        |              |
                        |              |
                        |              |
     +--------+    +---------+    +---------+    +----------+
     |  IPv4/ |    |         |    |         |    |  IPv4    |
     |  IPv6  |----|   NAS   |----|  NAT-   |----| Internet |
     |  Host  |    |         |    | device  |    |          |
     +--------+    +---------+    +---------+    +----------+

   For NAT44 deployments (IPv4 host):
        <----- Private IPv4 ----------><--- Public IPv4 --->

   For NAT64 deployments (IPv6 host):
        <----- Public  IPv6 ----------><--- Public IPv4 --->

          Figure 4: NAT Control Deployment: Autonomous Deployment

   Figure 4 shows examples of autonomous deployments.  It illustrates
   two scenarios: one where an IPv4 host (with a private IPv4 address)
   accesses the IPv4 Internet and another where an IPv6 host accesses
   the IPv4 Internet.



(page 12 continued on part 2)

Next RFC Part