--- 1/draft-ietf-dime-nat-control-05.txt 2011-01-10 14:24:18.000000000 +0100 +++ 2/draft-ietf-dime-nat-control-06.txt 2011-01-10 14:24:18.000000000 +0100 @@ -1,22 +1,22 @@ Internet Engineering Task Force F. Brockners Internet-Draft S. Bhandari Intended status: Standards Track Cisco -Expires: April 25, 2011 V. Singh - Mavenir Systems +Expires: July 14, 2011 V. Singh + V. Fajardo Telcordia Technologies - October 22, 2010 + January 10, 2011 Diameter Network Address and Port Translation Control Application - draft-ietf-dime-nat-control-05 + draft-ietf-dime-nat-control-06 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 cope with IPv4-address space completion. This Diameter application allows external devices to configure and manage a Network Address Translator device - expanding @@ -42,25 +42,25 @@ 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 April 25, 2011. + This Internet-Draft will expire on July 14, 2011. Copyright Notice - Copyright (c) 2010 IETF Trust and the persons identified as the + Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as @@ -115,44 +115,45 @@ 9.1. NAT Control Accounting Messages . . . . . . . . . . . . . 34 9.2. NAT Control Accounting AVPs . . . . . . . . . . . . . . . 34 9.2.1. NAT-Control-Record . . . . . . . . . . . . . . . . . . 34 9.2.2. NAT-Control-Binding-Status . . . . . . . . . . . . . . 34 9.2.3. Current-NAT-Bindings . . . . . . . . . . . . . . . . . 35 10. AVP Occurrence Table . . . . . . . . . . . . . . . . . . . . . 35 10.1. DNCA AVP Table for NAT Control Initial and Update Requests . . . . . . . . . . . . . . . . . . . . . . . . . 35 10.2. DNCA AVP Table for Session Query request . . . . . . . . . 36 10.3. DNCA AVP Table for Accounting Message . . . . . . . . . . 36 - 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 + 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 11.1. Command Codes . . . . . . . . . . . . . . . . . . . . . . 37 11.2. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . 37 - 11.3. AVP Values . . . . . . . . . . . . . . . . . . . . . . . . 38 + 11.3. AVP Values . . . . . . . . . . . . . . . . . . . . . . . . 37 11.3.1. Result-Code AVP Values . . . . . . . . . . . . . . . . 38 - 11.4. Application IDs . . . . . . . . . . . . . . . . . . . . . 39 + 11.4. Application IDs . . . . . . . . . . . . . . . . . . . . . 38 12. Security Considerations . . . . . . . . . . . . . . . . . . . 39 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 39 14. Change History (to be removed prior to publication as an - RFC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 - 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41 - 15.1. Normative References . . . . . . . . . . . . . . . . . . . 41 + RFC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 + 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40 + 15.1. Normative References . . . . . . . . . . . . . . . . . . . 40 15.2. Informative References . . . . . . . . . . . . . . . . . . 41 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41 1. Introduction Internet service providers have started to deploy Network Address Translators (NATs) and Network Address and Port Translators (NAPTs) at the edge of their networks to deal with the depletion of available public IPv4 addresses. This document defines a Diameter application for providers deploying such NAT and NAPT devices. The use of a Diameter application allows for simple integration into the existing - AAA environment of a provider. + Authentication, Authorization and Accounting (AAA) environment of a + provider. The Diameter Network address and port translation Control Application (DNCA) offers the following capabilities: 1. Limits or defines the number of NAPT/NAT bindings made available to an individual subscriber or end point. 2. Supports the allocation of specific NAPT/NAT bindings. Two types of specific bindings can be distinguished: @@ -180,30 +181,30 @@ select external IP address in NAPT/NAT bindings for multiple subscribers. 4. Generates reports and accounting records: Reports established bindings for a particular user. The collected information is used by accounting systems for statistical purposes. 5. Queries and retrieves details about bindings on demand: This feature complements the previously mentioned accounting functionality(see item 4). The query functionality complements - alternative information query mechanisms, such as SNMP-based - mechanism, if available. + alternative information query mechanisms, such as Simple Network + Management Protocol (SNMP) based mechanisms, if available. 6. Identifies a subscriber or endpoint on multiple network devices (NAPT or NAT device, the AAA-server, or the Network Access Server (NAS)): Endpoint identification is facilitated through a Global Endpoint ID. Endpoints are identified through a single or a set - of classifiers, such as IP address, VLAN identifier, or interface - identifier which uniquely identify the traffic associated with a - particular global endpoint + of classifiers, such as IP address, Virtual Local Area Network + (VLAN) identifier, or interface identifier which uniquely + identify the traffic associated with a particular global endpoint This document is structured as follows: Section 2 lists terminology, while Section 3 provides an introduction to the DNCA and its overall deployment framework. Sections 4 to 8 cover the DNCA specifics, with Section 4 describing session management, Section 5 the use of the Diameter base protocol, Section 6 new commands, Section 7 AVPs used, and Section 8 accounting aspects. Section 9 presents an AVP occurance table. IANA and security considerations are addressed in Sections 10 and 11. @@ -488,24 +489,24 @@ Request-Type AVP set to INITIAL_REQUEST that identifies an already existing session; that is, DNCA Manager and endpoint identifier match an already existing session, the DNCA Agent returns NCA with Result-Code set to SESSION_EXISTS, and provides the Session-Id of the existing session in Duplicate-Session-Id AVP. o If a DNCA Agent receives an NCR from a DNCA Manager with NC- Request-Type AVP set to INITIAL_REQUEST that matches more than one of the already existing sessions; that is, DNCA Manager and endpoint identifier match already existing sessions, the DNCA - Agent returns a NCA with Result-Code set to Insufficient- - Classifiers. In case a DNCA Manager receives NCA that reports + Agent returns a NCA with Result-Code set to INSUFFICIENT- + CLASSIFIERS. In case a DNCA Manager receives NCA that reports Insufficient-Classifiers, it may choose to retry establishing a - new session using additional or more specific classifiers. + new session using additional and more specific classifiers. o If the NCR contains a binding rule not defined on the NAT device, the DNCA Agent returns NCA with Result-Code AVP set to UNKNOWN_BINDING_RULE. o In case the DNCA Agent is unable to establish all of the bindings requested in the NCR, it will return a NCA with Result-Code set to BINDING_FAILURE. The DNCA Agent, that is NAT device, treats a NCR as an atomic operation; hence none of the requested bindings will be established by the NAT device. Either all requested actions @@ -546,21 +547,21 @@ Figure 5: Initial NAT Control request and session establishment 4.3. Session Re-Authorization Session re-authorization is performed if the DNCA Manager desires to change the behavior of the NAT for an existing session. Re- authorization could be used, for example, to change the number of allowed bindings for a particular session, or establish or remove a pre-defined binding. - The DNCA Manager generates a NC message to the DNCA Agent with NC- + The DNCA Manager generates a NCR message to the DNCA Agent with NC- Request-Type AVP set to UPDATE_REQUEST upon receiving a trigger signal. In case the session is updated successfully, the DNCA Agent notifies the DNCA Manager about successful session update using a NAT-Control Answer (NCA) message with Result-Code set to DIAMETER_SUCCESS. Figure 6 shows the protocol interaction between the DNCA Manager and the DNCA Agent. In certain cases, the DNCA Agent may not be able to perfborm the tasks requested within the NCR. These include the following: @@ -576,21 +577,21 @@ the maximum number of allowed bindings has been reached for the Endpoint Classifier, it returns NCA with Result-Code AVP set to MAXIMUM_BINDINGS_REACHED_FOR_ENDPOINT. o If the DNCA Agent cannot establish some or all of the bindings requested in a NCR, but has not yet reached the maximum number of allowed bindings for the subscriber, it returns a NCA with Result- Code set to BINDING_FAILURE. The DNCA Agent (i.e., NAT device) treats a NCR as an atomic operation. Hence none of the requested bindings will be established by NAT device. Either all requested - actions within a NCR are either successful or failed completely.. + actions within a NCR are either successful or failed completely. o If DNCA Agent does not have sufficient resources to process a request, it returns NCA with Result-Code set to RESOURCE_FAILURE. o If a NCR redefines the maximum number of NAT bindings allowed for the endpoint, the new value will override any previously defined limit on NAT bindings. It depends on the implementation of the NAT device on how the NAT device copes with a case where the new value is lower than the actual number of allocated bindings. Typically the NAT device refrains from enforcing the new limit @@ -662,21 +663,21 @@ case the NCR MUST NOT contain a NAT-Control-Definition AVP. Each NAT binding is reported in a NAT-Control-Definition AVP. In case the session ID is unknown, the DNCA Agent returns NCA with Result-Code set to DIAMETER_UNKNOWN_SESSION_ID. 2. Retrieve session IDs and internal IP address/port pairs for one or multiple external IP address/port pairs: If the DNCA Manager wishes to retrieve the session ID(s) for one or multiple external IP address/port pairs, it MUST include the external IP address/ port pair(s) as part of the NAT-Control-Definition AVP of the - NCR. The session ID used within the NCR is not meaningful for + NCR. The session ID is not included in the NCR or the NCA for this type of a query. The DNCA Agent reports the NAT bindings and associated session IDs corresponding to the external IP address/port pairs in a NCA message with Result-Code set to DIAMETER_SUCCESS with the same session ID, which is used in NCR. In case an external IP address/port pair has no associated existing NAT binding, the NAT-Control-Definition AVP contained in the reply just contains the NAT-External-Address AVP. DNCA Manager DNCA Agent | | @@ -754,21 +755,21 @@ DNCA relies on DNCA Manager and DNCA Agent to have builtin redundancy support to recover state in case of failure. Example failure cases include the following: o The DNCA Manager loses session state (e.g. due to a restart). In this case, * The DNCA Agent may receive a NCR with NC-Request-Type AVP set to INITIAL_REQUEST that matches an existing session of DNCA - agent. The DNCA Agent returns an error that contains + agent. The DNCA Agent returns a Result-Code that contains Duplicate-Session-Id AVP to report the Session-ID of existing session. The DNCA Manager may send an explicit Sesstion Terminate Request(STR) for the older session, which was lost. * The DNCA Manager may receive accounting records for a session that does not exist. The DNCA Manager sends an accounting answer with Result-Code set to DIAMETER_UNKNOWN_SESSION_ID. On receiving this, the DNCA Agent clears the session and removes the associated session state. @@ -788,21 +789,22 @@ offering of the service provider. The service provider can choose to terminate the access session to the endpoint. 5. Use Of The Diameter Base Protocol The Diameter Base Protocol defined by [RFC3588] applies with the clarifications listed in the present specification. 5.1. Securing Diameter Messages - For secure transport of Diameter messages, IPsec MAY be used. + For secure transport of Diameter messages recommendations in + [RFC3588] apply. The DNCA Agent MAY verify the identity of the DNCA Manager during the Capabilities Exchange Request procedure. The DNCA Agent MAY verify if the DNCA Manager that issues a NCR command is allowed and it is based on: o The identity of the DNCA Manager o The type of NCR Command @@ -863,31 +865,30 @@ 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 subscriber. Message Format: < NC-Request > ::= < Diameter Header: TBD, REQ, PXY> - - < Session-Id > + [ Session-Id ] { Auth-Application-Id } { Origin-Host } { Origin-Realm } { Destination-Realm } { Destination-Host } { NC-Request-Type } [ Origin-State-Id ] - * [ NAT-Control-Remove ] - * [ NAT-Control-Install ] + *1 [ NAT-Control-Remove ] + *1 [ NAT-Control-Install ] [ 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 ] @@ -897,21 +898,21 @@ 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 Agent in response to NAT-Control-Request command. Message Format: ::= < Diameter Header: TBD, PXY > - < Session-Id > + [ Session-Id ] { Origin-Host } { Origin-Realm } { NC-Request-Type } [ Result-Code ] * [ NAT-Control-Definition ] [ Current-NAT-Bindings ] [ Origin-State-Id ] [ Error-Message ] [ Error-Reporting-Host ] * [ Failed-AVP ] @@ -1526,80 +1527,72 @@ +-------------------+ | Command Code | +-----------------------------------+-------------------+ | Attribute Name NCR NCA | +-------------------------------------------------------+ |NC-Request-Type 1 1 | |NAT-Control-Install 0-1 0 | |NAT-Control-Remove 0-1 0 | |NAT-Control-Definition 0 0 | - |NAT-Control-Record 0 0 | |Current-NAT-Bindings 0 0 | |Duplicate-Session-Id 0 0-1 | +-------------------------------------------------------+ 10.2. DNCA AVP Table for Session Query request The following table lists the DNCA specific AVPs that have to be present in NCR and NCA with NC-Request-Type set to QUERY_REQUEST. +-------------------+ | Command Code | +-----------------------------------+-------------------+ | Attribute Name NCR NCA | +-------------------------------------------------------+ |NC-Request-Type 1 1 | |NAT-Control-Install 0 0 | |NAT-Control-Remove 0 0 | |NAT-Control-Definition 0 0+ | - |NAT-Control-Record 0 0 | |Current-NAT-Bindings 0 1 | |Duplicate-Session-Id 0 0 | +-------------------------------------------------------+ 10.3. DNCA AVP Table for Accounting Message The following table lists the DNCA specific AVPs, which may or may not be present in ACR and ACA messages. - +-------------------+ | Command Code | +-----------------------------------+-------------------+ | Attribute Name ACR ACA | +-------------------------------------------------------+ - |NC-Request-Type 0 0 | - |NAT-Control-Install 0 0 | - |NAT-Control-Remove 0 0 | - |NAT-Control-Definition 0 0 | |NAT-Control-Record 0+ 0 | |Current-NAT-Bindings 1 0 | - |Duplicate-Session-Id 0 0 | +-------------------------------------------------------+ 11. IANA Considerations This section contains the namespaces that have either been created in this specification or had their values assigned to existing namespaces managed by IANA. 11.1. Command Codes IANA is requested to allocate command code values for the following. Registry: - +----------------+---------------------------+-------------+ + +------------+-----------------------------------+------------------+ | Code Value | Name | Reference | - +----------------+---------------------------+-------------+ - | to be assigned | NAT-Control-Request (NCR) | Section 6.1 | - | to be assigned | NAT-Control-Answer (NCA) | Section 6.2 | - +----------------+---------------------------+-------------+ + +------------+-----------------------------------+------------------+ + | to be | NAT-Control-Request (NCR), | Section 6.1, | + | assigned | NAT-Control-Answer (NCA) | Section 6.2 | + +------------+-----------------------------------+------------------+ Table 1: Command codes 11.2. AVP Codes IANA is requested to allocate AVP codes for the following AVPs that are defined in this document. Registry: @@ -1667,34 +1659,33 @@ +----------------+----------------------------------+-----------+ | ID Value | Name | Reference | +----------------+----------------------------------+-----------+ | to be assigned | Diameter NAT Control Application | Section 4 | +----------------+----------------------------------+-----------+ Table 4: Diameter Application ID values 12. Security Considerations - Similar to the impact of Diameter QoS application (see - [I-D.ietf-dime-diameter-qos]) on authorization of QoS reservations, - this document describes procedures for authorizing NAT related - attributes and parameters by an entity, which is non-local to the - device performing NAT. The security considerations for the Diameter - QoS application (see [I-D.ietf-dime-diameter-qos] section 11) apply - in a similar way to the DNCA. Securing the information exchange - between the authorizing entity (the DNCA Manager) and the NAT device - requires bilateral authentication of the involved parties, - authorization of the involved parties to perform the required - procedures and functions, and procedures to ensure integrity and - confidentiality of the information exchange. The DNCA makes use of - the capabilities offered by Diameter and the underlying transport - protocols to deliver these requirements (see Section 5.1 ). + Similar to the impact of Diameter QoS application (see [RFC5866]) on + authorization of QoS reservations, this document describes procedures + for authorizing NAT related attributes and parameters by an entity, + which is non-local to the device performing NAT. The security + considerations for the Diameter QoS application (see [RFC5866] + section 11) apply in a similar way to the DNCA. Securing the + information exchange between the authorizing entity (the DNCA + Manager) and the NAT device requires bilateral authentication of the + involved parties, authorization of the involved parties to perform + the required procedures and functions, and procedures to ensure + integrity and confidentiality of the information exchange. The DNCA + makes use of the capabilities offered by Diameter and the underlying + transport protocols to deliver these requirements (see Section 5.1 ). It is assumed that the DNCA Agent and DNCA Manager are in the same domain and have a mutual trust set up. Authorization between the DNCA Agent and DNCA Manager is beyond the scope of this document. 13. Acknowledgements The authors would like to thank Jouni Korhonen, Avi Lior, Chris Metz, Hannes Tschofenig, Greg Weber, and Glen Zorn for their input on this document. @@ -1735,22 +1725,27 @@ b. Removed NCR Request type terminate and replaced with STR c. All references to Auth-Session-State are removed and a new section to describe FSM for Manager and Agent has been added d. Clarified reuse of External address and address pools among multiple subscribers Changes from -04 to -05 + a. Removed references to Large Scale NAT as per review comments + Changes from -05 to -06 + + a. Editorial changes + 15. References 15.1. Normative References [ETSIES283034] ETSI, "Telecommunications and Internet Converged Services and Protocols for Advanced Networks (TISPAN),Network Attachment Sub-System (NASS),e4 interface based on the Diameter protocol.", September 2008. @@ -1764,59 +1759,49 @@ for Virtual LAN and Priority Support", RFC 4675, September 2006. [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. 15.2. Informative References - [I-D.ietf-dime-diameter-qos] - Sun, D., McCann, P., Tschofenig, H., ZOU), T., Doria, A., - and G. Zorn, "Diameter Quality of Service Application", - draft-ietf-dime-diameter-qos-14 (work in progress), - February 2010. - [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, "Diameter Network Access Server Application", RFC 4005, August 2005. - [TS32299] "3rd Generation Partnership Project; Technical - Specification Group Service and System Aspects; - Telecommunication management; Charging management; - "Diameter charging applications", 3GPP TS 32.299 Version - 6.3.0.2", 2008. + [RFC5866] Sun, D., McCann, P., Tschofenig, H., Tsou, T., Doria, A., + and G. Zorn, "Diameter Quality-of-Service Application", + RFC 5866, May 2010. Authors' Addresses Frank Brockners Cisco Hansaallee 249, 3rd Floor DUESSELDORF, NORDRHEIN-WESTFALEN 40549 Germany Email: fbrockne@cisco.com Shwetha Bhandari Cisco Cessna Business Park, Sarjapura Marathalli Outer Ring Road Bangalore, KARNATAKA 560 087 India Email: shwethab@cisco.com Vaneeta Singh - Mavenir Systems - Sharda Towers, 56/13 Nandidurga Road - Bangalore 560046 + 18, Cambridge Road + Bangalore 560008 India - Email: vaneeta@mavenir.com - + Email: vaneeta.singh@gmail.com Victor Fajardo Telcordia Technologies 1 Telcordia Drive #1S-222 Piscataway, NJ 08854 USA Email: vf0213@gmail.com