--- 1/draft-ietf-dime-nat-control-14.txt 2012-03-26 11:14:06.834670826 +0200 +++ 2/draft-ietf-dime-nat-control-15.txt 2012-03-26 11:14:06.946670675 +0200 @@ -1,22 +1,22 @@ Internet Engineering Task Force F. Brockners Internet-Draft S. Bhandari Intended status: Standards Track Cisco -Expires: September 12, 2012 V. Singh +Expires: September 27, 2012 V. Singh V. Fajardo Telcordia Technologies - March 11, 2012 + March 26, 2012 Diameter Network Address and Port Translation Control Application - draft-ietf-dime-nat-control-14 + draft-ietf-dime-nat-control-15 Abstract This document describes the framework, messages, and procedures for the Diameter Network address and port translation Control Application. This Diameter application allows per endpoint control of Network Address Translators and Network Address and Port Translators, which are added to networks to cope with IPv4-address space depletion. This Diameter application allows external devices to configure and manage a Network Address Translator device - @@ -42,21 +42,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on September 12, 2012. + This Internet-Draft will expire on September 27, 2012. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -87,71 +87,71 @@ 5.3. Use of Sessions . . . . . . . . . . . . . . . . . . . . . 24 5.4. Routing Considerations . . . . . . . . . . . . . . . . . . 24 5.5. Advertising Application Support . . . . . . . . . . . . . 24 6. DNCA Commands . . . . . . . . . . . . . . . . . . . . . . . . 24 6.1. NAT-Control Request (NCR) Command . . . . . . . . . . . . 24 6.2. NAT-Control Answer (NCA) Command . . . . . . . . . . . . . 25 7. NAT Control Application Session State Machine . . . . . . . . 26 8. DNCA AVPs . . . . . . . . . . . . . . . . . . . . . . . . . . 29 8.1. Reused Base Protocol AVPs . . . . . . . . . . . . . . . . 30 8.2. Additional Result-Code AVP Values . . . . . . . . . . . . 30 - 8.2.1. Success . . . . . . . . . . . . . . . . . . . . . . . 30 + 8.2.1. Success . . . . . . . . . . . . . . . . . . . . . . . 31 8.2.2. Transient Failures . . . . . . . . . . . . . . . . . . 31 8.2.3. Permanent Failures . . . . . . . . . . . . . . . . . . 31 8.3. Reused NASREQ Diameter Application AVPs . . . . . . . . . 32 8.4. Reused AVPs from RFC 4675 . . . . . . . . . . . . . . . . 32 8.5. Reused AVPs from Diameter QoS Application . . . . . . . . 33 8.6. Reused AVPs from ETSI ES 283 034, e4 Diameter Application . . . . . . . . . . . . . . . . . . . . . . . 33 8.7. DNCA Defined AVPs . . . . . . . . . . . . . . . . . . . . 34 8.7.1. NC-Request-Type AVP . . . . . . . . . . . . . . . . . 35 8.7.2. NAT-Control-Install AVP . . . . . . . . . . . . . . . 36 8.7.3. NAT-Control-Remove AVP . . . . . . . . . . . . . . . . 36 - 8.7.4. NAT-Control-Definition AVP . . . . . . . . . . . . . . 36 + 8.7.4. NAT-Control-Definition AVP . . . . . . . . . . . . . . 37 8.7.5. NAT-Internal-Address AVP . . . . . . . . . . . . . . . 37 - 8.7.6. NAT-External-Address AVP . . . . . . . . . . . . . . . 37 + 8.7.6. NAT-External-Address AVP . . . . . . . . . . . . . . . 38 8.7.7. Max-NAT-Bindings . . . . . . . . . . . . . . . . . . . 38 8.7.8. NAT-Control-Binding-Template AVP . . . . . . . . . . . 38 8.7.9. Duplicate-Session-Id AVP . . . . . . . . . . . . . . . 38 - 8.7.10. NAT-External-Port-Style AVP . . . . . . . . . . . . . 38 + 8.7.10. NAT-External-Port-Style AVP . . . . . . . . . . . . . 39 9. Accounting Commands . . . . . . . . . . . . . . . . . . . . . 39 - 9.1. NAT Control Accounting Messages . . . . . . . . . . . . . 39 + 9.1. NAT Control Accounting Messages . . . . . . . . . . . . . 40 9.2. NAT Control Accounting AVPs . . . . . . . . . . . . . . . 40 9.2.1. NAT-Control-Record . . . . . . . . . . . . . . . . . . 40 9.2.2. NAT-Control-Binding-Status . . . . . . . . . . . . . . 40 - 9.2.3. Current-NAT-Bindings . . . . . . . . . . . . . . . . . 40 + 9.2.3. Current-NAT-Bindings . . . . . . . . . . . . . . . . . 41 10. AVP Occurrence Table . . . . . . . . . . . . . . . . . . . . . 41 10.1. DNCA AVP Table for NAT Control Initial and Update Requests . . . . . . . . . . . . . . . . . . . . . . . . . 41 10.2. DNCA AVP Table for Session Query request . . . . . . . . . 42 - 10.3. DNCA AVP Table for Accounting Message . . . . . . . . . . 42 + 10.3. DNCA AVP Table for Accounting Message . . . . . . . . . . 43 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 11.1. Application Identifier . . . . . . . . . . . . . . . . . . 43 - 11.2. Command Codes . . . . . . . . . . . . . . . . . . . . . . 43 - 11.3. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . 43 - 11.4. Result-Code AVP Values . . . . . . . . . . . . . . . . . . 43 - 11.5. NC-Request-Type AVP . . . . . . . . . . . . . . . . . . . 43 - 11.6. NAT-External-Port-Style AVP . . . . . . . . . . . . . . . 43 + 11.2. Command Codes . . . . . . . . . . . . . . . . . . . . . . 44 + 11.3. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . 44 + 11.4. Result-Code AVP Values . . . . . . . . . . . . . . . . . . 44 + 11.5. NC-Request-Type AVP . . . . . . . . . . . . . . . . . . . 44 + 11.6. NAT-External-Port-Style AVP . . . . . . . . . . . . . . . 44 11.7. NAT-Control-Binding-Status AVP . . . . . . . . . . . . . . 44 12. Security Considerations . . . . . . . . . . . . . . . . . . . 44 - 13. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 - 13.1. DNCA Session Establishment Example . . . . . . . . . . . . 46 - 13.2. DNCA Session Update with Port Style Example . . . . . . . 49 - 13.3. DNCA Session Query Example . . . . . . . . . . . . . . . . 50 - 13.4. DNCA Session Termination Example . . . . . . . . . . . . . 51 - 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 54 + 13. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 + 13.1. DNCA Session Establishment Example . . . . . . . . . . . . 47 + 13.2. DNCA Session Update with Port Style Example . . . . . . . 50 + 13.3. DNCA Session Query Example . . . . . . . . . . . . . . . . 51 + 13.4. DNCA Session Termination Example . . . . . . . . . . . . . 52 + 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 55 15. Change History (to be removed prior to publication as an - RFC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 - 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 57 - 16.1. Normative References . . . . . . . . . . . . . . . . . . . 57 - 16.2. Informative References . . . . . . . . . . . . . . . . . . 58 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 59 + RFC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 + 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 59 + 16.1. Normative References . . . . . . . . . . . . . . . . . . . 59 + 16.2. Informative References . . . . . . . . . . . . . . . . . . 59 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 60 1. Introduction Internet service providers deploy Network Address Translators (NATs) and Network Address and Port Translators (NAPTs) [RFC3022] in their networks. A key motivation for doing so is the depletion of available public IPv4 addresses. This document defines a Diameter application allowing providers to control the behavior of NAT and NAPT devices that implement IPv4-to-IPv4 network address and port translation [RFC2663] as well as stateful IPv6-to-IPv4 address family @@ -243,21 +243,26 @@ capabilities in that it allows to maintain the reference to an endpoint representing a user or subscriber in the control operation, enabling the control of the behavior of a NAT-device on a per endpoint basis. Following the requirements of different operators and deployments, different management protocols are employed. Examples include e.g. SNMP [RFC3411] and NETCONF [RFC6241] which can both be used for device configuration. Similarly, DNCA is complementing existing MIDCOM implementations, offering a MIDCOM protocol option for operators with an operational environment that is Diameter-focused which desire to use Diameter to perform per endpoint - NAT control. + NAT control. Note that in case an operator uses multiple methods and + protocols to configure a NAT-device, such as for example command line + interface, SNMP, NETCONF, or PCP, along with DNCA specified in this + document, the operator MUST ensure that the configurations performed + using the different methods and protocols do not conflict in order to + ensure a proper operation of the NAT service. This document is structured as follows: Section 2 lists terminology, while Section 3 provides an introduction to DNCA and its overall deployment framework. Sections 4 to 8 cover DNCA specifics, with Section 4 describing session management, Section 5 the use of the Diameter base protocol, Section 6 new commands, Section 7 Attribute Value Pairs(AVPs) used, and Section 8 accounting aspects. Section 9 presents AVP occurrence tables. IANA and security considerations are addressed in Sections 10 and 11. @@ -317,21 +322,26 @@ 3. Deployment Framework 3.1. Deployment Scenario Figure 1 shows a typical network deployment for IPv4-Internet access. A user's IPv4 host (i.e. endpoint) gains access to the Internet though a NAS, which facilitates the authentication of the endpoint and configures the endpoints's connection according to the authorization and configuration data received from the AAA-server upon successful authentication. Public IPv4 addresses are used - throughout the network. + throughout the network. DNCA manages an endpoint that represents a + network element or device or IPv4 host, associated with a subscriber, + a user or a group of users. An endpoint is represented by a single + access-session on a NAS. DNCA assumes a 1:1 relationship between an + endpoint, the access-session it represents, and the associated DNCA + session. +---------+ | | | AAA | | | +---------+ | | | | @@ -543,30 +553,34 @@ Figure 4 shows examples of autonomous deployments. The figure describes two scenarios: One where an IPv4-host (with a private IPv4 address) accesses the IPv4-Internet, as well as one where an IPv6- host accesses the IPv4-Internet. 4. DNCA Session Establishment and Management Note that this section forward references some of the commands and AVPs defined for DNCA. Please refer to Section 6 and Section 8 for details. DNCA runs between a Diameter peer residing in a NAT- - controller and a Diameter peer residing in a NAT-device. The - Diameter peer within the NAT-controller is always the control - requesting entity: It initiates, updates, or terminates the sessions. - Sessions are initiated when the NAT-controller learns about a new - endpoint (i.e., host) that requires a NAT service. This could for - example be due to the entity hosting the NAT-controller receiving - authentication, authorization, or accounting requests for or from the - endpoint. Alternate methods that could trigger session setup include - local configuration, receipt of a packet from a formerly unknown IP- - address, etc. + controller and a Diameter peer residing in a NAT-device. Note that, + per what was already mentioned above, each DNCA session between + Diameter peers in a NAT-controller and a NAT-device represents a + single endpoint, with an endpoint being either a network element, a + device or an IPv4 host associated with a subscriber, a user, or a + group of users. The Diameter peer within the NAT-controller is + always the control requesting entity: It initiates, updates, or + terminates the sessions. Sessions are initiated when the NAT- + controller learns about a new endpoint (i.e., host) that requires a + NAT service. This could for example be due to the entity hosting the + NAT-controller receiving authentication, authorization, or accounting + requests for or from the endpoint. Alternate methods that could + trigger session setup include local configuration, receipt of a + packet from a formerly unknown IP-address, etc. 4.1. Session Establishment The DNCA Diameter peer within the NAT-controller establishes a session with the DNCA Diameter peer within the NAT-device to control the behavior of the NAT function within the NAT-device. During session establishment, the DNCA Diameter peer within the NAT- controller passes along configuration information to DNCA Diameter peer within the NAT-device. The session configuration information comprises the maximum number of bindings allowed for the endpoint @@ -1042,43 +1056,44 @@ It is assumed that the DNCA Diameter peer within a NAT-controller knows the DiameterIdentity of the Diameter peer within a NAT-device for a given endpoint. Both the Destination-Realm and Destination- Host AVPs are present in the request from a DNCA Diameter peer within a NAT-controller to a DNCA Diameter peer within a NAT-device. 5.5. Advertising Application Support Diameter nodes conforming to this specification MUST advertise - support for DNCA by including the value of TBD in the Auth- + support for DNCA by including the value of TBD.APP-ID in the Auth- Application-Id of the Capabilities-Exchange-Request and Capabilities- Exchange-Answer command[RFC3588]. 6. DNCA Commands The following commands are used to establish, maintain and query NAT- bindings. 6.1. NAT-Control Request (NCR) Command The NAT-Control Request (NCR) command, indicated by the command field - set to TBD and the "R" bit set in the Command Flags field, is sent - from the DNCA Diameter peer within the NAT-controller to the DNCA - Diameter peer within the NAT-device in order to install NAT-bindings. + set to TBD.COM-CODE and the "R" bit set in the Command Flags field, + is sent from the DNCA Diameter peer within the NAT-controller to the + DNCA Diameter peer within the NAT-device in order to install NAT- + bindings. User-Name, Logical-Access-Id, Physical-Access-ID, Framed-IP-Address, Framed-IPv6-Prefix, Framed-Interface-Id, EGRESS-VLANID, NAS-Port-ID, Address-Realm, Calling-Station-ID AVPs serve as identifiers for the endpoint. Message format: - < NC-Request > ::= < Diameter Header: TBD, REQ, PXY> + < NC-Request > ::= < Diameter Header: TBD.COM-CODE, REQ, PXY> { Auth-Application-Id } { Origin-Host } { Origin-Realm } { Destination-Realm } { Destination-Host } { NC-Request-Type } [ Session-Id ] [ Origin-State-Id ] *1 [ NAT-Control-Remove ] *1 [ NAT-Control-Install ] @@ -1093,27 +1108,27 @@ [ NAS-Port-ID] [ Address-Realm ] [ Calling-Station-ID ] * [ Proxy-Info ] * [ Route-Record ] * [ AVP ] 6.2. NAT-Control Answer (NCA) Command The NAT-Control-Answer (NCA) command, indicated by the Command-Code - field set to TBD and the "R" bit cleared in the Command Flags field, - is sent by the DNCA Diameter peer within the NAT-device in response - to NAT-Control-Request command. + field set to TBD.COM-CODE and the "R" bit cleared in the Command + Flags field, is sent by the DNCA Diameter peer within the NAT-device + in response to NAT-Control-Request command. Message format: - ::= < Diameter Header: TBD, PXY > + ::= < Diameter Header: TBD.COM-CODE, PXY > { Origin-Host } { Origin-Realm } { Result-Code } [ Session-Id ] [ NC-Request-Type ] * [ NAT-Control-Definition ] [ Current-NAT-Bindings ] [ Origin-State-Id ] [ Error-Message ] [ Error-Reporting-Host ] @@ -1295,84 +1310,86 @@ |Proxy-Info 284 Grouped | M | P | N | |Result-Code 268 Unsigned32 | M | P | N | |Route-Record 282 DiamIdent | M | | N | |Session-Id 263 UTF8String | M | P | Y | |User-Name 1 UTF8String | M | P | Y | +-----------------------------------------------+-----+---+---------+ Table 1: DIAMETER AVPs used from Diameter base The Auth-Application-Id AVP (AVP Code 258) is assigned by IANA to Diameter applications. The value of the Auth-Application-Id for the - Diameter NAT Control Application is TBD. + Diameter NAT Control Application is TBD.APP-ID. Please refer to + [RFC3588] for the definition of the Diameter AVP flag rules and the + associated abbreviations used in the table. 8.2. Additional Result-Code AVP Values This section defines new values for the Result-Code AVP that SHALL be supported by all Diameter implementations that conform to the present document. 8.2.1. Success No new Result-Code AVP value is defined within this category. 8.2.2. Transient Failures Result-Code AVP values that fall within the transient failures category are those used to inform a peer that the request could not be satisfied at the time that it was received. The request may be able to be satisfied in the future. The following new values of the Result-Code AVP are defined: - RESOURCE_FAILURE (TBD) + RESOURCE_FAILURE (TBD.RCX) The DNCA Diameter peer within the NAT-device indicates that the binding could not be installed or a new session could not be created due to resource shortage. 8.2.3. Permanent Failures The Result-Code AVP values, which fall within the permanent failures category are used to inform the peer that the request failed, and should not be attempted again. The request may be able to be satisfied in the future. The following new values of the Result-Code AVP are defined: - UNKNOWN_BINDING_TEMPLATE_NAME (TBD) + UNKNOWN_BINDING_TEMPLATE_NAME (TBD.RCX) The DNCA Diameter peer within the NAT-device indicates that the binding could not be installed or a new session could not be created because the specified NAT-Control-Binding-Template AVP, that refers to a predefined policy template in the NAT-device, is unknown. - BINDING_FAILURE (TBD) + BINDING_FAILURE (TBD.RCX) DNCA indicates that the requested binding(s) could not be installed. For example: Requested ports are already in use. - MAXIMUM_BINDINGS_REACHED_FOR_ENDPOINT (TBD) + MAXIMUM_BINDINGS_REACHED_FOR_ENDPOINT (TBD.RCX) The DNCA Diameter peer within the NAT-device denies the request because the maximum number of allowed bindings has been reached for the specified endpoint classifier. - SESSION_EXISTS (TBD) + SESSION_EXISTS (TBD.RCX) The DNCA Diameter peer within the NAT-device denies request to initialize a new session, if it already has a DNCA session that uses the same set of classifiers as indicated by the DNCA Diameter peer within the NAT-controller in the new session initialization request. - INSUFFICIENT_CLASSIFIERS (TBD) + INSUFFICIENT_CLASSIFIERS (TBD.RCX) The DNCA Diameter peer within the NAT-device requests to initialize a new session, if the classifiers in the request match more than one of the existing sessions on the DNCA Diameter peer within the NAT-device. 8.3. Reused NASREQ Diameter Application AVPs The following table describes the AVPs reused from the Diameter Network Access Server Application [RFC4005]; their AVP Code values, @@ -1389,40 +1406,43 @@ | NAS-Port | 5 | Unsigned32 | M | P | | V | Y | | NAS-Port-Id | 87 | UTF8String | M | P | | V | Y | | Calling-Station- | 31 | UTF8String | M | P | | V | Y | | Id | | | | | | | | | Framed-IP-Address| 8 | OctetString| M | P | | V | Y | | Framed-Interface-| 96 | Unsigned64 | M | P | | V | Y | | Id | | | | | | | | | Framed-IPv6- | 97 | OctetString| M | P | | V | Y | | Prefix | | | | | | | | +------------------+------+------------|----+-----+----+-----|----+ - Table 2: Reused NASREQ Diameter application AVPs + Table 2: Reused NASREQ Diameter application AVPs. Please refer to + [RFC3588] for the definition of the Diameter AVP flag rules and the + associated abbreviations used in the table. 8.4. Reused AVPs from RFC 4675 The following table describes the AVPs reused from "RADIUS Attributes for Virtual LAN and Priority Support" specification [RFC4675]; their AVP Code values, types, and possible flag values; and whether the AVP MAY be encrypted. The [RFC3588] specifies the AVP Flag rules for AVPs in section 4.5. The Diameter AVP rules are defined in the [RFC3588], section 4. - +---------------------+ | AVP Flag rules | +------------------+------+------------|----+-----+----+-----|----+ | | AVP | | | |SHLD| MUST| | | Attribute Name | Code | Value Type|MUST| MAY | NOT| NOT|Encr| |------------------|------|------------|----+-----+----+-----|----| | Egress-VLANID | 56 | OctetString| M | P | | V | Y | +------------------+------+------------|----+-----+----+-----|----+ - Table 3: Reused attributes from RFC 4675 + Table 3: Reused attributes from RFC 4675. Please refer to [RFC3588] + for the definition of the Diameter AVP flag rules and the associated + abbreviations used in the table. 8.5. Reused AVPs from Diameter QoS Application The following table describes the AVPs reused from the Traffic Classification and Quality of Service (QoS) Attributes for Diameter [RFC5777]; their AVP Code values, types, and possible flag values; and whether the AVP MAY be encrypted. The [RFC3588] specifies the AVP Flag rules for AVPs in section 4.5. The Diameter AVP rules are defined in the [RFC3588], section 4. +---------+ @@ -1431,21 +1451,23 @@ | rules | +-----------------------------------------------|-----+---+---------+ | AVP | | | | | Attribute Name Code Data Type |MUST |MAY| Encr | +-----------------------------------------------+-----+---+---------+ |Port 530 Integer32 | M | P | Y | |Protocol 513 Enumerated | M | P | Y | |Direction 514 Enumerated | M | P | Y | +-----------------------------------------------+-----+---+---------+ - Table 4: Reused QoS-attributes + Table 4: Reused QoS-attributes. Please refer to [RFC3588] for the + definition of the Diameter AVP flag rules and the associated + abbreviations used in the table. 8.6. Reused AVPs from ETSI ES 283 034, e4 Diameter Application The following table describes the AVPs reused from the Diameter e4 Application [ETSIES283034]; their AVP Code values, types, and possible flag values; and whether the AVP MAY be encrypted. The [RFC3588] specifies the AVP Flag rules for AVPs in section 4.5. The Diameter AVP rules are defined in the [RFC3588], section 4. The Vendor-ID field in these AVP header will be set to ETSI (13019). @@ -1455,63 +1477,67 @@ | rules | +-----------------------------------------------|-----+---+---------+ | AVP | | | | | Attribute Name Code Data Type |MUST |MAY| Encr | +-----------------------------------------------+-----+---+---------+ |Address-Realm 301 OctetString | M,V | | Y | |Logical-Access-Id 302 OctetString | V | M | Y | |Physical-Access-ID 313 UTF8String | V | M | Y | +-----------------------------------------------+-----+---+---------+ - Table 5: Reused AVPs from Diameter e4 application + Table 5: Reused AVPs from Diameter e4 application. Please refer to + [RFC3588] for the definition of the Diameter AVP flag rules and the + associated abbreviations used in the table. 8.7. DNCA Defined AVPs The following table describes the new Diameter AVPs defined in this document; their AVP Code values, types, and possible flag values; and whether the AVP MAY be encrypted. The [RFC3588] specifies the AVP Flag rules for AVPs in section 4.5. The Diameter AVP rules are defined in the [RFC3588], section 4. The AVPs defined here MUST NOT have the V bit in the AVP Flag set. +---------+ | AVP | | Flag | | rules | - +-----------------------------------------------|-----+---+---------+ + +--------------------------------------------------|-----+---+------+ | AVP | | | | | Attribute Name Code Data Type |MUST |MAY| Encr | - +-----------------------------------------------+-----+---+---------+ - |NC-Request-Type TBD 8.7.1 Enumerated | M | P | Y | - |NAT-Control-Install TBD 8.7.2 Grouped | M | P | Y | - |NAT-Control-Remove TBD 8.7.3 Grouped | M | P | Y | - |NAT-Control-Definition TBD 8.7.4 Grouped | M | P | Y | - |NAT-Internal-Address TBD 8.7.5 Grouped | M | P | Y | - |NAT-External-Address TBD 8.7.6 Grouped | M | P | Y | - |Max-NAT-Bindings TBD 8.7.7 Unsigned32 | M | P | Y | - |NAT-Control- TBD 8.7.8 OctetString| M | P | Y | + +--------------------------------------------------+-----+---+------+ + |NC-Request-Type TBD.AX 8.7.1 Enumerated | M | P | Y | + |NAT-Control-Install TBD.AX 8.7.2 Grouped | M | P | Y | + |NAT-Control-Remove TBD.AX 8.7.3 Grouped | M | P | Y | + |NAT-Control-Definition TBD.AX 8.7.4 Grouped | M | P | Y | + |NAT-Internal-Address TBD.AX 8.7.5 Grouped | M | P | Y | + |NAT-External-Address TBD.AX 8.7.6 Grouped | M | P | Y | + |Max-NAT-Bindings TBD.AX 8.7.7 Unsigned32 | M | P | Y | + |NAT-Control- TBD.AX 8.7.8 OctetString| M | P | Y | | Binding-Template | | | | - |Duplicate- TBD 8.7.9 UTF8String | M | P | Y | + |Duplicate- TBD.AX 8.7.9 UTF8String | M | P | Y | | Session-ID | | | | - |NAT-External-Port- TBD 8.7.10 Enumerated | M | P | Y | + |NAT-External-Port- TBD.AX 8.7.10 Enumerated | M | P | Y | | Style | | | | - |NAT-Control-Record TBD 9.2.1 Grouped | M | P | Y | - |NAT-Control- TBD 9.2.2 Enumerated | M | P | Y | + |NAT-Control-Record TBD.AX 9.2.1 Grouped | M | P | Y | + |NAT-Control- TBD.AX 9.2.2 Enumerated | M | P | Y | | Binding-Status | | | | - |Current-NAT-Bindings TBD 9.2.3 Unsigned32 | M | P | Y | - +-----------------------------------------------+-----+---+---------+ + |Current-NAT-Bindings TBD.AX 9.2.3 Unsigned32 | M | P | Y | + +--------------------------------------------------+-----+---+------+ - Table 6: New Diameter AVPs + Table 6: New Diameter AVPs. Please refer to [RFC3588] for the + definition of the Diameter AVP flag rules and the associated + abbreviations used in the table. 8.7.1. NC-Request-Type AVP - The NC-Request-Type AVP (AVP Code TBD) is of type Enumerated and + The NC-Request-Type AVP (AVP Code TBD.AX) is of type Enumerated and contains the reason for sending the NAT-Control-Request command. It shall be present in all NAT-Control-Request messages. The following values are defined: INITIAL_REQUEST (1) An Initial Request is to initiate a Diameter NAT control session between the DNCA Diameter peers. @@ -1522,59 +1548,59 @@ given access session, or to remove one or several binding(s) activated on a given access session. QUERY_REQUEST (3) Query Request is used to query a NAT-device about the currently installed bindings for an endpoint classifier. 8.7.2. NAT-Control-Install AVP - The NAT-Control AVP (AVP code TBD) is of type Grouped, and it is used - to activate or install NAT bindings. It also contains Max-NAT- + The NAT-Control AVP (AVP code TBD.AX) is of type Grouped, and it is + used to activate or install NAT bindings. It also contains Max-NAT- Bindings that defines the maximum number of NAT bindings allowed for an endpoint and the NAT-Control-Binding-Template that references a predefined template on the NAT-device that may contain static binding, a maximum number of bindings allowed, an IP-address pool from which external binding addresses should be allocated, etc. If the NAT-External-Port-Style AVP is present, then the NAT-device MUST select the external ports for the NAT-Bindings as per the style specified. The NAT-External-Port-Style is applicable for NAT- Bindings defined by the NAT-Control-Definition AVPs whose NAT- External-Address or Port AVPs within the NAT-External-Address are unspecified. AVP format: - NAT-Control-Install ::= < AVP Header: TBD > + NAT-Control-Install ::= < AVP Header: TBD.AX > * [ NAT-Control-Definition ] [ NAT-Control-Binding-Template ] [ Max-NAT-Bindings ] [ NAT-External-Port-Style ] * [ AVP ] 8.7.3. NAT-Control-Remove AVP - The NAT-Control-Remove AVP (AVP code TBD) is of type Grouped, and it - is used to deactivate or remove NAT-bindings. At least one of the + The NAT-Control-Remove AVP (AVP code TBD.AX) is of type Grouped, and + it is used to deactivate or remove NAT-bindings. At least one of the two AVPs (NAT-Control-Definition AVP, NAT-Control-Binding-Template AVP) SHOULD be present in the NAT-Control-Remove AVP. AVP format: - NAT-Control-Remove ::= < AVP Header: TBD > + NAT-Control-Remove ::= < AVP Header: TBD.AX > * [ NAT-Control-Definition ] [ NAT-Control-Binding-Template ] * [ AVP ] 8.7.4. NAT-Control-Definition AVP - The NAT-Control-Definition AVP (AVP code TBD) is of type Grouped, and - it describes a binding. + The NAT-Control-Definition AVP (AVP code TBD.AX) is of type Grouped, + and it describes a binding. The NAT-Control-Definition AVP uniquely identifies the binding between the DNCA Diameter peers. If both the NAT-Internal-Address and NAT-External-Address AVP(s) are supplied, it is a pre-defined binding. If the NAT-External-Address AVP is not specified then the NAT-device MUST select the external port as per the NAT-External-Port-Style AVP, if present in the NAT-Control-Definition AVP. @@ -1586,92 +1612,94 @@ IP-addresses for all transport protocols. The Direction AVP is of type Enumerated. It specifies the direction for the binding. The values of the enumeration applicable in this context are: "IN","OUT". If Direction AVP is OUT or absent, the NAT- Internal-Address refers to the IP-address of the endpoint that needs to be translated. If Direction AVP is "IN", NAT-Internal-Address is the destination IP-address that has to be translated. AVP format: - NAT-Control-Definition ::= < AVP Header: TBD > + NAT-Control-Definition ::= < AVP Header: TBD.AX > { NAT-Internal-Address } [ Protocol ] [ Direction ] [ NAT-External-Address ] [ Session-Id ] * [ AVP ] 8.7.5. NAT-Internal-Address AVP - The NAT-Internal-Address AVP (AVP code TBD) is of type Grouped. It - describes the internal IP-address and port for a binding. Framed- + The NAT-Internal-Address AVP (AVP code TBD.AX) is of type Grouped. + It describes the internal IP-address and port for a binding. Framed- IPV6-Prefix and Framed-IP-Address AVPs are mutually exclusive. AVP format: - NAT-Internal-Address ::= < AVP Header: TBD > + + NAT-Internal-Address ::= < AVP Header: TBD.AX > [ Framed-IP-Address ] [ Framed-IPv6-Prefix ] [ Port] * [ AVP ] 8.7.6. NAT-External-Address AVP - The NAT-External-Address AVP (AVP code TBD) is of type Grouped, and - it describes the external IP-address and port for a binding. The + The NAT-External-Address AVP (AVP code TBD.AX) is of type Grouped, + and it describes the external IP-address and port for a binding. The external IP-address specified in this attribute can be reused for multiple endpoints by specifying the same address in the respective NAT-External-Address AVPs. If the external IP-address is not specified and the NAT-External-Port-Style AVP is specified in the NAT-Control-Definition AVP then the NAT-device MUST select external port as per the NAT-External-Port-Style AVP. AVP format: - NAT-External-Address ::= < AVP Header: TBD > + NAT-External-Address ::= < AVP Header: TBD.AX > [ Framed-IP-Address ] [ Port ] * [ AVP ] 8.7.7. Max-NAT-Bindings - The Max-NAT-Bindings AVP (AVP code TBD) is of type Unsigned32. It + The Max-NAT-Bindings AVP (AVP code TBD.AX) is of type Unsigned32. It indicates the maximum number of NAT-bindings allowed for a particular endpoint. 8.7.8. NAT-Control-Binding-Template AVP - The NAT-Control-Binding-Template AVP (AVP code TBD) is of type + The NAT-Control-Binding-Template AVP (AVP code TBD.AX) is of type OctetString. It defines a name for a policy template that is predefined at the NAT-device. Details on the contents and structure of the template and configuration are outside the scope of this document. The policy to which this AVP refers to may contain NAT- bindings, IP-address pool for allocating the external IP-address of a NAT-binding, and maximum number of allowed NAT-bindings. Such policy template can be reused by specifying the same NAT-Control-Binding- Template AVP in the corresponding NAT-Control-Install AVPs of multiple endpoints. 8.7.9. Duplicate-Session-Id AVP - The Duplicate-Session-Id AVP (AVP Code TBD) is of type UTF8String. + The Duplicate-Session-Id AVP (AVP Code TBD.AX) is of type UTF8String. It is used to report errors and contains the Session-Id of an existing session. 8.7.10. NAT-External-Port-Style AVP - The NAT-External-Port-Style AVP (AVP Code TBD) is of type Enumerated - and contains the style to be followed while selecting the external - port for a NAT-Binding relative to the internal port. + The NAT-External-Port-Style AVP (AVP Code TBD.AX) is of type + Enumerated and contains the style to be followed while selecting the + external port for a NAT-Binding relative to the internal port. The following values are defined: FOLLOW_INTERNAL_PORT_STYLE (1) + External port numbers selected MUST follow the same sequence and oddity as the internal ports of the NAT-bindings. The port odditity is required to support protocols like RTP and RTCP as defined in [RFC3550]. If for example the internal port in a requested NAT-binding is odd numbered then the external port allocated MUST also be odd numbered, and vice versa for an even numbered port. In addition, the sequence of port numbering is maintained: If internal ports are consecutive, then the NAT- device MUST choose consecutive external ports for the NAT- bindings. @@ -1714,55 +1742,55 @@ Current-NAT-Bindings AVP. This number needs to match the number of bindings identified as active within the NAT-Control-Record AVP. 9.2. NAT Control Accounting AVPs In addition to AVPs for ACR specified in [RFC3588], the DNCA Diameter peer within the NAT-device must add the NAT-Control-Record AVP. 9.2.1. NAT-Control-Record - The NAT-Control-Record AVP (AVP code TBD) is of type Grouped. It + The NAT-Control-Record AVP (AVP code TBD.AX) is of type Grouped. It describes a binding and its status. If NAT-Control-Binding-Status is set to Created, Event-Timestamp indicates the binding creation time. If NAT-Control-Binding-Status is set to Removed, Event-Timestamp indicates the binding removal time. If NAT-Control-Binding-Status is active, Event-Timestamp need not be present; if a value is present, it indicates that binding is active at the given time. - NAT-Control-Record ::= < AVP Header: TBD > + NAT-Control-Record ::= < AVP Header: TBD.AX > { NAT-Control-Definition } { NAT-Control-Binding-Status } [ Event-Timestamp ] 9.2.2. NAT-Control-Binding-Status - The NAT-Control-Binding-Status AVP (AVP code TBD) is of type + The NAT-Control-Binding-Status AVP (AVP code TBD.AX) is of type enumerated. It indicates the status of the binding - created, removed, or active. The following values are defined: Created (1) NAT binding is created. Active (2) NAT binding is active. Removed (3) NAT binding was removed. 9.2.3. Current-NAT-Bindings - The Current-NAT-Bindings AVP (AVP code TBD) is of type Unsigned32. + The Current-NAT-Bindings AVP (AVP code TBD.AX) is of type Unsigned32. It indicates the number of NAT bindings active on the NAT-device. 10. AVP Occurrence Table The following sections present the AVPs defined in this document and specify the Diameter messages in which they can be present. Note: AVPs that can only be present within a Grouped AVP are not represented in this table. The table uses the following symbols: @@ -1858,41 +1888,41 @@ this specification, or the values assigned to existing namespaces managed by IANA. In the subsections below, when we speak about review by a Designated Expert, please note that the designated expert will be assigned by the IESG. Initially, such Expert discussions take place on the AAA WG mailing list. 11.1. Application Identifier - This specification assigns the value , 'Diameter NAT Control - Application', to the Application Identifier namespace defined in - [RFC3588]. See Section 4 for more information. + This specification assigns the value , 'Diameter NAT + Control Application', to the Application Identifier namespace defined + in [RFC3588]. See Section 4 for more information. 11.2. Command Codes - This specification uses the value from the Command code - namespace defined in [RFC3588] for the NAT-Control-Request (NCR), - NAT-Control-Answer (NCA) commands. See Section 6.1 and Section 6.2 - for more information on these commands. + This specification uses the value from the Command + code namespace defined in [RFC3588] for the NAT-Control-Request + (NCR), NAT-Control-Answer (NCA) commands. See Section 6.1 and + Section 6.2 for more information on these commands. 11.3. AVP Codes - This specification assigns the values from the AVP code + This specification assigns the values from the AVP code namespace defined in [RFC3588]. See Section 8.7 for the assignment of the namespace in this specification. 11.4. Result-Code AVP Values - This specification assigns the values (4xxx, 5xxx, 5xxx, 5xxx, - 5xxx,5xxx) from the Result-Code AVP value namespace defined in + This specification assigns the values (4xxx, 5xxx, 5xxx, + 5xxx, 5xxx,5xxx) from the Result-Code AVP value namespace defined in [RFC3588]. See Section 8.2 for the assignment of the namespace in this specification. 11.5. NC-Request-Type AVP As defined in Section 8.7.1, the NC-Request-Type AVP includes Enumerated type values 1 - 3. IANA has created and is maintaining a namespace for this AVP. All remaining values are available for assignment by a Designated Expert [RFC5226]. @@ -1999,23 +2029,25 @@ competitive practices among providers, censorship, crime, etc. NAT- control could be used as a tool for preventing or redirecting access to particular sites. For instance, by controlling the NAT bindings, one could ensure that endpoints aren't able to receive particular flows, or that those flows are redirected to a relay that snoops or tampers with traffic instead of directly forwarding the traffic to the intended endpoint. In addition one could set up a binding in a way that the source IP address used is one of a relay so that traffic coming back can be snooped on or interfered with. The protections on DNCA and its Diameter protocol exchanges don't prevent such abuses of - NAT-control. A service provider deploying DNCA needs to make sure - that higher layer processes and procedures are put in place which - allow them to detect and mitigate misuses. + NAT-control. Prevention of mis-use or mis-configuration of a NAT- + device by an authorized NAT-controller is beyond the scope of this + protocol specification. A service provider deploying DNCA needs to + make sure that higher layer processes and procedures are put in place + which allow them to detect and mitigate misuses. 13. Examples This section shows example DNCA message content and exchange. 13.1. DNCA Session Establishment Example Figure 15 depicts a typical call flow for DNCA session establishment. In this example, the NAT-controller: @@ -2082,21 +2114,21 @@ 3. If there is no Diameter session already established with the DNCA Diameter peer within NAT-device, a Diameter connection is established and Diameter Base CER/CEA are exchanged. 4. The NAT-Controller creates an NCR message (see below) and sends it to the NAT-device. This example shows IPv4 to IPv4 address and port translation. For IPv6 to IPv4 translation, the Framed- IP-Address AVP would be replaced by the Framed-IPv6-Address AVP with the value set to the IPv6 address of the endpoint. - < NC-Request > ::= < Diameter Header: TBD, REQ, PXY> + < NC-Request > ::= < Diameter Header: TBD.COM-CODE, REQ, PXY> Session-Id = "natC.example.com:33041;23432;" Auth-Application-Id = Origin-Host = "natC.example.com" Origin-Realm = "example.com" Destination-Realm = "example.com" Destination-Host = "nat-device.example.com" NC-Request-Type = INITIAL_REQUEST User-Name = "subscriber_example1" Framed-IP-Address = "192.0.2.1" NAT-Control-Install = { @@ -2115,21 +2147,21 @@ Max-NAT-Bindings = 100 NAT-Control-Binding-Template = "local-policy" } 5. The NAT-device establishes a DNCA session as it is able to comply with the request. 6. The NAT-device sends an NCA to indicate the successful completion of the request. - ::= < Diameter Header: TBD, PXY > + ::= < Diameter Header: TBD.COM-CODE, PXY > Session-Id = "natC.example.com:33041;23432;" Origin-Host = "nat-device.example.com" Origin-Realm = "example.com" NC-Request-Type = INITIAL_REQUEST Result-Code = DIAMETER_SUCCESS 7. The endpoint sends packets that reach the NAT-device. 8. The NAT-device performs NAT for traffic received from the endpoint with source address 192.0.2.1. Traffic with source IP- @@ -2151,21 +2183,21 @@ FOLLOW_INTERNAL_PORT_STYLE) that directs the NAT-device to maintain port-sequence and port-oddity for the newly created NAT-bindings. In the example shown, the internal ports are UDP port 1036 and 1037. The NAT-device follows the directive selects the external ports accordingly. The NAT-device would for example create a mapping of 192.0.2.1:1036 to 198.51.100.1:5056 and 192.0.2.1:1037 to 198.51.100.1:5057, thereby maintaining port oddity (1036->5056, 1037->5057) and sequence ( the consecutive internal ports 1036 and 1037 map to the consecutive external ports 5056 and 5057). - < NC-Request > ::= < Diameter Header: TBD, REQ, PXY> + < NC-Request > ::= < Diameter Header: TBD.COM-CODE, REQ, PXY> Session-Id = "natC.example.com:33041;23432;" Auth-Application-Id = Origin-Host = "natC.example.com" Origin-Realm = "example.com" Destination-Realm = "example.com" Destination-Host = "nat-device.example.com" NC-Request-Type = UPDATE_REQUEST NAT-Control-Install = { NAT-Control-Definition = { Protocol = UDP @@ -2184,33 +2216,33 @@ } } NAT-External-Port- Style = FOLLOW_INTERNAL_PORT_STYLE } 13.3. DNCA Session Query Example This section shows an example for DNCA session query for a subscriber whose internal IP-Address is 192.0.2.1. - < NC-Request > ::= < Diameter Header: TBD, REQ, PXY> + < NC-Request > ::= < Diameter Header: TBD.COM-CODE, REQ, PXY> Auth-Application-Id = Origin-Host = "natC.example.com" Origin-Realm = "example.com" Destination-Realm = "example.com" Destination-Host = "nat-device.example.com" NC-Request-Type = QUERY_REQUEST Framed-IP-Address = "192.0.2.1" The NAT-device constructs an NCA to report all currently active NAT- bindings whose internal address is 192.0.2.1. - ::= < Diameter Header: TBD, PXY > + ::= < Diameter Header: TBD.COM-CODE, PXY > Origin-Host = "nat-device.example.com" Origin-Realm = "example.com" NC-Request-Type = QUERY_REQUEST NAT-Control-Definition = { Protocol = TCP Direction = OUT NAT-Internal-Address = { Framed-IP-Address = "192.0.2.1" Port = 80 } @@ -2344,21 +2376,21 @@ Origin-Realm = "example.com" Result-Code = DIAMETER_SUCCESS Accounting-Record-Type = STOP_RECORD Accounting-Record-Number = 1 6. On receipt of the ACA the NAT-device cleans up all NAT-bindings and associated session state for the endpoint. 7. NAT-device sends an STA. On receipt of the STA the NAT- controller will clean up the corresponding session state. - ::= < Diameter Header: TBD, PXY > + ::= < Diameter Header: 275, PXY > Session-Id = "natC.example.com:33041;23432;" Origin-Host = "nat-device.example.com" Origin-Realm = "example.com" Result-Code = DIAMETER_SUCCESS 14. Acknowledgements The authors would like to thank Jari Arkko, Wesley Eddy, Stephen Farrell, Miguel A. Garcia, David Harrington, Jouni Korhonen, Matt Lepinski, Avi Lior, Chris Metz, Pallavi Mishra, Lionel Morand, Robert @@ -2498,22 +2530,33 @@ external IP-address based query Changes from -13 to -14 a. Added NAT-External-Address in NC-request for session query by external IP-address b. Reordered all mandatory AVPs in NCR and NCA to appear before optional AVPs -16. References + Changes from -14 to -15 + a. As part of IESG discuss - clarified that multiple methods if used + along with DNCA for NAT control should be configured to prevent + conflict. + + b. Clarified misuse of NAT-device by a Diameter authorized NAT- + controller using DNCA is beyond the scope of this protocol + specification. + + c. Editorial updates. + +16. References 16.1. Normative References [ETSIES283034] ETSI, "Telecommunications and Internet Converged Services and Protocols for Advanced Networks (TISPAN),Network Attachment Sub-System (NASS),e4 interface based on the Diameter protocol.", September 2008. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. @@ -2535,23 +2578,23 @@ [RFC5777] Korhonen, J., Tschofenig, H., Arumaithurai, M., Jones, M., and A. Lior, "Traffic Classification and Quality of Service (QoS) Attributes for Diameter", RFC 5777, February 2010. 16.2. Informative References [I-D.ietf-behave-lsn-requirements] Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A., - and H. Ashida, "Common requirements for Carrier Grade NAT - (CGN)", draft-ietf-behave-lsn-requirements-04 (work in - progress), October 2011. + and H. Ashida, "Common requirements for Carrier Grade NATs + (CGNs)", draft-ietf-behave-lsn-requirements-05 (work in + progress), November 2011. [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994. [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999. [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022,