RFC 6736
Diameter Network Address and Port Translation Control Application
Pages: 58
Proposed Standard
Proposed Standard
Part 1 of 3 – Pages 1 to 12
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 ApplicationAbstract
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.
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
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
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.
* 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
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.
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
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
+---------+ | | | 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.
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
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.
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)