idnits 2.17.1 draft-ietf-dime-nat-control-17.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 20, 2012) is 4382 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'ETSIES283034' ** Obsolete normative reference: RFC 3588 (Obsoleted by RFC 6733) ** Obsolete normative reference: RFC 4005 (Obsoleted by RFC 7155) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-10) exists of draft-ietf-behave-lsn-requirements-05 -- Obsolete informational reference (is this intentional?): RFC 6145 (Obsoleted by RFC 7915) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force F. Brockners 3 Internet-Draft S. Bhandari 4 Intended status: Standards Track Cisco 5 Expires: October 22, 2012 V. Singh 7 V. Fajardo 8 Telcordia Technologies 9 April 20, 2012 11 Diameter Network Address and Port Translation Control Application 12 draft-ietf-dime-nat-control-17 14 Abstract 16 This document describes the framework, messages, and procedures for 17 the Diameter Network address and port translation Control 18 Application. This Diameter application allows per endpoint control 19 of Network Address Translators and Network Address and Port 20 Translators, which are added to networks to cope with IPv4-address 21 space depletion. This Diameter application allows external devices 22 to configure and manage a Network Address Translator device - 23 expanding the existing Diameter-based AAA and policy control 24 capabilities with a Network Address Translators and Network Address 25 and Port Translators control component. These external devices can 26 be network elements in the data plane such as a Network Access 27 Server, or can be more centralized control plane devices such as AAA- 28 servers. This Diameter application establishes a context to commonly 29 identify and manage endpoints on a gateway or server, and a Network 30 Address Translator and Network Address and Port Translator device. 31 This includes, for example, the control of the total number of 32 Network Address Translator bindings allowed or the allocation of a 33 specific Network Address Translator binding for a particular 34 endpoint. In addition, it allows Network Address Translator devices 35 to provide information relevant to accounting purposes. 37 Status of this Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at http://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on October 22, 2012. 54 Copyright Notice 56 Copyright (c) 2012 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 72 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 7 73 3. Deployment Framework . . . . . . . . . . . . . . . . . . . . . 8 74 3.1. Deployment Scenario . . . . . . . . . . . . . . . . . . . 8 75 3.2. Diameter NAPT Control Application Overview . . . . . . . . 10 76 3.3. Deployment Scenarios For DNCA . . . . . . . . . . . . . . 11 77 4. DNCA Session Establishment and Management . . . . . . . . . . 13 78 4.1. Session Establishment . . . . . . . . . . . . . . . . . . 14 79 4.2. Session Update . . . . . . . . . . . . . . . . . . . . . . 17 80 4.3. Session and Binding Query . . . . . . . . . . . . . . . . 19 81 4.4. Session Termination . . . . . . . . . . . . . . . . . . . 21 82 4.5. Session Abort . . . . . . . . . . . . . . . . . . . . . . 22 83 4.6. Failure cases of the DNCA Diameter peers . . . . . . . . . 23 84 5. Use of the Diameter Base Protocol . . . . . . . . . . . . . . 24 85 5.1. Securing Diameter Messages . . . . . . . . . . . . . . . . 24 86 5.2. Accounting Functionality . . . . . . . . . . . . . . . . . 25 87 5.3. Use of Sessions . . . . . . . . . . . . . . . . . . . . . 25 88 5.4. Routing Considerations . . . . . . . . . . . . . . . . . . 25 89 5.5. Advertising Application Support . . . . . . . . . . . . . 25 90 6. DNCA Commands . . . . . . . . . . . . . . . . . . . . . . . . 26 91 6.1. NAT-Control Request (NCR) Command . . . . . . . . . . . . 26 92 6.2. NAT-Control Answer (NCA) Command . . . . . . . . . . . . . 27 93 7. NAT Control Application Session State Machine . . . . . . . . 27 94 8. DNCA AVPs . . . . . . . . . . . . . . . . . . . . . . . . . . 30 95 8.1. Reused Base Protocol AVPs . . . . . . . . . . . . . . . . 30 96 8.2. Additional Result-Code AVP Values . . . . . . . . . . . . 31 97 8.2.1. Success . . . . . . . . . . . . . . . . . . . . . . . 31 98 8.2.2. Transient Failures . . . . . . . . . . . . . . . . . . 31 99 8.2.3. Permanent Failures . . . . . . . . . . . . . . . . . . 32 100 8.3. Reused NASREQ Diameter Application AVPs . . . . . . . . . 33 101 8.4. Reused AVPs from RFC 4675 . . . . . . . . . . . . . . . . 33 102 8.5. Reused AVPs from Diameter QoS Application . . . . . . . . 34 103 8.6. Reused AVPs from ETSI ES 283 034, e4 Diameter 104 Application . . . . . . . . . . . . . . . . . . . . . . . 34 105 8.7. DNCA Defined AVPs . . . . . . . . . . . . . . . . . . . . 35 106 8.7.1. NC-Request-Type AVP . . . . . . . . . . . . . . . . . 36 107 8.7.2. NAT-Control-Install AVP . . . . . . . . . . . . . . . 37 108 8.7.3. NAT-Control-Remove AVP . . . . . . . . . . . . . . . . 37 109 8.7.4. NAT-Control-Definition AVP . . . . . . . . . . . . . . 38 110 8.7.5. NAT-Internal-Address AVP . . . . . . . . . . . . . . . 38 111 8.7.6. NAT-External-Address AVP . . . . . . . . . . . . . . . 39 112 8.7.7. Max-NAT-Bindings . . . . . . . . . . . . . . . . . . . 39 113 8.7.8. NAT-Control-Binding-Template AVP . . . . . . . . . . . 39 114 8.7.9. Duplicate-Session-Id AVP . . . . . . . . . . . . . . . 39 115 8.7.10. NAT-External-Port-Style AVP . . . . . . . . . . . . . 40 116 9. Accounting Commands . . . . . . . . . . . . . . . . . . . . . 40 117 9.1. NAT Control Accounting Messages . . . . . . . . . . . . . 41 118 9.2. NAT Control Accounting AVPs . . . . . . . . . . . . . . . 41 119 9.2.1. NAT-Control-Record . . . . . . . . . . . . . . . . . . 41 120 9.2.2. NAT-Control-Binding-Status . . . . . . . . . . . . . . 41 121 9.2.3. Current-NAT-Bindings . . . . . . . . . . . . . . . . . 42 122 10. AVP Occurrence Table . . . . . . . . . . . . . . . . . . . . . 42 123 10.1. DNCA AVP Table for NAT Control Initial and Update 124 Requests . . . . . . . . . . . . . . . . . . . . . . . . . 42 125 10.2. DNCA AVP Table for Session Query request . . . . . . . . . 43 126 10.3. DNCA AVP Table for Accounting Message . . . . . . . . . . 44 127 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44 128 11.1. Application Identifier . . . . . . . . . . . . . . . . . . 44 129 11.2. Command Codes . . . . . . . . . . . . . . . . . . . . . . 45 130 11.3. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . 45 131 11.4. Result-Code AVP Values . . . . . . . . . . . . . . . . . . 45 132 11.5. NC-Request-Type AVP . . . . . . . . . . . . . . . . . . . 45 133 11.6. NAT-External-Port-Style AVP . . . . . . . . . . . . . . . 45 134 11.7. NAT-Control-Binding-Status AVP . . . . . . . . . . . . . . 45 135 12. Security Considerations . . . . . . . . . . . . . . . . . . . 45 136 13. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 137 13.1. DNCA Session Establishment Example . . . . . . . . . . . . 48 138 13.2. DNCA Session Update with Port Style Example . . . . . . . 51 139 13.3. DNCA Session Query Example . . . . . . . . . . . . . . . . 52 140 13.4. DNCA Session Termination Example . . . . . . . . . . . . . 53 141 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 56 142 15. Change History (to be removed prior to publication as an 143 RFC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 144 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 60 145 16.1. Normative References . . . . . . . . . . . . . . . . . . . 60 146 16.2. Informative References . . . . . . . . . . . . . . . . . . 61 147 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 62 149 1. Introduction 151 Internet service providers deploy Network Address Translators (NATs) 152 and Network Address and Port Translators (NAPTs) [RFC3022] in their 153 networks. A key motivation for doing so is the depletion of 154 available public IPv4 addresses. This document defines a Diameter 155 application allowing providers to control the behavior of NAT and 156 NAPT devices that implement IPv4-to-IPv4 network address and port 157 translation [RFC2663] as well as stateful IPv6-to-IPv4 address family 158 translation as defined in [RFC2663], [RFC6145], and [RFC6146]. The 159 use of a Diameter application allows for simple integration into the 160 existing Authentication, Authorization and Accounting (AAA) 161 environment of a provider. 163 The Diameter Network address and port translation Control Application 164 (DNCA) offers the following capabilities: 166 1. Limits or defines the number of NAPT/NAT bindings made available 167 to an individual endpoint. The main motivation for restricting 168 the number of bindings on a per endpoint basis is to protect the 169 service of the service provider against denial of service 170 attacks. If multiple endpoints share a single public IP address, 171 these endpoints can share fate. If one endpoint would (either 172 intentionally, or due to mis-behavior, mis-configuration, mal- 173 ware, etc.) be able to consume all available bindings for a given 174 single public IP address, service would be hampered (or might 175 even become unavailable) for those other endpoints sharing the 176 same public IP address. The efficiency of a NAPT deployment 177 depends on the maximum number of bindings an endpoint could use. 178 Given that the typical number of bindings an endpoint uses 179 depends on the type of endpoint (e.g. a personal computer of a 180 broadband user is expected to use a higher number of bindings 181 than a simple mobile phone) and a NAPT device is often shared by 182 different types of endpoints, it is desirable to actively manage 183 the maximum number of bindings. This requirement is specified in 184 REQ-3 of [I-D.ietf-behave-lsn-requirements] 186 2. Supports the allocation of specific NAPT/NAT bindings. Two types 187 of specific bindings can be distinguished: 189 * Allocation of a pre-defined NAT binding: Both the internal and 190 external IP address and port pair are specified within the 191 request. Some deployment cases, such as access to a web- 192 server within a user's home network with IP address and port, 193 benefit from statically configured bindings. 195 * Allocation of an external IP address for a given internal IP 196 address: The allocated external IP address is reported back to 197 the requestor. In some deployment scenarios, the application 198 requires immediate knowledge of the allocated binding for a 199 given internal IP address but does not control the allocation 200 of the external IP address; for example, SIP-proxy server 201 deployments. 203 3. Defines the external address pool(s) to be used for allocating an 204 external IP address: External address pools can either be pre- 205 assigned at the NAPT/NAT device, or specified within a request. 206 If pre-assigned address pools are used, a request needs to 207 include a reference to identify the pool. Otherwise, the request 208 contains a description of the IP address pool(s) to be used; for 209 example, a list of IP-subnets. Such external address pools can 210 be used to select the external IP address in NAPT/NAT bindings 211 for multiple subscribers. 213 4. Generates reports and accounting records: Reports established 214 bindings for a particular endpoint. The collected information is 215 used by accounting systems for statistical purposes. 217 5. Queries and retrieves details about bindings on demand: This 218 feature complements the previously mentioned accounting 219 functionality (see item 4). This feature can be used by an 220 entity to find NAT-bindings belonging to one or multiple 221 endpoints on the NAT-device. The entity is not required to 222 create a DNCA control session to perform the query, but would 223 obviously still need to create a Diameter session complying to 224 the security requirements. 226 6. Identifies a subscriber or endpoint on multiple network devices 227 (NAT/NAPT device, the AAA-server, or the Network Access Server 228 (NAS)): Endpoint identification is facilitated through a Global 229 Endpoint ID. Endpoints are identified through a single or a set 230 of classifiers, such as IP address, Virtual Local Area Network 231 (VLAN) identifier, or interface identifier which uniquely 232 identify the traffic associated with a particular global 233 endpoint. 235 With the above capabilities, DNCA qualifies as a MIDCOM protocol 236 [RFC3303], [RFC3304], [RFC5189] for middle boxes which perform NAT. 237 The MIDCOM protocol evaluation [RFC4097] evaluated Diameter as a 238 candidate protocol for MIDCOM. DNCA provides the extensions to the 239 Diameter base protocol [RFC3588] following the MIDCOM protocol 240 requirements, such as the support of NAT-specific rule transport, 241 support for oddity of mapped ports, as well as support for 242 consecutive range port numbers. DNCA adds to the MIDCOM protocol 243 capabilities in that it allows to maintain the reference to an 244 endpoint representing a user or subscriber in the control operation, 245 enabling the control of the behavior of a NAT-device on a per 246 endpoint basis. Following the requirements of different operators 247 and deployments, different management protocols are employed. 248 Examples include e.g. SNMP [RFC3411] and NETCONF [RFC6241] which can 249 both be used for device configuration. Similarly, DNCA is 250 complementing existing MIDCOM implementations, offering a MIDCOM 251 protocol option for operators with an operational environment that is 252 Diameter-focused which desire to use Diameter to perform per endpoint 253 NAT control. Note that in case an operator uses multiple methods and 254 protocols to configure a NAT-device, such as for example command line 255 interface, SNMP, NETCONF, or PCP, along with DNCA specified in this 256 document, the operator MUST ensure that the configurations performed 257 using the different methods and protocols do not conflict in order to 258 ensure a proper operation of the NAT service. 260 This document is structured as follows: Section 2 lists terminology, 261 while Section 3 provides an introduction to DNCA and its overall 262 deployment framework. Sections 4 to 8 cover DNCA specifics, with 263 Section 4 describing session management, Section 5 the use of the 264 Diameter base protocol, Section 6 new commands, Section 7 Attribute 265 Value Pairs(AVPs) used, and Section 8 accounting aspects. Section 9 266 presents AVP occurrence tables. IANA and security considerations are 267 addressed in Sections 10 and 11. 269 2. Conventions 271 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 272 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 273 document are to be interpreted as described in [RFC2119]. 275 Abbreviations used in this document: 277 AAA: Authentication, Authorization, Accounting 279 DNCA: Diameter Network address and port translation Control 280 Application 282 Endpoint: Managed entity of the DNCA. An endpoint represents a 283 network element or device, associated with a subscriber, a user or 284 a group of users. An endpoint is represented by a single access- 285 session on a NAS. DNCA assumes a 1:1 relationship between an 286 endpoint, the access-session it represents, and the associated 287 DNCA session. 289 NAPT: Network Address and Port Translation, see also [RFC3022] 290 NAT: Network Address Translation (NAT and NAPT are used in this 291 document interchangeably) 293 NAT-binding or binding: Association of two IP address/port pairs 294 (with one IP address typically being private and the other one 295 public) to facilitate NAT 297 NAT binding predefined template: Is a policy template or 298 configuration that is predefined at the NAT-device. It may 299 contain NAT-bindings, IP-address pools for allocating the external 300 IP-address of a NAT-binding, the maximum number of allowed NAT- 301 bindings for end-points, etc. 303 NAT-device: Network Address Translator or Network Address and Port 304 Translator: An entity performing NAT or NAPT. 306 NAT-controller: Entity controlling the behavior of a NAT-device. 308 NAS: Network Access Server 310 NCR: NAT Control Request 312 NCA: NAT Control Answer 314 NAT44: IPv4 to IPv4 network address and port translation, see 315 [RFC2663] 317 NAT64: IPv6 to IPv4 address family translation, see [RFC6145] and 318 [RFC6146] 320 PPP: Point-to-Point Protocol [RFC1661] 322 3. Deployment Framework 324 3.1. Deployment Scenario 326 Figure 1 shows a typical network deployment for IPv4-Internet access. 327 A user's IPv4 host (i.e. endpoint) gains access to the Internet 328 though a NAS, which facilitates the authentication of the endpoint 329 and configures the endpoints's connection according to the 330 authorization and configuration data received from the AAA-server 331 upon successful authentication. Public IPv4 addresses are used 332 throughout the network. DNCA manages an endpoint that represents a 333 network element or device or IPv4 host, associated with a subscriber, 334 a user or a group of users. An endpoint is represented by a single 335 access-session on a NAS. DNCA assumes a 1:1 relationship between an 336 endpoint, the access-session it represents, and the associated DNCA 337 session. 339 +---------+ 340 | | 341 | AAA | 342 | | 343 +---------+ 344 | 345 | 346 | 347 | 348 +---------+ +---------+ +----------+ 349 | IPv4 | | | | IPv4 | 350 | Host |----------| NAS |-------------| Internet | 351 | | | | | | 352 +---------+ +---------+ +----------+ 354 <-------------------- Public IPv4 ----------------------> 356 Figure 1: Typical network deployment for internet access 358 Figure 2 depicts the deployment scenario where a service provider 359 places a NAT between the host and the public Internet. The objective 360 is to provide the customer with connectivity to the public IPv4 361 Internet. The NAT-device performs network address and port (and 362 optionally address family) translation, depending on whether the 363 access network uses private IPv4 addresses or public IPv6 addresses, 364 to public IPv4 addresses. Note that there may be more than one NAS, 365 NAT-device, or AAA-entity in a deployment, although the figures only 366 depict one entity each for clarity. 368 If the NAT-device would be put in place without any endpoint 369 awareness, the service offerings of the service provider could be 370 impacted as detailed in [I-D.ietf-behave-lsn-requirements]. This 371 includes cases like: 373 o Provisioning static NAT bindings for particular endpoints 375 o Using different public IP address pools for different set of 376 endpoints (for example, residential or business customers) 378 o Reporting allocated bindings on a per endpoint basis 380 o Integrate control of the NAT-device into the already existing per 381 endpoint management infrastructure of the service provider 382 +---------+ 383 | | 384 | AAA | 385 | | 386 +---------+ 387 | 388 | 389 | 390 | 391 +--------+ +---------+ +--------+ +----------+ 392 | IPv4 |----| |----| NAT- |----| IPv4- | 393 | Host | | NAS | | device | | Internet | 394 | | | | | | | | 395 +--------+ +---------+ +--------+ +----------+ 397 For NAT44 deployments (IPv4 host): 398 <----- Private IPv4 ----------><--- Public IPv4 ---> 400 For NAT64 deployments (IPv6 host): 401 <----- Public IPv6 ----------><--- Public IPv4 ---> 403 Figure 2: Access network deployment with NAT 405 Figure 2 shows a typical deployment for IPv4-Internet access 406 involving a NAT-device within the service provider network. The 407 figure describes two scenarios: One where an IPv4-host (with a 408 private IPv4 address) accesses the IPv4-Internet, as well as one 409 where an IPv6-host accesses the IPv4-Internet. 411 3.2. Diameter NAPT Control Application Overview 413 DNCA runs between two DNCA Diameter peers. One DNCA Diameter peer 414 resides within the NAT-device, the other DNCA Diameter peer resides 415 within a NAT-controller (discussed in Section 3.3). DNCA allows per 416 endpoint control and management of NAT within the NAT-device. Based 417 on Diameter, DNCA integrates well with the suite of Diameter 418 applications deployed for per endpoint authentication, authorization, 419 accounting, and policy control in service provider networks. 421 DNCA offers: 423 o Request and answer commands to control the allowed number of NAT 424 bindings per endpoint to request the allocation of specific 425 bindings for an endpoint, to define the address pool to be used 426 for an endpoint. 428 o Provides per endpoint reporting of the allocated NAT bindings. 430 o Provides unique identification of an endpoint on NAT-device, AAA- 431 server and NAS, to simplify correlation of accounting data 432 streams. 434 DNCA allows controlling the behavior of a NAT-device on a per 435 endpoint basis during initial session establishment and at later 436 stages by providing an update procedure for already established 437 sessions. Using DNCA, per endpoint NAT binding information can be 438 retrieved either using accounting mechanisms or through an explicit 439 session query to the NAT. 441 3.3. Deployment Scenarios For DNCA 443 DNCA can be deployed in different ways. DNCA supports deployments 444 with "n" NAT-controllers and "m" NAT-devices, with n and m equal to 445 or greater than 1. From a DNCA perspective an operator should ensure 446 that the session representing a particular endpoint is atomic. Any 447 deployment MUST ensure that for any given endpoint only a single DNCA 448 NAT-controller and is active at any point in time. This is to ensure 449 that NAT-devices controlled by multiple NAT-controllers do not 450 receive conflicting control requests for a particular endpoint, or 451 would be unclear which NAT-controller to send accounting information 452 to. Operational considerations MAY require an operator to use 453 alternate control mechanisms or protocols such as SNMP or manual 454 configuration via a Command-Line-Interface to apply per-endpoint NAT- 455 specific configuration, like for example static NAT-bindings. For 456 these cases, the NAT-device MUST allow the operator to configure a 457 policy how configuration conflicts are resolved. Such a policy could 458 for example specify that manually configured NAT-bindings using the 459 Command-Line-Interface always take precedence over those configured 460 using DNCA. 462 Two common deployment scenarios are outlined in Figure 3 ("integrated 463 deployment") and Figure 4 ("autonomous deployment"). Per the note 464 above, multiple instances of NAT-controllers and NAT-devices could be 465 deployed. The figures only show single instances for reasons of 466 clarity. The two shown scenarios differ in which entity fulfills the 467 role of the NAT-controller. Within the figures (C) denotes the 468 network element performing the role of the NAT-controller. 470 The integrated deployment approach hides the existence of the NAT- 471 device from external servers, such as the AAA-server. It is suited 472 for environments where minimal changes to the existing AAA deployment 473 are desired. The NAS and the NAT-device are Diameter peers 474 supporting the DNCA. The Diameter peer within the NAS, performing 475 the role of the NAT-controller, initiates and manages sessions with 476 the NAT-device, exchanges NAT specific configuration information and 477 handles reporting and accounting information. The NAS receives 478 reporting and accounting information from the NAT-device. With this 479 information, the NAS can provide a single accounting record for the 480 endpoint. A system correlating the accounting information received 481 from the NAS and NAT-device would not be needed. 483 An example network attachment for an integrated NAT deployment can be 484 described as follows: An endpoint connects to the network, with the 485 NAS being the point of attachment. After successful authentication, 486 the NAS receives endpoint related authorization data from the AAA- 487 server. A portion of the authorization data applies to per endpoint 488 configuration on the NAS itself, another portion describes 489 authorization and configuration information for NAT control aimed at 490 the NAT-device. The NAS initiates a DNCA session to the NAT-device 491 and sends relevant authorization and configuration information for 492 the particular endpoint to the NAT-device. This can comprise NAT- 493 bindings, which have to be pre-established for the endpoint, or 494 management related configuration, such as the maximum number of NAT- 495 bindings allowed for the endpoint. The NAT-device sends its per 496 endpoint accounting information to the NAS, which aggregates the 497 accounting information received from the NAT-device with its local 498 accounting information for the endpoint into a single accounting 499 stream towards the AAA-server. 501 +---------+ 502 | | 503 | AAA | 504 | | 505 +---------+ 506 | 507 | 508 | 509 +--------+ +---------+ +--------+ +----------+ 510 | | | (C) | | | | | 511 | Host |----| NAS |----| NAT- |----| IPv4- | 512 | | | | | device | | Internet | 513 +--------+ +---------+ +--------+ +----------+ 515 For NAT44 deployments (IPv4 host): 516 <----- Private IPv4 ----------><--- Public IPv4 ---> 518 For NAT64 deployments (IPv6 host): 519 <----- Public IPv6 ----------><--- Public IPv4 ---> 521 Figure 3: NAT control deployment: Integrated deployment 523 Figure 3 shows examples of integrated deployments. The figure 524 describes two scenarios: One where an IPv4-host (with a private IPv4 525 address) accesses the IPv4-Internet, as well as one where an IPv6- 526 host accesses the IPv4-Internet. 528 The autonomous deployment approach decouples endpoint management on 529 the NAS and NAT-device. In the autonomous deployment approach, the 530 AAA-system and the NAT-device are the Diameter peers running the 531 DNCA. The AAA-system also serves as NAT-controller. It manages the 532 connection to the NAT-device, controls the per endpoint 533 configuration, and also receives accounting and reporting information 534 from the NAT-device. Different from the integrated deployment 535 scenario, the autonomous deployment scenario does not "hide" the 536 existence of the NAT-device from the AAA infrastructure. Here two 537 accounting streams are received by the AAA-server for one particular 538 endpoint, one from the NAS, and one from the NAT-device. 540 +---------+ 541 | (C) | 542 | AAA |--------- 543 | | | 544 +---------+ | 545 | | 546 | | 547 | | 548 +--------+ +---------+ +---------+ +----------+ 549 | IPv4/ | | | | | | IPv4 | 550 | IPv6 |----| NAS |----| NAT- |----| Internet | 551 | Host | | | | device | | | 552 +--------+ +---------+ +---------+ +----------+ 554 For NAT44 deployments (IPv4 host): 555 <----- Private IPv4 ----------><--- Public IPv4 ---> 557 For NAT64 deployments (IPv6 host): 558 <----- Public IPv6 ----------><--- Public IPv4 ---> 560 Figure 4: NAT control deployment: Autonomous deployment 562 Figure 4 shows examples of autonomous deployments. The figure 563 describes two scenarios: One where an IPv4-host (with a private IPv4 564 address) accesses the IPv4-Internet, as well as one where an IPv6- 565 host accesses the IPv4-Internet. 567 4. DNCA Session Establishment and Management 569 Note that this section forward references some of the commands and 570 AVPs defined for DNCA. Please refer to Section 6 and Section 8 for 571 details. DNCA runs between a Diameter peer residing in a NAT- 572 controller and a Diameter peer residing in a NAT-device. Note that, 573 per what was already mentioned above, each DNCA session between 574 Diameter peers in a NAT-controller and a NAT-device represents a 575 single endpoint, with an endpoint being either a network element, a 576 device or an IPv4 host associated with a subscriber, a user, or a 577 group of users. The Diameter peer within the NAT-controller is 578 always the control requesting entity: It initiates, updates, or 579 terminates the sessions. Sessions are initiated when the NAT- 580 controller learns about a new endpoint (i.e., host) that requires a 581 NAT service. This could for example be due to the entity hosting the 582 NAT-controller receiving authentication, authorization, or accounting 583 requests for or from the endpoint. Alternate methods that could 584 trigger session setup include local configuration, receipt of a 585 packet from a formerly unknown IP-address, etc. 587 4.1. Session Establishment 589 The DNCA Diameter peer within the NAT-controller establishes a 590 session with the DNCA Diameter peer within the NAT-device to control 591 the behavior of the NAT function within the NAT-device. During 592 session establishment, the DNCA Diameter peer within the NAT- 593 controller passes along configuration information to DNCA Diameter 594 peer within the NAT-device. The session configuration information 595 comprises the maximum number of bindings allowed for the endpoint 596 associated with this session, a set of pre-defined NAT bindings to be 597 established for this endpoint, or a description of the address pool, 598 that external addresses are to be allocated from. 600 The DNCA Diameter peer within the NAT-controller generates a NAT- 601 Control Request (NCR) message to the DNCA Diameter peer within the 602 NAT-device with NC-Request-Type AVP set to INITIAL_REQUEST to 603 initiate a Diameter NAT control session. On receipt of a NCR the 604 DNCA Diameter peer within the NAT-device sets up a new session for 605 the endpoint associated with the endpoint classifier(s) contained in 606 the NCR. The DNCA Diameter peer within the NAT-device notifies its 607 DNCA Diameter peer within the NAT-controller about successful session 608 setup using a NAT-Control Answer (NCA) message with Result-Code set 609 to DIAMETER_SUCCESS. Figure 5 shows the initial protocol interaction 610 between the two DNCA Diameter peers. 612 The initial NAT-Control-Request MAY contain configuration information 613 for the session, which specifies the behavior of the NAT-device for 614 the session. The configuration information that MAY be included, 615 comprises: 617 o A list of NAT bindings, which should be pre-allocated for the 618 session; for example, in case an endpoint requires a fixed 619 external IP-address/port pair for an application. 621 o The maximum number of NAT-bindings allowed for an endpoint. 623 o A description of the external IP-address pool(s) to be used for 624 the session. 626 o A reference to a NAT Binding Predefined template on the NAT- 627 device, which is applied to the session. Such a NAT Binding 628 Predefined template on the NAT-device may contain, for example, 629 the name of the IP-address pool that external IP-addresses should 630 be allocated from, the maximum number of bindings permitted for 631 the endpoint, etc. 633 In certain cases, the NAT-device may not be able to perform the tasks 634 requested within the NCR. These include the following: 636 o If a DNCA Diameter peer within the NAT-device receives a NCR from 637 a DNCA Diameter peer within a NAT-controller with NC-Request-Type 638 AVP set to INITIAL_REQUEST that identifies an already existing 639 session; that is endpoint identifier match an already existing 640 session, the DNCA Diameter peer within the NAT-device MUST return 641 an NCA with Result-Code set to SESSION_EXISTS, and provide the 642 Session-Id of the existing session in the Duplicate-Session-Id 643 AVP. 645 o If a DNCA Diameter peer within the NAT-device receives a NCR from 646 a DNCA Diameter peer within a NAT-controller with NC-Request-Type 647 AVP set to INITIAL_REQUEST that matches more than one of the 648 already existing sessions; that is, DNCA Diameter peer and 649 endpoint identifier match already existing sessions, the DNCA 650 Diameter peer within the NAT-device MUST return an NCA with 651 Result-Code set to INSUFFICIENT-CLASSIFIERS. In case a DNCA 652 Diameter peer receives a NCA that reports Insufficient- 653 Classifiers, it MAY choose to retry establishing a new session 654 using additional or more specific classifiers. 656 o If the NCR contains a NAT Binding predefined template not defined 657 on the NAT-device, the DNCA Diameter peer within the NAT-device 658 MUST return an NCA with Result-Code AVP set to 659 UNKNOWN_BINDING_TEMPLATE_NAME. 661 o In case the NAT-device is unable to establish all of the bindings 662 requested in the NCR, the DNCA Diameter peer MUST return an NCA 663 with Result-Code set to BINDING_FAILURE. A DNCA Diameter peer 664 within a NAT-device MUST treat a NCR as an atomic operation; hence 665 none of the requested bindings will be established by the NAT- 666 device. Either all requested actions within a NCR MUST be 667 completed successfully, or the entire request fails. 669 o If a NAT-device cannot conform to a request to set the maximum 670 number of NAT bindings allowed for a session, the DNCA Diameter 671 peer in the NAT-device MUST return an NCA with Result-Code AVP set 672 to MAX_BINDINGS_SET_FAILURE. Such a condition can for example 673 occur if the operator specified the maximum number of NAT bindings 674 through another mechanism, which per the operator's policy, takes 675 precedence over DNCA. 677 o If a NAT-device does not have sufficient resources to process a 678 request, the DNCA Diameter peer MUST return an NCA with Result- 679 Code set to RESOURCE_FAILURE. 681 o In case Max-NAT-Bindings, NAT-Control-Definition as well as NAT- 682 Control-Binding-Template are included in the NCR, and the values 683 in Max-NAT-Bindings and NAT-Control-Definition contradict those 684 specified in the pre-provisioned template on the NAT-device which 685 NAT-Control-Binding-Template references, Max-NAT-Bindings and NAT- 686 Control-Definition MUST override the values specified in the 687 template that NAT-Control-Binding-Template refers to. 689 NAT-controller (DNCA Diameter peer) NAT-device (DNCA Diameter peer) 690 | | 691 | | 692 | | 693 Trigger | 694 | | 695 | NCR | 696 |------------------------------------------>| 697 | | 698 | | 699 | | 700 | | 701 | If Able to comply 702 | with Request then 703 | Create session state 704 | | 705 | | 706 | NCA | 707 |<------------------------------------------| 708 | | 709 | | 711 Figure 5: Initial NAT control request and session establishment 713 Note: The DNCA Diameter peer within the NAT-device creates session 714 state only if it is able to comply with the NCR. On success it will 715 reply with an NCA with Result-Code set to DIAMETER_SUCCESS. 717 4.2. Session Update 719 Session update is performed if the NAT-controller desires to change 720 the behavior of the NAT-device for an existing session. Session 721 update could be used, for example, to change the number of allowed 722 bindings for a particular session, or establish or remove a pre- 723 defined binding. 725 The DNCA Diameter peer within the NAT-controller generates a NCR 726 message to the DNCA Diameter peer within the NAT-device with NC- 727 Request-Type AVP set to UPDATE_REQUEST upon receiving a trigger 728 signal. If the session is updated successfully, the DNCA Diameter 729 peer within the NAT-device notifies the DNCA Diameter peer within the 730 NAT-controller about the successful session update using a NAT- 731 Control Answer (NCA) message with Result-Code set to 732 DIAMETER_SUCCESS.Figure 6 shows the protocol interaction between the 733 two DNCA Diameter peers. 735 In certain cases, the NAT-device may not be able to perform the tasks 736 requested within the NCR. These include the following: 738 o If DNCA Diameter peer within a NAT-device receives an NCR update 739 or query request for a non-existent session, it MUST set Result- 740 Code in the answer to DIAMETER_UNKNOWN_SESSION_ID. 742 o If the NCR contains a NAT Binding Predefined template not defined 743 on the NAT-device, an NCA with Result-Code AVP set to 744 UNKNOWN_BINDING_TEMPLATE_NAME MUST be returned. 746 o If the NAT-device cannot establish the requested binding because 747 the maximum number of allowed bindings has been reached for the 748 endpoint classifier, an NCA with Result-Code AVP set to 749 MAXIMUM_BINDINGS_REACHED_FOR_ENDPOINT MUST be returned to the DNCA 750 Diameter peer. 752 o If the NAT-device cannot establish some or all of the bindings 753 requested in an NCR, but has not yet reached the maximum number of 754 allowed bindings for the endpoint, an NCA with Result-Code set to 755 BINDING_FAILURE MUST be returned. As already noted, the DNCA 756 Diameter peer in a NAT-device MUST treat an NCR as an atomic 757 operation. Hence none of the requested bindings will be 758 established by the NAT-device in case of failure. Actions 759 requested within a NCR are either all successful or all fail. 761 o If the NAT-device cannot conform to a request to set the maximum 762 number of bindings allowed for a session as specified by the Max- 763 NAT-Bindings, the DNCA Diameter peer in the NAT-device MUST return 764 an NCA with Result-Code AVP set to MAX_BINDINGS_SET_FAILURE. 766 o If the NAT-device does not have sufficient resources to process a 767 request, an NCA with Result-Code set to RESOURCE_FAILURE MUST be 768 returned. 770 o If an NCR changes the maximum number of NAT-bindings allowed for 771 the endpoint defined through an earlier NCR, the new value MUST 772 override any previously defined limit on the maximum number of NAT 773 bindings set through DNCA. Note that prior to overwriting an 774 existing value, the NAT-device MUST check whether the overwrite 775 action conforms to the locally configured policy. Deployment 776 dependent, an existing value could have been set by a protocol or 777 mechanism different from DNCA and with higher priority. In which 778 case, the NAT-device will refuse the change and the DNCA Diameter 779 peer in the NAT-device MUST return an NCA with Result-Code AVP set 780 to MAX_BINDINGS_SET_FAILURE. It depends on the implementation of 781 the NAT-device on how the NAT-device copes with a case where the 782 new value is lower than the actual number of allocated bindings. 783 The NAT-device SHOULD refrain from enforcing the new limit 784 immediately (that is, actively remove bindings), but rather 785 disallows the establishment of new bindings until the current 786 number of bindings is lower than the newly established maximum 787 number of allowed bindings. 789 o If an NCR specifies a new NAT Binding Predefined template on the 790 NAT-device, the NAT Binding Predefined template overrides any 791 previously defined rule for the session. Existing NAT-bindings 792 SHOULD NOT be impacted by the change of templates. 794 o In case Max-NAT-Binding, NAT-Control-Definition as well as NAT- 795 Control-Binding-Template are included in the NCR, and the values 796 in Max-NAT-Bindings and NAT-Control-Definition contradict those 797 specified in the pre-provisioned template on the NAT-device which 798 NAT-Control-Binding-Template references, Max-NAT-Bindings and NAT- 799 Control-Definition MUST override the values specified in the 800 template that the NAT-Control-Binding-Template refers to. 802 Note: Already established bindings for the session SHOULD NOT be 803 affected in case the tasks requested within the NCR cannot be 804 completed. 806 NAT-controller (DNCA Diameter peer) NAT-device (DNCA Diameter peer) 807 | | 808 | | 809 | | 810 Change of session | 811 attributes | 812 | | 813 | NCR | 814 |------------------------------------------>| 815 | | 816 | | 817 | If able to comply 818 | with the request: 819 | Update session state 820 | | 821 | | 822 | NCA | 823 |<------------------------------------------| 824 | | 826 Figure 6: NAT control request for session update 828 4.3. Session and Binding Query 830 A Session and NAT-binding query MAY be used by the DNCA Diameter peer 831 within the NAT-controller to either retrieve information on the 832 current bindings for a particular session at the NAT-device or 833 discover the session identifier for a particular external IP address/ 834 port pair. 836 A DNCA Diameter peer within the NAT-controller starts a session query 837 by sending an NCR message with NC-Request-Type AVP set to 838 QUERY_REQUEST. Figure 7 shows the protocol interaction between the 839 DNCA Diameter peers. 841 Two types of query requests exist. The first type of query request 842 uses the session ID as input parameter to the query. It is to allow 843 the DNCA Diameter peer within the NAT-controller to retrieve the 844 current set of bindings for a specific session. The second type of 845 query request is used to retrieve the session identifiers, along with 846 the associated bindings, matching a criteria. This enables the DNCA 847 Diameter peer within the NAT-controller to find those sessions, which 848 utilize a specific external or internal IP-address. 850 1. Request a list of currently allocated NAT bindings for a 851 particular session: On receiving a NCR, the NAT-device SHOULD 852 look up the session information for the session ID contained in 853 the NCR, and report all currently active NAT-bindings for the 854 session using an NCA message with Result-Code set to 855 DIAMETER_SUCCESS. In this case the NCR MUST NOT contain a NAT- 856 Control-Definition AVP. Each NAT-binding is reported in a NAT- 857 Control-Definition AVP. In case the session ID is unknown, the 858 DNCA Diameter peer within the NAT-device MUST return an NCA 859 message with Result-Code set to DIAMETER_UNKNOWN_SESSION_ID. 861 2. Retrieve session IDs and bindings for internal IP-address or one 862 or multiple external IP-address/port pairs: If the DNCA Diameter 863 peer within the NAT-controller wishes to retrieve the session 864 ID(s) for internal IP-address or one or multiple external IP- 865 address/port pairs, it MUST include the internal IP-address as 866 part of Framed-IP-Address or external IP-address/port pair(s) as 867 part of the NAT-External-Address AVP of the NCR. The external 868 IP-address/port pair(s) are pre-known to the controller via 869 configuration, AAA interactions, or other means. The session ID 870 is not included in the NCR or the NCA for this type of a query. 871 The DNCA Diameter peer within the NAT-device SHOULD report the 872 NAT-bindings and associated session IDs corresponding to the 873 internal IP-address or external IP-address/port pairs in an NCA 874 message using one or multiple instances of the NAT-Control- 875 Definition AVP. The Result-Code is set to DIAMETER_SUCCESS. In 876 case an external IP-address/port pair has no associated existing 877 NAT-binding, the NAT-Control-Definition AVP contained in the 878 reply just contains the NAT-External-Address AVP. 880 NAT-controller (DNCA Diameter peer) NAT-device (DNCA Diameter peer) 881 | | 882 | | 883 | | 884 DNCA Session Established | 885 | | 886 | NCR | 887 |------------------------------------------>| 888 | | 889 | | 890 | | 891 | | 892 | Look up corresponding session 893 | and associated NAT-bindings 894 | | 895 | NCA | 896 |<------------------------------------------| 897 | | 898 | | 899 | | 900 Figure 7: Session query 902 4.4. Session Termination 904 Similar to session initiation, session tear down MUST be initiated by 905 the DNCA Diameter peer within the NAT-controller. The DNCA Diameter 906 peer sends a Session Terminate Request (STR) message to its peer 907 within the NAT-device upon receiving a trigger signal. The source of 908 the trigger signal is outside the scope of this document. As part of 909 STR message processing the DNCA Diameter peer within the NAT-device 910 MAY send an accounting stop record reporting all bindings. All the 911 NAT-bindings belonging to the session MUST be removed and the session 912 state MUST be cleaned up. The DNCA Diameter peer within the NAT- 913 device MUST notify its DNCA Diameter peer in the NAT-controller about 914 successful session termination using a Session Terminate Answer (STA) 915 message with Result-Code set to DIAMETER_SUCCESS. Figure 8 shows the 916 protocol interaction between the two DNCA Diameter peers. 918 If a DNCA Diameter peer within a NAT-device receives a STR and fails 919 to find a matching session, the DNCA Diameter peer MUST return a STA 920 with Result-Code set to DIAMETER_UNKNOWN_SESSION_ID. 922 NAT-controller (DNCA Diameter peer) NAT-device (DNCA Diameter peer) 923 | | 924 | | 925 Trigger | 926 | | 927 | STR | 928 |------------------------------------------->| 929 | | 930 | | 931 | | 932 | | 933 | | 934 | Send accounting stop | 935 |<-------------------------------------------| 936 | reporting all session bindings | 937 | | 938 | | 939 | Remove NAT-bindings 940 | of session 941 | | 942 | Terminate session / 943 | Remove session state 944 | | 945 | | 946 | | 947 | STA | 948 |<-------------------------------------------| 949 | | 950 | | 952 Figure 8: Terminate NAT control session 954 4.5. Session Abort 956 An Abort-Session-Request (ASR) message is sent from the DNCA Diameter 957 peer within the NAT-device to the DNCA Diameter peer within the NAT- 958 controller when it is unable to maintain a session due to resource 959 limitations. The DNCA Diameter peer within the NAT-controller MUST 960 acknowledge successful session abort using a Abort Session Answer 961 (ASA) message with Result-Code set to DIAMETER_SUCCESS. Figure 9 962 shows the protocol interaction between the DNCA Diameter peers. The 963 DNCA Diameter peers will start a session termination procedure as 964 described in Section 4.4 following an ASA with Result-Code set to 965 DIAMETER_SUCCESS. 967 If the DNCA Diameter peer within a NAT-controller receives an ASR but 968 fails to find a matching session, it MUST return an ASA with Result- 969 Code set to DIAMETER_UNKNOWN_SESSION_ID. If the DNCA Diameter peer 970 within the NAT-controller is unable to comply with the ASR for any 971 other reason, an ASA with Result-Code set to 972 DIAMETER_UNABLE_TO_COMPLY MUST be returned. 974 NAT-controller (DNCA Diameter peer) NAT-device (DNCA Diameter peer) 975 | | 976 | | 977 | Trigger 978 | | 979 | ASR | 980 |<-------------------------------------------| 981 | | 982 | | 983 | | 984 | ASA | 985 |------------------------------------------->| 986 | | 987 | | 988 | | 989 | On successful ASA | 990 |<------Session Termination Procedure------->| 992 Figure 9: Abort NAT control session 994 4.6. Failure cases of the DNCA Diameter peers 996 This document does not specify the behavior in case the NAT-device 997 and NAT-controller, or their respective DNCA Diameter peers are out 998 of sync or lose state. This could happen for example if one of the 999 entities restarts, in case of a (temporary) loss of network 1000 connectivity etc. Example failure cases include the following: 1002 o NAT-controller and the DNCA Diameter peer within the NAT- 1003 controller lose state (e.g., due to a restart). In this case, 1005 * the DNCA Diameter peer within the NAT-device MAY receive an NCR 1006 with NC-Request-Type AVP set to INITIAL_REQUEST that matches an 1007 existing session of the DNCA Diameter peer within the NAT- 1008 device. The DNCA Diameter peer within the NAT-device MUST 1009 return Result-Code that contains Duplicate-Session-Id AVP to 1010 report the Session-ID of the existing session. The DNCA 1011 Diameter peer within the NAT-controller MAY send an explicit 1012 Session Terminate Request (STR) for the older session, which 1013 was lost. 1015 * a DNCA Diameter peer MAY receive accounting records for a 1016 session that does not exist. The DNCA Diameter peer sends an 1017 accounting answer with Result-Code set to 1018 DIAMETER_UNKNOWN_SESSION_ID in response. On receiving the 1019 response, the DNCA Diameter peer SHOULD clear the session and 1020 remove associated session state. 1022 o NAT-device and the DNCA Diameter peer within NAT-device lose 1023 state. In such a case, the DNCA Diameter peer MAY receive a NCR 1024 with NC-Request-Type AVP set to UPDATE_REQUEST for a non-existent 1025 session. The DNCA Diameter peer MUST return an NCA with Result- 1026 Code set to DIAMETER_UNKNOWN_SESSION_ID. When DNCA application 1027 within NAT-controller receives this NCA within Result-Code set to 1028 DIAMETER_UNKNOWN_SESSION_ID, it MAY try to reestablish DNCA 1029 session or disconnect corresponding access session. 1031 o The DNCA Diameter peer within the NAT-controller is unreachable, 1032 for example detected by Diameter device watchdog messages (as 1033 defined in Section 5.5 of [RFC3588]), or accounting requests from 1034 the DNCA Diameter peer fail to get a response, NAT-bindings and 1035 NAT-device state pertaining to that session MUST be cleaned up 1036 after a grace period that is configurable on the NAT-device. The 1037 grace period can be configured as zero or higher, depending on 1038 operator preference. 1040 o The DNCA Diameter peer within the NAT-device is unreachable or 1041 down and NCR fails to get a response. Handling of this case 1042 depends on the actual service offering of the service provider. 1043 The service provider could for example choose to stop offering 1044 connectivity service. 1046 o A discussion of the mechanisms how a NAT-device cleans up state in 1047 case the DNCA Diameter peer within the NAT-device crashes is 1048 outside the scope of this document. Implementers of NAT-devices 1049 could choose from a variety of options such as coupling the state 1050 (e.g. NAT bindings) to timers which require periodic refresh, or 1051 time out otherwise, operating system watchdogs for applications, 1052 etc. 1054 5. Use of the Diameter Base Protocol 1056 The Diameter Base Protocol defined by [RFC3588] applies with the 1057 clarifications listed in the present specification. 1059 5.1. Securing Diameter Messages 1061 For secure transport of Diameter messages, the recommendations in 1062 [RFC3588] apply. 1064 DNCA Diameter peers SHOULD verify their identity during the 1065 Capabilities Exchange Request procedure. 1067 A DNCA Diameter peer within the NAT-device SHOULD verify that a DNCA 1068 Diameter peer that issues a NCR command is allowed to do so based on: 1070 o The identity of the DNCA Diameter peer 1072 o The type of NCR Command 1074 o The content of the NCR Command 1076 o Any combination of the above 1078 5.2. Accounting Functionality 1080 Accounting functionality (accounting session state machine, related 1081 command codes and AVPs) is defined in Section 9 below. 1083 5.3. Use of Sessions 1085 Each DNCA session MUST have a globally unique Session-ID as defined 1086 in [RFC3588], which MUST NOT be changed during the lifetime of a DNCA 1087 session. The Diameter Session-ID serves as the global endpoint 1088 identifier. The DNCA Diameter peers maintain state associated with 1089 the Session-ID. This globally unique Session-ID is used for 1090 updating, accounting, and terminating the session. A DNCA session 1091 MUST NOT have more than one outstanding request at any given instant. 1092 A DNCA Diameter peer sends an Abort-Session-Request as defined in 1093 [RFC3588] if it is unable to maintain sessions due to resource 1094 limitation. 1096 5.4. Routing Considerations 1098 It is assumed that the DNCA Diameter peer within a NAT-controller 1099 knows the DiameterIdentity of the Diameter peer within a NAT-device 1100 for a given endpoint. Both the Destination-Realm and Destination- 1101 Host AVPs are present in the request from a DNCA Diameter peer within 1102 a NAT-controller to a DNCA Diameter peer within a NAT-device. 1104 5.5. Advertising Application Support 1106 Diameter nodes conforming to this specification MUST advertise 1107 support for DNCA by including the value of TBD.APP-ID in the Auth- 1108 Application-Id of the Capabilities-Exchange-Request and Capabilities- 1109 Exchange-Answer command[RFC3588]. 1111 6. DNCA Commands 1113 The following commands are used to establish, maintain and query NAT- 1114 bindings. 1116 6.1. NAT-Control Request (NCR) Command 1118 The NAT-Control Request (NCR) command, indicated by the command field 1119 set to TBD.COM-CODE and the "R" bit set in the Command Flags field, 1120 is sent from the DNCA Diameter peer within the NAT-controller to the 1121 DNCA Diameter peer within the NAT-device in order to install NAT- 1122 bindings. 1124 User-Name, Logical-Access-Id, Physical-Access-ID, Framed-IP-Address, 1125 Framed-IPv6-Prefix, Framed-Interface-Id, EGRESS-VLANID, NAS-Port-ID, 1126 Address-Realm, Calling-Station-ID AVPs serve as identifiers for the 1127 endpoint. 1129 Message format: 1130 < NC-Request > ::= < Diameter Header: TBD.COM-CODE, REQ, PXY> 1131 { Auth-Application-Id } 1132 { Origin-Host } 1133 { Origin-Realm } 1134 { Destination-Realm } 1135 { Destination-Host } 1136 { NC-Request-Type } 1137 [ Session-Id ] 1138 [ Origin-State-Id ] 1139 *1 [ NAT-Control-Remove ] 1140 *1 [ NAT-Control-Install ] 1141 [ NAT-External-Address ] 1142 [ User-Name ] 1143 [ Logical-Access-Id ] 1144 [ Physical-Access-ID ] 1145 [ Framed-IP-Address ] 1146 [ Framed-IPv6-Prefix ] 1147 [ Framed-Interface-Id ] 1148 [ EGRESS-VLANID] 1149 [ NAS-Port-ID] 1150 [ Address-Realm ] 1151 [ Calling-Station-ID ] 1152 * [ Proxy-Info ] 1153 * [ Route-Record ] 1154 * [ AVP ] 1156 6.2. NAT-Control Answer (NCA) Command 1158 The NAT-Control-Answer (NCA) command, indicated by the Command-Code 1159 field set to TBD.COM-CODE and the "R" bit cleared in the Command 1160 Flags field, is sent by the DNCA Diameter peer within the NAT-device 1161 in response to NAT-Control-Request command. 1163 Message format: 1164 ::= < Diameter Header: TBD.COM-CODE, PXY > 1165 { Origin-Host } 1166 { Origin-Realm } 1167 { Result-Code } 1168 [ Session-Id ] 1169 [ NC-Request-Type ] 1170 * [ NAT-Control-Definition ] 1171 [ Current-NAT-Bindings ] 1172 [ Origin-State-Id ] 1173 [ Error-Message ] 1174 [ Error-Reporting-Host ] 1175 * [ Failed-AVP ] 1176 * [ Proxy-Info ] 1177 [ Duplicate-Session-ID ] 1178 * [ Redirect-Host] 1179 [ Redirect-Host-Usage ] 1180 [ Redirect-Max-Cache-Time ] 1181 * [ Proxy-Info ] 1182 * [ Route-Record ] 1183 * [ Failed-AVP ] 1184 * [ AVP ] 1186 7. NAT Control Application Session State Machine 1188 This section contains a set of finite state machines, representing 1189 the life cycle of a DNCA session, which MUST be observed by all 1190 implementations of the DNCA Diameter application. The DNCA Diameter 1191 peers are stateful and the state machine maintained is similar to the 1192 stateful Client and Server authorization state machine described in 1193 [RFC3588]. When a session is moved to the Idle state, any resources 1194 that were allocated for the particular session must be released. Any 1195 event not listed in the state machines MUST be considered as an error 1196 condition, and an answer, if applicable, MUST be returned to the 1197 originator of the message. 1199 In the state table, the event 'Failure to send NCR' means that the 1200 DNCA Diameter peer within the NAT-controller is unable to send the 1201 NCR command to the desired destination. This could be due to the 1202 peer being down, or due to the peer sending back the transient 1203 failure or temporary protocol error notification DIAMETER_TOO_BUSY or 1204 DIAMETER_LOOP_DETECTED in the Result-Code AVP of an NCA. 1206 In the state table "FAILED NCA" means that the DNCA Diameter peer 1207 within the NAT-device was not able to honor the corresponding NCR. 1208 This can happen due to any transient and permanent error at the NAT- 1209 device or its associated DNCA Diameter peer within indicated by the 1210 following error Result-Code values: RESOURCE_FAILURE, 1211 UNKNOWN_BINDING_TEMPLATE_NAME, MAX_BINDINGS_SET_FAILURE, 1212 BINDING_FAILURE, MAXIMUM_BINDINGS_REACHED_FOR_ENDPOINT, 1213 SESSION_EXISTS, INSUFFICIENT_CLASSIFIERS. 1215 The following state machine is observed by a DNCA Diameter peer 1216 within a NAT-controller. The state machine description uses the term 1217 "access session" to describe the connectivity service offered to the 1218 endpoint or host. "Access session" should not be confused with the 1219 Diameter session ID. 1221 DNCA Diameter peer within a NAT-controller 1222 State Event Action New State 1223 ------------------------------------------------------------- 1224 Idle New endpoint detected that Send Pending 1225 requires NAT Control NCR 1226 Initial 1227 Request 1229 Idle ASR Received Send ASA Idle 1230 for unknown session with 1231 Result-Code 1232 = UNKNOWN_ 1233 SESSION_ID 1235 Pending Successful NCA Setup Open 1236 received complete 1238 Pending Successful NCA Send STR Discon 1239 received 1240 but peer unable to provide 1241 service 1243 Pending Error processing successful Send STR Discon 1244 NCA 1246 Pending Failed Clean up Idle 1247 NCA received 1249 Open NAT control Send Open 1250 update required NCR Update 1251 Request 1252 Open Successful Open 1253 NCA received 1255 Open Failed Clean up Idle 1256 NCA received 1258 Open Access session end detected Send STR Discon 1260 Open ASR Received, Send ASA Discon 1261 access session will be with 1262 terminated Result-Code 1263 = SUCCESS, 1264 Send STR 1266 Open ASR Received, Send ASA Open 1267 access session will not with 1268 be terminated Result-Code 1269 != SUCCESS 1271 Discon ASR Received Send ASA Idle 1273 Discon STA Received Discon. Idle 1274 endpoint 1276 The following state machine is observed by a DNCA Diameter peer 1277 within a NAT-device. 1279 DNCA Diameter peer within a NAT-device 1280 State Event Action New State 1281 ------------------------------------------------------------- 1282 Idle NCR Query request Send Idle 1283 received, and successful 1284 able to provide requested NCA 1285 NAT Binding report 1287 Idle NCR received Send Open 1288 and able to successful 1289 provide requested NCA 1290 NAT control service 1292 Idle NCR request Send Idle 1293 received, and failed 1294 unable to provide requested NCA 1295 NAT control service 1297 Open NCR request Send Open 1298 received, and successful 1299 able to provide requested NCA 1300 NAT control service 1302 Open NCR request Send Idle 1303 received, and failed 1304 unable to provide requested NCA, 1305 NAT control service Clean up 1307 Open Unable to continue Send ASR Discon 1308 providing requested 1309 NAT control service 1311 Open Unplanned loss of session/ Clean up Idle 1312 connection to DNCA Diameter 1313 peer in NAT controller 1314 detected (e.g. due to Diameter 1315 watchdog notification) 1317 Discon Failure to send ASR Wait, Discon 1318 resend ASR 1320 Discon ASR successfully sent and Clean up Idle 1321 ASA Received with Result-Code 1323 Not ASA Received None No change 1324 Discon 1326 Any STR Received Send STA, Idle 1327 Clean up 1329 8. DNCA AVPs 1331 8.1. Reused Base Protocol AVPs 1333 The following table describes the AVPs reused from Diameter Base 1334 Protocol [RFC3588]; their AVP Code values, types, and possible flag 1335 values; and whether the AVP MAY be encrypted. The [RFC3588] 1336 specifies the AVP Flag rules for AVPs in section 4.5. The Diameter 1337 AVP rules are defined in the [RFC3588], section 4. 1339 +---------+ 1340 | AVP | 1341 | Flag | 1342 | rules | 1343 +-----------------------------------------------|-----+---+---------+ 1344 | AVP | | | | 1345 | Attribute Name Code Data Type |MUST |MAY| Encr | 1346 +-----------------------------------------------+-----+---+---------+ 1347 |Acct-Interim-Interval 85 Unsigned32 | M | P | Y | 1348 |Auth-Application-Id 258 Unsigned32 | M | P | N | 1349 |Destination-Host 293 DiamIdent | M | P | N | 1350 |Destination-Realm 283 DiamIdent | M | P | N | 1351 |Error-Message 281 UTF8String | M | P | N | 1352 |Error-Reporting-Host 294 DiamIdent | M | P | N | 1353 |Failed-AVP 279 Grouped | M | P | N | 1354 |Origin-Host 264 DiamIdent | M | P | N | 1355 |Origin-Realm 296 DiamIdent | M | P | N | 1356 |Origin-State-Id 278 Unsigned32 | M | P | N | 1357 |Proxy-Info 284 Grouped | M | P | N | 1358 |Result-Code 268 Unsigned32 | M | P | N | 1359 |Route-Record 282 DiamIdent | M | | N | 1360 |Session-Id 263 UTF8String | M | P | Y | 1361 |User-Name 1 UTF8String | M | P | Y | 1362 +-----------------------------------------------+-----+---+---------+ 1363 Table 1: DIAMETER AVPs used from Diameter base 1365 The Auth-Application-Id AVP (AVP Code 258) is assigned by IANA to 1366 Diameter applications. The value of the Auth-Application-Id for the 1367 Diameter NAT Control Application is TBD.APP-ID. Please refer to 1368 [RFC3588] for the definition of the Diameter AVP flag rules and the 1369 associated abbreviations used in the table. 1371 8.2. Additional Result-Code AVP Values 1373 This section defines new values for the Result-Code AVP that SHALL be 1374 supported by all Diameter implementations that conform to the present 1375 document. 1377 8.2.1. Success 1379 No new Result-Code AVP value is defined within this category. 1381 8.2.2. Transient Failures 1383 Result-Code AVP values that fall within the transient failures 1384 category are those used to inform a peer that the request could not 1385 be satisfied at the time that it was received. The request may be 1386 able to be satisfied in the future. 1388 The following new values of the Result-Code AVP are defined: 1390 RESOURCE_FAILURE (TBD.RCX) 1392 The DNCA Diameter peer within the NAT-device indicates that the 1393 binding could not be installed or a new session could not be 1394 created due to resource shortage. 1396 8.2.3. Permanent Failures 1398 The Result-Code AVP values, which fall within the permanent failures 1399 category are used to inform the peer that the request failed, and 1400 should not be attempted again. The request may be able to be 1401 satisfied in the future. 1403 The following new values of the Result-Code AVP are defined: 1405 UNKNOWN_BINDING_TEMPLATE_NAME (TBD.RCX) 1407 The DNCA Diameter peer within the NAT-device indicates that the 1408 binding could not be installed or a new session could not be 1409 created because the specified NAT-Control-Binding-Template AVP, 1410 that refers to a predefined policy template in the NAT-device, 1411 is unknown. 1413 BINDING_FAILURE (TBD.RCX) 1415 The DNCA Diameter peer within the NAT-device indicates that the 1416 requested binding(s) could not be installed. For example: 1417 Requested ports are already in use. 1419 MAX_BINDINGS_SET_FAILURE (TBD.RCX) 1421 The DNCA Diameter peer within the NAT-device indicates that it 1422 failed to conform to a request to configure the maximum number 1423 of bindings for a session. For example: An operator defined 1424 the maximum number of bindings on the NAT-device using a method 1425 or protocol which takes precendence over DNCA. 1427 MAXIMUM_BINDINGS_REACHED_FOR_ENDPOINT (TBD.RCX) 1429 The DNCA Diameter peer within the NAT-device denies the request 1430 because the maximum number of allowed bindings has been reached 1431 for the specified endpoint classifier. 1433 SESSION_EXISTS (TBD.RCX) 1434 The DNCA Diameter peer within the NAT-device denies request to 1435 initialize a new session, if it already has a DNCA session that 1436 uses the same set of classifiers as indicated by the DNCA 1437 Diameter peer within the NAT-controller in the new session 1438 initialization request. 1440 INSUFFICIENT_CLASSIFIERS (TBD.RCX) 1442 The DNCA Diameter peer within the NAT-device requests to 1443 initialize a new session, if the classifiers in the request 1444 match more than one of the existing sessions on the DNCA 1445 Diameter peer within the NAT-device. 1447 8.3. Reused NASREQ Diameter Application AVPs 1449 The following table describes the AVPs reused from the Diameter 1450 Network Access Server Application [RFC4005]; their AVP Code values, 1451 types, and possible flag values; and whether the AVP MAY be 1452 encrypted. The [RFC3588] specifies the AVP Flag rules for AVPs in 1453 section 4.5. The Diameter AVP rules are defined in the [RFC3588], 1454 section 4. 1455 +---------------------+ 1456 | AVP Flag rules | 1457 +------------------+------+------------|----+-----+----+-----|----+ 1458 | | AVP | | | |SHLD| MUST| | 1459 | Attribute Name | Code | Value Type|MUST| MAY | NOT| NOT|Encr| 1460 |------------------|------|------------|----+-----+----+-----|----| 1461 | NAS-Port | 5 | Unsigned32 | M | P | | V | Y | 1462 | NAS-Port-Id | 87 | UTF8String | M | P | | V | Y | 1463 | Calling-Station- | 31 | UTF8String | M | P | | V | Y | 1464 | Id | | | | | | | | 1465 | Framed-IP-Address| 8 | OctetString| M | P | | V | Y | 1466 | Framed-Interface-| 96 | Unsigned64 | M | P | | V | Y | 1467 | Id | | | | | | | | 1468 | Framed-IPv6- | 97 | OctetString| M | P | | V | Y | 1469 | Prefix | | | | | | | | 1470 +------------------+------+------------|----+-----+----+-----|----+ 1471 Table 2: Reused NASREQ Diameter application AVPs. Please refer to 1472 [RFC3588] for the definition of the Diameter AVP flag rules and the 1473 associated abbreviations used in the table. 1475 8.4. Reused AVPs from RFC 4675 1477 The following table describes the AVPs reused from "RADIUS Attributes 1478 for Virtual LAN and Priority Support" specification [RFC4675]; their 1479 AVP Code values, types, and possible flag values; and whether the AVP 1480 MAY be encrypted. The [RFC3588] specifies the AVP Flag rules for 1481 AVPs in section 4.5. The Diameter AVP rules are defined in the 1483 [RFC3588], section 4. 1484 +---------------------+ 1485 | AVP Flag rules | 1486 +------------------+------+------------|----+-----+----+-----|----+ 1487 | | AVP | | | |SHLD| MUST| | 1488 | Attribute Name | Code | Value Type|MUST| MAY | NOT| NOT|Encr| 1489 |------------------|------|------------|----+-----+----+-----|----| 1490 | Egress-VLANID | 56 | OctetString| M | P | | V | Y | 1491 +------------------+------+------------|----+-----+----+-----|----+ 1492 Table 3: Reused attributes from RFC 4675. Please refer to [RFC3588] 1493 for the definition of the Diameter AVP flag rules and the associated 1494 abbreviations used in the table. 1496 8.5. Reused AVPs from Diameter QoS Application 1498 The following table describes the AVPs reused from the Traffic 1499 Classification and Quality of Service (QoS) Attributes for Diameter 1500 [RFC5777]; their AVP Code values, types, and possible flag values; 1501 and whether the AVP MAY be encrypted. The [RFC3588] specifies the 1502 AVP Flag rules for AVPs in section 4.5. The Diameter AVP rules are 1503 defined in the [RFC3588], section 4. 1504 +---------+ 1505 | AVP | 1506 | Flag | 1507 | rules | 1508 +-----------------------------------------------|-----+---+---------+ 1509 | AVP | | | | 1510 | Attribute Name Code Data Type |MUST |MAY| Encr | 1511 +-----------------------------------------------+-----+---+---------+ 1512 |Port 530 Integer32 | M | P | Y | 1513 |Protocol 513 Enumerated | M | P | Y | 1514 |Direction 514 Enumerated | M | P | Y | 1515 +-----------------------------------------------+-----+---+---------+ 1517 Table 4: Reused QoS-attributes. Please refer to [RFC3588] for the 1518 definition of the Diameter AVP flag rules and the associated 1519 abbreviations used in the table. 1521 8.6. Reused AVPs from ETSI ES 283 034, e4 Diameter Application 1523 The following table describes the AVPs reused from the Diameter e4 1524 Application [ETSIES283034]; their AVP Code values, types, and 1525 possible flag values; and whether the AVP MAY be encrypted. The 1526 [RFC3588] specifies the AVP Flag rules for AVPs in section 4.5. The 1527 Diameter AVP rules are defined in the [RFC3588], section 4. The 1528 Vendor-ID field in these AVP header will be set to ETSI (13019). 1530 +---------+ 1531 | AVP | 1532 | Flag | 1533 | rules | 1534 +-----------------------------------------------|-----+---+---------+ 1535 | AVP | | | | 1536 | Attribute Name Code Data Type |MUST |MAY| Encr | 1537 +-----------------------------------------------+-----+---+---------+ 1538 |Address-Realm 301 OctetString | M,V | | Y | 1539 |Logical-Access-Id 302 OctetString | V | M | Y | 1540 |Physical-Access-ID 313 UTF8String | V | M | Y | 1541 +-----------------------------------------------+-----+---+---------+ 1543 Table 5: Reused AVPs from Diameter e4 application. Please refer to 1544 [RFC3588] for the definition of the Diameter AVP flag rules and the 1545 associated abbreviations used in the table. 1547 8.7. DNCA Defined AVPs 1549 The following table describes the new Diameter AVPs defined in this 1550 document; their AVP Code values, types, and possible flag values; and 1551 whether the AVP MAY be encrypted. The [RFC3588] specifies the AVP 1552 Flag rules for AVPs in section 4.5. The Diameter AVP rules are 1553 defined in the [RFC3588], section 4. The AVPs defined here MUST NOT 1554 have the V bit in the AVP Flag set. 1556 +---------+ 1557 | AVP | 1558 | Flag | 1559 | rules | 1560 +--------------------------------------------------|-----+---+------+ 1561 | AVP | | | | 1562 | Attribute Name Code Data Type |MUST |MAY| Encr | 1563 +--------------------------------------------------+-----+---+------+ 1564 |NC-Request-Type TBD.AX 8.7.1 Enumerated | M | P | Y | 1565 |NAT-Control-Install TBD.AX 8.7.2 Grouped | M | P | Y | 1566 |NAT-Control-Remove TBD.AX 8.7.3 Grouped | M | P | Y | 1567 |NAT-Control-Definition TBD.AX 8.7.4 Grouped | M | P | Y | 1568 |NAT-Internal-Address TBD.AX 8.7.5 Grouped | M | P | Y | 1569 |NAT-External-Address TBD.AX 8.7.6 Grouped | M | P | Y | 1570 |Max-NAT-Bindings TBD.AX 8.7.7 Unsigned32 | M | P | Y | 1571 |NAT-Control- TBD.AX 8.7.8 OctetString| M | P | Y | 1572 | Binding-Template | | | | 1573 |Duplicate- TBD.AX 8.7.9 UTF8String | M | P | Y | 1574 | Session-ID | | | | 1575 |NAT-External-Port- TBD.AX 8.7.10 Enumerated | M | P | Y | 1576 | Style | | | | 1577 |NAT-Control-Record TBD.AX 9.2.1 Grouped | M | P | Y | 1578 |NAT-Control- TBD.AX 9.2.2 Enumerated | M | P | Y | 1579 | Binding-Status | | | | 1580 |Current-NAT-Bindings TBD.AX 9.2.3 Unsigned32 | M | P | Y | 1581 +--------------------------------------------------+-----+---+------+ 1583 Table 6: New Diameter AVPs. Please refer to [RFC3588] for the 1584 definition of the Diameter AVP flag rules and the associated 1585 abbreviations used in the table. 1587 8.7.1. NC-Request-Type AVP 1589 The NC-Request-Type AVP (AVP Code TBD.AX) is of type Enumerated and 1590 contains the reason for sending the NAT-Control-Request command. It 1591 shall be present in all NAT-Control-Request messages. 1593 The following values are defined: 1595 INITIAL_REQUEST (1) 1597 An Initial Request is to initiate a Diameter NAT control 1598 session between the DNCA Diameter peers. 1600 UPDATE_REQUEST (2) 1602 An Update Request is used to update bindings previously 1603 installed on a given access session, to add new binding on a 1604 given access session, or to remove one or several binding(s) 1605 activated on a given access session. 1607 QUERY_REQUEST (3) 1609 Query Request is used to query a NAT-device about the currently 1610 installed bindings for an endpoint classifier. 1612 8.7.2. NAT-Control-Install AVP 1614 The NAT-Control AVP (AVP code TBD.AX) is of type Grouped, and it is 1615 used to activate or install NAT bindings. It also contains Max-NAT- 1616 Bindings that defines the maximum number of NAT bindings allowed for 1617 an endpoint and the NAT-Control-Binding-Template that references a 1618 predefined template on the NAT-device that may contain static 1619 binding, a maximum number of bindings allowed, an IP-address pool 1620 from which external binding addresses should be allocated, etc. If 1621 the NAT-External-Port-Style AVP is present, then the NAT-device MUST 1622 select the external ports for the NAT-Bindings as per the style 1623 specified. The NAT-External-Port-Style is applicable for NAT- 1624 Bindings defined by the NAT-Control-Definition AVPs whose NAT- 1625 External-Address or Port AVPs within the NAT-External-Address are 1626 unspecified. 1628 AVP format: 1629 NAT-Control-Install ::= < AVP Header: TBD.AX > 1630 * [ NAT-Control-Definition ] 1631 [ NAT-Control-Binding-Template ] 1632 [ Max-NAT-Bindings ] 1633 [ NAT-External-Port-Style ] 1634 * [ AVP ] 1636 8.7.3. NAT-Control-Remove AVP 1638 The NAT-Control-Remove AVP (AVP code TBD.AX) is of type Grouped, and 1639 it is used to deactivate or remove NAT-bindings. At least one of the 1640 two AVPs (NAT-Control-Definition AVP, NAT-Control-Binding-Template 1641 AVP) SHOULD be present in the NAT-Control-Remove AVP. 1643 AVP format: 1644 NAT-Control-Remove ::= < AVP Header: TBD.AX > 1645 * [ NAT-Control-Definition ] 1646 [ NAT-Control-Binding-Template ] 1647 * [ AVP ] 1649 8.7.4. NAT-Control-Definition AVP 1651 The NAT-Control-Definition AVP (AVP code TBD.AX) is of type Grouped, 1652 and it describes a binding. 1654 The NAT-Control-Definition AVP uniquely identifies the binding 1655 between the DNCA Diameter peers. 1657 If both the NAT-Internal-Address and NAT-External-Address AVP(s) are 1658 supplied, it is a pre-defined binding. 1660 If the NAT-External-Address AVP is not specified then the NAT-device 1661 MUST select the external port as per the NAT-External-Port-Style AVP, 1662 if present in the NAT-Control-Definition AVP. 1664 The Protocol AVP describes the transport protocol for the binding. 1665 The NAT-Control-Definition AVP can contain either zero or one 1666 Protocol AVP. If the Protocol AVP is omitted and if both internal 1667 and external IP-address are specified then the binding reserves the 1668 IP-addresses for all transport protocols. 1670 The Direction AVP is of type Enumerated. It specifies the direction 1671 for the binding. The values of the enumeration applicable in this 1672 context are: "IN","OUT". If Direction AVP is OUT or absent, the NAT- 1673 Internal-Address refers to the IP-address of the endpoint that needs 1674 to be translated. If Direction AVP is "IN", NAT-Internal-Address is 1675 the destination IP-address that has to be translated. 1677 AVP format: 1678 NAT-Control-Definition ::= < AVP Header: TBD.AX > 1679 { NAT-Internal-Address } 1680 [ Protocol ] 1681 [ Direction ] 1682 [ NAT-External-Address ] 1683 [ Session-Id ] 1684 * [ AVP ] 1686 8.7.5. NAT-Internal-Address AVP 1688 The NAT-Internal-Address AVP (AVP code TBD.AX) is of type Grouped. 1689 It describes the internal IP-address and port for a binding. Framed- 1690 IPV6-Prefix and Framed-IP-Address AVPs are mutually exclusive. The 1691 endpoint identifier Framed-IP-Address, Framed-IPv6-Prefix and the 1692 internal address in this NAT-Internal-Address AVP to install NAT- 1693 bindings for the session MUST match. 1695 AVP format: 1697 NAT-Internal-Address ::= < AVP Header: TBD.AX > 1698 [ Framed-IP-Address ] 1699 [ Framed-IPv6-Prefix ] 1700 [ Port] 1701 * [ AVP ] 1703 8.7.6. NAT-External-Address AVP 1705 The NAT-External-Address AVP (AVP code TBD.AX) is of type Grouped, 1706 and it describes the external IP-address and port for a binding. The 1707 external IP-address specified in this attribute can be reused for 1708 multiple endpoints by specifying the same address in the respective 1709 NAT-External-Address AVPs. If the external IP-address is not 1710 specified and the NAT-External-Port-Style AVP is specified in the 1711 NAT-Control-Definition AVP then the NAT-device MUST select external 1712 port as per the NAT-External-Port-Style AVP. 1714 AVP format: 1715 NAT-External-Address ::= < AVP Header: TBD.AX > 1716 [ Framed-IP-Address ] 1717 [ Port ] 1718 * [ AVP ] 1720 8.7.7. Max-NAT-Bindings 1722 The Max-NAT-Bindings AVP (AVP code TBD.AX) is of type Unsigned32. It 1723 indicates the maximum number of NAT-bindings allowed for a particular 1724 endpoint. 1726 8.7.8. NAT-Control-Binding-Template AVP 1728 The NAT-Control-Binding-Template AVP (AVP code TBD.AX) is of type 1729 OctetString. It defines a name for a policy template that is 1730 predefined at the NAT-device. Details on the contents and structure 1731 of the template and configuration are outside the scope of this 1732 document. The policy to which this AVP refers to may contain NAT- 1733 bindings, IP-address pool for allocating the external IP-address of a 1734 NAT-binding, and maximum number of allowed NAT-bindings. Such policy 1735 template can be reused by specifying the same NAT-Control-Binding- 1736 Template AVP in the corresponding NAT-Control-Install AVPs of 1737 multiple endpoints. 1739 8.7.9. Duplicate-Session-Id AVP 1741 The Duplicate-Session-Id AVP (AVP Code TBD.AX) is of type UTF8String. 1742 It is used to report errors and contains the Session-Id of an 1743 existing session. 1745 8.7.10. NAT-External-Port-Style AVP 1747 The NAT-External-Port-Style AVP (AVP Code TBD.AX) is of type 1748 Enumerated and contains the style to be followed while selecting the 1749 external port for a NAT-Binding relative to the internal port. 1751 The following values are defined: 1753 FOLLOW_INTERNAL_PORT_STYLE (1) 1755 External port numbers selected MUST follow the same sequence 1756 and oddity as the internal ports of the NAT-bindings. The port 1757 odditity is required to support protocols like RTP and RTCP as 1758 defined in [RFC3550]. If for example the internal port in a 1759 requested NAT-binding is odd numbered then the external port 1760 allocated MUST also be odd numbered, and vice versa for an even 1761 numbered port. In addition, the sequence of port numbering is 1762 maintained: If internal ports are consecutive, then the NAT- 1763 device MUST choose consecutive external ports for the NAT- 1764 bindings. 1766 9. Accounting Commands 1768 The DNCA reuses session based accounting as defined in the Diameter 1769 Base Protocol[RFC3588] to report the bindings per endpoint. This 1770 reporting is achieved by sending Diameter Accounting Requests (ACR) 1771 [Start, Interim and Stop] from the DNCA Diameter peer within the NAT- 1772 device to its associated DNCA Diameter peer within the NAT- 1773 controller. 1775 The DNCA Diameter peer within the NAT-device sends an ACR Start on 1776 receiving a NCR with NC-Request-Type AVP set to INITIAL_REQUEST for a 1777 session or on creation of the first binding for a session requested 1778 in an earlier NCR. DNCA may send ACR Interim updates, if required, 1779 either due to a change in bindings resulting from a NCR with NC- 1780 Request-Type AVP set to UPDATE_REQUEST, or periodically as specified 1781 in Acct-Interim-Interval by the DNCA Diameter peer within the NAT- 1782 controller, or when it creates or tears down bindings. An ACR Stop 1783 is sent by the DNCA Diameter peer within the NAT-device on receiving 1784 STR. 1786 The function of correlating the multiple bindings used by an endpoint 1787 at any given time is relegated to the post processor. 1789 The DNCA Diameter peer within the NAT-device may trigger an interim 1790 accounting record when the maximum number of bindings, if received in 1791 an NCR, is reached. 1793 9.1. NAT Control Accounting Messages 1795 The ACR and ACA messages are reused as defined in the Diameter Base 1796 Protocol [RFC3588] for exchanging endpoint NAT binding details 1797 between the DNCA Diameter peers. The DNCA Application IDs is used in 1798 the accounting commands. ACR contains one or more optional NAT- 1799 Control-Record AVPs to report the bindings. The NAT-device indicates 1800 the number of allocated NAT bindings to the NAT-controller using the 1801 Current-NAT-Bindings AVP. This number needs to match the number of 1802 bindings identified as active within the NAT-Control-Record AVP. 1804 9.2. NAT Control Accounting AVPs 1806 In addition to AVPs for ACR specified in [RFC3588], the DNCA Diameter 1807 peer within the NAT-device must add the NAT-Control-Record AVP. 1809 9.2.1. NAT-Control-Record 1811 The NAT-Control-Record AVP (AVP code TBD.AX) is of type Grouped. It 1812 describes a binding and its status. If NAT-Control-Binding-Status is 1813 set to Created, Event-Timestamp indicates the binding creation time. 1814 If NAT-Control-Binding-Status is set to Removed, Event-Timestamp 1815 indicates the binding removal time. If NAT-Control-Binding-Status is 1816 active, Event-Timestamp need not be present; if a value is present, 1817 it indicates that binding is active at the given time. 1818 NAT-Control-Record ::= < AVP Header: TBD.AX > 1819 { NAT-Control-Definition } 1820 { NAT-Control-Binding-Status } 1821 [ Event-Timestamp ] 1823 9.2.2. NAT-Control-Binding-Status 1825 The NAT-Control-Binding-Status AVP (AVP code TBD.AX) is of type 1826 enumerated. It indicates the status of the binding - created, 1827 removed, or active. 1829 The following values are defined: 1831 Created (1) 1833 NAT binding is created. 1835 Active (2) 1837 NAT binding is active. 1839 Removed (3) 1841 NAT binding was removed. 1843 9.2.3. Current-NAT-Bindings 1845 The Current-NAT-Bindings AVP (AVP code TBD.AX) is of type Unsigned32. 1846 It indicates the number of NAT bindings active on the NAT-device. 1848 10. AVP Occurrence Table 1850 The following sections present the AVPs defined in this document and 1851 specify the Diameter messages in which they can be present. Note: 1852 AVPs that can only be present within a Grouped AVP are not 1853 represented in this table. 1855 The table uses the following symbols: 1857 0 The AVP MUST NOT be present in the message. 1859 0+ Zero or more instances of the AVP can be present in the 1860 message. 1862 0-1 Zero or one instance of the AVP can be present in the 1863 message. It is considered an error if there is more 1864 than one instance of the AVP. 1866 1 One instance of the AVP MUST be present in the message. 1868 1+ At least one instance of the AVP MUST be present in the 1869 message. 1871 10.1. DNCA AVP Table for NAT Control Initial and Update Requests 1873 The following table lists DNCA specific AVPs that have to be present 1874 in NCRs and NCAs with NC-Request-Type set to INITIAL_REQUEST or 1875 UPDATE_REQUEST. 1877 +-------------------+ 1878 | Command Code | 1879 +-----------------------------------+-------------------+ 1880 | Attribute Name NCR NCA | 1881 +-------------------------------------------------------+ 1882 |NC-Request-Type 1 1 | 1883 |NAT-Control-Install 0-1 0 | 1884 |NAT-Control-Remove 0-1 0 | 1885 |NAT-Control-Definition 0 0 | 1886 |Current-NAT-Bindings 0 0 | 1887 |Duplicate-Session-Id 0 0-1 | 1888 +-------------------------------------------------------+ 1890 Note that any combination of "NAT-Control-Install" and "NAT-Control- 1891 Remove" AVPs could be present in an update or initial requests. 1892 Consider the following examples: 1894 Neither "NAT-Control-Install AVP" nor "NAT-Control-Remove AVP" are 1895 present: This could for example be the case if the NAT-controller 1896 would only want to receive accounting information, but not control 1897 NAT-bindings. 1899 Only "NAT-Control-Install AVP" is present: This could for example 1900 be the case if a new NAT-binding is installed for an existing 1901 session. 1903 Only "NAT-Control-Remove AVP" is present: This could for example 1904 be the case if a new NAT-binding is removed from an existing 1905 session. 1907 Both, "NAT-Control-Install AVP" and "NAT-Control-Remove AVP" are 1908 present: This could for example be the case if a formerly created 1909 NAT-binding is removed and a new NAT-binding is established within 1910 the same request. 1912 10.2. DNCA AVP Table for Session Query request 1914 The following table lists DNCA specific AVPs that have to be present 1915 in NCRs and NCAs with NC-Request-Type set to QUERY_REQUEST. 1917 +-------------------+ 1918 | Command Code | 1919 +-----------------------------------+-------------------+ 1920 | Attribute Name NCR NCA | 1921 +-------------------------------------------------------+ 1922 |NC-Request-Type 1 1 | 1923 |NAT-Control-Install 0 0 | 1924 |NAT-Control-Remove 0 0 | 1925 |NAT-Control-Definition 0 0+ | 1926 |NAT-External-Address 0+ 0 | 1927 |Current-NAT-Bindings 0 1 | 1928 |Duplicate-Session-Id 0 0 | 1929 +-------------------------------------------------------+ 1931 10.3. DNCA AVP Table for Accounting Message 1933 The following table lists DNCA specific AVPs, which may or may not be 1934 present in ACR and ACA messages. 1935 +-------------------+ 1936 | Command Code | 1937 +-----------------------------------+-------------------+ 1938 | Attribute Name ACR ACA | 1939 +-------------------------------------------------------+ 1940 |NAT-Control-Record 0+ 0 | 1941 |Current-NAT-Bindings 1 0 | 1942 +-------------------------------------------------------+ 1944 11. IANA Considerations 1946 This section contains the namespaces that have either been created in 1947 this specification, or the values assigned to existing namespaces 1948 managed by IANA. 1950 In the subsections below, when we speak about review by a Designated 1951 Expert, please note that the designated expert will be assigned by 1952 the IESG. Initially, such Expert discussions take place on the AAA 1953 WG mailing list. 1955 11.1. Application Identifier 1957 This specification assigns the value , 'Diameter NAT 1958 Control Application', to the Application Identifier namespace defined 1959 in [RFC3588]. See Section 4 for more information. 1961 11.2. Command Codes 1963 This specification uses the value from the Command 1964 code namespace defined in [RFC3588] for the NAT-Control-Request 1965 (NCR), NAT-Control-Answer (NCA) commands. See Section 6.1 and 1966 Section 6.2 for more information on these commands. 1968 11.3. AVP Codes 1970 This specification assigns the values from the AVP code 1971 namespace defined in [RFC3588]. See Section 8.7 for the assignment 1972 of the namespace in this specification. 1974 11.4. Result-Code AVP Values 1976 This specification assigns the values (4xxx, 5xxx, 5xxx, 1977 5xxx, 5xxx,5xxx) from the Result-Code AVP value namespace defined in 1978 [RFC3588]. See Section 8.2 for the assignment of the namespace in 1979 this specification. 1981 11.5. NC-Request-Type AVP 1983 As defined in Section 8.7.1, the NC-Request-Type AVP includes 1984 Enumerated type values 1 - 3. IANA has created and is maintaining a 1985 namespace for this AVP. All remaining values are available for 1986 assignment by a Designated Expert [RFC5226]. 1988 11.6. NAT-External-Port-Style AVP 1990 As defined in Section 8.7.10, the NAT-External-Port-Style AVP 1991 includes Enumerated type value 1. IANA has created and is 1992 maintaining a namespace for this AVP. All remaining values are 1993 available for assignment by a Designated Expert [RFC5226]. 1995 11.7. NAT-Control-Binding-Status AVP 1997 As defined in Section 8.7.1, the NAT-Control-Binding-Status AVP 1998 includes Enumerated type values 1 - 3. IANA has created and is 1999 maintaining a namespace for this AVP. All remaining values are 2000 available for assignment by a Designated Expert [RFC5226]. 2002 12. Security Considerations 2004 This document describes procedures for controlling NAT related 2005 attributes and parameters by an entity, which is non-local to the 2006 device performing NAT. This section discusses security 2007 considerations for DNCA. This includes the interactions between the 2008 Diameter peers within a NAT-controller and a NAT-device as well as 2009 general considerations for NAT-control in a service provider network. 2011 Security between a NAT-controller and a NAT-device has a number of 2012 components: authentication, authorization, integrity, and 2013 confidentiality. 2015 Authentication refers to confirming the identity of an originator for 2016 all datagrams received from the originator. Lack of authentication 2017 of Diameter messages between the Diameter peers can jeopardize the 2018 fundamental service of the peering network elements. A consequence 2019 of not authenticating the message sender by the recipient would be 2020 that an attacker could spoof the identity of a "legitimate" 2021 authorizing entity in order to change the behavior of the receiver. 2022 An attacker could for example launch a denial of service attack by 2023 setting the maximum number of bindings for a session on the NAT- 2024 device to zero; provision bindings on a NAT-device which include IP- 2025 addresses already in use in other parts of the network; or request 2026 session termination of the Diameter session and hamper an endpoint's 2027 (i.e. a user's) connectivity. Lack of authentication of a NAT-device 2028 to a NAT-controller could lead to situations where the NAT-device 2029 could provide a wrong view of the resources (i.e. NAT-bindings). In 2030 addition, NAT Binding Predefined template on the NAT-device could be 2031 configured differently than expected by the NAT-controller. Failing 2032 of any of the two DNCA Diameter peers to provide the required 2033 credentials should be subject to logging. The corresponding logging 2034 infrastructure of the operator SHOULD be built in a way that it can 2035 mitigate potential denial of service attacks resulting from large 2036 amounts of logging events. This could include proper dimensioning of 2037 the logging infrastructure combined with policing the maximum amount 2038 of logging events accepted by the logging system to a threshold which 2039 the system is known to be able to handle. 2041 Authorization refers to whether a particular authorizing entity is 2042 authorized to signal a network element requests for one or more 2043 applications, adhering to a certain policy profile. Failing the 2044 authorization process might indicate a resource theft attempt or 2045 failure due to administrative and/or credential deficiencies. In 2046 either case, the network element should take the proper measures to 2047 log such attempts. 2049 Integrity is required to ensure that a Diameter message exchanged 2050 between the Diameter peers has not been maliciously altered by 2051 intermediate devices. The result of a lack of data integrity 2052 enforcement in an untrusted environment could be that an impostor 2053 will alter the messages exchanged between the peers. This could 2054 cause a change of behavior of the peers, including the potential of a 2055 denial of service. 2057 Confidentiality protection of Diameter messages ensures that the 2058 signaling data is accessible only to the authorized entities. When 2059 signaling messages between the DNCA Diameter peers traverse untrusted 2060 networks, lack of confidentiality will allow eavesdropping and 2061 traffic analysis. 2063 Diameter offers security mechanisms to deal with the functionality 2064 demanded above. DNCA makes use of the capabilities offered by 2065 Diameter and the underlying transport protocols to deliver these 2066 requirements (see Section 5.1). If the DNCA communication traverses 2067 untrusted networks, messages between DNCA Diameter peers SHOULD be 2068 secured using either IPsec or TLS. Please refer to [RFC3588], 2069 section 13 for details. DNCA Diameter peers SHOULD perform bilateral 2070 authentication, authorization as well as procedures to ensure 2071 integrity and confidentiality of the information exchange. In 2072 addition the Session-Id chosen for a particular Diameter session 2073 SHOULD be chosen in a way that it is hard to guess in order to 2074 mitigate issues through potential message replay. 2076 DNCA Diameter peers SHOULD have a mutual trust setup. This document 2077 does not specify a mechanisms for authorization between the DNCA 2078 Diameter peers. The DNCA Diameter peers SHOULD be provided with 2079 sufficient information to make an authorization decision. The 2080 information can come from various sources, for example the peering 2081 devices could store local authentication policy, listing the 2082 identities of authorized peers. 2084 Any mechanism or protocol providing control of a NAT-device, and DNCA 2085 is an example of such a control mechanism, could allow for misuse of 2086 the NAT-device given that it enables the definition of per- 2087 destination or per-source rules. Misuse could include anti- 2088 competitive practices among providers, censorship, crime, etc. NAT- 2089 control could be used as a tool for preventing or redirecting access 2090 to particular sites. For instance, by controlling the NAT bindings, 2091 one could ensure that endpoints aren't able to receive particular 2092 flows, or that those flows are redirected to a relay that snoops or 2093 tampers with traffic instead of directly forwarding the traffic to 2094 the intended endpoint. In addition one could set up a binding in a 2095 way that the source IP address used is one of a relay so that traffic 2096 coming back can be snooped on or interfered with. The operator also 2097 needs to consider security threats resulting from unplanned 2098 termination of the DNCA session. Unplanned session termination, 2099 which could e.g. happen due to an attacker taking down the NAT- 2100 controller, leads to the NAT-device cleaning up the state associated 2101 with this session after a grace period. If the grace period is set 2102 to zero, the endpoint will experience an immediate loss of 2103 connectivity to services reachable through the NAT-device following 2104 the termination of the DNCA session.The protections on DNCA and its 2105 Diameter protocol exchanges don't prevent such abuses of NAT-control. 2106 Prevention of mis-use or mis-configuration of a NAT-device by an 2107 authorized NAT-controller is beyond the scope of this protocol 2108 specification. A service provider deploying DNCA needs to make sure 2109 that higher layer processes and procedures are put in place which 2110 allow them to detect and mitigate misuses. 2112 13. Examples 2114 This section shows example DNCA message content and exchange. 2116 13.1. DNCA Session Establishment Example 2118 Figure 15 depicts a typical call flow for DNCA session establishment. 2120 In this example, the NAT-controller: 2122 a. requests a maximum of 100 NAT-bindings for the endpoint. 2124 b. defines a static binding for a TCP connection which associates 2125 the internal IP-Address:Port 192.0.2.1:80 with the external IP- 2126 Address:Port 198.51.100.1:80 for the endpoint. 2128 c. requests the use of a preconfigured template called "local- 2129 policy" while creating NAT-bindings for the endpoint. 2131 endpoint NAT-Controller (within NAS) NAT-device 2132 | | | 2133 | | | 2134 | 1. Trigger | | 2135 |--------------------------->| | 2136 | +-------------------------------------+ | 2137 | | 2. Determine that NAT control | | 2138 | | is required for the endpoint | | 2139 | +-------------------------------------+ | 2140 | | | 2141 | | | 2142 | ................................... 2143 | .| 3. Diameter Base CER/CEA |. 2144 | .|<----------------------------->|. 2145 | ................................... 2146 | | | 2147 | | | 2148 | | 4. NCR | 2149 | |------------------------------>| 2150 | | | 2151 | | 5. DNCA session 2152 | | established 2153 | | | 2154 | | 6. NCA | 2155 | |<------------------------------| 2156 | | | 2157 | | | 2158 | 7. Data traffic | 2159 |----------------------------------------------------------->| 2160 | | | 2161 | | | 2162 | | 8. NAT Bindings 2163 | | created as per 2164 | | directives in the 2165 | | DNCA session 2166 | | | 2168 Figure 15: Initial NAT control request and session establishment 2169 example 2171 Detailed description of the steps shown in Figure 15: 2173 1. The NAT-controller (co-located with the NAS here) creates state 2174 for an endpoint based on a trigger. This could for example be 2175 the successful establishment of a Point-to-Point Protocol (PPP) 2176 [RFC1661] access session. 2178 2. Based on the configuration of the DNCA Diameter peer within the 2179 NAT-controller, the NAT-controller determines that NAT-control is 2180 required and is to be enforced at a NAT-device. 2182 3. If there is no Diameter session already established with the DNCA 2183 Diameter peer within NAT-device, a Diameter connection is 2184 established and Diameter Base CER/CEA are exchanged. 2186 4. The NAT-Controller creates an NCR message (see below) and sends 2187 it to the NAT-device. This example shows IPv4 to IPv4 address 2188 and port translation. For IPv6 to IPv4 translation, the Framed- 2189 IP-Address AVP would be replaced by the Framed-IPv6-Address AVP 2190 with the value set to the IPv6 address of the endpoint. 2191 < NC-Request > ::= < Diameter Header: TBD.COM-CODE, REQ, PXY> 2192 Session-Id = "natC.example.com:33041;23432;" 2193 Auth-Application-Id = 2194 Origin-Host = "natC.example.com" 2195 Origin-Realm = "example.com" 2196 Destination-Realm = "example.com" 2197 Destination-Host = "nat-device.example.com" 2198 NC-Request-Type = INITIAL_REQUEST 2199 User-Name = "subscriber_example1" 2200 Framed-IP-Address = "192.0.2.1" 2201 NAT-Control-Install = { 2202 NAT-Control-Definition = { 2203 Protocol = TCP 2204 Direction = OUT 2205 NAT-Internal-Address = { 2206 Framed-IP-Address = "192.0.2.1" 2207 Port = 80 2208 } 2209 NAT-External-Address = { 2210 Framed-IP-Address = "198.51.100.1" 2211 Port = 80 2212 } 2213 } 2214 Max-NAT-Bindings = 100 2215 NAT-Control-Binding-Template = "local-policy" 2216 } 2218 5. The NAT-device establishes a DNCA session as it is able to comply 2219 with the request. 2221 6. The NAT-device sends an NCA to indicate the successful completion 2222 of the request. 2224 ::= < Diameter Header: TBD.COM-CODE, PXY > 2225 Session-Id = "natC.example.com:33041;23432;" 2226 Origin-Host = "nat-device.example.com" 2227 Origin-Realm = "example.com" 2228 NC-Request-Type = INITIAL_REQUEST 2229 Result-Code = DIAMETER_SUCCESS 2231 7. The endpoint sends packets that reach the NAT-device. 2233 8. The NAT-device performs NAT for traffic received from the 2234 endpoint with source address 192.0.2.1. Traffic with source IP- 2235 address 192.0.2.1 and port 80 are translated to the external IP- 2236 address 198.51.100.1 and port 80. Traffic with source IP-address 2237 192.0.2.1 and a source port different from 80 will be translated 2238 to IP-address 198.51.100.1 and a port chosen by the NAT-device. 2239 Note that this example assumes that the NAT-device follows 2240 typical binding allocation rules for endpoints, in that only a 2241 single external IP-address is used for all traffic received from 2242 a single IP-address of an endpoint. The NAT-device will allow a 2243 maximum of 100 NAT-bindings be created for the endpoint. 2245 13.2. DNCA Session Update with Port Style Example 2247 This section gives an example for a DNCA session update: A new set of 2248 NAT-bindings is requested for an existing session. The request 2249 contains a directive ( the "NAT-External-Port-Style" AVP set to 2250 FOLLOW_INTERNAL_PORT_STYLE) that directs the NAT-device to maintain 2251 port-sequence and port-oddity for the newly created NAT-bindings. In 2252 the example shown, the internal ports are UDP port 1036 and 1037. 2253 The NAT-device follows the directive selects the external ports 2254 accordingly. The NAT-device would for example create a mapping of 2255 192.0.2.1:1036 to 198.51.100.1:5056 and 192.0.2.1:1037 to 2256 198.51.100.1:5057, thereby maintaining port oddity (1036->5056, 2257 1037->5057) and sequence ( the consecutive internal ports 1036 and 2258 1037 map to the consecutive external ports 5056 and 5057). 2260 < NC-Request > ::= < Diameter Header: TBD.COM-CODE, REQ, PXY> 2261 Session-Id = "natC.example.com:33041;23432;" 2262 Auth-Application-Id = 2263 Origin-Host = "natC.example.com" 2264 Origin-Realm = "example.com" 2265 Destination-Realm = "example.com" 2266 Destination-Host = "nat-device.example.com" 2267 NC-Request-Type = UPDATE_REQUEST 2268 NAT-Control-Install = { 2269 NAT-Control-Definition = { 2270 Protocol = UDP 2271 Direction = OUT 2272 NAT-Internal-Address = { 2273 Framed-IP-Address = "192.0.2.1" 2274 Port = 1035 2275 } 2276 } 2277 NAT-Control-Definition = { 2278 Protocol = UDP 2279 Direction = OUT 2280 NAT-Internal-Address = { 2281 Framed-IP-Address = "192.0.2.1" 2282 Port = 1036 2283 } 2284 } 2285 NAT-External-Port- 2286 Style = FOLLOW_INTERNAL_PORT_STYLE 2287 } 2289 13.3. DNCA Session Query Example 2291 This section shows an example for DNCA session query for a subscriber 2292 whose internal IP-Address is 192.0.2.1. 2293 < NC-Request > ::= < Diameter Header: TBD.COM-CODE, REQ, PXY> 2294 Auth-Application-Id = 2295 Origin-Host = "natC.example.com" 2296 Origin-Realm = "example.com" 2297 Destination-Realm = "example.com" 2298 Destination-Host = "nat-device.example.com" 2299 NC-Request-Type = QUERY_REQUEST 2300 Framed-IP-Address = "192.0.2.1" 2302 The NAT-device constructs an NCA to report all currently active NAT- 2303 bindings whose internal address is 192.0.2.1. 2305 ::= < Diameter Header: TBD.COM-CODE, PXY > 2306 Origin-Host = "nat-device.example.com" 2307 Origin-Realm = "example.com" 2308 NC-Request-Type = QUERY_REQUEST 2309 NAT-Control-Definition = { 2310 Protocol = TCP 2311 Direction = OUT 2312 NAT-Internal-Address = { 2313 Framed-IP-Address = "192.0.2.1" 2314 Port = 80 2315 } 2316 NAT-External-Address = { 2317 Framed-IP-Address = "198.51.100.1" 2318 Port = 80 2319 } 2320 Session-Id = "natC.example.com:33041;23432;" 2321 } 2322 NAT-Control-Definition = { 2323 Protocol = TCP 2324 Direction = OUT 2325 NAT-Internal-Address = { 2326 Framed-IP-Address = "192.0.2.1" 2327 Port = 1036 2328 } 2329 NAT-External-Address = { 2330 Framed-IP-Address = "198.51.100.1" 2331 Port = 5056 2332 } 2333 Session-Id = "natC.example.com:33041;23432;" 2334 } 2335 NAT-Control-Definition = { 2336 Protocol = TCP 2337 Direction = OUT 2338 NAT-Internal-Address = { 2339 Framed-IP-Address = "192.0.2.1" 2340 Port = 1037 2341 } 2342 NAT-External-Address = { 2343 Framed-IP-Address = "198.51.100.1" 2344 Port = 5057 2345 } 2346 Session-Id = "natC.example.com:33041;23432;" 2347 } 2349 13.4. DNCA Session Termination Example 2351 In this example the NAT-controller decides to terminate the 2352 previously established DNCA session. This could for example be the 2353 case as a result of an access session (e.g. a PPP session) associated 2354 with an endpoint been torn down. 2356 NAT-Controller NAT-device 2357 | | 2358 | | 2359 +--------------+ | 2360 | 1. Trigger | | 2361 +--------------+ | 2362 | | 2363 | | 2364 | 2. STR | 2365 |-------------------------------------->| 2366 | | 2367 | 3. DNCA session 2368 | lookup 2369 | 4. ACR | 2370 |<--------------------------------------| 2371 | | 2372 | 5. ACA | 2373 |-------------------------------------->| 2374 | | 2375 | | 2376 | 6. DNCA bindings 2377 | and session cleanup 2378 | | 2379 | 7. STA | 2380 |<--------------------------------------| 2381 | | 2383 Figure 20: NAT control session termination example 2385 The following steps describe the sequence of events for tearing down 2386 the DNCA session in the example above: 2388 1. The NAT-controller receives a trigger that a DNCA session 2389 associated with a specific endpoint should be terminated. An 2390 example event could be the termination of the PPP [RFC1661] 2391 access session to an endpoint in a NAS. The NAS correspondingly 2392 triggers the NAT-controller request tear-down of the associated 2393 DNCA session. 2395 2. The NAT-controller creates the required NCR message and sends it 2396 to the NAT-device: 2398 < STR > ::= < Diameter Header: 275, REQ, PXY> 2399 Session-Id = "natC.example.com:33041;23432;" 2400 Auth-Application-Id = 2401 Origin-Host = "natC.example.com" 2402 Origin-Realm = "example.com" 2403 Destination-Realm = "example.com" 2404 Destination-Host = "nat-device.example.com" 2405 Termination-Cause = DIAMETER_LOGOUT 2407 3. The NAT-device looks up the DNCA session based on the Session-Id 2408 AVP and finds a previously established active session. 2410 4. The NAT-device reports all NAT-bindings established for that 2411 subscriber using an ACR: 2412 < ACR > ::= < Diameter Header: 271, REQ, PXY> 2413 Session-Id = "natC.example.com:33041;23432;" 2414 Auth-Application-Id = 2415 Origin-Host = "nat-device.example.com" 2416 Origin-Realm = "example.com" 2417 Destination-Realm = "example.com" 2418 Destination-Host = "natC.example.com" 2419 Accounting-Record-Type = STOP_RECORD 2420 Accounting-Record-Number = 1 2421 NAT-Control-Record = { 2422 NAT-Control-Definition = { 2423 Protocol = TCP 2424 Direction = OUT 2425 NAT-Internal-Address = { 2426 Framed-IP-Address = "192.0.2.1" 2427 Port = 5001 2428 } 2429 NAT-External-Address = { 2430 Framed-IP-Address = "198.51.100.1" 2431 Port = 7777 2432 } 2433 } 2434 NAT-Control-Binding-Status = Removed 2435 } 2437 5. The NAT-controller receives and processes the ACR as per its 2438 configuration. It responds with an ACA to the NAT-device. 2440 ::= < Diameter Header: 271, PXY > 2441 Session-Id = "natC.example.com:33041;23432;" 2442 Origin-Host = "natC.example.com" 2443 Origin-Realm = "example.com" 2444 Result-Code = DIAMETER_SUCCESS 2445 Accounting-Record-Type = STOP_RECORD 2446 Accounting-Record-Number = 1 2448 6. On receipt of the ACA the NAT-device cleans up all NAT-bindings 2449 and associated session state for the endpoint. 2451 7. NAT-device sends an STA. On receipt of the STA the NAT- 2452 controller will clean up the corresponding session state. 2453 ::= < Diameter Header: 275, PXY > 2454 Session-Id = "natC.example.com:33041;23432;" 2455 Origin-Host = "nat-device.example.com" 2456 Origin-Realm = "example.com" 2457 Result-Code = DIAMETER_SUCCESS 2459 14. Acknowledgements 2461 The authors would like to thank Jari Arkko, Wesley Eddy, Stephen 2462 Farrell, Miguel A. Garcia, David Harrington, Jouni Korhonen, Matt 2463 Lepinski, Avi Lior, Chris Metz, Pallavi Mishra, Lionel Morand, Robert 2464 Sparks, Martin Stiemerling, Dave Thaler, Hannes Tschofenig, Sean 2465 Turner, Shashank Vikram, Greg Weber, and Glen Zorn for their input on 2466 this document. 2468 15. Change History (to be removed prior to publication as an RFC) 2470 Changes from -00 to -01 2472 a. new values for Result-Code AVP used - instead of Experimental- 2473 Result AVP 2475 b. added support for transport specific binding (UDP/TCP) 2477 c. added support for twice-NAT 2479 d. clarified the use of the two different types of query-requests 2481 Changes from -01 to -02 2482 a. Reference to pull mode removed, session initiation event 2483 clarified in section 4.1 2485 b. added Redirect-* AVPs in NCA command 2487 c. Removed reference to Called-Station-Id AVP in NCR command 2489 d. Editorial changes 2491 e. added support for bindings providing AFT (NAT64) 2493 Changes from -02 to -03 2495 a. Editorial changes 2497 Changes from -03 to -04 2499 a. Editorial changes suggested in WG last call review 2501 b. Removed NCR Request type terminate and replaced with STR 2503 c. All references to Auth-Session-State are removed and a new 2504 section to describe FSM for Manager and Agent has been added 2506 d. Clarified reuse of External address and address pools among 2507 multiple subscribers 2509 Changes from -04 to -05 2511 a. Removed references to Large Scale NAT as per review comments 2513 Changes from -05 to -06 2515 a. Editorial changes 2517 Changes from -06 to -07 2519 a. Added a note in section 4.3 stating the state of pre-existing 2520 bindings on update failure 2522 b. Security considerations are made consistent between sections 5.1 2523 and 12 2525 c. Editorial changes 2527 Changes from -07 to -08 2528 a. Added section 4.6 to describe session abort 2530 b. Editorial changes 2532 c. Nomenclature change: From DNCA Agent/Manager to DNCA Diameter 2533 peers identifying the location where they reside (NAT-controller 2534 or NAT-device) 2536 d. IANA consideration Section format changes 2538 e. Updated security section (included considerations directly, 2539 rather than referring to Diameter QoS similarities). 2541 Changes from -08 to -09 2543 a. expanded on the need for an SP controlling the maximum number of 2544 bindings of an endpoint (see introduction section) 2546 b. added a paragraph in the security section outlining general mis- 2547 uses of NAT-control (non specific to DNCA), with DNCA being an 2548 example of such a NAT-control protocol 2550 c. editorial changes 2552 Changes from -09 to -10 2554 a. Section 4 and security considerations updated with RFC 2119 2555 language 2557 b. NAT-External-Port-Style AVP added to aid external port oddity 2558 requirement as per MIDCOM framework 2560 c. NAT related RFCs added in normative reference 2562 d. Section 13 added to provide example DNCA message exchange flows 2564 e. Added a description to provide DNCA comparison with MIDCOM 2566 f. n:1 deployment model for NAT-controllers and NAT-devices 2567 explicitly specified 2569 g. editorial changes as per IESG DISCUSS comments 2571 Changes from -10 to -11 2573 a. clarified DNCA session query to be done after Diameter session is 2574 established 2576 b. Section 4.4 Session Termination updated to specify resource 2577 cleanup at NAT-Device upon session termination 2579 c. Removed Framed-IP-Netmask AVP from NAT-External-Address as 2580 external address is fully defined by Framed-IP-Address AVP 2582 d. Updated Section 12 to highlight Session-Id to be chosen such that 2583 it is hard to guess 2585 e. editorial changes as per IESG DISCUSS 2587 Changes from -11 to -12 2589 a. endpoint replaces references to end point and user and defines 2590 what Endpoint means in this draft 2592 b. editorial changes as per IESG DISCUSS 2594 Changes from -12 to -13 2596 a. Section 4.3 session query updated to use NAT-External-Address for 2597 external IP-address based query 2599 Changes from -13 to -14 2601 a. Added NAT-External-Address in NC-request for session query by 2602 external IP-address 2604 b. Reordered all mandatory AVPs in NCR and NCA to appear before 2605 optional AVPs 2607 Changes from -14 to -15 2609 a. As part of IESG discuss - clarified that multiple methods if used 2610 along with DNCA for NAT control should be configured to prevent 2611 conflict. 2613 b. Clarified misuse of NAT-device by a Diameter authorized NAT- 2614 controller using DNCA is beyond the scope of this protocol 2615 specification. 2617 c. Editorial updates. 2619 Changes from -15 to -16 2621 a. Extended section covering case of a single NAT-device controlled 2622 by multiple NAT-ontrollers which use different protocols for 2623 configuring the NAT-device. 2625 b. Added NAT-device state cleanup in case of unexpected/unplanned 2626 termination of Diameter session or application either on NAT- 2627 controller or NAT-device. 2629 c. Added MAX_BINDINGS_SET_FAILURE failure case (for those scenarios 2630 where the maximum number of bindings cannot be set by the 2631 controller) 2633 Change from -16 to -17 2635 a. Clarified that the endpoint identifier Framed-IP-Address and the 2636 internal address in NAT-Internal-Address specified to install 2637 NAT-bindings for the session MUST match. 2639 16. References 2641 16.1. Normative References 2643 [ETSIES283034] 2644 ETSI, "Telecommunications and Internet Converged Services 2645 and Protocols for Advanced Networks (TISPAN),Network 2646 Attachment Sub-System (NASS),e4 interface based on the 2647 Diameter protocol.", September 2008. 2649 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2650 Requirement Levels", BCP 14, RFC 2119, March 1997. 2652 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 2653 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 2655 [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, 2656 "Diameter Network Access Server Application", RFC 4005, 2657 August 2005. 2659 [RFC4675] Congdon, P., Sanchez, M., and B. Aboba, "RADIUS Attributes 2660 for Virtual LAN and Priority Support", RFC 4675, 2661 September 2006. 2663 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2664 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 2665 May 2008. 2667 [RFC5777] Korhonen, J., Tschofenig, H., Arumaithurai, M., Jones, M., 2668 and A. Lior, "Traffic Classification and Quality of 2669 Service (QoS) Attributes for Diameter", RFC 5777, 2670 February 2010. 2672 16.2. Informative References 2674 [I-D.ietf-behave-lsn-requirements] 2675 Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A., 2676 and H. Ashida, "Common requirements for Carrier Grade NATs 2677 (CGNs)", draft-ietf-behave-lsn-requirements-05 (work in 2678 progress), November 2011. 2680 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, 2681 RFC 1661, July 1994. 2683 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 2684 Translator (NAT) Terminology and Considerations", 2685 RFC 2663, August 1999. 2687 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 2688 Address Translator (Traditional NAT)", RFC 3022, 2689 January 2001. 2691 [RFC3303] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and 2692 A. Rayhan, "Middlebox communication architecture and 2693 framework", RFC 3303, August 2002. 2695 [RFC3304] Swale, R., Mart, P., Sijben, P., Brim, S., and M. Shore, 2696 "Middlebox Communications (midcom) Protocol Requirements", 2697 RFC 3304, August 2002. 2699 [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An 2700 Architecture for Describing Simple Network Management 2701 Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, 2702 December 2002. 2704 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 2705 Jacobson, "RTP: A Transport Protocol for Real-Time 2706 Applications", STD 64, RFC 3550, July 2003. 2708 [RFC4097] Barnes, M., "Middlebox Communications (MIDCOM) Protocol 2709 Evaluation", RFC 4097, June 2005. 2711 [RFC5189] Stiemerling, M., Quittek, J., and T. Taylor, "Middlebox 2712 Communication (MIDCOM) Protocol Semantics", RFC 5189, 2713 March 2008. 2715 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 2716 Algorithm", RFC 6145, April 2011. 2718 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 2719 NAT64: Network Address and Protocol Translation from IPv6 2720 Clients to IPv4 Servers", RFC 6146, April 2011. 2722 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 2723 Bierman, "Network Configuration Protocol (NETCONF)", 2724 RFC 6241, June 2011. 2726 Authors' Addresses 2728 Frank Brockners 2729 Cisco 2730 Hansaallee 249, 3rd Floor 2731 DUESSELDORF, NORDRHEIN-WESTFALEN 40549 2732 Germany 2734 Email: fbrockne@cisco.com 2736 Shwetha Bhandari 2737 Cisco 2738 Cessna Business Park, Sarjapura Marathalli Outer Ring Road 2739 Bangalore, KARNATAKA 560 087 2740 India 2742 Email: shwethab@cisco.com 2744 Vaneeta Singh 2745 18, Cambridge Road 2746 Bangalore 560008 2747 India 2749 Email: vaneeta.singh@gmail.com 2751 Victor Fajardo 2752 Telcordia Technologies 2753 1 Telcordia Drive #1S-222 2754 Piscataway, NJ 08854 2755 USA 2757 Email: vf0213@gmail.com