Tech-invite3GPPspaceIETF RFCsSIP
9190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 6736

Diameter Network Address and Port Translation Control Application

Pages: 58
Proposed Standard
Part 1 of 3 – Pages 1 to 12
None   None   Next

Top   ToC   RFC6736 - 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.
Top   ToC   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   RFC6736 - 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   RFC6736 - 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   RFC6736 - 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   RFC6736 - 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   RFC6736 - 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   RFC6736 - 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   RFC6736 - 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   RFC6736 - 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   RFC6736 - 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   RFC6736 - 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 Section