idnits 2.17.1 draft-brockners-diameter-nat-control-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 64 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 3, 2009) is 5532 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) == Unused Reference: 'RFC4005' is defined on line 1585, but no explicit reference was found in the text == Unused Reference: '3GPP32299' is defined on line 1597, but no explicit reference was found in the text == Unused Reference: 'RFC4675' is defined on line 1603, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3588 (Obsoleted by RFC 6733) == Outdated reference: A later version (-15) exists of draft-ietf-dime-qos-attributes-11 -- Obsolete informational reference (is this intentional?): RFC 4005 (Obsoleted by RFC 7155) == Outdated reference: A later version (-05) exists of draft-nishitani-cgn-01 == Outdated reference: A later version (-15) exists of draft-ietf-dime-diameter-qos-07 Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Diameter Maintenance and Extensions F. Brockners 2 Internet Draft V. Singh 3 S. Bhandari 4 Cisco Systems 5 Intended status: Standards Track March 3, 2009 6 Expires: September 3, 2009 8 Diameter NAT Control Application 9 draft-brockners-diameter-nat-control-00.txt 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on August 29, 2009. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents in effect on the date of 41 publication of this document (http://trustee.ietf.org/license-info). 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. 45 This Internet-Draft is submitted to IETF in full conformance with the 46 provisions of BCP 78 and BCP 79. 48 Internet-Drafts are working documents of the Internet Engineering 49 Task Force (IETF), its areas, and its working groups. Note that 50 other groups may also distribute working documents as Internet- 51 Drafts. 53 Abstract 55 This document describes the framework, messages, and procedures for 56 the Diameter NAT Control Application (DNCA), allowing for per- 57 endpoint control of large scale NAT devices, which are put in place 58 to cope with IPv4-address space completion. The Diameter NAT Control 59 Application allows external devices to configure and manage a Large 60 Scale NAT (LSN) device - expanding the existing Diameter-based AAA 61 and policy control capabilities with a NAT control component. These 62 external devices can be network elements in the data plane such as a 63 Network Access Server (NAS), or can be more centralized control plane 64 devices such as AAA-servers. DNCA establishes a context to commonly 65 identify and manage endpoints on a gateway or server, and a large 66 scale NAT device. This includes, for example, the control of the 67 total number of NAT-bindings allowed or the allocation of a specific 68 NAT-binding for a particular endpoint. In addition, it allows large 69 scale NAT devices to provide information relevant to accounting 70 purposes. 72 Table of Contents 74 Copyright Notice...............................................1 75 Abstract.......................................................2 76 1. Introduction...................................................5 77 2. Terminology....................................................6 78 3. Deployment framework and DNCA capabilities.....................6 79 3.1. Diameter NAT Control Application capabilities.............6 80 3.2. LSN Control Deployment Framework..........................8 81 3.2.1. LSN Deployment Scenario..............................8 82 3.2.2. Diameter NAT Control Application overview............9 83 3.2.3. Deployment scenarios for the Diameter NAT Control 84 Application................................................10 85 4. Diameter NAT Control Application Session Establishment and 86 Management.......................................................12 87 4.1. Parties involved.........................................12 88 4.2. Session Establishment....................................13 89 4.3. Session Re-Authorization.................................16 90 4.4. Session and Binding Query................................18 91 4.5. Session Termination......................................20 92 4.6. DNCA Manager/Agent failures..............................21 93 5. Use of the DIAMETER base protocol.............................22 94 5.1. Securing DIAMETER messages...............................22 95 5.2. Accounting functionality.................................22 96 5.3. Use of sessions..........................................22 97 5.4. Routing considerations...................................23 98 5.5. Advertising Application support..........................23 99 6. Diameter NAT Control Application Commands.....................23 100 6.1. NAT-Control Request (NCR) Command........................23 101 6.2. NAT-Control Answer (NCA) Command.........................25 102 7. Diameter NAT Control Application AVPs.........................26 103 7.1. Reused Base Protocol AVPs................................26 104 7.2. Experimental-Result-Code AVP values......................26 105 7.2.1. Success.............................................27 106 7.2.2. Transient failures..................................27 107 7.2.3. Permanent failures..................................27 108 7.3. Reused NASREQ Diameter application AVPs..................28 109 7.4. Reused from RFC 4675.....................................29 110 7.5. Reused from Diameter QoS Application [I-D.ietf-dime-qos- 111 attributes]...................................................29 112 7.6. Reused from ETSI ES 283 034, e4 Diameter application.....30 113 7.7. Diameter NAT Control Application Defined AVPs............31 114 7.7.1. NC-Request-Type AVP.................................31 115 7.7.2. NAT-Control-Install AVP.............................32 116 7.7.3. NAT-Control-Remove AVP..............................33 117 7.7.4. NAT-Control-Definition AVP..........................33 118 7.7.5. NAT-Internal-Address AVP............................33 119 7.7.6. NAT-External-Address AVP............................33 120 7.7.7. Max-NAT-Bindings....................................34 121 7.7.8. NAT-Control-Binding-Rule............................34 122 7.7.9. Duplicate-Session-Id AVP............................34 123 8. Accounting Commands...........................................34 124 8.1. NAT Control Accounting Messages..........................35 125 8.2. NAT Control Accounting AVPs..............................35 126 8.2.1. NAT-Control-Record..................................35 127 8.2.2. NAT-Control-Binding-Status..........................35 128 8.2.3. Current-NAT-Bindings................................36 129 9. AVP Occurrence Table..........................................36 130 9.1. DNCA AVP Table for NAT control initial & update requests 37 131 9.2. DNCA AVP Table for Session Query request.................37 132 9.3. DNCA AVP Table for NAT Control Terminate requests........37 133 9.4. DNCA AVP Table for accounting message....................38 134 10. IANA Considerations..........................................38 135 10.1. Command Codes...........................................38 136 10.2. AVP Codes...............................................39 137 10.3. Application IDs.........................................39 138 11. Security Considerations......................................39 139 12. References...................................................40 140 12.1. Normative References....................................40 141 12.2. Informative References..................................40 142 13. Author's Addresses...........................................41 144 1. Introduction 146 With the foreseeable depletion of available IPv4 addresses from the 147 IANA pool, service providers are starting to consider network designs 148 which no longer assign unique global IPv4 addresses to their 149 subscribers. One of the approaches considered, is the deployment of a 150 provider-operated large scale NAT device between the end-users and 151 the Internet. Nishitani et al. [I-D.nishitani-cgn] call this NAT 152 device a ''Large Scale NAT (LSN)''. 154 LSNs will be inserted into the existing subscriber access and 155 aggregation networks which typically provide for per-endpoint service 156 management and control as well as per-endpoint accounting. Per- 157 endpoint rules include those which relate to service offerings of the 158 SP (e.g. access bandwidth, time or volume based access restrictions) 159 as well as rules which follow legal regulations of the ''National 160 Regulation Authorities (NRA)''. The introduction of a LSN impacts the 161 per-endpoint service offerings as well as the regulatory requirements 162 and gives rise to new control requirements within the service 163 provider network: Service providers need to manage the behavior of 164 the LSN on a per-endpoint basis. 166 The per-endpoint management capabilities of a LSN comprise, for 167 example the control of the number of NAT-address-port pairs (often 168 called ''NAT-bindings'' or simply ''bindings'') allocated to a single 169 endpoint. Given that global IPv4 address-port pairs are becoming a 170 scarce resource, several service providers intend to restrict the 171 number of NAT-bindings on a per endpoint basis and thus increase 172 address utilization efficiency. The number of bindings an endpoint 173 can consume becomes another parameter within a tiered-service 174 offering. In addition, the service provider might offer static 175 bindings to endpoints or pre-allocate external IP-address/port-ranges 176 to certain endpoints. One of the NRA requirements is that a service 177 provider needs to provide the identity of a user (which e.g. 178 translates to the public IP address and ports leveraged by the user 179 at a given point in time) upon request. 181 Dynamic per-endpoint management at the LSN requires an associated 182 interface that has to be tightly integrated with the existing per- 183 endpoint authentication, authorization, and accounting (AAA) 184 environment of the service provider. 186 This document describes the framework, messages and procedures for 187 the Diameter carrier-grade NAT Control Application (DNCA). The DNCA 188 interacts with the LSN to coordinate per-endpoint configuration and 189 management of subscriber traffic traversing the LSN. Use of a 190 Diameter application allows for simple integration into the existing 191 AAA environment of a service provider. 193 2. Terminology 195 Conventions used in this document 197 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 198 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 199 document are to be interpreted as described in [RFC2119]. 201 Abbreviations are used in this document: 203 AAA: Authentication, Authorization, Accounting 205 DNCA: Diameter NAT Control Application 207 LSN: Large Scale NAT device 209 NAT: Network Address Translation 211 NAS: Network Access Server 213 NAT-Binding or Binding: Association of two IP-address/port pairs 214 (with one IP-address typically being private and the other one 215 public) to facilitate NAT 217 NRA: National Regulatory Authority 219 3. Deployment framework and DNCA capabilities 221 3.1. Diameter NAT Control Application capabilities 223 The Diameter NAT control application offers the following 224 capabilities: 226 1 Limit the number of NAT-bindings per endpoint: 227 Define/restrict the maximum number of NAT-bindings on a per- 228 endpoint basis. This enables service providers to offer 229 differentiated services based on the number of bindings and hence 230 optimize the consumption of IP-address/port-ranges. 232 2 Request the allocation of specific NAT-bindings: Under normal 233 operation the LSN would allocate NAT-bindings based on rules and 234 algorithms local to the LSN. Fixed or pre-defined bindings would 235 be the exception rather than the rule but are essential for 236 certain deployment scenarios. Requests for NAT-binding allocation 237 could happen either at or after initial session establishment. Two 238 cases could be distinguished: 240 o Request the allocation of a pre-defined NAT-binding. Both the 241 internal as well as the external IP-address/port pair are 242 specified within the request. Some deployment cases, such as 243 access to a web-server within a user's home network with IP- 244 address and port, benefit from statically configured 245 bindings. 247 o Request the allocation of an external IP-address for a given 248 internal IP-address and report the allocated external IP- 249 address back to the requestor. In some deployment scenarios, 250 the application requires immediate knowledge of the allocated 251 binding for a given internal IP-address but does not control 252 the allocation of the external IP-address (e.g. SIP-proxy 253 server deployments). 255 3 Define the external address-pool(s) to be used for allocating an 256 external IP-address. External address-pools can either be pre- 257 defined on the LSN, or specified within a request. If pre-defined 258 address-pools are used, a request would just include a reference 259 (e.g. name) to an already defined address pool on LSN. Otherwise, 260 the request will contain a description of the IP-address pool(s) 261 to be used (e.g. list of IP-subnets). 263 4 Accounting/Reporting: Report established bindings for a particular 264 user. Apart from statistical and charging purposes, binding 265 reporting is also required for legal reasons. Most National 266 Regulatory Authorities (NRA) require that service providers 267 provide the identity of a user upon request. The service provider 268 needs to be able to correlate a tuple (public IP-address, port, 269 time) to a particular user or endpoint. 271 5 Flexible Information Query: Report details and statistics of 272 bindings for a single endpoint or a set of endpoints through an 273 external interface which integrates with the overall per-endpoint 274 management suite. Hence this information query capability of the 275 DNCA potentially complements alternative information query 276 mechanisms such as SNMP-based mechanisms. 278 6 Global Endpoint ID: The global endpoint ID will allow for common 279 identification of an endpoint on a LSN as well as other endpoint- 280 or subscriber-aware devices such as a Network Access Server (NAS) 281 or an AAA system. Endpoints are identified through a single or a 282 set of classifiers such as IP address, VLAN identifier, or 283 interface identifier which uniquely identify the traffic 284 associated with a particular global endpoint. 286 3.2. LSN Control Deployment Framework 288 3.2.1. LSN Deployment Scenario 290 Figure 1 shows a typical network deployment for internet access. A 291 user's IPv4-host gains access to the internet though a Network Access 292 Server (NAS) which facilitates the authentication of the endpoint and 293 configures the user's connection according to the authorization and 294 configuration data received from the AAA-server upon successful 295 authentication. Public IPv4 addresses are used throughout the 296 network. 298 +---------+ 299 | | 300 | AAA | 301 | | 302 +---------+ 303 | 304 | 305 | 306 | 307 +---------+ +---------+ +----------+ 308 | IPv4 | | | | IPv4 | 309 | Host |----------| NAS |-------------| Internet | 310 | | | | | | 311 +---------+ +---------+ +----------+ 313 <-------------------- Public IPv4 ----------------------> 315 Figure 1: Typical network deployment for internet access 317 Figure 2 depicts the deployment scenario when a service provider 318 introduces a LSN to increase the efficiency of the global IPv4 319 address pool utilization. The objective is to provide the customer 320 with connectivity to the public IPv4 Internet. The LSN performs 321 network address translation between private IPv4 addresses and public 322 IPv4 addresses. If the LSN would be put in place without any endpoint 323 awareness, the service offerings of the service provider would be 324 hampered. Provisioning static NAT-bindings for particular endpoints, 325 using different public IP-address pools for different set of 326 endpoints (e.g. residential or business customers), as well as 327 reporting on the allocated bindings on a per-endpoint basis would be 328 burdensome for a service provider if the LSN would not be aware of 329 endpoints and allow for per-endpoint control and management which 330 easily integrates with the already existing per-endpoint management 331 infrastructure of the service provider. 333 +---------+ 334 | | 335 | AAA | 336 | | 337 +---------+ 338 | 339 | 340 | 341 | 342 +--------+ +---------+ +---------+ +----------+ 343 | IPv4 | | | | | | IPv4 | 344 | Host |----| NAS |----| LSN |----| Internet | 345 | | | | | | | | 346 +--------+ +---------+ +---------+ +----------+ 348 <-------- Private IPv4 -----------><------- Public IPv4 -----> 350 Figure 2: Access network deployment with LSN 352 3.2.2. Diameter NAT Control Application overview 354 The Diameter NAT Control Application runs between a Diameter NAT 355 Control Application Agent on the LSN and the Diameter NAT Control 356 Application Manager. DNCA allows for per-endpoint control and 357 management of a LSN. Being based on Diameter, DNCA integrates well 358 with the suite of Diameter applications deployed for per-endpoint 359 authentication, authorization, accounting, and policy control in 360 service provider networks. 362 DNCA offers request and answer commands to control the allowed number 363 of NAT-bindings per endpoint, to request the allocation of specific 364 bindings for an endpoint, to define the address pool to be used for 365 an endpoint, to provide per endpoint reporting on the allocated NAT- 366 bindings, as well as to provide for unique identification of an 367 endpoint on both LSN, AAA-server and NAS, thus simplifying the 368 correlation of accounting data streams. 370 DNCA allows for controlling the behavior of a LSN on a per-endpoint 371 basis during initial session establishment as well as at later stages 372 by providing an update procedure for already established sessions. 373 Using DNCA, per-endpoint NAT-binding information can be retrieved 374 either using accounting mechanisms or through an explicit session 375 query to the LSN. 377 3.2.3. Deployment scenarios for the Diameter NAT Control Application 379 Deployment dependent, the role of the Diameter NAT Control Manager 380 can be fulfilled by either the NAS or by an external server such as 381 an AAA-server. The two deployment scenarios are outlined in Figure 3 382 (''integrated deployment'') and Figure 4 (''autonomous deployment''). 384 Within the figures (M) denotes the network element which takes on the 385 DNCA manager role. Similarly, (A) identifies the network element 386 which performs the DNCA agent role. 388 The integrated deployment approach hides the existence of the LSN 389 from external servers such as the AAA-server as much as possible. It 390 is suited for environments where minimal changes to the existing AAA 391 deployment are desired. The NAS, taking the role of the DNCA 392 manager, is in charge of initiating and managing the session to the 393 LSN, exchanging LSN specific configuration information as well as 394 handling reporting and accounting information. The NAS receives 395 reporting and accounting information from LSN. This way the NAS can 396 provide for a single accounting record for the user - - offloading 397 external accounting systems from correlating accounting information 398 received from multiple sources. 400 An example network attachment for an integrated LSN deployment could 401 be described as follows: An endpoint connects to the network, with 402 the NAS being the point of attachment. After successful 403 authentication, NAS receives endpoint related authorization data from 404 the AAA-server. A portion of the authorization data applies to per- 405 endpoint configuration on the NAS itself, another portion describes 406 authorization and configuration information for NAT control aimed at 407 the LSN. NAS will initiate a DNCA session to the LSN and send the 408 relevant authorization and configuration information for the 409 particular endpoint to the LSN. This could comprise e.g. NAT-bindings 410 which have to be pre-established for the endpoint, or management 411 related configuration, such as the maximum number of NAT-bindings 412 allowed for the endpoint or accounting requirements. The LSN will 413 send its per-endpoint accounting information to the NAS which 414 aggregates the accounting information received form the LSN with its 415 local accounting information for the endpoint into a single 416 accounting stream towards the AAA-server. 418 +---------+ 419 | | 420 | AAA | 421 | | 422 +---------+ 423 | 424 | 425 | 426 +--------+ +---------+ +---------+ +----------+ 427 | IPv4 | | (M) | | (A) | | IPv4 | 428 | Host |----| NAS |----| LSN |----| Internet | 429 | | | | | | | | 430 +--------+ +---------+ +---------+ +----------+ 432 <-------- Private IPv4 -----------><------- Public IPv4 -----> 434 Figure 3: LSN Control deployment: Integrated deployment 436 The autonomous deployment approach decouples user management on NAS 437 and LSN. The AAA system performing the role of the DNCA manager 438 manages the connection to the LSN, controls the per-endpoint 439 configuration, and also receives accounting and reporting information 440 from LSN. Different from the integrated deployment scenario, the 441 autonomous deployment scenario does not ''hide'' the existence of the 442 LSN from the AAA infrastructure. Here two accounting streams are 443 received by the AAA-server for one particular endpoint - - one from the 444 NAS, and one from the LSN. 446 +---------+ 447 | (M) | 448 | AAA | 449 | | 450 +---------+ 451 | 452 | 453 | 454 +--------+ +---------+ +---------+ +----------+ 455 | IPv4 | | | | (A) | | IPv4 | 456 | Host |----| NAS |----| LSN |----| Internet | 457 | | | | | | | | 458 +--------+ +---------+ +---------+ +----------+ 460 <-------- Private IPv4 -----------><------- Public IPv4 -----> 462 Figure 4: LSN Control deployment: Autonomous deployment 464 4. Diameter NAT Control Application Session Establishment and Management 466 Note that this section forward references some of the commands and 467 AVPs defined for the DNCA. Please refer to sections 6. and 7. for 468 details. 470 4.1. Parties involved 472 Authorization and control models supported by this application 473 include the following parties: 475 o Diameter NAT Control Application (DNCA) agent: The DNCA agent is 476 part of the Large scale NAT (LSN) device 477 o Diameter NAT Control Application (DNCA) manager 478 The current version of the draft assumes that the NAT control 479 requesting entity is always the DNCA manager. Sessions will always be 480 initiated, updated, or terminated by the DNCA manager. This mode of 481 operation is sometimes also referred to as ''push mode''. Session 482 initiation by the DNCA agent (sometimes referred to as ''pull mode'') 483 will be covered in a future version of this draft. 485 4.2. Session Establishment 487 The DNCA manager establishes a session to the DNCA agent to control 488 the behavior of the NAT device. During session establishment, the 489 DNCA manager will pass along configuration information to the DNCA 490 agent. Session configuration information could for example comprise 491 the maximum number of bindings allowed for the endpoint associated 492 with this session, a set of pre-defined NAT-bindings to be 493 established for this endpoint, or a description of the address pool, 494 external addresses should be allocated from. 496 The DNCA manager initiates the Diameter NAT Control session to the 497 DNCA agent. The DNCA manager generates a NAT-Control Request (NCR) 498 message to the DNCA agent with NC-Request-Type AVP set to 499 INITIAL_REQUEST. On receipt of the NCR the DNCA agent will setup a 500 new session for the endpoint associated with the endpoint 501 classifier(s) contained in the NCR. The DNCA agent notifies the DNCA 502 manager about successful session setup using a NAT-Control Answer 503 (NCA) message with Result-Code set to DIAMETER_SUCCESS. Figure 5 504 shows the protocol interaction between the DNCA manager and the DNCA 505 agent. 507 The initial NAT-Control-Request can contain configuration information 508 for the session which specifies the behavior of the LSN for the 509 session. Configuration information which can be included comprises: 511 o A list of NAT-bindings which should be pre-allocated for the 512 session (e.g. in case a subscriber requires a fixed external IP- 513 address/port pair for one of his applications). 515 o The maximum number of NAT bindings allowed for an endpoint. 517 o A description of the external address pool(s) to be used for the 518 session. 520 o A reference to a predefined binding rule on DNCA agent that will 521 be applied to the session. Such a predefined binding rule on DNCA 522 agent may contain, for example, the name of the IP-address pool 523 that external IP-addresses should be allocated from, maximum 524 number of bindings permitted for the endpoint etc. 526 In certain cases, the DNCA agent may not be able to perform the tasks 527 requested within the NCR. These include the following: 529 o If a DNCA agent receives a NCR from a DNCA manager with NC- 530 Request-Type AVP set to INITIAL_REQUEST that identifies an already 531 existing session (i.e. DNCA manager and endpoint identifier match 532 an already existing session), the DNCA agent will return NCA with 533 Experimental-Result-Code set to Session-Exists, and provides 534 Session-Id of the existing session in Duplicate-Session-Id AVP. 536 o If a DNCA agent receives an NCR from a DNCA manager with NC- 537 Request-Type AVP set to INITIAL_REQUEST that matches more than one 538 of the already existing sessions (i.e. DNCA manager and endpoint 539 identifier match already existing sessions), the DNCA agent will 540 return a NCA with Experimental-Result-Code set to Insufficient- 541 Classifiers. In case a DNCA manager receives a NCA that reports 542 Insufficient-Classifiers, it may choose to retry establishing a 543 new session using additional/more specific classifiers. 545 o If the NCR contains a binding rule not defined on the LSN, the 546 DNCA agent will return a NCA with Experimental-Result-Code AVP set 547 to UNKNOWN_BINDING_RULE. 549 o In case the DNCA agent is unable to establish all of the bindings 550 requested in the NCR, it will return a NCA with Experimental- 551 Result-Code set to BINDING_FAILURE. The DNCA agent (i.e. LSN) 552 treats a NCR as an atomic operation; hence none of the requested 553 bindings will be established by LSN. Either all requested actions 554 within a NCR are completed successfully, or the entire request 555 fails. 557 o If DNCA agent does not have sufficient resources to process a 558 request, it will return NCA with Experimental-Result-Code set to 559 RESOURCE_FAILURE. 561 o In case Max-NAT-Binding and Nat-Control-Definition are included in 562 the NCR along with a reference to a binding rule (i.e. a 563 predefined template on LSN) and the values in Max-NAT-Binding and 564 NAT-Control-Definition contradict those specified in the pre- 565 defined binding rule, Max-NAT-Binding and NAT-Control-Definition 566 override the values specified in the binding rule. 568 DNCA Manager DNCA Agent 569 | | 570 | | 571 | | 572 Trigger | 573 | | 574 | NCR | 575 |------------------------------------------>| 576 | (INITIAL_REQUEST, endpoint classifier, | 577 | session id, NAT control config data) | 578 | | 579 | | 580 | Create session state 581 | | 582 | | 583 | NCA | 584 |<------------------------------------------| 585 | (result code) | 586 | | 587 | | 589 Figure 5: Initial NAT Control request and session establishment 591 4.3. Session Re-Authorization 593 Session re-authorization is performed if the DNCA manager desires to 594 change the behavior of the LSN for an existing session. Re- 595 authorization could be used, for example, to change the number of 596 allowed bindings for a particular session, or establish or remove a 597 pre-defined binding. 599 The DNCA manager generates a NAT-Control Request (NCR) message to the 600 DNCA agent with NC-Request-Type AVP set to UPDATE_REQUEST upon 601 receiving a trigger signal. In case the session is updated 602 successfully, the DNCA agent notifies the DNCA manager about 603 successful session update using a NAT-Control Answer (NCA) message 604 with Result-Code set to DIAMETER_SUCCESS. Figure 6 shows the protocol 605 interaction between the DNCA manager and the DNCA agent. 607 In certain cases, the DNCA agent may not be able to perform the tasks 608 requested within the NCR. These include the following: 610 o If DNCA agent receives a NCR update/query request for non-existent 611 session it will set error code in answer, to 612 DIAMETER_UNKNOWN_SESSION_ID. 614 o If the NCR contains a binding rule not defined on the LSN, the 615 DNCA agent will return a NCA with Experimental-Result-Code AVP set 616 to UNKNOWN_BINDING_RULE. 618 o If the DNCA agent cannot establish the requested binding because 619 the maximum number of allowed bindings has been reached for the 620 Endpoint Classifier, it will return NCA with Experimental-Result- 621 Code AVP set to MAXIMUM_BINDINGS_REACHED_FOR_ENDPOINT. 623 o In case the DNCA agent cannot establish some or all of the 624 bindings requested in a NCR, but has not yet reached the maximum 625 number of allowed bindings for the subscriber, it will return a 626 NCA with Experimental-Result-Code set to BINDING_FAILURE. The DNCA 627 agent (i.e. LSN) treats a NCR as an atomic operation; hence none 628 of the requested bindings will be established by LSN. Either all 629 requested actions within a NCR are completed successfully, or the 630 entire request fails. 632 o If DNCA agent does not have sufficient resources to process a 633 request, it will return a NCA with Experimental-Result-Code set to 634 RESOURCE_FAILURE. 636 o If a NCR redefines the maximum number of NAT bindings allowed for 637 the endpoint, the new value will override any previously defined 638 limit on NAT-bindings. It depends on the implementation of the LSN 639 how LSN would cope with a case where the new value is lower than 640 the actual number of allocated bindings. Typically the LSN would 641 refrain from enforcing the new limit immediately (i.e. actively 642 remove bindings) but rather disallow the establishment of new 643 bindings until the current number of bindings is lower than the 644 newly established maximum number of allowed bindings. 646 o If a NCR specifies a new binding rule, predefined on the DNCA 647 agent, the binding rule will override any previously defined rules 648 for the session. 650 o In case Max-NAT-Binding and Nat-Control-Definition are included in 651 the NCR along with a reference to a binding rule (i.e. a 652 predefined template on LSN) and the values in Max-NAT-Binding and 653 Nat-Control-Definition contradict those specified in the pre- 654 defined binding rule, Max-NAT-Binding and NAT-Control-Definition 655 override the values specified in the binding rule. 657 DNCA Manager DNCA Agent 658 | | 659 | | 660 | | 661 Change of session | 662 attributes | 663 | | 664 | NCR | 665 |------------------------------------------>| 666 | (UPDATE_REQUEST session id, | 667 | NAT control config data) | 668 | | 669 | | 670 | Update session state 671 | | 672 | | 673 | NCA | 674 |<------------------------------------------| 675 | (result code) | 676 | | 677 | | 678 Figure 6: NAT Control request for session update 680 4.4. Session and Binding Query 682 Session query can be used by the DNCA manager to either retrieve 683 information on the current bindings for a particular session at the 684 LSN or discover the session identifier for a particular external IP- 685 address/port pair. 687 The DNCA manager initiates a session query by sending a NAT-Control 688 Request (NCR) message to the DNCA agent with NC-Request-Type AVP set 689 to QUERY_REQUEST. Figure 7 shows the protocol interaction between the 690 DNCA manager and the DNCA agent. 692 Two types of query requests exist: 694 o Request a list of currently allocated NAT-bindings for a 695 particular session: 696 The DNCA agent will, on receipt of the NCR, lookup the session 697 information for the session id contained in the NCR, and will 698 report all currently active NAT-bindings for the session using 699 a NAT-Control Answer (NCA) message with Result-Code set to 700 DIAMETER_SUCCESS. In this case the NCR MUST NOT contain a NAT- 701 Control-Definition AVP. Each NAT-Binding will be reported in a 702 NAT-Control-Definition AVP. In case the session id is unknown 703 to the DNCA agent a DIAMETER_UNKNOWN_SESSION_ID error is 704 returned. 706 o Retrieve session ids and internal IP-address/port pairs for 707 one or multiple external IP-address/port pairs: 708 If the DNCA manager wishes to retrieve the session id(s) for 709 one or multiple external IP-address/port pairs, it MUST 710 include the external IP-address/port pair(s) as part of the 711 NAT-Control-Definition AVP of the NCR. The session id used 712 within the NCR is not meaningful for this type of a query. The 713 DNCA agent will report the NAT-bindings and associated session 714 ids corresponding to the external IP-address/port pairs in a 715 NAT-Control Answer (NCA) message with Result-Code set to 716 DIAMETER_SUCCESS and the same session id as the one used in 717 the NCR. In case an external IP-address/port pair has no 718 associated existing NAT-binding, the NAT-Control-Definition 719 AVP contained in the reply just contains the NAT-External- 720 Address AVP. 722 DNCA Manager DNCA Agent 723 | | 724 | | 725 | | 726 DNCA Session Established | 727 | | 728 | NCR | 729 |------------------------------------------>| 730 | (QUERY_REQUEST) | 731 | | 732 | | 733 | | 734 | Look up corresponding session 735 | and associated NAT Bindings 736 | | 737 | NCA | 738 |<------------------------------------------| 739 | (result code) | 740 | | 741 | | 743 Figure 7: Session Query 745 4.5. Session Termination 747 The DNCA manager generates a NAT-Control Request (NCR) message to the 748 DNCA agent with NC-Request-Type AVP set to TERMINATE REQUEST upon 749 receiving a trigger signal. The DNCA agent sends accounting stop 750 record reporting all the bindings and notifies the DNCA manager about 751 successful session termination using a NAT-Control Answer (NCA) 752 message with Result-Code set to DIAMETER_SUCCESS. Figure 8 shows the 753 protocol interaction between the DNCA manager and the DNCA agent. 755 If a DNCA agent receives a NCR from a DNCA manager with NC-Request- 756 Type AVP set to Terminate REQUEST and fails to find a matching 757 session, the DNCA agent returns DIAMETER_UNKNOWN_SESSION_ID error. 759 DNCA Manager DNCA Agent 760 | | 761 | | 762 Trigger | 763 | | 764 | NCR | 765 |------------------------------------------->| 766 | (TERMINATE_REQUEST, session id) | 767 | | 768 | | 769 | Remove NAT bindings 770 | of session 771 | | 772 | | 773 | Send accounting stop | 774 |<-------------------------------------------| 775 | for all session bindings | 776 | | 777 | Terminate Session / 778 | Remove session state 779 | | 780 | | 781 | | 782 | NCA | 783 |<-------------------------------------------| 784 | (result code) | 785 | | 786 Figure 8: Terminate NAT Control session 788 4.6. DNCA Manager/Agent failures 790 Disclaimer: This version of the draft does not cover details in case 791 DNCA manager and DNCA agent go out of sync, which could happen for 792 example due to DNCA manager or DNCA agent restart, (temporary) loss 793 of network connectivity etc. Future versions of this draft will cover 794 failure cases and corresponding behavior of DNCA manager and DNCA 795 agent in detail. 797 Example failure cases include the following: 799 o The DNCA manager loses session state (e.g. due to a restart). 800 In this case, 802 - the DNCA agent may receive a NCR with NC-Request-Type 803 AVP set to INITIAL_REQUEST that matches an existing 804 session of DNCA agent. The DNCA agent will return an 805 error that contains Duplicate-Session-Id AVP to report 806 Session-Id of existing session. The DNCA manager may 807 then send an explicit TERMINATE_REQUEST for the older 808 session that was lost. 810 - the DNCA manager may receive accounting records for a 811 session that does not exist. The DNCA manager will send 812 an accounting answer with error-code set to 813 DIAMETER_UNKNOWN_SESSION_ID. On receipt of which the 814 DNCA agent clears the session and removes the associated 815 session state. 817 o The DNCA agent loses session state. In such a case, the DNCA 818 agent could receive a NCR with NC-Request-Type AVP set to 819 UPDATE_REQUEST for a non-existent session. The DNCA agent will 820 return NCA with error code set to DIAMETER_UNKNOWN_SESSION_ID. 821 State recovery procedures of the DNCA agent will be covered in 822 a future version of this document. 824 o The DNCA manager is unreachable (as e.g. detected by Diameter 825 watchdog) or down and accounting requests from the DNCA agent 826 fail to get a response. The current version of the draft does 827 not specify procedures for DNCA agent session state clean up 828 or recovery. The mechanism to ensure that a DNCA manager no 829 longer has associated state for a session being cleared at the 830 DNCA agent is beyond the scope of this document. 832 o The DNCA agent is unreachable or down and NCR requests fail to 833 get a response. Handling of this case depends on the actual 834 service offering of the service provider. The service provider 835 could, for example, choose to terminate the access session to 836 the endpoint. 838 5. Use of the DIAMETER base protocol 840 The DIAMETER Base Protocol defined by [RFC3588] shall apply, with the 841 clarifications listed in the present specification. 843 5.1. Securing DIAMETER messages 845 For secure transport of DIAMETER messages, IPSec may be used. 847 The DNCA agent may verify the identity of the DNCA Manager during the 848 Capabilities Exchange Request procedure. 850 The DNCA agent may verify if the DNCA Manager that issues a NCR 851 command is allowed to do so, based on: 853 o The Identity of the DNCA Manager 854 o The Type of NCR Command 855 o The content of the NCR Command 856 o Any combination of the above 858 5.2. Accounting functionality 860 Accounting functionality (Accounting Session State Machine, related 861 command codes and AVPs) is defined in section 8 below. 863 5.3. Use of sessions 865 Each DNCA session MUST have a globally unique Session-Id as defined 866 in [RFC3588], which MUST NOT be changed during the lifetime of a DNCA 867 session. The Diameter Session-Id serves as the global endpoint 868 identifier (see also capabilities section 3.1. The DNCA agent and 869 DNCA manager maintain state associated with the Session-Id. This 870 globally unique Session-Id is used for updating, accounting for and 871 terminating the session. DNCA session MUST NOT have more than one 872 outstanding request at any given instant. 874 The DNCA agent sends an Abort-Session-Request as defined in [RFC3588] 875 if it is unable to maintain sessions due to resource limitation. 877 5.4. Routing considerations 879 It is assumed that the DNCA manager knows the address/name of the 880 DNCA agent for a given endpoint. Both the Destination-Realm and 881 Destination-Host AVPs are present in the Request from the DNCA 882 manager to the DNCA agent. 884 5.5. Advertising Application support 886 Diameter applications conforming to this specification MUST advertise 887 support by including the value of TBD in: 889 - Auth-Application-Id and Acct-Application-Id of Capabilities- 890 Exchange-Request (CER) 892 - Auth-Application-Id of NC-request (NCR), NC-Answer (NCA), Abort- 893 Session-Request(ASR), Abort-Session-Answer (AAA) messages 895 - Acct-Application-Id in Accounting-Request (ACR) and Accounting- 896 Answer (AAA) messages. 898 6. Diameter NAT Control Application Commands 900 The following commands are used to establish, maintain and clear LSN 901 bindings. 903 6.1. NAT-Control Request (NCR) Command 905 The NAT-Control Request (NCR) command, indicated by the command field 906 set to TBD and the "R" bit set in the Command Flags field, is sent 907 from the DNCA manager to the DNCA agent in order to install NAT 908 bindings. 910 Message Format: 912 < NC-Request > ::= < Diameter Header: TBD, REQ, PXY> 914 < Session-Id > 915 { Auth-Application-Id } 916 { Origin-Host } 917 { Origin-Realm } 918 { Destination-Realm } 919 { Destination-Host } 920 { NC-Request-Type } 921 [ Origin-State-Id ] 922 [ Auth-Session-State ] 923 * [ NAT-Control-Remove ] 924 * [ NAT-Control-Install ] 925 [ User-Name ] 926 [ Logical-Access-Id ] 927 [ Physical-Access-ID ] 928 [ Framed-IP-Address ] 929 [ Framed-Interface-Id ] 930 [ EGRESS-VLANID] 931 [ NAS-Port-ID] 932 [ Address-Realm ] 933 [ Called-Station-ID ] 934 * [ Proxy-Info ] 935 * [ Route-Record ] 936 * [ AVP ] 938 6.2. NAT-Control Answer (NCA) Command 940 The NAT-Control-Answer (NCA) command, indicated by the Command-Code 941 field set to TBD and the "R" bit cleared in the Command Flags field, 942 is sent by the DNCA agent in response to NAT-Control-Request 943 command. 945 Message Format: 946 ::= < Diameter Header: TBD, PXY > 947 < Session-Id > 948 { Origin-Host } 949 { Origin-Realm } 950 { NC-Request-Type } 951 [ Result-Code ] 952 * [ NAT-Control-Definition ] 953 [ Current-NAT-Bindings ] 954 [ Experimental-Result ] 955 [ Origin-State-Id ] 956 [ Error-Message ] 957 [ Error-Reporting-Host ] 958 * [ Failed-AVP ] 959 * [ Proxy-Info ] 960 [ Duplicate-Session-ID ] 961 * [ AVP ] 963 7. Diameter NAT Control Application AVPs 965 7.1. Reused Base Protocol AVPs 967 AVPs reused from Diameter Base Protocol [RFC3588] are listed below. 969 +-------------------+ 970 | AVP Flag rules | 971 +-----------------------------------------------|-----+---+---------+ 972 | AVP | | | May | 973 | Attribute Name Code Data Type |MUST |MAY| encrypt | 974 +-----------------------------------------------+-----+---+---------+ 975 |Acct-Interim-Interval 85 Unsigned32 | M | P | Y | 976 |Auth-Application-Id 258 Unsigned32 | M | P | N | 977 |Auth-Session-State 277 Enumerated | M | P | N | 978 |Destination-Host 293 DiamIdent | M | P | N | 979 |Destination-Realm 283 DiamIdent | M | P | N | 980 |Error-Message 281 UTF8String | M | P | N | 981 |Error-Reporting-Host 294 DiamIdent | M | P | N | 982 |Experimental-Result 297 Grouped | M | P | N | 983 |Experimental-Result-Code 298 Unsigned32 | M | P | N | 984 |Failed-AVP 279 Grouped | M | P | N | 985 |Origin-Host 264 DiamIdent | M | P | N | 986 |Origin-Realm 296 DiamIdent | M | P | N | 987 |Origin-State-Id 278 Unsigned32 | M | P | N | 988 |Proxy-Info 284 Grouped | M | P | N | 989 |Result-Code 268 Unsigned32 | M | P | N | 990 |Route-Record 282 DiamIdent | M | | N | 991 |Session-Id 263 UTF8String | M | P | Y | 992 |User-Name 1 UTF8String | M | P | Y | 993 +-----------------------------------------------+-----+---+---------+ 994 |M - Mandatory bit. An AVP with "M" bit set and its value MUST be | 995 | supported and recognized by a Diameter entity in order the | 996 | message, which carries this AVP, to be accepted. | 997 |P - Indicates the need for encryption for end-to-end security. | 998 +-------------------------------------------------------------------+ 1000 Table 1: DIAMETER AVPs used from Diameter base [RFC3588] 1002 The Auth-Application-Id AVP (AVP Code 258) is assigned by IANA to 1003 Diameter applications. The value of the Auth-Application-Id for the 1004 Diameter NAT Control Application is TBD. 1006 7.2. Experimental-Result-Code AVP values 1008 This section defines new Experimental-Result-Code values that shall 1009 be supported by all DIAMETER implementations that conform to the 1010 present document. When one of the Experimental Result Code defined in 1011 the present section is included in a response, it shall be inside an 1012 Experimental-Result AVP and the Result-Code AVP shall be absent. 1014 7.2.1. Success 1016 Experimental Result Codes that fall within the success category are 1017 used to inform a peer that a request has been successfully completed. 1019 No new Result Code has been defined within this category. 1021 7.2.2. Transient failures 1023 Experimental Result Codes that fall within the transient failures 1024 category are those used to inform a peer that the request could not 1025 be satisfied at the time that it was received. The request may be 1026 able to be satisfied in the future. 1028 This document defines the following new values of the Experimental- 1029 Result-Code AVP: 1031 RESOURCE_FAILURE (TBD) 1033 The DNCA agent indicates that the binding could not be 1034 installed or a new session could not be created due to resource 1035 shortage. 1037 7.2.3. Permanent failures 1039 Experimental Result Codes that fall within the Permanent Failures 1040 category are used to inform the peer that the request failed, and 1041 should not be attempted again. 1043 This document defines the following new values of the Experimental- 1044 Result-Code AVP: 1046 UNKNOWN_BINDING_RULE_NAME (TBD) 1048 The DNCA agent indicates that the specified NAT-Binding-Rule 1049 AVP is unknown. 1051 BINDING_FAILURE (TBD) 1053 The DNCA indicates that the requested binding(s) could not be 1054 installed. 1056 MAXIMUM_BINDINGS_REACHED_FOR_ENDPOINT (TBD) 1057 The DNCA agent denies the request because the maximum number of 1058 allowed bindings has been reached for the specified Endpoint 1059 Classifier. 1061 SESSION_EXISTS (TBD) 1063 The DNCA agent denies request to initialize a new session, if 1064 it already has a DNCA session that uses the same set of 1065 classifiers as indicated by DNCA manager in the new session 1066 init request. 1068 INSUFFICIENT_CLASSIFIERS (TBD) 1070 The DNCA agent defines request to initialize a new session, if 1071 the classifiers in the request match more than one of the 1072 existing sessions on DNCA agent. 1074 7.3. Reused NASREQ Diameter application AVPs 1076 +---------------------+ 1077 | AVP Flag rules | 1078 +------------------+------+------------|----+-----+----+-----|----+ 1079 | | AVP | | | |SHLD| MUST| | 1080 | Attribute Name | Code | Value Type|MUST| MAY | NOT| NOT|Encr| 1081 |------------------|------|------------|----+-----+----+-----|----| 1082 | NAS-Port | 5 | Unsigned32 | M | P | | V | Y | 1083 | NAS-Port-Id | 87 | UTF8String | M | P | | V | Y | 1084 | Called-Station-Id| 30 | UTF8String | M | P | | V | Y | 1085 | Calling-Station- | 31 | UTF8String | M | P | | V | Y | 1086 | Id | | | | | | | | 1087 | Framed-IP-Address| 8 | OctetString| M | P | | V | Y | 1088 | Framed-Interface-| 96 | Unsigned64 | M | P | | V | Y | 1089 | ID | | | | | | | | 1090 +------------------+------+------------|----+-----+----+-----|----+ 1092 Table 2: Reused NASREQ Diameter application AVPs 1094 7.4. Reused from RFC 4675 1096 +---------------------+ 1097 | AVP Flag rules | 1098 +------------------+------+------------|----+-----+----+-----|----+ 1099 | | AVP | | | |SHLD| MUST| | 1100 | Attribute Name | Code | Value Type|MUST| MAY | NOT| NOT|Encr| 1101 |------------------|------|------------|----+-----+----+-----|----| 1102 | Egress-VLANID | 56 | OctetString| M | P | | V | Y | 1103 +------------------+------+------------|----+-----+----+-----|----+ 1105 7.5. Reused from Diameter QoS Application [I-D.ietf-dime-qos-attributes] 1107 +-------------------+ 1108 | AVP Flag rules | 1109 +-----------------------------------------------|-----+---+---------+ 1110 | AVP | | | May | 1111 | Attribute Name Code Data Type |MUST |MAY| encrypt | 1112 +-----------------------------------------------+-----+---+---------+ 1113 |Port TBD Integer32 | M | P | Y 1114 |IP-Address-Mask TBD Grouped | M | P | Y | 1115 +-----------------------------------------------+-----+---+---------+ 1116 |M - Mandatory bit. An AVP with "M" bit set and its value MUST be | 1117 | supported and recognized by a Diameter entity in order the | 1118 | message, which carries this AVP, to be accepted. | 1119 |P - Indicates the need for encryption for end-to-end security. | 1120 |V - Indicates whether the optional Vendor-ID field is present | 1121 | in the AVP header. Vendor-Id header of all AVPs in | 1122 | this table will be set to ETSI (13019) | 1123 +-------------------------------------------------------------------+ 1125 Table 3: Reused QoS-attributes 1127 7.6. Reused from ETSI ES 283 034, e4 Diameter application 1129 +-------------------+ 1130 | AVP Flag rules | 1131 +-----------------------------------------------|-----+---+---------+ 1132 | AVP | | | May | 1133 | Attribute Name Code Data Type |MUST |MAY| encrypt | 1134 +-----------------------------------------------+-----+---+---------+ 1135 |Address-Realm 301 OctetString | M,V | | Y | 1136 |Logical-Access-Id 302 OctetString | V | M | Y | 1137 |Physical-Access-ID 313 UTF8String | V | M | Y | 1138 +-----------------------------------------------+-----+---+---------+ 1139 |M - Mandatory bit. An AVP with "M" bit set and its value MUST be | 1140 | supported and recognized by a Diameter entity in order the | 1141 | message, which carries this AVP, to be accepted. | 1142 |P - Indicates the need for encryption for end-to-end security. | 1143 |V - Indicates whether the optional Vendor-ID field is present | 1144 | in the AVP header. Vendor-Id header of all AVPs in | 1145 | this table will be set to ETSI (13019) | 1146 +-------------------------------------------------------------------+ 1148 Table 4: Reused AVPs from Diameter e4 application 1150 7.7. Diameter NAT Control Application Defined AVPs 1152 The following table describes the new Diameter AVPs used in the 1153 present document, their AVP Code values, types, possible flag values 1154 and whether the AVP may or not be encrypted. 1156 +-------------------+ 1157 | AVP Flag rules | 1158 +-----------------------------------------------|-----+---+---------+ 1159 | AVP Section | | | May | 1160 | Attribute Name Code Defined Data Type |MUST |MAY| encrypt | 1161 +-----------------------------------------------+-----+---+---------+ 1162 |NC-Request-Type TBD 7.7.1 Enumerated | M | P | Y | 1163 |NAT-Control-Install TBD 7.7.2 Grouped | M | P | Y | 1164 |NAT-Control-Remove TBD 7.7.3 Grouped | M | P | Y | 1165 |NAT-Control-Definition TBD 7.7.4 Grouped | M | P | Y | 1166 |NAT-Internal-Address TBD 7.7.5 Grouped | M | P | Y | 1167 |NAT-External-Address TBD 7.7.6 Grouped | M | P | Y | 1168 |Max-NAT-Bindings TBD 7.7.7 Unsigned32 | M | P | Y | 1169 |NAT-Control- TBD 7.7.8 OctetString| M | P | Y | 1170 | Binding-Rule | | | | 1171 |Duplicate- TBD 7.7.9 UTF8String | M | P | Y | 1172 | Session-ID | | | | 1173 |NAT-Control-Record TBD 8.2.1 Grouped | M | P | Y | 1174 |NAT-Control- TBD 8.2.2 Enumerated | M | P | Y | 1175 | Binding-Status | | | | 1176 |Current-NAT-Bindings TBD 8.2.3 Unsigned32 | M | P | Y | 1177 +-----------------------------------------------+-----+---+---------+ 1178 |M - Mandatory bit. An AVP with "M" bit set and its value MUST be | 1179 | supported and recognized by a Diameter entity in order the | 1180 | message, which carries this AVP, to be accepted. | 1181 |P - Indicates the need for encryption for end-to-end security. | 1182 |V - Vendor specific bit that indicates whether the optional | 1183 | Vendor-ID field is present in the AVP header | 1184 +-------------------------------------------------------------------+ 1186 Table 5: New Diameter AVPs 1188 7.7.1. NC-Request-Type AVP 1190 The NC-Request-Type AVP (AVP Code TBD) is of type Enumerated and 1191 contains the reason for sending the NAT-Control-Request command. It 1192 shall be present in all NAT-Control-Request messages. 1194 The following values are defined: 1196 INITIAL_REQUEST (1) 1198 An Initial Request is used to install binding at the DNCA 1199 agent on a successful access session setup. 1201 UPDATE_REQUEST (2) 1203 An Update Request is used to update bindings previously 1204 installed on a given access session, to add new binding on 1205 a given access session, or to remove one or several 1206 binding(s) activated on a given access session. 1208 TERMINATION_REQUEST (3) 1210 Termination Request is used to deactivate and remove all 1211 bindings previously activated on a given access session. 1213 QUERY_REQUEST (4) 1215 Query Request is used to query the DNCA agent about the 1216 currently installed bindings for an endpoint classifier. 1218 7.7.2. NAT-Control-Install AVP 1220 The NAT-Control AVP (AVP code TBD) is of type Grouped, and it is 1221 used to activate or install NAT bindings. It also contains Max-NAT- 1222 Bindings that defines maximum number of NAT bindings to be allowed 1223 for a subscriber and NAT-Control-Binding-Rule that references 1224 predefined policy template on DNCA agent that may contain static 1225 bindings, maximum number of bindings to be allowed, address pool 1226 from which external binding address should be allocated. 1228 AVP Format: 1230 NAT-Control-Install ::= < AVP Header: TBD > 1231 * [ NAT-Control-Definition ] 1232 [ NAT-Control-Binding-Rule ] 1233 [ Max-NAT-Bindings] 1234 * [ AVP ] 1236 7.7.3. NAT-Control-Remove AVP 1238 The NAT-Control-Remove AVP (AVP code TBD) is of type Grouped, and 1239 it is used to deactivate or remove NAT bindings. 1241 AVP Format: 1243 NAT-Control-Remove ::= < AVP Header: TBD > 1244 * [ NAT-Control-Definition ] 1245 [ NAT-Control-Binding-Rule ] 1246 * [ AVP ] 1248 7.7.4. NAT-Control-Definition AVP 1250 The NAT-Control-Definition AVP (AVP code TBD) is of type Grouped, 1251 and it describes a binding. 1253 The NAT-Control-Definition AVP uniquely identifies the binding 1254 between the DNCA agent and the DNCA manager. 1256 If both the NAT-Internal-Address and NAT-External-Address AVP(s) 1257 are supplied, it is a pre-defined binding. 1259 AVP Format: 1261 NAT-Control-Definition ::= < AVP Header: TBD > 1262 { NAT-Internal-Address } 1263 [ NAT-External-Address ] 1264 [ Session-Id ] 1265 * [ AVP ] 1267 7.7.5. NAT-Internal-Address AVP 1269 The NAT-Internal-Address AVP (AVP code TBD) is of type Grouped, and 1270 it describes the internal IP address and port for a binding. 1272 AVP Format: 1274 NAT-Internal-Address ::= < AVP Header: TBD > 1275 [ Framed-IP-Address ] 1276 [ Port] 1277 [ AVP ] 1279 7.7.6. NAT-External-Address AVP 1281 The NAT-External-Address AVP (AVP code TBD) is of type Grouped, and 1282 it describes the external IP address and port for a binding. IP- 1283 Address-Mask AVP can only be specified when Framed-IP-Address AVP 1284 is present. 1286 AVP Format: 1288 NAT-External-Address ::= < AVP Header: TBD > 1289 [ Framed-IP-Address ] 1290 [ IP-Address-Mask ] 1291 [ Port ] 1292 [ AVP ] 1294 7.7.7. Max-NAT-Bindings 1296 The Max-NAT-Bindings AVP (AVP code TBD) is of type Unsigned32, and 1297 it indicates the maximum number of NAT bindings allowed. 1299 7.7.8. NAT-Control-Binding-Rule 1301 The NAT-Control-Binding-Rule AVP (AVP code TBD) is of type is of 1302 type OctetString, and it defines a name for a policy template that 1303 will be predefined at LSN. Details on the contents and structure of 1304 the template as well as how it would be configured are outside the 1305 scope of this document. The policy to which this AVP refers to may 1306 contain NAT Bindings, address pool for external address allocation 1307 of NAT binding, maximum allowed NAT bindings etc. 1309 7.7.9. Duplicate-Session-Id AVP 1311 The Duplicate-Session-Id AVP (AVP Code TBD) is of is of type 1312 UTF8String. It is used to report error and contains the Session-Id of 1313 an existing session. 1315 8. Accounting Commands 1317 The Diameter NAT Control Application reuses session based accounting 1318 as defined in Diameter Base Protocol [RFC3588] to report the bindings 1319 used per endpoint. This reporting is achieved by sending Diameter 1320 Accounting Requests (ACR) [Start, Interim and Stop] from the DNCA 1321 agent to DNCA manager. 1323 The DNCA agent sends an ACR Start on receiving an NCR with NC- 1324 Request-Type AVP set to INITIAL_REQUEST received for a session, or on 1325 creation of the first binding for a session requested in an earlier 1326 NCR. The DNCA may send ACR Interim updates, if required, either due 1327 to a change in bindings resulting from an NCR with NC-Request-Type 1328 AVP set to UPDATE_REQUEST, or periodically as specified in Acct- 1329 Interim-Interval by DNCA Manager or when it creates/tears down 1330 bindings. An ACR Stop is sent by the DNCA agent on receiving an NCR 1331 with NC-Request-Type AVP set to TERMINATION_REQUEST. 1333 The function of correlating the multiple bindings used by an endpoint 1334 at any given time is relegated to the post processor. 1336 DNCA agent may trigger an interim accounting record when maximum 1337 number of bindings, if received in NCR, is reached. 1339 8.1. NAT Control Accounting Messages 1341 The ACR and ACA messages are reused as defined in Diameter Base 1342 Protocol [RFC3588] for exchanging endpoint NAT binding details 1343 between the DNCA agent and the CDF. ACR will contain one or more 1344 optional NAT-Control-Record AVP to report the bindings. The DNCA 1345 agent indicates the number of the currently allocated NAT bindings to 1346 the DNCA manager using the Current-NAT-Bindings AVP. This number 1347 needs to match the number of bindings identified as active within the 1348 NAT-Control-Record AVP. 1350 8.2. NAT Control Accounting AVPs 1352 In addition to AVPs for ACR specified in [RFC3588], the DNCA agent 1353 must add the NAT-Control-Record AVP. 1355 8.2.1. NAT-Control-Record 1357 The NAT-Control-Record AVP (AVP code TBD) is of type Grouped, and 1358 it describes a binding and its status. Event-Timestamp indicates 1359 the time at which binding was created if NAT-Control-Binding-Status 1360 is set to Created, or time at which the binding was removed if NAT- 1361 Control-Binding-Status is set to removed. If the NAT-Control- 1362 Binding-Status is active Event-Timestamp need not be present, if 1363 present it indicates that binding is active at the mentioned time. 1365 NAT-Control-Record ::= < AVP Header: TBD > 1366 { NAT-Control-Definition } 1367 { NAT-Control-Binding-Status } 1368 [ Event-Timestamp ] 1370 8.2.2. NAT-Control-Binding-Status 1372 The NAT-Control-Binding-Status AVP (AVP code TBD) is of type 1373 enumerated and it describes whether the binding being reported was 1374 created or removed or simply indicates that it is active. 1376 The following values are defined: 1378 Created (1) 1380 Indicates that NAT binding is created. 1382 Active (2) 1384 Indicates that NAT binding is active. 1386 Removed (3) 1388 Indicates that the NAT binding was removed. 1390 8.2.3. Current-NAT-Bindings 1392 The Current-NAT-Bindings AVP (AVP code TBD) is of type Unsigned32, 1393 and it indicates number of NAT bindings active on LSN. 1395 9. AVP Occurrence Table 1397 The following sections presents the AVPs defined in this document and 1398 specifies in which Diameter messages they MAY be present. Note that 1399 AVPs that can only be present within a Grouped AVP are not 1400 represented in this table. 1402 The table uses the following symbols: 1404 0 The AVP MUST NOT be present in the message. 1406 0+ Zero or more instances of the AVP MAY be present in the 1407 message. 1409 0-1 Zero or one instance of the AVP MAY be present in the 1410 message. It is considered an error if there is more than 1411 one instance of the AVP. 1413 1 One instance of the AVP MUST be present in the message. 1415 1+ At least one instance of the AVP MUST be present in the 1416 message. 1418 9.1. DNCA AVP Table for NAT control initial and update requests 1420 Following table presents which NAT control application specific AVPs 1421 are to be present in NCR/NCA with NC-Request-Type set to 1422 INITIAL_REQUEST or UPDATE_REQUEST 1424 +-------------------+ 1425 | Command Code | 1426 +-----------------------------------+-------------------+ 1427 | Attribute Name NCR NCA | 1428 +-------------------------------------------------------+ 1429 |NC-Request-Type 1 1 | 1430 |NAT-Control-Install 0-1 0 | 1431 |NAT-Control-Remove 0-1 0 | 1432 |NAT-Control-Definition 0 0 | 1433 |NAT-Control-Record 0 0 | 1434 |Current-NAT-Bindings 0 0 | 1435 |Duplicate-Session-Id 0 0-1 | 1436 +-------------------------------------------------------+ 1438 9.2. DNCA AVP Table for Session Query request 1440 Following table presents which NAT control application specific AVPs 1441 are to be present in NCR/NCA with NC-Request-Type set to 1442 QUERY_REQUEST 1444 +-------------------+ 1445 | Command Code | 1446 +-----------------------------------+-------------------+ 1447 | Attribute Name NCR NCA | 1448 +-------------------------------------------------------+ 1449 |NC-Request-Type 1 1 | 1450 |NAT-Control-Install 0 0 | 1451 |NAT-Control-Remove 0 0 | 1452 |NAT-Control-Definition 0 0+ | 1453 |NAT-Control-Record 0 0 | 1454 |Current-NAT-Bindings 0 1 | 1455 |Duplicate-Session-Id 0 0 | 1456 +-------------------------------------------------------+ 1458 9.3. DNCA AVP Table for NAT Control Terminate requests 1460 Following table presents which NAT control application specific AVPs 1461 are to be present in NCR/NCA with NC-Request-Type set to 1462 TERMINATION_REQUEST 1463 +-------------------+ 1464 | Command Code | 1465 +-----------------------------------+-------------------+ 1466 | Attribute Name NCR NCA | 1467 +-------------------------------------------------------+ 1468 |NC-Request-Type 1 1 | 1469 |NAT-Control-Install 0 0 | 1470 |NAT-Control-Remove 0 0 | 1471 |NAT-Control-Definition 0 0 | 1472 |NAT-Control-Record 0 0 | 1473 |Current-NAT-Bindings 0 0 | 1474 |Duplicate-Session-Id 0 0 | 1475 +-------------------------------------------------------+ 1477 9.4. DNCA AVP Table for accounting message 1479 Following table presents which NAT control application specific AVPs 1480 May or May Not be present in ACR/ACA messages. 1482 +-------------------+ 1483 | Command Code | 1484 +-----------------------------------+-------------------+ 1485 | Attribute Name ACR ACA | 1486 +-------------------------------------------------------+ 1487 |NC-Request-Type 0 0 | 1488 |NAT-Control-Install 0 0 | 1489 |NAT-Control-Remove 0 0 | 1490 |NAT-Control-Definition 0 0 | 1491 |NAT-Control-Record 0+ 0 | 1492 |Current-NAT-Bindings 1 0 | 1493 |Duplicate-Session-Id 0 0 | 1494 +-------------------------------------------------------+ 1496 10. IANA Considerations 1498 This section contains the namespaces that have either been created in 1499 this specification or had their values assigned to existing 1500 namespaces managed by IANA. 1502 10.1. Command Codes 1504 IANA is requested to allocate command code values for the following. 1506 Registry: 1507 Code Value Name Reference 1508 ----------------------------------------------------------- 1509 to be assigned NAT-Control-Request (NCR) Section 6.1 1510 to be assigned NAT-Control-Answer (NCA) Section 6.2 1512 10.2. AVP Codes 1514 IANA is requested to allocate AVP codes for the following AVPs that 1515 are defined in this document. 1517 Code Value Name Reference 1518 ----------------------------------------------------------- 1519 TBD NC-Request-Type 7.7.1 1520 TBD NAT-Control-Install 7.7.2 1521 TBD NAT-Control-Remove 7.7.3 1522 TBD NAT-Control-Definition 7.7.4 1523 TBD NAT-Internal-Address 7.7.5 1524 TBD NAT-External-Address 7.7.6 1525 TBD Max-NAT-Bindings 7.7.7 1526 TBD NAT-Control-Binding-Rule 7.7.8 1527 TBD Duplicate-Session-Id 7.7.9 1528 TBD NAT-Control-Record 8.2.1 1529 TBD NAT-Control-Binding-Status 8.2.2 1530 TBD Current-NAT-Bindings 8.2.3 1532 10.3. Application IDs 1534 IANA is requested to allocate the following application ID using the 1535 next value from the 7-16777215 range. 1537 Registry: 1538 ID values Name Reference 1539 ----------------------------------------------------------- 1540 to be assigned Diameter NAT Control Application Section 4 1542 11. Security Considerations 1544 Similar to what the Diameter QoS application (see [I-D.sun-dqa]) does 1545 for authorization of QoS reservations, this document describes 1546 procedures for authorizing network address translation related 1547 attributes and parameters by an entity which is non-local to the 1548 device performing network address translation. The security 1549 considerations for the Diameter QoS application (see [I-D.sun-dqa], 1550 section 11) apply in a similar way to the DNCA. Securing the 1551 information exchange between the authorizing entity (the DNCA 1552 manager) as well as the NAT device requires bilateral authentication 1553 of the involved parties, authorization of the involved parties to 1554 perform the required procedures and functions, as well as procedures 1555 to ensure integrity and confidentiality of the information exchange. 1556 DNCA makes use of the capabilities offered by Diameter as well as the 1557 underlying transport protocols to deliver on these requirements (see 1558 section 5.1. ). 1560 It is assumed that the DNCA agent and DNCA manager are in the same 1561 domain and have a mutual trust set up. Authorization between the DNCA 1562 agent and DNCA manager is beyond the scope of this document. 1564 12. References 1566 12.1. Normative References 1568 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1569 Requirement Levels", BCP 14, RFC 2119, March 1997. 1571 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 1572 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 1574 [I-D.ietf-dime-qos-attributes] J. Korhonen, et al. ''Quality of 1575 Service Attributes for Diameter'', draft-ietf-dime-qos- 1576 attributes-11.txt (work in progress), February 2009 1578 [ETSI ES 283 034] Telecommunications and Internet Converged Services 1579 and Protocols for Advanced Networks (TISPAN),Network 1580 Attachment Sub-System (NASS),e4 interface based on the 1581 Diameter protocol. 1583 12.2. Informative References 1585 [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, "Diameter 1586 Network Access Server Application", RFC 4005, August 2005. 1588 [I-D.nishitani-cgn] Nishitani, T. and S. Miyakawa, "Common Functions 1589 of Large Scale NAT (LSN) ", draft-nishitani-cgn-01 (work in 1590 progress), November 2008. 1592 [I-D.sun-dqa] Sun, D., McCann P., Tschofenig, H., Tsou, T., Doria, 1593 A., Zorn, G., ''Diameter Quality of Service Application'', 1594 draft-ietf-dime-diameter-qos-07 (work in progress), 1595 December 2008. 1597 [3GPP32299] 3rd Generation Partnership Project; Technical 1598 Specification Group Service and System Aspects; 1599 Telecommunication management; Charging management; 1600 ''Diameter charging applications'', 3GPP TS 32.299 Version 1601 6.3.0. 1603 [RFC4675] Congdon, P., Sanchez, M., Aboba, B. ''RADIUS Attributes for 1604 Virtual LAN and Priority Support'', September 2006 1606 13. Author's Addresses 1608 Frank Brockners 1609 Cisco Systems, Inc. 1610 Hansaallee 249 1611 40549 Duesseldorf 1612 Germany 1613 Email: fbrockne@cisco.com 1615 Vaneeta Singh 1616 Cisco Systems, Inc. 1617 Cessna Business Park, 1618 Sarjapura Marathalli Outer Ring Road 1619 Bangalore, KARNATAKA 560 087 1620 India 1621 Email: vansingh@cisco.com 1623 Shwetha Bhandari 1624 Cisco Systems, Inc. 1625 Cessna Business Park, 1626 Sarjapura Marathalli Outer Ring Road 1627 Bangalore, KARNATAKA 560 087 1628 India 1629 Email: shwethab@cisco.com