RFC 6736
Diameter Network Address and Port Translation Control Application
RFC 6736: Diameter Network Address and Port Translation Control Application 🎀
Okay so this RFC is called Diameter Network Address and Port Translation Control Application, and it's a Standards Track document from October 2012 💖. The authors are F. Brockners, S. Bhandari, and V. Singh from Cisco, plus V. Fajardo from Telcordia Technologies 🧚. Its ISSN is 2070-1721. The title block doesn't list anything it obsoletes or updates ✨.
Abstract 🌸
Bestie, this document is all about the framework, messages, and procedures for the Diameter Network address and port translation Control Application. It lets you control each endpoint on the NAT (Network Address Translator) and NAPT (Network Address and Port Translator) boxes that networks added to cope with IPv4 address space depletion 😭. The whole point is that external devices can configure and manage a NAT device, which expands the Diameter-based AAA (Authentication, Authorization, and Accounting) and policy control stuff with a NAT and NAPT control component 💅.
Those external devices can be data plane network elements, like a Network Access Server, or more centralized control plane devices, like AAA-servers 🔥. The application sets up a context so you can commonly identify and manage endpoints on a gateway or server and on a NAT or NAPT device. For example, you can control the total number of NAT bindings that are allowed, or give a specific NAT binding to one particular endpoint 🦋. It's also giving accounting energy, because NAT devices can share information that's relevant to accounting 👑.
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 ...................................561. Introduction ✨
okay bestie, so internet service providers put Network Address Translators (NATs) and Network Address and Port Translators (NAPTs) [RFC3022] all over their networks 🌐. the big reason? they're running out of public IPv4 addresses 😭. this document defines a Diameter application that lets providers control how NAT and NAPT devices behave 💅. it covers IPv4-to-IPv4 network address and port translation [RFC2663] and stateful IPv6-to-IPv4 address family translation as defined in [RFC2663], [RFC6145], and [RFC6146] 🦋. using Diameter means it slots right into a provider's existing Authentication, Authorization, and Accounting (AAA) setup, which is so convenient 🫶.
the Diameter Network address and port translation Control Application (DNCA) gives you these capabilities 👑:
- Limit or define how many NAPT/NAT-bindings an individual endpoint gets. this is the main way to protect the provider's service from denial-of-service (DoS) attacks 🛡️. if a bunch of endpoints share one public IP address, they share fate. if one endpoint (on purpose, or because of misbehavior, misconfiguration, malware, etc.) grabs every binding for that public IP, everyone else sharing it gets hampered or might even lose service entirely 💀. the more bindings an endpoint can use, the less efficient the NAPT deployment is. and since a personal computer on a broadband connection is expected to use way more bindings than a simple mobile phone, and one NAPT device is often shared by different kinds of endpoints, actively managing the maximum number of bindings is highly desirable 🔥. this requirement is specified in REQ-3 of [CGN-REQS] ✨.
- Support allocating specific NAPT/NAT-bindings. there are two flavors here 🍓:
- * Allocation of a predefined NAT-binding: the internal and external IP addresses, plus the port pair, are specified in the request. some setups, like reaching a web-server inside a user's home network by IP address and port, really benefit from statically configured bindings 🏠.
- * Allocation of an external IP address for a given internal IP address: the allocated external IP address gets reported back to the requester. in some deployments the application needs to know the allocated binding for a given internal IP address right away, but doesn't get to control which external IP address gets picked. SIP-proxy server deployments are a classic example 📞.
- Define the external address pool(s) used for allocating an external IP address. external address pools can either be pre-assigned at the NAPT/NAT device or specified within a request 🌊. if pre-assigned pools are used, the request needs to include a reference that identifies the pool. otherwise, the request carries a description of the IP address pool(s) to use, like a list of IP-subnets. these pools can be used to pick the external IP address in NAPT/NAT-bindings for multiple subscribers 🎀.
- Generate reports and accounting records. this reports established bindings for a particular endpoint, and the accounting systems use that info for statistics 📊.
- Query and retrieve details about bindings on demand. this complements the accounting feature from item 4 🔍. an entity can use it to find the NAT-bindings belonging to one or more endpoints on the NAT device. the entity doesn't have to create a DNCA control session to do the query, but it would obviously still need to create a Diameter session that complies with the security requirements 🔐.
- Identify a subscriber or endpoint across multiple network devices (the NAT/NAPT device, the AAA-server, or the Network Access Server (NAS)) 🧚. endpoint identification is handled through a Global Endpoint ID. endpoints are identified by a single classifier or a set of classifiers, like an IP address, a Virtual Local Area Network (VLAN) identifier, or an interface identifier, that uniquely identify the traffic belonging to a particular global endpoint 💜.
with all of that, DNCA qualifies as a Middlebox Communications (MIDCOM) protocol [RFC3303], [RFC3304], [RFC5189] for middleboxes that perform NAT 🌈. the MIDCOM protocol evaluation [RFC4097] looked at Diameter as a candidate protocol for MIDCOM ✨. DNCA adds extensions to the Diameter base protocol [RFC6733] that follow the MIDCOM protocol requirements, like support for NAT-specific rule transport, support for oddity of mapped ports, and support for consecutive range port numbers 🦋. where DNCA goes further is that it lets you maintain a reference to an endpoint representing a user or subscriber during the control operation, so you can control a NAT device's behavior on a per-endpoint basis 👑. different operators and deployments use different management protocols. examples include the Simple Network Management Protocol (SNMP) [RFC3411] and Network Configuration (NETCONF) [RFC6241], which can both be used for device configuration 🛠️. DNCA complements existing MIDCOM implementations by offering a MIDCOM protocol option for operators whose environment is Diameter-focused and who want Diameter to do per-endpoint NAT control 💖.
⚠️ bestie, listen up: if an operator uses multiple methods and protocols to configure a NAT device (like a command line interface (CLI), SNMP, NETCONF, or Port Control Protocol (PCP), alongside DNCA from this document), the operator MUST ensure that the configurations made through those different methods and protocols do not conflict. otherwise the NAT service won't run properly 😭.
this document is laid out like this 🗺️: Section 2 lists the terminology, and Section 3 introduces DNCA and its overall deployment framework. Sections 3.2 to 8 cover the DNCA specifics: Section 3.2 describes session management, Section 5 covers the use of the Diameter base protocol, Section 6 covers new commands, Section 8 covers the Attribute Value Pairs (AVPs) used, and Section 9 covers accounting aspects. Section 10 presents the 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] 📖.
here are the abbreviations and terminology used in this document 💅:
- AAA: Authentication, Authorization, Accounting
- DNCA: Diameter Network address and port translation Control Application
- Endpoint: the 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: an association of two IP address/port pairs (usually one private and one public) that facilitates NAT 🦋.
- NAT-binding predefined template: a policy template or configuration 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: a Network Address Translator or Network Address and Port Translator, meaning an entity performing NAT or NAPT 🏰.
- NAT controller: the 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] 4️⃣.
- NAT64: IPv6-to-IPv4 address family translation, see [RFC6145] and [RFC6146] 6️⃣.
- PPP: Point-to-Point Protocol [RFC1661] 🚋.
3. Deployment Framework 🧚♀️
3.1. Deployment Scenario 🌸
okay so Figure 1 is the typical setup for IPv4 internet access, and it's giving simple 💅. A user's IPv4 host (aka the endpoint) gets online through a NAS. The NAS handles authentication and then sets up the endpoint's connection using the authorization and config data it gets from the AAA-server once the login works ✨. Public IPv4 addresses are used everywhere in this one. DNCA manages an endpoint, which can be a network element or device, or an IPv4 host tied to a subscriber, a user, or a group of users 🫶. Each endpoint is represented by one access-session on a NAS. DNCA treats it as a 1:1:1 relationship between the endpoint, the access-session that represents it, and the matching DNCA session. Iconic logic 👑
+---------+
| |
| AAA |
| |
+---------+
|
|
|
|
+---------+ +---------+ +----------+
| IPv4 | | | | IPv4 |
| Host |----------| NAS |-------------| Internet |
| | | | | |
+---------+ +---------+ +----------+
<-------------------- Public IPv4 ---------------------->
Figure 1: Typical Network Deployment for Internet AccessFigure 2 is where it gets spicy 🌶️ The service provider drops a NAT between the host and the public internet, so the customer can still reach the public IPv4 internet. The NAT device does network address and port translation, and it can also do address family translation, depending on whether the access network uses private IPv4 addresses or public IPv6 addresses going out to public IPv4 addresses. Also, there can be more than one NAS, NAT device, or AAA-entity in a deployment. The figures only show one of each because it's easier to read 🦋
If the NAT device shows up with no endpoint awareness at all, the provider's service offerings can get messed up, as explained in [CGN-REQS]. Stuff like this can break:
- Provisioning static NAT-bindings for particular endpoints
- Using different public IP address pools for a different set of endpoints (for example, residential or business customers)
- Reporting allocated bindings on a per-endpoint basis
- Integrating 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 NATFigure 2 is a typical IPv4 internet access setup with a NAT device sitting inside the service provider network 🧠 It covers two cases: an IPv4 host with a private IPv4 address getting onto the IPv4 internet, and an IPv6 host getting onto the IPv4 internet too. Two scenarios, one diagram, lots of vibes ✨
3.2. Diameter NAPT Control Application Overview 🧚
DNCA runs between two DNCA Diameter peers. One peer lives inside the NAT device, and the other lives inside a NAT controller (more on that in Section 3.3). DNCA lets you control and manage NAT on a per-endpoint basis inside the NAT device 💜 Since it's built on Diameter, it plays really nicely with the whole family of Diameter applications that service providers already use for per-endpoint authentication, authorization, accounting, and policy control. Main character energy, no cap 🎀
DNCA offers:
- Request and answer commands to control how many NAT-bindings an endpoint is allowed, to ask for specific bindings for an endpoint, and to define which address pool an endpoint uses
- Per-endpoint reporting of the allocated NAT-bindings
- Unique identification of an endpoint across a NAT device, AAA-server, and NAS, which makes correlating accounting data way easier 📊
DNCA lets you control how a NAT device behaves for each endpoint, both when the session first gets set up and later on, since it has an update procedure for sessions that already exist 🦋 You can grab per-endpoint NAT-binding info either through accounting mechanisms or by sending an explicit session query to the NAT.
3.3. Deployment Scenarios for DNCA 💖
DNCA can be deployed in a bunch of different ways 🌈 It supports deployments with "n" NAT controllers and "m" NAT devices, where both n and m are equal to or greater than 1. From DNCA's point of view, the operator should make sure the session for a particular endpoint is atomic. Any deployment MUST ensure that, for any given endpoint, only a single DNCA NAT controller is active at any point in time 🚫 The reason is so NAT devices controlled by multiple NAT controllers don't get conflicting control requests for the same endpoint, and so they don't get confused about which NAT controller should receive accounting information. Operational considerations MAY require an operator to use other control mechanisms or protocols, like SNMP or manual configuration through a CLI, to apply per-endpoint NAT-specific configuration such as static NAT-bindings 🛠️ In those cases, the NAT device MUST allow the operator to configure a policy for how configuration conflicts get resolved. For example, that policy could say manually configured NAT-bindings made through the CLI always win over the ones configured with DNCA 👑
Two common deployment scenarios are shown in Figure 3 ("Integrated Deployment") and Figure 4 ("Autonomous Deployment"). Like the note above says, you could have multiple NAT controller and NAT device instances. The figures only show single instances for clarity 🧚 The two scenarios differ in which entity plays the NAT controller role. In the figures, (C) marks the network element acting as the NAT controller.
The integrated deployment hides the NAT device from external servers, like the AAA-server 🫣 It's a good fit when you want minimal changes to the existing AAA deployment. The NAS and the NAT device are both Diameter peers supporting DNCA. The Diameter peer inside the NAS is the NAT controller. It starts and manages sessions with the NAT device, exchanges NAT-specific configuration info, and handles reporting and accounting. The NAS gets reporting and accounting info from the NAT device too, so it can produce a single accounting record for the endpoint. You don't need a separate system to correlate accounting data from the NAS and NAT device, which is honestly a huge win 🙌
Here's an example of how an integrated NAT deployment attachment goes: an endpoint connects to the network, and the NAS is its point of attachment. After successful authentication, the NAS gets endpoint-related authorization data from the AAA-server. Part of that data applies to per-endpoint configuration on the NAS itself. Another part describes authorization and configuration for NAT control aimed at the NAT device. The NAS starts a DNCA session to the NAT device and sends the relevant authorization and configuration info for that endpoint. That can include NAT-bindings that need to be pre-established for the endpoint, or management config like the max number of NAT-bindings allowed for the endpoint 📦 The NAT device sends its per-endpoint accounting info to the NAS. The NAS combines that with its own local accounting info for the endpoint and sends it on as one accounting stream to 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 DeploymentFigure 3 shows integrated deployment examples with two scenarios: an IPv4 host with a private IPv4 address getting onto the IPv4 internet, and an IPv6 host getting onto the IPv4 internet 🎀
The autonomous deployment approach splits up endpoint management between the NAS and the NAT device 🦋 In this one, the AAA-system and the NAT device are the Diameter peers running DNCA. The AAA-system is also the NAT controller. It manages the connection to the NAT device, controls the per-endpoint configuration, and gets accounting and reporting info from the NAT device. Unlike the integrated approach, autonomous deployment does not hide the NAT device from the AAA infrastructure 👀 So the AAA-server ends up receiving two accounting streams for one endpoint: one from the NAS and one from the NAT device. Different vibes, same goal 💅
+---------+
| (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 DeploymentFigure 4 shows autonomous deployment examples with two scenarios: an IPv4 host with a private IPv4 address getting onto the IPv4 internet, and an IPv6 host getting onto the IPv4 internet 💜
4. DNCA Session Establishment and Management ✨
Okay bestie, from this point on we're gonna be talking about a bunch of DNCA commands and AVPs, so if you want the full details, peek at Sections 6 and 8 🧚. DNCA runs between a Diameter peer living in a NAT controller and a Diameter peer living in a NAT device 🌸. Remember how we said each DNCA session between those two is basically one endpoint? An endpoint can be a network element, a device, or an IPv4 host tied to a subscriber, a user, or a group of users 💅. The Diameter peer in the NAT controller is always the control-requesting one. It starts, updates, or terminates the sessions 👑. A session kicks off when the NAT controller learns about a new endpoint (aka a host) that needs a NAT service 🦋. That could happen because the entity hosting the NAT controller gets authentication, authorization, or accounting requests for or from the endpoint 😭. Other ways to trigger setup are local configuration, or getting a packet from an IP address it's never seen before, etc. 🫶
4.1. Session Establishment
The DNCA Diameter peer in the NAT controller sets up a session with the DNCA Diameter peer in the NAT device so it can control how the NAT function behaves there 💖. During setup, the controller-side peer passes along the config info: the max number of bindings allowed for the endpoint, a set of predefined NAT-bindings to create for this endpoint, or a description of the address pool that external addresses get pulled from 🎀.
The controller-side peer sends a NAT-Control-Request (NCR) to the device-side peer with the NC-Request-Type AVP set to INITIAL_REQUEST to start a Diameter NAT control session 🔥. When the NCR shows up, the device-side peer sets up a new session for the endpoint matching the endpoint classifier(s) in that NCR 👑. If it all works out, the device-side peer lets the controller know with a NAT-Control-Answer (NCA) that has the Result-Code set to DIAMETER_SUCCESS ✨. Figure 5 shows this first back-and-forth, so check it out 🌈.
The initial NAT-Control-Request MAY contain configuration information for the session, which specifies the behavior of the NAT device for the session. The config info that MAY be included is:
- A list of NAT-bindings, which should be pre-allocated for the session; for example, in case an endpoint requires a fixed external IP address/port pair for an application.
- The maximum number of NAT-bindings allowed for an endpoint.
- A description of the external IP address pool(s) to be used for the session.
- A reference to a NAT-binding Predefined template on the NAT device, which is applied to the session. Such a NAT-binding Predefined template on the NAT device may contain, for example, the name of the IP address pool from which external IP addresses should be allocated, the maximum number of bindings permitted for the endpoint, etc.
Now, sometimes the NAT device just can't do what the NCR is asking 😭. Here's when that happens:
- If a DNCA Diameter peer within the NAT device receives an NCR from a DNCA Diameter peer within a NAT controller with the
NC-Request-TypeAVP set toINITIAL_REQUESTthat identifies an already existing session, that is, the endpoint identifier matches an already existing session, the DNCA Diameter peer within the NAT device MUST return an NCA with theResult-Codeset toSESSION_EXISTSand provide the Session-Id of the existing session in theDuplicate-Session-IdAVP. - If a DNCA Diameter peer within the NAT device receives an NCR from a DNCA Diameter peer within a NAT controller with the
NC-Request-TypeAVP set toINITIAL_REQUESTthat matches more than one of the already existing sessions, that is, the DNCA Diameter peer and endpoint identifier match already existing sessions, the DNCA Diameter peer within the NAT device MUST return an NCA with theResult-Codeset toINSUFFICIENT-CLASSIFIERS. In case a DNCA Diameter peer receives an NCA that reports Insufficient-Classifiers, it MAY choose to retry establishing a new session using additional or more specific classifiers. - If the NCR contains a NAT-binding Predefined template not defined on the NAT device, the DNCA Diameter peer within the NAT device MUST return an NCA with the
Result-CodeAVP set toUNKNOWN_BINDING_TEMPLATE_NAME. - In case the NAT device is unable to establish all of the bindings requested in the NCR, the DNCA Diameter peer MUST return an NCA with the
Result-Codeset toBINDING_FAILURE. A DNCA Diameter peer within a NAT device MUST treat an NCR as an atomic operation; hence, none of the requested bindings will be established by the NAT device. Either all requested actions within an NCR MUST be completed successfully or the entire request fails. - If a NAT device cannot conform to a request to set the maximum number of NAT-bindings allowed for a session, the DNCA Diameter peer in the NAT device MUST return an NCA with the
Result-CodeAVP set toMAX_BINDINGS_SET_FAILURE. Such a condition can, for example, occur if the operator specified the maximum number of NAT-bindings through another mechanism, which, per the operator's policy, takes precedence over DNCA. - If a NAT device does not have sufficient resources to process a request, the DNCA Diameter peer MUST return an NCA with the
Result-Codeset toRESOURCE_FAILURE. - In the case where
Max-NAT-Bindings,NAT-Control-Definition, andNAT-Control-Binding-Templateare included in the NCR, and the values inMax-NAT-BindingsandNAT-Control-Definitioncontradict those specified in the pre-provisioned template on the NAT device thatNAT-Control-Binding-Templatereferences,Max-NAT-BindingsandNAT-Control-DefinitionMUST override the values specified in the template to whichNAT-Control-Binding-Templaterefers.
NAT controller (DNCA Diameter peer) NAT device (DNCA Diameter peer)
| |
| |
| |
Trigger |
| |
| NCR |
|------------------------------------------>|
| |
| |
| |
| |
| If able to comply
| with request, then
| create session state
| |
| |
| NCA |
|<------------------------------------------|
| |
| |Figure 5: Initial NAT-Control-Request and Session Establishment
Note: The DNCA Diameter peer within the NAT device creates session state only if it is able to comply with the NCR. On success, it will reply with an NCA with theResult-Codeset toDIAMETER_SUCCESS. 💅✨
4.2. Session Update ✨
Okay bestie, a session update happens when the NAT controller wants to change how the NAT device behaves for a session that already exists 💅 For example, it could change how many bindings a session is allowed to have, or set up or tear down a predefined binding 🦋
When the trigger signal comes in, the DNCA Diameter peer inside the NAT controller sends an NCR to the DNCA Diameter peer inside the NAT device, with NC-Request-Type set to UPDATE_REQUEST 🔥 If the update works, the NAT device's DNCA peer tells the controller about it with an NCA (NAT-Control-Answer) that has Result-Code set to DIAMETER_SUCCESS 🎀 Figure 6 shows how the two peers talk to each other ✨
Sometimes the NAT device just can't do what the NCR asks 🥺 Here's where that can happen:
- If a DNCA Diameter peer in a NAT device gets an NCR update or query for a session that doesn't exist, it MUST set the
Result-Codein the answer toDIAMETER_UNKNOWN_SESSION_ID💀 - If the NCR includes a NAT-binding Predefined template that isn't defined on the NAT device, an NCA with the
Result-CodeAVP set toUNKNOWN_BINDING_TEMPLATE_NAMEMUST be returned 🙈 - If the NAT device can't set up the requested binding because the endpoint classifier has already hit its maximum number of allowed bindings, an NCA with the
Result-CodeAVP set toMAXIMUM_BINDINGS_REACHED_FOR_ENDPOINTMUST be returned to the DNCA Diameter peer 😭 - If the NAT device can't set up some or all of the bindings in an NCR, but the endpoint hasn't hit the maximum yet, an NCA with
Result-Codeset toBINDING_FAILUREMUST be returned. As already mentioned, the DNCA Diameter peer in a NAT device MUST treat an NCR as an atomic operation 🫶 So if anything fails, none of the requested bindings get established. It's all or nothing, babe: either every action in an NCR works, or every single one fails 🧚 - If the NAT device can't go along with a request to set the maximum number of bindings allowed for a session (the one specified by
Max-NAT-Bindings), the DNCA Diameter peer in the NAT device MUST return an NCA with theResult-CodeAVP set toMAX_BINDINGS_SET_FAILURE🥀 - If the NAT device doesn't have enough resources to process a request, an NCA with
Result-Codeset toRESOURCE_FAILUREMUST be returned 🌸 - If an NCR changes the maximum number of NAT-bindings for an endpoint that an earlier NCR set, the new value MUST override any earlier limit that was set through DNCA 👑 Before overwriting anything, though, the NAT device MUST check that the overwrite follows its locally configured policy 🔍 Depending on the deployment, the existing value might have been set by some other protocol or mechanism with higher priority. In that case the NAT device will refuse the change, and the DNCA Diameter peer in the NAT device MUST return an NCA with the
Result-CodeAVP set toMAX_BINDINGS_SET_FAILURE🙅♀️ What happens when the new value is lower than the number of bindings already allocated depends on how the NAT device is implemented. The NAT device SHOULD refrain from enforcing the new limit right away (so no actively removing bindings) 🧼 Instead, it disallows new bindings until the current count drops below the newly set maximum 💅 - If an NCR specifies a new NAT-binding Predefined template on the NAT device, that template overrides any rule previously defined for the session 🌈 Existing NAT-bindings SHOULD NOT be impacted by the template change 🫧
- If
Max-NAT-Bindings,NAT-Control-Definition, andNAT-Control-Binding-Templateare all included in the NCR, and the values inMax-NAT-BindingsandNAT-Control-Definitioncontradict what the pre-provisioned template on the NAT device says (the one thatNAT-Control-Binding-Templatepoints to), thenMax-NAT-BindingsandNAT-Control-DefinitionMUST override the values in that template 🍓
Note: Bindings that are already established for the session SHOULD NOT be affected if the NCR's tasks can't be finished 🥹 Protect those bindings, bestie!
NAT controller (DNCA Diameter peer) NAT device (DNCA Diameter peer)
| |
| |
| |
Change of session |
attributes |
| |
| NCR |
|------------------------------------------>|
| |
| |
| If able to comply
| with the request:
| update session state
| |
| |
| NCA |
|<------------------------------------------|
| |
Figure 6: NAT-Control-Request for Session Update4.3. Session and Binding Query 🔎
A DNCA Diameter peer in the NAT controller MAY use a session and NAT-binding query 💜 It can either pull up the current bindings for a particular session on the NAT device, or find the session identifier for a particular external IP address/port pair. It's giving detective energy 🕵️♀️
The DNCA Diameter peer in the NAT controller kicks off a session query by sending an NCR with NC-Request-Type set to QUERY_REQUEST ✨ Figure 7 shows how the DNCA Diameter peers interact here 🦋
There are two types of query request, and they're both lowkey iconic 👑 The first type uses the Session-Id as its input. It lets the DNCA Diameter peer in the NAT controller grab the current set of bindings for one specific session 🎀 The second type returns the session identifiers, along with their associated bindings, that match some criteria. This is how the controller finds the sessions using a specific external or internal IP address 🌈
- Request a list of currently allocated NAT-bindings for a particular session: When it gets an NCR, the NAT device SHOULD look up the session information for the
Session-Idin the NCR and report all currently active NAT-bindings for that session, using an NCA withResult-Codeset toDIAMETER_SUCCESS🌸 For this kind of query, the NCR MUST NOT contain aNAT-Control-DefinitionAVP. Each NAT-binding gets reported in its ownNAT-Control-DefinitionAVP 🧚 If theSession-Idis unknown, the DNCA Diameter peer in the NAT device MUST return an NCA withResult-Codeset toDIAMETER_UNKNOWN_SESSION_ID💀 - Retrieve Session-Ids and bindings for an internal IP address or one or more external IP address/port pairs: If the DNCA Diameter peer in the NAT controller wants the Session-Id(s) for an internal IP address or for one or more external IP address/port pairs, it MUST include the internal IP address in the
Framed-IP-AddressAVP, or the external IP address/port pair(s) in theNAT-External-AddressAVP of the NCR 🫶 The controller already knows those external pairs ahead of time, through configuration, AAA interactions, or other means. For this type of query, theSession-Idis not included in the NCR or the NCA 🙈 The DNCA Diameter peer in the NAT device SHOULD report the NAT-bindings and associated Session-Ids for the internal IP address or external IP address/port pairs in an NCA, using one or more instances of theNAT-Control-DefinitionAVP 🍓 TheResult-Codeis set toDIAMETER_SUCCESS✨ If an external IP address/port pair has no existing NAT-binding, theNAT-Control-DefinitionAVP in the reply just carries theNAT-External-AddressAVP 🫧
NAT controller (DNCA Diameter peer) NAT device (DNCA Diameter peer)
| |
| |
| |
DNCA Session Established |
| |
| NCR |
|------------------------------------------>|
| |
| |
| |
| |
| Look up corresponding session
| and associated NAT-bindings
| |
| NCA |
|<------------------------------------------|
| |
| |
| |
Figure 7: Session Query4.4. Session Termination 🌸
Okay so tearing a session down works just like starting one, bestie 💅 Teardown MUST be kicked off by the DNCA Diameter peer living in the NAT controller 🫶 That peer sends a Session-Termination-Request (STR) to its buddy inside the NAT device once it gets a trigger signal. Where the trigger comes from is totally outside this doc, so we're not going there 🙈
When the STR lands, the DNCA Diameter peer in the NAT device MAY send an accounting stop record that reports all the bindings ✨ Then the good stuff happens: every NAT-binding belonging to the session MUST be removed, and the session state MUST be cleaned up 🧹 Once that's done, the NAT device peer MUST tell its NAT controller peer that the termination went through, using a Session-Termination-Answer (STA) message with Result-Code set to DIAMETER_SUCCESS 💖 Figure 8 shows the whole back-and-forth between the two peers, and it's giving clean.
If a DNCA Diameter peer in a NAT device gets an STR and can't find a matching session, it MUST return an STA with Result-Code set to DIAMETER_UNKNOWN_SESSION_ID 🙃
NAT controller (DNCA Diameter peer) NAT device (DNCA Diameter peer)
| |
| |
Trigger |
| |
| STR |
|------------------------------------------->|
| |
| |
| |
| |
| |
| Send accounting stop |
|<-------------------------------------------|
| reporting all session bindings |
| |
| |
| Remove NAT-bindings
| of session
| |
| Terminate session /
| Remove session state
| |
| |
| |
| STA |
|<-------------------------------------------|
| |
| |
Figure 8: Terminate NAT Control Session4.5. Session Abort 🦋
Sometimes a NAT device just can't keep a session going because it's out of resources 😭 In that case it sends an Abort-Session-Request (ASR) message to the NAT controller peer. The NAT controller peer MUST acknowledge a successful abort with an Abort-Session-Answer (ASA) message with Result-Code set to DIAMETER_SUCCESS ✨ Figure 9 shows how the peers chat during this. After that good ASA with Result-Code set to DIAMETER_SUCCESS, the peers kick off the session termination procedure from Section 4.4 🔥
If the NAT controller peer gets an ASR but can't find a matching session, it MUST return an ASA with Result-Code set to DIAMETER_UNKNOWN_SESSION_ID. And if the NAT controller peer can't comply with the ASR for any other reason, it MUST return an ASA with Result-Code set to DIAMETER_UNABLE_TO_COMPLY 💀
NAT controller (DNCA Diameter peer) NAT device (DNCA Diameter peer)
| |
| |
| Trigger
| |
| ASR |
|<-------------------------------------------|
| |
| |
| |
| ASA |
|------------------------------------------->|
| |
| |
| |
| On successful ASA |
|<------Session Termination Procedure------->|
Figure 9: Abort NAT Control Session4.6. Failure Cases of the DNCA Diameter Peers 🥀
Real talk: this document doesn't specify what happens when the NAT device and NAT controller, or their DNCA Diameter peers, get out of sync or lose state 😩 That can happen if one of them restarts or if the connection drops for a bit. Here are the example failure cases:
- NAT controller and the DNCA Diameter peer within the NAT controller lose state (e.g., due to a restart). In this case:
- the DNCA Diameter peer within the NAT device MAY receive an NCR with the NC-Request-Type AVP set to
INITIAL_REQUESTthat matches an existing session of the DNCA Diameter peer within the NAT device. The DNCA Diameter peer within the NAT device MUST return aResult-Codethat contains a Duplicate-Session-Id AVP to report the Session-Id of the existing session. The DNCA Diameter peer within the NAT controller MAY send an explicit Session-Termination-Request (STR) for the older session, which was lost. - a DNCA Diameter peer MAY receive accounting records for a session that does not exist. The DNCA Diameter peer sends an accounting answer with
Result-Codeset toDIAMETER_UNKNOWN_SESSION_IDin response. On receiving that response, the DNCA Diameter peer SHOULD clear the session and remove the associated session state.
- the DNCA Diameter peer within the NAT device MAY receive an NCR with the NC-Request-Type AVP set to
- The NAT device and the DNCA Diameter peer within the NAT device lose state. In that case, the DNCA Diameter peer MAY receive an NCR with the NC-Request-Type AVP set to
UPDATE_REQUESTfor a non-existent session. The DNCA Diameter peer MUST return an NCA withResult-Codeset toDIAMETER_UNKNOWN_SESSION_ID. When a DNCA application within a NAT controller gets this NCA withResult-Codeset toDIAMETER_UNKNOWN_SESSION_ID, it MAY try to re-establish the DNCA session or disconnect the corresponding access session. - The DNCA Diameter peer within the NAT controller is unreachable. For example, that could be detected by Diameter device watchdog messages (as defined in Section 5.5 of [RFC6733]), or by accounting requests from the DNCA Diameter peer failing to get a response. The NAT-bindings and NAT device state for that session MUST be cleaned up after a grace period that is configurable on the NAT device. The grace period can be set to zero or higher, depending on operator preference ⏳
- The DNCA Diameter peer within the NAT device is unreachable or down, and the NCR fails to get a response. How this gets handled depends on the actual service offering of the service provider. For example, the service provider could choose to stop offering connectivity service 🫠
- How a NAT device cleans up state when its DNCA Diameter peer crashes is outside the scope of this document. NAT device implementers could pick from a variety of options, like tying the state (e.g., NAT-bindings) to timers that need periodic refresh or time out otherwise, operating system watchdogs for applications, etc. 🧚
5. Use of the Diameter Base Protocol 🎀
The Diameter base protocol [RFC6733] applies here, with the clarifications listed in this specification 🌈
5.1. Securing Diameter Messages 🔐
For secure transport of Diameter messages, the recommendations in [RFC6733] apply 💜
DNCA Diameter peers SHOULD verify their identity during the Capabilities Exchange Request procedure ✨
A DNCA Diameter peer within the NAT device SHOULD verify that a DNCA Diameter peer issuing an NCR command is allowed to do so, based on:
- The identity of the DNCA Diameter peer
- The type of NCR Command
- The content of the NCR Command
- Any combination of the above
5.2. Accounting Functionality 🧾
Accounting functionality (the accounting session state machine, related Command Codes and AVPs) is defined in Section 9 💅
5.3. Use of Sessions 👑
Each DNCA session MUST have a globally unique Session-Id, as defined in [RFC6733], and it MUST NOT be changed during the lifetime of the DNCA session 🔒 The Diameter Session-Id serves as the global endpoint identifier, and the DNCA Diameter peers keep state tied to that Session-Id. This globally unique Session-Id is what gets used for updating, accounting, and terminating the session. A DNCA session MUST NOT have more than one outstanding request at any given time 🙅♀️ A DNCA Diameter peer sends an Abort-Session-Request as defined in [RFC6733] if it can't maintain sessions due to resource limitation.
5.4. Routing Considerations 🗺️
It's assumed that the DNCA Diameter peer within a NAT controller knows the DiameterIdentity of the Diameter peer within a NAT device for a given endpoint. Both the Destination-Realm and Destination-Host AVPs are present in the request from a DNCA Diameter peer within a NAT controller to a DNCA Diameter peer within a NAT device 📬
5.5. Advertising Application Support 📣
Diameter nodes conforming to this specification MUST advertise support for DNCA by including the value of 12 in the Auth-Application-Id of the Capabilities-Exchange-Request and Capabilities-Exchange-Answer commands [RFC6733] 🌟
6. DNCA Commands 🧚♀️
The following commands are used to establish, maintain, and query NAT-bindings 🦋
6.1. NAT-Control-Request (NCR) Command
okay so the NCR command is the big ask 🎀 It's command code 330 with the 'R' bit set in Command Flags, and the DNCA Diameter peer in the NAT controller sends it to the DNCA Diameter peer in the NAT device so the NAT-bindings get installed. ✨
User-Name, Logical-Access-Id, Physical-Access-ID, Framed-IP-Address, Framed-IPv6-Prefix, Framed-Interface-Id, EGRESS-VLANID, NAS-Port-ID, Address-Realm, and Calling-Station-ID are all AVPs that act as identifiers for the endpoint. they're literally how the device knows who it's talking about 🦋
Message format:
< NC-Request > ::= < Diameter Header: 330, REQ, PXY>
{ Auth-Application-Id }
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
{ Destination-Host }
{ NC-Request-Type }
[ Session-Id ]
[ Origin-State-Id ]
*1 [ NAT-Control-Remove ]
*1 [ NAT-Control-Install ]
[ NAT-External-Address ]
[ User-Name ]
[ Logical-Access-Id ]
[ Physical-Access-ID ]
[ Framed-IP-Address ]
[ Framed-IPv6-Prefix ]
[ Framed-Interface-Id ]
[ EGRESS-VLANID]
[ NAS-Port-ID]
[ Address-Realm ]
[ Calling-Station-ID ]
* [ Proxy-Info ]
* [ Route-Record ]
* [ AVP ]6.2. NAT-Control-Answer (NCA) Command
the NCA is the reply 💜 It's command code 330 with the 'R' bit cleared in Command Flags, and the DNCA Diameter peer in the NAT device sends it back in response to the NAT-Control-Request. bestie, it's the other half of the conversation 🫶
Message format:
<NC-Answer> ::= < Diameter Header: 330, PXY >
{ Origin-Host }
{ Origin-Realm }
{ Result-Code }
[ Session-Id ]
[ NC-Request-Type ]
* [ NAT-Control-Definition ]
[ Current-NAT-Bindings ]
[ Origin-State-Id ]
[ Error-Message ]
[ Error-Reporting-Host ]
* [ Failed-AVP ]
* [ Proxy-Info ]
[ Duplicate-Session-Id ]
* [ Redirect-Host]
[ Redirect-Host-Usage ]
[ Redirect-Max-Cache-Time ]
* [ Proxy-Info ]
* [ Route-Record ]
* [ Failed-AVP ]
* [ AVP ]7. NAT Control Application Session State Machine 🌸
this section is basically the life cycle of a DNCA session, drawn out as a set of finite state machines 🧚 Every implementation of the DNCA Diameter application MUST observe these, no exceptions, bestie. The DNCA Diameter peers are stateful, and the state machine they keep is similar to the stateful client and server authorization state machine from [RFC6733]. When a session moves to the Idle state, any resources that were allocated for that session must be released. 🧹 And if an event isn't listed in the state machines, it MUST be considered an error condition, and an answer, if one applies, MUST be returned to whoever sent the message. not optional, periodt 💀
in the state tables, "Failure to send NCR" means the DNCA Diameter peer in the NAT controller can't send the NCR to where it's supposed to go. that could be because the peer is down, or because the peer sent back the transient failure or temporary protocol error DIAMETER_TOO_BUSY or DIAMETER_LOOP_DETECTED in the Result-Code AVP of an NCA. 😭
"FAILED NCA" in the tables means the DNCA Diameter peer in the NAT device couldn't honor the matching NCR. this can happen from any transient or permanent error at the NAT device or its DNCA peer, and it shows up as one of these Result-Code values: RESOURCE_FAILURE, UNKNOWN_BINDING_TEMPLATE_NAME, MAX_BINDINGS_SET_FAILURE, BINDING_FAILURE, MAXIMUM_BINDINGS_REACHED_FOR_ENDPOINT, SESSION_EXISTS, INSUFFICIENT_CLASSIFIERS. 🙈
the following state machine is the one a DNCA Diameter peer in a NAT controller follows. quick heads up: it uses the term "access session" for the connectivity service given to the endpoint or host. "Access session" should not be confused with the Diameter session, iykyk 🎀
DNCA Diameter peer within a NAT controller
State Event Action New State
-------------------------------------------------------------
Idle New endpoint detected that Send Pending
requires NAT control NCR
Initial
Request
Idle ASR received Send ASA Idle
for unknown session with
Result-Code
= UNKNOWN_
SESSION_ID
Pending Successful NCA Setup Open
received complete
Pending Successful NCA Send STR Discon
received,
but peer unable to provide
service
Pending Error processing successful Send STR Discon
NCA
Pending Failed Clean up Idle
NCA received
Open NAT control Send Open
update required NCR update
request
Open Successful Open
NCA received
Open Failed Clean up Idle
NCA received
Open Access session end detected Send STR Discon
Open ASR received, Send ASA Discon
access session will be with
terminated Result-Code
= SUCCESS,
Send STR
Open ASR received, Send ASA Open
access session will not with
be terminated Result-Code
!= SUCCESS
Discon ASR Received Send ASA Idle
Discon STA Received Discon. Idle
endpoint
the next state machine is the one a DNCA Diameter peer in a NAT device follows 🦋
DNCA Diameter peer within a NAT device
State Event Action New State
-------------------------------------------------------------
Idle NCR query request Send Idle
received, and successful
able to provide requested NCA
NAT-binding report
Idle NCR received Send Open
and able to successful
provide requested NCA
NAT control service
Idle NCR request Send Idle
received, and failed
unable to provide requested NCA
NAT control service
Open NCR request Send Open
received, and successful
able to provide requested NCA
NAT control service
Open NCR request Send Idle
received, and failed
unable to provide requested NCA,
NAT control service Clean up
Open Unable to continue Send ASR Discon
providing requested
NAT control service
Open Unplanned loss of session/ Clean up Idle
connection to DNCA Diameter
peer in NAT controller
detected (e.g., due to Diameter
watchdog notification)
Discon Failure to send ASR Wait, Discon
resend ASR
Discon ASR successfully sent and Clean up Idle
ASA received with Result-Code
Not ASA received None No change
Discon
Any STR received Send STA, Idle
Clean up8. DNCA AVPs 💖
8.1. Reused Base Protocol AVPs 🍓
this table lists the AVPs DNCA borrows from the Diameter base protocol [RFC6733]. You get their AVP Code values, types, possible flag values, and whether the AVP MAY be encrypted. [RFC6733] covers the AVP Flag rules in Section 4.5, and the general Diameter AVP rules are in [RFC6733], Section 4.
+---------+
| AVP |
| Flag |
| rules |
+-----------------------------------------------|-----+---+---------+
| AVP | | | |
| Attribute Name Code Data Type |MUST |MAY| Encr |
+-----------------------------------------------+-----+---+---------+
|Acct-Interim-Interval 85 Unsigned32 | M | P | Y |
|Auth-Application-Id 258 Unsigned32 | M | P | N |
|Destination-Host 293 DiamIdent | M | P | N |
|Destination-Realm 283 DiamIdent | M | P | N |
|Error-Message 281 UTF8String | M | P | N |
|Error-Reporting-Host 294 DiamIdent | M | P | N |
|Failed-AVP 279 Grouped | M | P | N |
|Origin-Host 264 DiamIdent | M | P | N |
|Origin-Realm 296 DiamIdent | M | P | N |
|Origin-State-Id 278 Unsigned32 | M | P | N |
|Proxy-Info 284 Grouped | M | P | N |
|Result-Code 268 Unsigned32 | M | P | N |
|Route-Record 282 DiamIdent | M | | N |
|Session-Id 263 UTF8String | M | P | Y |
|User-Name 1 UTF8String | M | P | Y |
+-----------------------------------------------+-----+---+---------+
Table 1: DIAMETER AVPs from the Diameter Base Protocolthe Auth-Application-Id AVP (AVP Code 258) is assigned by IANA to Diameter applications, and for the Diameter NAT Control Application it's set to 12 ✨ For the definition of the AVP flag rules and the abbreviations in the table, go check [RFC6733].
8.2. Additional Result-Code AVP Values 🌈
this section defines new Result-Code AVP values that SHALL be supported by every Diameter implementation that conforms to this document. no skipping them!! 👑
8.2.1. Success 🎀
no new Result-Code AVP value is defined in this category ⭐
8.2.2. Transient Failures 🫧
Okay so transient failures are the "not right now, bestie" bucket 🥺 The peer is basically saying it couldn't satisfy the request when it showed up, but it might totally work later. Hope isn't lost! 🦋
The new Result-Code value here is:
RESOURCE_FAILURE (4014): The DNCA Diameter peer inside the NAT device says the binding couldn't be installed, or a new session couldn't be created, because of a resource shortage. Literally just not enough room in the closet right now 💅
8.2.3. Permanent Failures 🚫
These are the Result-Code values that mean "nope, we're done here." The request failed, and the peer should not try it again 💀 (Even though the request may be able to be satisfied in the future, so keep that in your back pocket 🧚)
The new Result-Code values are:
UNKNOWN_BINDING_TEMPLATE_NAME (5042): The DNCA Diameter peer inside the NAT device says the binding couldn't be installed or a new session couldn't be created because the specified NAT-Control-Binding-Template AVP is unknown. That AVP points at a predefined policy template in the NAT device, and the NAT device has never heard of it 🙈BINDING_FAILURE (5043): The DNCA Diameter peer inside the NAT device says the requested binding(s) couldn't be installed. For example, the requested ports are already in use. Taken, sorry 🫠MAX_BINDINGS_SET_FAILURE (5044): The DNCA Diameter peer inside the NAT device failed to conform to a request to configure the maximum number of bindings for a session. For example, an operator defined the maximum number of bindings on the NAT device using a method or protocol that takes precedence over DNCA. Main character energy from the operator, honestly 👑MAXIMUM_BINDINGS_REACHED_FOR_ENDPOINT (5045): The DNCA Diameter peer inside the NAT device denies the request because the maximum number of allowed bindings has been reached for the specified endpoint classifier. The limit is the limit, periodt ✋SESSION_EXISTS (5046): The DNCA Diameter peer inside the NAT device denies a request to initialize a new session if it already has a DNCA session that uses the same set of classifiers as indicated by the DNCA Diameter peer within the NAT controller in the new session initialization request. Two of the same session? Not in this house 🙅♀️INSUFFICIENT_CLASSIFIERS (5047): The DNCA Diameter peer inside the NAT device requests to initialize a new session if the classifiers in the request match more than one of the existing sessions on the DNCA Diameter peer within the NAT device. Too many matches, not enough uniqueness 🥴
8.3. Reused NASREQ Diameter Application AVPs 🎀
Here's the table of AVPs reused from the Diameter Network Access Server Application [RFC4005]. It lists their AVP Code values, types, and possible flag values, plus whether the AVP MAY be encrypted. [RFC6733] is where the AVP Flag rules for AVPs live, in Section 4.5, and the general Diameter AVP rules are also in [RFC6733], Section 4. Bookmark that one, it's giving reference material 📚
+---------------------+
| AVP Flag Rules |
+------------------+------+------------|----+-----+----+-----|----+
| | AVP | | | |SHLD| MUST| |
| Attribute Name | Code | Value Type|MUST| MAY | NOT| NOT|Encr|
|------------------|------|------------|----+-----+----+-----|----|
| NAS-Port | 5 | Unsigned32 | M | P | | V | Y |
| NAS-Port-Id | 87 | UTF8String | M | P | | V | Y |
| Calling-Station- | 31 | UTF8String | M | P | | V | Y |
| Id | | | | | | | |
| Framed-IP-Address| 8 | OctetString| M | P | | V | Y |
| Framed-Interface-| 96 | Unsigned64 | M | P | | V | Y |
| Id | | | | | | | |
| Framed-IPv6- | 97 | OctetString| M | P | | V | Y |
| Prefix | | | | | | | |
+------------------+------+------------|----+-----+----+-----|----+Table 2: Reused NASREQ Diameter application AVPs. Please refer to [RFC6733] for the definition of the Diameter AVP Flag rules and the associated abbreviations used in the table.
8.4. Reused AVPs from RFC 4675 🧁
This table covers the AVPs reused from "RADIUS Attributes for Virtual LAN and Priority Support" [RFC4675]. It shows their AVP Code values, types, and possible flag values, and whether the AVP MAY be encrypted. [RFC6733] specifies the AVP Flag rules for AVPs in Section 4.5, and the Diameter AVP rules are defined in [RFC6733], Section 4. Small table, big vibes ✨
+---------------------+
| AVP Flag Rules |
+------------------+------+------------|----+-----+----+-----|----+
| | AVP | | | |SHLD| MUST| |
| Attribute Name | Code | Value Type|MUST| MAY | NOT| NOT|Encr|
|------------------|------|------------|----+-----+----+-----|----|
| Egress-VLANID | 56 | OctetString| M | P | | V | Y |
+------------------+------+------------|----+-----+----+-----|----+Table 3: Reused attributes from [RFC4675]. Please refer to [RFC6733] for the definition of the Diameter AVP Flag rules and the associated abbreviations used in the table.
8.5. Reused AVPs from Diameter QoS Application 🌈
Next up are the AVPs reused from "Traffic Classification and Quality of Service (QoS) Attributes for Diameter" [RFC5777]. Same deal: their AVP Code values, types, possible flag values, and whether the AVP MAY be encrypted. The AVP Flag rules are in [RFC6733] Section 4.5, and the Diameter AVP rules are in [RFC6733], Section 4 🦋
+---------+
| AVP |
| Flag |
| Rules |
+-----------------------------------------------|-----+---+---------+
| AVP | | | |
| Attribute Name Code Data Type |MUST |MAY| Encr |
+-----------------------------------------------+-----+---+---------+
|Port 530 Integer32 | M | P | Y |
|Protocol 513 Enumerated | M | P | Y |
|Direction 514 Enumerated | M | P | Y |
+-----------------------------------------------+-----+---+---------+Table 4: Reused QoS-attributes. Please refer to [RFC6733] for the definition of the Diameter AVP Flag rules and the associated abbreviations used in the table.
8.6. Reused AVPs from ETSI ES 283 034, e4 Diameter Application 🛰️
This table is for the AVPs reused from the Diameter e4 Application [ETSIES283034]. It has their AVP Code values, types, possible flag values, and whether the AVP MAY be encrypted. The AVP Flag rules are in [RFC6733] Section 4.5, and the Diameter AVP rules are in [RFC6733], Section 4. One extra detail: the Vendor-ID field in these AVP headers will be set to ETSI (13019). Vendor ID drop 💜
+---------+
| AVP |
| Flag |
| Rules |
+-----------------------------------------------|-----+---+---------+
| AVP | | | |
| Attribute Name Code Data Type |MUST |MAY| Encr |
+-----------------------------------------------+-----+---+---------+
|Address-Realm 301 OctetString | M,V | | Y |
|Logical-Access-Id 302 OctetString | V | M | Y |
|Physical-Access-ID 313 UTF8String | V | M | Y |
+-----------------------------------------------+-----+---+---------+Table 5: Reused AVPs from the Diameter e4 application. Please refer to [RFC6733] for the definition of the Diameter AVP Flag rules and the associated abbreviations used in the table.
8.7. DNCA-Defined AVPs 🌸
Now the new stuff! This table covers the new Diameter AVPs defined in this document, with their AVP Code values, types, possible flag values, and whether the AVP MAY be encrypted. [RFC6733] has the AVP Flag rules in Section 4.5, and the Diameter AVP rules are in [RFC6733], Section 4. The big rule to remember: the AVPs defined here MUST NOT have the 'V' bit in the AVP Flags field set. That's a hard no 🚫
+---------+
| AVP |
| Flag |
| Rules |
+--------------------------------------------------|-----+---+------+
| AVP | | | |
| Attribute Name Code Sect. Data Type |MUST |MAY| Encr |
+--------------------------------------------------+-----+---+------+
|NC-Request-Type 595 8.7.1 Enumerated | M | P | Y |
|NAT-Control-Install 596 8.7.2 Grouped | M | P | Y |
|NAT-Control-Remove 597 8.7.3 Grouped | M | P | Y |
|NAT-Control-Definition 598 8.7.4 Grouped | M | P | Y |
|NAT-Internal-Address 599 8.7.5 Grouped | M | P | Y |
|NAT-External-Address 600 8.7.6 Grouped | M | P | Y |
|Max-NAT-Bindings 601 8.7.7 Unsigned32 | M | P | Y |
|NAT-Control- 602 8.7.8 OctetString| M | P | Y |
| Binding-Template | | | |
|Duplicate- 603 8.7.9 UTF8String | M | P | Y |
| Session-Id | | | |
|NAT-External-Port- 604 8.7.10 Enumerated | M | P | Y |
| Style | | | |
|NAT-Control-Record 605 9.2.1 Grouped | M | P | Y |
|NAT-Control- 606 9.2.2 Enumerated | M | P | Y |
| Binding-Status | | | |
|Current-NAT-Bindings 607 9.2.3 Unsigned32 | M | P | Y |
+--------------------------------------------------+-----+---+------+Table 6: New Diameter AVPs. Please refer to [RFC6733] for the definition of the Diameter AVP Flag rules and the associated abbreviations used in the table.
8.7.1. NC-Request-Type AVP 🧭
The NC-Request-Type AVP (AVP Code 595) is an Enumerated type, and it tells you the reason for sending the NAT-Control-Request command. It shall be present in all NAT-Control-Request messages, so don't leave it out 🫶
The values are:
INITIAL_REQUEST (1): An Initial Request is used to start a Diameter NAT control session between the DNCA Diameter peers. Session starter pack, let's go 🎬UPDATE_REQUEST (2): An Update Request is used to update bindings previously installed on a given access session, to add new binding on a given access session, or to remove one or several binding(s) activated on a given access session. Glow-up, downsize, or switch-up, all in one request 💅QUERY_REQUEST (3): A Query Request is used to ask a NAT device about the bindings currently installed for an endpoint classifier. Just checking what's on the books 👀
8.7.2. NAT-Control-Install AVP ✨
okay bestie, the NAT-Control-Install AVP (AVP code 596) is a Grouped AVP, and its whole job is to activate or install NAT-bindings 🦋. It can carry Max-NAT-Bindings, which sets the maximum number of NAT-bindings allowed for an endpoint, plus a NAT-Control-Binding-Template. That template points at a predefined template on the NAT device that might hold static bindings, a maximum number of bindings, an IP address pool for external binding addresses, and more 💅. If NAT-External-Port-Style is present, the NAT device MUST select the external ports for the NAT-bindings, following the style you asked for 🎀. This applies to NAT-bindings defined by NAT-Control-Definition AVPs where the NAT-External-Address or its Port AVP is unspecified. It's giving "you decide the details, but you follow the rules" 🙈
AVP format:
NAT-Control-Install ::= < AVP Header: 596 >
* [ NAT-Control-Definition ]
[ NAT-Control-Binding-Template ]
[ Max-NAT-Bindings ]
[ NAT-External-Port-Style ]
* [ AVP ]8.7.3. NAT-Control-Remove AVP 🧚
The NAT-Control-Remove AVP (AVP code 597) is also Grouped, and it's the opposite energy: it deactivates or removes NAT-bindings 🍓. At least one of the two AVPs (NAT-Control-Definition or NAT-Control-Binding-Template) SHOULD be present in the NAT-Control-Remove AVP ✨
AVP format:
NAT-Control-Remove ::= < AVP Header: 597 >
* [ NAT-Control-Definition ]
[ NAT-Control-Binding-Template ]
* [ AVP ]8.7.4. NAT-Control-Definition AVP 💜
The NAT-Control-Definition AVP (AVP code 598) is Grouped, and it describes a binding 🌈 It's the thing that uniquely identifies the binding between the DNCA Diameter peers, so it's literally the ID card of the binding 🪪
If both the NAT-Internal-Address and NAT-External-Address AVP(s) are supplied, it's a predefined binding 🎀
If the NAT-External-Address AVP is not specified, then the NAT device MUST select the external port as per the NAT-External-Port-Style AVP, but only if that AVP is present in the NAT-Control-Definition AVP 💅
The Protocol AVP describes the transport protocol for the binding. The NAT-Control-Definition AVP can hold zero or one Protocol AVP. If the Protocol AVP is left out and both the internal and external IP addresses are specified, then the binding reserves those IP addresses for all transport protocols 🦋
The Direction AVP is Enumerated, and it sets the direction for the binding. The values that apply here are "IN" and "OUT". If Direction is OUT or absent, NAT-Internal-Address refers to the IP address of the endpoint that needs to be translated. If Direction is "IN", then NAT-Internal-Address is the destination IP address that has to be translated 🙈
AVP format:
NAT-Control-Definition ::= < AVP Header: 598 >
{ NAT-Internal-Address }
[ Protocol ]
[ Direction ]
[ NAT-External-Address ]
[ Session-Id ]
* [ AVP ]8.7.5. NAT-Internal-Address AVP 🍓
The NAT-Internal-Address AVP (AVP code 599) is Grouped, and it holds the internal IP address and port for a binding 🫶 Heads up: Framed-IPv6-Prefix and Framed-IP-Address are mutually exclusive, so you can't have both 😭 The endpoint identifier (Framed-IP-Address, Framed-IPv6-Prefix, and the internal address in this AVP) used to install NAT-bindings for the session MUST match. No mismatch drama allowed 💅
AVP format:
NAT-Internal-Address ::= < AVP Header: 599 >
[ Framed-IP-Address ]
[ Framed-IPv6-Prefix ]
[ Port]
* [ AVP ]8.7.6. NAT-External-Address AVP 🌸
The NAT-External-Address AVP (AVP code 600) is Grouped, and it describes the external IP address and port for a binding ✨ Sharing is caring here: the same external IP address can be reused for multiple endpoints, as long as you put that same address in each endpoint's NAT-External-Address AVP 🧚 If the external IP address isn't specified and the NAT-External-Port-Style AVP is specified in the NAT-Control-Definition AVP, then the NAT device MUST select an external port as per the NAT-External-Port-Style AVP 👑
AVP format:
NAT-External-Address ::= < AVP Header: 600 >
[ Framed-IP-Address ]
[ Port ]
* [ AVP ]8.7.7. Max-NAT-Bindings 🎀
The Max-NAT-Bindings AVP (AVP code 601) is Unsigned32. It indicates the maximum number of NAT-bindings allowed for a particular endpoint. Simple, clean, iconic 💅
8.7.8. NAT-Control-Binding-Template AVP 🦋
The NAT-Control-Binding-Template AVP (AVP code 602) is OctetString, and it defines a name for a policy template that's predefined at the NAT device 🌈 The details on what's inside the template and how it's structured and configured are outside the scope of this document, so that's a whole other vibe 🙈 The policy it points to may contain NAT-bindings, an IP address pool for allocating the external IP address of a NAT-binding, and a maximum number of allowed NAT-bindings 💜 Reuse is the move: you can use the same NAT-Control-Binding-Template AVP in the corresponding NAT-Control-Install AVPs of multiple endpoints 🍓
8.7.9. Duplicate-Session-Id AVP 😭
The Duplicate-Session-Id AVP (AVP Code 603) is UTF8String. It's used to report errors, and it contains the Session-Id of an existing session. Basically it's the "hey, this session already exists" tattletale 🫣
8.7.10. NAT-External-Port-Style AVP 👑
The NAT-External-Port-Style AVP (AVP Code 604) is Enumerated, and it holds the style that gets followed when selecting the external port for a NAT-binding, relative to the internal port 🔥
The following values are defined:
FOLLOW_INTERNAL_PORT_STYLE (1): The external port numbers selected MUST follow the same sequence and oddity as the internal ports of the NAT-bindings. The port oddity is required to support protocols like RTP and RTCP as defined in [RFC3550]. For example, if the internal port in a requested NAT-binding is odd numbered, then the external port allocated MUST also be odd numbered, and vice versa for an even numbered port 🌈 The sequence of port numbering is also maintained: if internal ports are consecutive, then the NAT device MUST choose consecutive external ports for the NAT-bindings. Main character energy, zero chaos 💖
9. Accounting Commands 💅
The DNCA reuses session-based accounting as defined in the Diameter base protocol [RFC6733] to report the bindings per endpoint 📊 This reporting happens by sending Diameter Accounting-Request (ACR) commands ([Start, Interim, and Stop]) from the DNCA Diameter peer inside the NAT device to its associated DNCA Diameter peer inside the NAT controller 🧚
The DNCA Diameter peer within the NAT device sends an ACR Start when it receives an NCR with NC-Request-Type AVP set to INITIAL_REQUEST for a session, or when it creates the first binding for a session requested in an earlier NCR 🦋 DNCA may send ACR Interim updates if they're needed, either because of a change in bindings from an NCR with NC-Request-Type AVP set to UPDATE_REQUEST, periodically as specified in Acct-Interim-Interval by the DNCA Diameter peer within the NAT controller, or when it creates or tears down bindings 🌸 An ACR Stop is sent by the DNCA Diameter peer within the NAT device when it receives an STR message 🛑
Figuring out which of the multiple bindings an endpoint is using at any given time? That's the post processor's job 🫶
The DNCA Diameter peer within the NAT device may trigger an Interim accounting record when the maximum number of bindings (if received in an NCR) is reached 🍓
9.1. NAT Control Accounting Messages 🎀
The ACR and ACA messages are reused as defined in the Diameter base protocol [RFC6733] for exchanging endpoint NAT-binding details between the DNCA Diameter peers 💜 The DNCA Application ID is used in the accounting commands. The ACR contains one or more optional NAT-Control-Record AVPs to report the bindings. The NAT device indicates the number of allocated NAT-bindings to the NAT controller using the Current-NAT-Bindings AVP, and this number needs to match the number of bindings identified as active within the NAT-Control-Record AVP 🔥
9.2. NAT Control Accounting AVPs ✨
In addition to the AVPs for ACR specified in [RFC6733], the DNCA Diameter peer within the NAT device must add the NAT-Control-Record AVP 🌈
9.2.1. NAT-Control-Record 🧚
The NAT-Control-Record AVP (AVP code 605) is Grouped. It describes a binding and its status 🦋 If NAT-Control-Binding-Status is set to Created, Event-Timestamp indicates the binding creation time. If NAT-Control-Binding-Status is set to Removed, Event-Timestamp indicates the binding removal time. If NAT-Control-Binding-Status is active, Event-Timestamp need not be present; if a value is present, it indicates that the binding is active at the given time 🕰️
AVP format:
NAT-Control-Record ::= < AVP Header: 605 >
{ NAT-Control-Definition }
{ NAT-Control-Binding-Status }
[ Event-Timestamp ]9.2.2. NAT-Control-Binding-Status 🌸
The NAT-Control-Binding-Status AVP (AVP code 606) is enumerated. It indicates the status of the binding: created, removed, or active 💖
The following values are defined:
Created (1): NAT-binding is created.Active (2): NAT-binding is active.Removed (3): NAT-binding was removed.
9.2.3. Current-NAT-Bindings 👑
The Current-NAT-Bindings AVP (AVP code 607) is Unsigned32. It indicates the number of NAT-bindings active on the NAT device. That's the headcount, bestie 🫶
10. AVP Occurrence Tables 🌈
The following sections present the AVPs defined in this document and specify the Diameter messages in which they can be present. Note: AVPs that can only be present within a Grouped AVP are not represented in this table 🙈
The table uses the following symbols:
0 The AVP MUST NOT be present in the message.
0+ Zero or more instances of the AVP can be present in the
message.
0-1 Zero or one instance of the AVP can be present in the
message. It is considered an error if there is more
than one instance of the AVP.
1 One instance of the AVP MUST be present in the message.
1+ At least one instance of the AVP MUST be present in the
message.10.1. DNCA AVP Table for NAT Control Initial and Update Requests 💖
Okay bestie, this table is for the NCRs and NCAs where NC-Request-Type is set to INITIAL_REQUEST or UPDATE_REQUEST 🎀 It lists the DNCA-specific AVPs that have to be present in those messages ✨
+-------------------+
| Command Code |
+-----------------------------------+-------------------+
| Attribute Name NCR NCA |
+-------------------------------------------------------+
|NC-Request-Type 1 1 |
|NAT-Control-Install 0-1 0 |
|NAT-Control-Remove 0-1 0 |
|NAT-Control-Definition 0 0 |
|Current-NAT-Bindings 0 0 |
|Duplicate-Session-Id 0 0-1 |
+-------------------------------------------------------+Note that any combination of NAT-Control-Install and NAT-Control-Remove AVPs could be present in an update or initial request 🧚 Here are some examples that are giving main character energy:
- Neither the NAT-Control-Install AVP nor the NAT-Control-Remove AVP is present: This could, for example, be the case if the NAT controller only wants to receive accounting information and doesn't want to control NAT-bindings 📊
- Only the NAT-Control-Install AVP is present: This could, for example, be the case if a new NAT-binding is installed for an existing session 🌸
- Only the NAT-Control-Remove AVP is present: This could, for example, be the case if a new NAT-binding is removed from an existing session 🦋
- Both the NAT-Control-Install AVP and the NAT-Control-Remove AVP are present: This could, for example. be the case if a formerly created NAT-binding is removed and a new NAT-binding is established within the same request 🔥 Swap-and-go, iconic 👑
10.2. DNCA AVP Table for Session Query Requests 🔍
This table covers the NCRs and NCAs where NC-Request-Type is set to QUERY_REQUEST. Same vibe, different job: these are the DNCA-specific AVPs that have to be present in those messages 💅
+-------------------+
| Command Code |
+-----------------------------------+-------------------+
| Attribute Name NCR NCA |
+-------------------------------------------------------+
|NC-Request-Type 1 1 |
|NAT-Control-Install 0 0 |
|NAT-Control-Remove 0 0 |
|NAT-Control-Definition 0 0+ |
|NAT-External-Address 0+ 0 |
|Current-NAT-Bindings 0 1 |
|Duplicate-Session-Id 0 0 |
+-------------------------------------------------------+10.3. DNCA AVP Table for Accounting Messages 📒
This table lists the DNCA-specific AVPs that may or may not be present in ACR and ACA messages. So optional, very chill 🫶
+-------------------+
| Command Code |
+-----------------------------------+-------------------+
| Attribute Name ACR ACA |
+-------------------------------------------------------+
|NAT-Control-Record 0+ 0 |
|Current-NAT-Bindings 1 0 |
+-------------------------------------------------------+11. IANA Considerations 🌈
This section lists either the namespaces created in this specification or the values assigned to existing namespaces managed by IANA. Basically, the paperwork bit that keeps everything organised 📋
In the subsections below, when we talk about review by a Designated Expert [RFC5226], please note that the Designated Expert will be assigned by the IESG. Initially, those Expert discussions happen on the AAA WG mailing list 💬
11.1. Application Identifier 🆔
This specification assigns the value 12, 'Diameter NAT Control Application', to the Application Identifier namespace defined in [RFC6733]. See Section 4 for more information ✨
11.2. Command Codes 🎫
This specification uses the value 330 from the Command code namespace defined in [RFC6733] for the NAT-Control-Request (NCR) and NAT-Control-Answer (NCA) commands. See Section 6.1 and Section 6.2 for more information on these commands 💜
11.3. AVP Codes 🔢
This specification assigns the values 595-607 from the AVP Code namespace defined in [RFC6733]. See Section 8.7 for the assignment of the namespace in this specification 🍓
11.4. Result-Code AVP Values 🎯
This specification assigns the values 4014 and 5042-5047 from the Result-Code AVP value namespace defined in [RFC6733]. See Section 8.2 for the assignment of the namespace in this specification 🦋
11.5. NC-Request-Type AVP 🧾
As defined in Section 8.7.1, the NC-Request-Type AVP includes Enumerated type values 1-3. IANA has created and is maintaining a namespace for this AVP. All remaining values are available for assignment by a Designated Expert [RFC5226] 🌸
11.6. NAT-External-Port-Style AVP 🔌
As defined in Section 8.7.10, the NAT-External-Port-Style AVP includes Enumerated type value 1. IANA has created and is maintaining a namespace for this AVP. All remaining values are available for assignment by a Designated Expert [RFC5226] 🧚
11.7. NAT-Control-Binding-Status AVP 🫧
As defined in Section 8.7.1, the NAT-Control-Binding-Status AVP includes Enumerated type values 1-3. IANA has created and is maintaining a namespace for this AVP. All remaining values are available for assignment by a Designated Expert [RFC5226] 💅
12. Security Considerations 🔐✨
okay bestie, this section is SO important 💅 DNCA is all about one entity controlling NAT stuff on a device that is not that entity, so security is literally everything here. this part covers the interactions between the Diameter peers inside a NAT controller and a NAT device, plus general security stuff for NAT-control in a service provider network 🦋
Security between a NAT controller and a NAT device has four parts: authentication, authorization, integrity, and confidentiality 🌈
Authentication means confirming who the sender of every datagram is 🫶 Without it, the Diameter peers are basically trusting strangers, and that can seriously mess with the peering network elements 😭 If the recipient doesn't authenticate the sender, an attacker could pretend to be a "legitimate" authorizing entity and change how the receiver behaves 💀 Here's what that could look like:
- an attacker sets the maximum number of bindings for a session on the NAT device to zero, which is a DoS attack 🙈
- an attacker provisions bindings on the NAT device that use IP addresses already in use in other parts of the network 🍓
- an attacker requests termination of the Diameter session, which hampers an endpoint's (i.e., a user's) connectivity 😭
And if a NAT device isn't authenticated to the NAT controller, the NAT device could give a wrong view of its resources (i.e., NAT-bindings) 🤯 A NAT-binding Predefined template on the NAT device could also end up configured differently than the NAT controller expects ✨
If either of the two DNCA Diameter peers fails to provide the required credentials, that failure should be subject to logging 📝 The operator's logging infrastructure SHOULD be built so it can handle potential DoS attacks caused by huge amounts of logging events 🛡️ That could mean properly dimensioning the logging infrastructure, plus policing how many logging events it accepts so the count stays under a threshold the system is known to handle 💪
Authorization is about whether a particular authorizing entity is allowed to signal a network element request for one or more applications while following a certain policy profile 👑 If that check fails, it might mean someone is trying to steal resources, or it might just be admin or credential problems 🤷♀️ Either way, the network element should take the proper steps to log those attempts 📝
Integrity is required so that a Diameter message exchanged between the Diameter peers hasn't been maliciously altered by intermediate devices 🔒 If integrity isn't enforced in an untrusted environment, an impostor could change the messages between the peers 😱 That could change how the peers behave, and it could even lead to a DoS 💀
Confidentiality protection makes sure the signaling data is only accessible to the entities that are supposed to see it 🧚 When signaling messages between the DNCA Diameter peers cross untrusted networks, a lack of confidentiality lets people eavesdrop and do traffic analysis 👀
Diameter has built-in security mechanisms for everything above, and DNCA uses what Diameter and its underlying transport protocols offer to meet these requirements (see Section 5.1) 💖 If DNCA traffic goes through untrusted networks, messages between DNCA Diameter peers SHOULD be secured with either IPsec or TLS 🔐 For the details, check [RFC6733], Section 13 🧠 DNCA Diameter peers SHOULD also do bilateral authentication and authorization, and use procedures that keep the information exchange integral and confidential 🫶 And the Session-Id for a particular Diameter session SHOULD be hard to guess, so that message replay is harder to pull off 🙅♀️
DNCA Diameter peers SHOULD have a mutual trust setup 🤝 This document does NOT specify a mechanism for authorization between DNCA Diameter peers, so the peers SHOULD be given enough information to make an authorization decision 🧩 That info can come from different places, like peering devices storing a local authentication policy that lists the identities of authorized peers 📋
Now the big-picture stuff 🌸 Any mechanism or protocol that controls a NAT device could be misused, and DNCA is one of those control mechanisms, since it lets someone define per-destination or per-source rules 😬 Misuse could include anti-competitive practices among providers, censorship, crime, and more 🚨 NAT-control could be used as a tool to prevent or redirect access to particular sites 🙃 For example, by controlling NAT-bindings, someone could make sure endpoints can't receive particular flows, or redirect those flows to a relay that snoops on or tampers with traffic instead of forwarding it straight to the intended endpoint 👻 Someone could also set up a binding so that the source IP address is a relay's, so the traffic coming back can be snooped on or interfered with 🕵️♀️
The operator also needs to think about security threats from an unplanned termination of the DNCA session 💀 An unplanned termination could happen if, for example, an attacker takes down the NAT controller 😱 When that happens, the NAT device cleans up the state associated with the session after a grace period ⏳ If the grace period is set to zero, the endpoint loses connectivity to services reachable through the NAT device immediately after the DNCA session terminates 📉
the protections on DNCA and its Diameter protocol exchanges do NOT prevent these kinds of NAT-control abuses 🚩 Stopping misuse or misconfiguration of a NAT device by an authorized NAT controller is beyond the scope of this protocol specification 🙅♀️ A service provider deploying DNCA needs to put higher-layer processes and procedures in place so they can detect and mitigate misuse 🛠️ bestie, this part is their job, not the protocol's 💅
13. Examples 🎀
okay so this section shows example DNCA message content and exchange 👀✨
13.1. DNCA Session Establishment Example
okay so Figure 15 shows a typical call flow for DNCA session establishment, and it is giving clean, organized vibes 🎀
In this example, the NAT controller does the following:
- a. requests a maximum of 100 NAT-bindings for the endpoint. 💅
- b. defines a static binding for a TCP connection that associates the internal IP Address:Port 192.0.2.1:80 with the external IP Address:Port 198.51.100.1:80 for the endpoint. 🦋
- c. requests the use of a preconfigured template called "local-policy" while creating NAT-bindings for the endpoint. ✨
endpoint NAT controller (within NAS) NAT device
| | |
| | |
| 1. Trigger | |
|--------------------------->| |
| +-------------------------------------+ |
| | 2. Determine that NAT control | |
| | is required for the endpoint | |
| +-------------------------------------+ |
| | |
| | |
| ...................................
| .| 3. Diameter Base CER/CEA |.
| .|<----------------------------->|.
| ...................................
| | |
| | |
| | 4. NCR |
| |------------------------------>|
| | |
| | 5. DNCA session
| | established
| | |
| | 6. NCA |
| |<------------------------------|
| | |
| | |
| 7. Data traffic |
|----------------------------------------------------------->|
| | |
| | |
| | 8. NAT-bindings
| | created as per
| | directives in the
| | DNCA session
| | | Figure 15: Initial NAT-Control-Request and
Session Establishment ExampleHere's the step-by-step breakdown of Figure 15, bestie 🫶
- The NAT controller (co-located with the NAS here) creates state for an endpoint based on a trigger. This could, for example, be the successful establishment of a Point-to-Point Protocol (PPP) [RFC1661] access session. 🌸
- Based on the configuration of the DNCA Diameter peer within the NAT controller, the NAT controller determines that NAT-control is required and is to be enforced at a NAT device. 👑
- If there is no Diameter session already established with the DNCA Diameter peer within NAT device, a Diameter connection is established and Diameter Base CER/CEA are exchanged. 🧚
- The NAT-Controller creates an NCR message (see below) and sends it to the NAT device. This example shows IPv4 to IPv4 address and port translation. For IPv6 to IPv4 translation, the Framed-IP-Address AVP would be replaced by the Framed-IPv6-Address AVP with the value set to the IPv6 address of the endpoint. 💖
< NC-Request > ::= < Diameter Header: 330, REQ, PXY>
Session-Id = "natC.example.com:33041;23432;"
Auth-Application-Id = <DNCA Application ID>
Origin-Host = "natC.example.com"
Origin-Realm = "example.com"
Destination-Realm = "example.com"
Destination-Host = "nat-device.example.com"
NC-Request-Type = INITIAL_REQUEST
User-Name = "subscriber_example1"
Framed-IP-Address = "192.0.2.1"
NAT-Control-Install = {
NAT-Control-Definition = {
Protocol = TCP
Direction = OUT
NAT-Internal-Address = {
Framed-IP-Address = "192.0.2.1"
Port = 80
}
NAT-External-Address = {
Framed-IP-Address = "198.51.100.1"
Port = 80
}
}
Max-NAT-Bindings = 100
NAT-Control-Binding-Template = "local-policy"
}- The NAT device establishes a DNCA session as it is able to comply with the request. ✅
- The NAT device sends an NCA to indicate the successful completion of the request. 🎉
<NC-Answer> ::= < Diameter Header: 330, PXY >
Session-Id = "natC.example.com:33041;23432;"
Origin-Host = "nat-device.example.com"
Origin-Realm = "example.com"
NC-Request-Type = INITIAL_REQUEST
Result-Code = DIAMETER_SUCCESS- The endpoint sends packets that reach the NAT device. 📦
- The NAT device performs NAT for traffic received from the endpoint with source address 192.0.2.1. Traffic with source IP address 192.0.2.1 and port 80 are translated to the external IP address 198.51.100.1 and port 80. Traffic with source IP address 192.0.2.1 and a source port different from 80 will be translated to IP address 198.51.100.1 and a port chosen by the NAT device. Note that this example assumes that the NAT device follows typical binding allocation rules for endpoints, in that only a single external IP address is used for all traffic received from a single IP address of an endpoint. The NAT device will allow a maximum of 100 NAT-bindings be created for the endpoint. 🌈
13.2. DNCA Session Update with Port Style Example
this section is giving session update energy 💅 A new set of NAT-bindings is requested for an existing session. The request contains a directive (the "NAT-External-Port-Style" AVP set to FOLLOW_INTERNAL_PORT_STYLE) that directs the NAT device to maintain port-sequence and port-oddity for the newly created NAT-bindings. In the example shown, the internal ports are UDP port 1036 and 1037. The NAT device follows the directive selects the external ports accordingly. The NAT device would, for example, create a mapping of 192.0.2.1:1036 to 198.51.100.1:5056 and 192.0.2.1:1037 to 198.51.100.1:5057, thereby maintaining port oddity (1036->5056, 1037->5057) and sequence (the consecutive internal ports 1036 and 1037 map to the consecutive external ports 5056 and 5057). ✨
< NC-Request > ::= < Diameter Header: 330, REQ, PXY>
Session-Id = "natC.example.com:33041;23432;"
Auth-Application-Id = <DNCA Application ID>
Origin-Host = "natC.example.com"
Origin-Realm = "example.com"
Destination-Realm = "example.com"
Destination-Host = "nat-device.example.com"
NC-Request-Type = UPDATE_REQUEST
NAT-Control-Install = {
NAT-Control-Definition = {
Protocol = UDP
Direction = OUT
NAT-Internal-Address = {
Framed-IP-Address = "192.0.2.1"
Port = 1035
}
}
NAT-Control-Definition = {
Protocol = UDP
Direction = OUT
NAT-Internal-Address = {
Framed-IP-Address = "192.0.2.1"
Port = 1036
}
}
NAT-External-Port-
Style = FOLLOW_INTERNAL_PORT_STYLE
}13.3. DNCA Session Query Example ✨
okay so this one is a query, meaning the NAT controller asks the NAT device what's going on for a subscriber. The subscriber here has internal IP Address 192.0.2.1 💅
< NC-Request > ::= < Diameter Header: 330, REQ, PXY>
Auth-Application-Id = <DNCA Application ID>
Origin-Host = "natC.example.com"
Origin-Realm = "example.com"
Destination-Realm = "example.com"
Destination-Host = "nat-device.example.com"
NC-Request-Type = QUERY_REQUEST
Framed-IP-Address = "192.0.2.1"The NAT device builds an NCA that reports every NAT binding that's currently active and has 192.0.2.1 as its internal address. literally the whole list 📋
<NC-Answer> ::= < Diameter Header: 330, PXY >
Origin-Host = "nat-device.example.com"
Origin-Realm = "example.com"
NC-Request-Type = QUERY_REQUEST
NAT-Control-Definition = {
Protocol = TCP
Direction = OUT
NAT-Internal-Address = {
Framed-IP-Address = "192.0.2.1"
Port = 80
}
NAT-External-Address = {
Framed-IP-Address = "198.51.100.1"
Port = 80
}
Session-Id = "natC.example.com:33041;23432;"
}
NAT-Control-Definition = {
Protocol = TCP
Direction = OUT
NAT-Internal-Address = {
Framed-IP-Address = "192.0.2.1"
Port = 1036
}
NAT-External-Address = {
Framed-IP-Address = "198.51.100.1"
Port = 5056
}
Session-Id = "natC.example.com:33041;23432;"
}
NAT-Control-Definition = {
Protocol = TCP
Direction = OUT
NAT-Internal-Address = {
Framed-IP-Address = "192.0.2.1"
Port = 1037
}
NAT-External-Address = {
Framed-IP-Address = "198.51.100.1"
Port = 5057
}
Session-Id = "natC.example.com:33041;23432;"
}Three bindings, all the same subscriber, all with the same session. It's giving organized 🎀
13.4. DNCA Session Termination Example 🦋
In this one the NAT controller decides it's time to end the DNCA session it set up earlier. A reason could be that the access session (like a PPP session) for that endpoint got torn down, so the NAT stuff goes too 🫶
NAT controller NAT device
| |
| |
+--------------+ |
| 1. Trigger | |
+--------------+ |
| |
| |
| 2. STR |
|-------------------------------------->|
| |
| 3. DNCA session
| lookup
| 4. ACR |
|<--------------------------------------|
| |
| 5. ACA |
|-------------------------------------->|
| |
| |
| 6. DNCA bindings
| and session cleanup
| |
| 7. STA |
|<--------------------------------------|
| |
Figure 20: NAT Control Session Termination ExampleHere's the play by play of how the session gets torn down:
- The NAT controller gets a trigger saying a DNCA session tied to one endpoint needs to end. For example, the PPP [RFC1661] access session to an endpoint in a NAS gets terminated. The NAS then tells the NAT controller to tear down the matching DNCA session, which is so real 😭
- The NAT controller makes the NCR message it needs and sends it to the NAT device:
< STR > ::= < Diameter Header: 275, REQ, PXY>
Session-Id = "natC.example.com:33041;23432;"
Auth-Application-Id = <DNCA Application ID>
Origin-Host = "natC.example.com"
Origin-Realm = "example.com"
Destination-Realm = "example.com"
Destination-Host = "nat-device.example.com"
Termination-Cause = DIAMETER_LOGOUT- The NAT device looks up the DNCA session by its Session-Id AVP and finds a session that's still active 👀
- The NAT device reports every NAT binding it set up for that subscriber, using an ACR:
< ACR > ::= < Diameter Header: 271, REQ, PXY>
Session-Id = "natC.example.com:33041;23432;"
Auth-Application-Id = <DNCA Application ID>
Origin-Host = "nat-device.example.com"
Origin-Realm = "example.com"
Destination-Realm = "example.com"
Destination-Host = "natC.example.com"
Accounting-Record-Type = STOP_RECORD
Accounting-Record-Number = 1
NAT-Control-Record = {
NAT-Control-Definition = {
Protocol = TCP
Direction = OUT
NAT-Internal-Address = {
Framed-IP-Address = "192.0.2.1"
Port = 5001
}
NAT-External-Address = {
Framed-IP-Address = "198.51.100.1"
Port = 7777
}
}
NAT-Control-Binding-Status = Removed
}- The NAT controller takes the ACR and handles it however its configuration says to. Then it sends back an ACA to the NAT device 🙌
<ACA> ::= < Diameter Header: 271, PXY >
Session-Id = "natC.example.com:33041;23432;"
Origin-Host = "natC.example.com"
Origin-Realm = "example.com"
Result-Code = DIAMETER_SUCCESS
Accounting-Record-Type = STOP_RECORD
Accounting-Record-Number = 1- Once the ACA arrives, the NAT device cleans up all the NAT bindings and the session state tied to that endpoint. Gone, cleaned, no cap 🧹
- The NAT device sends an STA. When the NAT controller gets that STA, it cleans up its own matching session state. Everyone's clean and happy 🌸
<STA> ::= < Diameter Header: 275, PXY >
Session-Id = "natC.example.com:33041;23432;"
Origin-Host = "nat-device.example.com"
Origin-Realm = "example.com"
Result-Code = DIAMETER_SUCCESS14. Acknowledgements 🫶
The authors want to thank Jari Arkko, Wesley Eddy, Stephen Farrell, Miguel A. Garcia, David Harrington, Jouni Korhonen, Matt Lepinski, Avi Lior, Chris Metz, Pallavi Mishra, Lionel Morand, Robert Sparks, Martin Stiemerling, Dave Thaler, Hannes Tschofenig, Sean Turner, Shashank Vikram, Greg Weber, and Glen Zorn for their input on this document. Thank you, legends 💜
15. References 📚
15.1. Normative References
- [ETSIES283034]: ETSI, "Telecommunications and Internet Converged Services and Protocols for Advanced Networks (TISPAN), Network Attachment Sub-System (NASS), e4 interface based on the Diameter protocol.", September 2008.
- [RFC2119]: Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [RFC4005]: Calhoun, P., Zorn, G., Spence, D., and D. Mitton, "Diameter Network Access Server Application", RFC 4005, August 2005.
- [RFC4675]: Congdon, P., Sanchez, M., and B. Aboba, "RADIUS Attributes for Virtual LAN and Priority Support", RFC 4675, September 2006.
- [RFC5226]: Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
- [RFC5777]: Korhonen, J., Tschofenig, H., Arumaithurai, M., Jones, M., and A. Lior, "Traffic Classification and Quality of Service (QoS) Attributes for Diameter", RFC 5777, February 2010.
- [RFC6733]: Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, "Diameter Base Protocol", RFC 6733, October 2012.
Okay bestie, the reference list is where the fun ends and the real homework starts 📚🫶 These are the informative ones, meaning the background reading that gives the whole thing context. Then we get to the authors, who are the squad behind it 💅
15.2. Informative References 📚✨
[CGN-REQS]Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A., and H. Ashida, "Common requirements for Carrier Grade NATs (CGNs)", Work in Progress, September 2012. 🧚[RFC1661]Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994. 🎀[RFC2663]Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999. 💜[RFC3022]Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001. 🌸[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. 🍓[RFC3411]Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. 🌈[RFC3550]Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. 🔥[RFC4097]Barnes, M., "Middlebox Communications (MIDCOM) Protocol Evaluation", RFC 4097, June 2005. ⭐[RFC5189]Stiemerling, M., Quittek, J., and T. Taylor, "Middlebox Communication (MIDCOM) Protocol Semantics", RFC 5189, March 2008. 🫶[RFC6145]Li, X., Bao, C., and F. Baker, "IP/ICMP Translation Algorithm", RFC 6145, April 2011. 💅[RFC6146]Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, April 2011. 👑[RFC6241]Enns, R., Bjorklund, M., Schoenwaelder, J., and A. Bierman, "Network Configuration Protocol (NETCONF)", RFC 6241, June 2011. ✨
Authors' Addresses 🌸
Frank Brockners Cisco Hansaallee 249, 3rd Floor Duesseldorf, Nordrhein-Westfalen 40549 Germany
EMail: fbrockne@cisco.com
Shwetha Bhandari Cisco Cessna Business Park, Sarjapura Marathalli Outer Ring Road Bangalore, Karnataka 560 087 India
EMail: shwethab@cisco.com
Vaneeta Singh 18, Cambridge Road Bangalore 560008 India
EMail: vaneeta.singh@gmail.com
Victor Fajardo Telcordia Technologies 1 Telcordia Drive #1S-222 Piscataway, NJ 08854 USA
EMail: vf0213@gmail.com
And that's the whole vibe, bestie! 🌈💖 The people who wrote this are seriously iconic, and if you ever need to find them, their emails are right above. Periodt 💅🦋
📦 where this page comes from
- ietf: rfc6736 2012-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms