draft-ietf-dime-nat-control-08.txt   draft-ietf-dime-nat-control-09.txt 
Internet Engineering Task Force F. Brockners Internet Engineering Task Force F. Brockners
Internet-Draft S. Bhandari Internet-Draft S. Bhandari
Intended status: Standards Track Cisco Intended status: Standards Track Cisco
Expires: January 1, 2012 V. Singh Expires: January 11, 2012 V. Singh
V. Fajardo V. Fajardo
Telcordia Technologies Telcordia Technologies
June 30, 2011 July 10, 2011
Diameter Network Address and Port Translation Control Application Diameter Network Address and Port Translation Control Application
draft-ietf-dime-nat-control-08 draft-ietf-dime-nat-control-09
Abstract Abstract
This document describes the framework, messages, and procedures for This document describes the framework, messages, and procedures for
the Diameter Network address and port translation Control the Diameter Network address and port translation Control
Application. This Diameter application allows per endpoint control Application. This Diameter application allows per endpoint control
of Network Address Translators and Network Address and Port of Network Address Translators and Network Address and Port
Translators, which are added to networks to cope with IPv4-address Translators, which are added to networks to cope with IPv4-address
space completion. This Diameter application allows external devices space depletion. This Diameter application allows external devices
to configure and manage a Network Address Translator device - to configure and manage a Network Address Translator device -
expanding the existing Diameter-based AAA and policy control expanding the existing Diameter-based AAA and policy control
capabilities with a Network Address Translators and Network Address capabilities with a Network Address Translators and Network Address
and Port Translators control component. These external devices can and Port Translators control component. These external devices can
be network elements in the data plane such as a Network Access be network elements in the data plane such as a Network Access
Server, or can be more centralized control plane devices such as AAA- Server, or can be more centralized control plane devices such as AAA-
servers. This Diameter application establishes a context to commonly servers. This Diameter application establishes a context to commonly
identify and manage endpoints on a gateway or server, and a Network identify and manage endpoints on a gateway or server, and a Network
Address Translator and Network Address and Port Translator device. Address Translator and Network Address and Port Translator device.
This includes, for example, the control of the total number of This includes, for example, the control of the total number of
skipping to change at page 2, line 7 skipping to change at page 2, line 7
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 1, 2012. This Internet-Draft will expire on January 11, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 11 skipping to change at page 3, line 11
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Deployment Framework . . . . . . . . . . . . . . . . . . . . . 7 3. Deployment Framework . . . . . . . . . . . . . . . . . . . . . 7
3.1. Deployment Scenario . . . . . . . . . . . . . . . . . . . 7 3.1. Deployment Scenario . . . . . . . . . . . . . . . . . . . 7
3.2. Diameter NAPT Control Application Overview . . . . . . . . 8 3.2. Diameter NAPT Control Application Overview . . . . . . . . 9
3.3. Deployment Scenarios For DNCA . . . . . . . . . . . . . . 9 3.3. Deployment Scenarios For DNCA . . . . . . . . . . . . . . 10
4. DNCA Session Establishment and Management . . . . . . . . . . 11 4. DNCA Session Establishment and Management . . . . . . . . . . 12
4.1. Session Establishment . . . . . . . . . . . . . . . . . . 11 4.1. Session Establishment . . . . . . . . . . . . . . . . . . 12
4.2. Session Re-Authorization . . . . . . . . . . . . . . . . . 14 4.2. Session Re-Authorization . . . . . . . . . . . . . . . . . 14
4.3. Session and Binding Query . . . . . . . . . . . . . . . . 16 4.3. Session and Binding Query . . . . . . . . . . . . . . . . 17
4.4. Session Termination . . . . . . . . . . . . . . . . . . . 18 4.4. Session Termination . . . . . . . . . . . . . . . . . . . 18
4.5. Session Abort . . . . . . . . . . . . . . . . . . . . . . 19 4.5. Session Abort . . . . . . . . . . . . . . . . . . . . . . 19
4.6. Failure cases of the DNCA Diameter peers . . . . . . . . . 20 4.6. Failure cases of the DNCA Diameter peers . . . . . . . . . 20
5. Use Of The Diameter Base Protocol . . . . . . . . . . . . . . 21 5. Use Of The Diameter Base Protocol . . . . . . . . . . . . . . 21
5.1. Securing Diameter Messages . . . . . . . . . . . . . . . . 21 5.1. Securing Diameter Messages . . . . . . . . . . . . . . . . 21
5.2. Accounting Functionality . . . . . . . . . . . . . . . . . 22 5.2. Accounting Functionality . . . . . . . . . . . . . . . . . 22
5.3. Use Of Sessions . . . . . . . . . . . . . . . . . . . . . 22 5.3. Use Of Sessions . . . . . . . . . . . . . . . . . . . . . 22
5.4. Routing Considerations . . . . . . . . . . . . . . . . . . 22 5.4. Routing Considerations . . . . . . . . . . . . . . . . . . 22
5.5. Advertising Application Support . . . . . . . . . . . . . 22 5.5. Advertising Application Support . . . . . . . . . . . . . 22
6. DNCA Commands . . . . . . . . . . . . . . . . . . . . . . . . 22 6. DNCA Commands . . . . . . . . . . . . . . . . . . . . . . . . 22
skipping to change at page 4, line 23 skipping to change at page 4, line 23
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
11.1. Application Identifier . . . . . . . . . . . . . . . . . . 39 11.1. Application Identifier . . . . . . . . . . . . . . . . . . 39
11.2. Command Codes . . . . . . . . . . . . . . . . . . . . . . 39 11.2. Command Codes . . . . . . . . . . . . . . . . . . . . . . 39
11.3. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . 39 11.3. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . 39
11.4. Result-Code AVP Values . . . . . . . . . . . . . . . . . . 39 11.4. Result-Code AVP Values . . . . . . . . . . . . . . . . . . 39
11.5. NC-Request-Type AVP . . . . . . . . . . . . . . . . . . . 39 11.5. NC-Request-Type AVP . . . . . . . . . . . . . . . . . . . 39
11.6. NAT-Control-Binding-Status AVP . . . . . . . . . . . . . . 39 11.6. NAT-Control-Binding-Status AVP . . . . . . . . . . . . . . 39
12. Security Considerations . . . . . . . . . . . . . . . . . . . 40 12. Security Considerations . . . . . . . . . . . . . . . . . . . 40
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 41 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 41
14. Change History (to be removed prior to publication as an 14. Change History (to be removed prior to publication as an
RFC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 RFC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
15. Normative References . . . . . . . . . . . . . . . . . . . . . 43 15. Normative References . . . . . . . . . . . . . . . . . . . . . 43
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 43 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44
1. Introduction 1. Introduction
Internet service providers have started to deploy Network Address Internet service providers have started to deploy Network Address
Translators (NATs) and Network Address and Port Translators (NAPTs) Translators (NATs) and Network Address and Port Translators (NAPTs)
in their networks to deal with the depletion of available public IPv4 in their networks to deal with the depletion of available public IPv4
addresses. This document defines a Diameter application allowing addresses. This document defines a Diameter application allowing
providers to control the behavior of these NAT and NAPT devices. The providers to control the behavior of these NAT and NAPT devices. The
use of a Diameter application allows for simple integration into the use of a Diameter application allows for simple integration into the
existing Authentication, Authorization and Accounting (AAA) existing Authentication, Authorization and Accounting (AAA)
environment of a provider. environment of a provider.
The Diameter Network address and port translation Control Application The Diameter Network address and port translation Control Application
(DNCA) offers the following capabilities: (DNCA) offers the following capabilities:
1. Limits or defines the number of NAPT/NAT bindings made available 1. Limits or defines the number of NAPT/NAT bindings made available
to an individual subscriber or end point. to an individual end point or user. The main motivation for
restricting the number of bindings on a per end point basis is to
protect the service of the service provider against denial of
service attacks. If multiple end points share a single public IP
address, these end points can share fate. If one end point would
(either intentionally, or due to mis-behavior, mis-configuration,
mal-ware, etc.) be able to consume all available bindings for a
given single public IP address, service would be hampered (or
might even become unavailable) for those other end points sharing
the same public IP address. The efficiency of a NAPT deployment
depends on the maximum number of bindings an end point could use.
Given that the typical number of bindings an end point uses
depends on the type of end point (e.g. a personal computer of a
broadband user is expected to use a higher number of bindings
than a simple mobile phone) and a NAPT device is often shared by
different types of end points, it is desirable to actively manage
the maximum number of bindings.
2. Supports the allocation of specific NAPT/NAT bindings. Two types 2. Supports the allocation of specific NAPT/NAT bindings. Two types
of specific bindings can be distinguished: of specific bindings can be distinguished:
* Allocation of a pre-defined NAT binding: Both the internal and * Allocation of a pre-defined NAT binding: Both the internal and
external IP address and port pair are specified within the external IP address and port pair are specified within the
request. Some deployment cases, such as access to a web- request. Some deployment cases, such as access to a web-
server within a user's home network with IP address and port, server within a user's home network with IP address and port,
benefit from statically configured bindings. benefit from statically configured bindings.
skipping to change at page 40, line 10 skipping to change at page 40, line 10
As defined in Section 8.7.1, the NAT-Control-Binding-Status AVP As defined in Section 8.7.1, the NAT-Control-Binding-Status AVP
includes Enumerated type values 1 - 3. IANA has created and is includes Enumerated type values 1 - 3. IANA has created and is
maintaining a namespace for this AVP. All remaining values are maintaining a namespace for this AVP. All remaining values are
available for assignment by a Designated Expert [RFC5226]. available for assignment by a Designated Expert [RFC5226].
12. Security Considerations 12. Security Considerations
This document describes procedures for controlling NAT related This document describes procedures for controlling NAT related
attributes and parameters by an entity, which is non-local to the attributes and parameters by an entity, which is non-local to the
device performing NAT. This section discusses security device performing NAT. This section discusses security
considerations for DNCA interactions between the Diameter peers considerations for DNCA. This includes the interactions between the
within a NAT-controller and a NAT-device. Security between NAT- Diameter peers within a NAT-controller and a NAT-device as well as
controller and NAT-device has a number of components: authentication, general considerations for NAT-control in a service provider network.
authorization, integrity, and confidentiality.
Security between NAT-controller and NAT-device has a number of
components: authentication, authorization, integrity, and
confidentiality.
Authentication refers to confirming the identity of an originator for Authentication refers to confirming the identity of an originator for
all datagrams received from the originator. Lack of authentication all datagrams received from the originator. Lack of authentication
of Diameter messages between the Diameter peers can jeopardize the of Diameter messages between the Diameter peers can jeopardize the
fundamental service of the peering network elements. A consequence fundamental service of the peering network elements. A consequence
of not authenticating the message sender by the recipient would be of not authenticating the message sender by the recipient would be
that an attacker could spoof the identity of a "legitimate" that an attacker could spoof the identity of a "legitimate"
authorizing entity in order to change the behavior of the receiver. authorizing entity in order to change the behavior of the receiver.
An attacker could for example launch a denial of service attack by An attacker could for example launch a denial of service attack by
setting the maximum number of bindings for a session on the NAT- setting the maximum number of bindings for a session on the NAT-
skipping to change at page 41, line 27 skipping to change at page 41, line 30
It is assumed that the DNCA Diameter peers are typically in the same It is assumed that the DNCA Diameter peers are typically in the same
domain and have a mutual trust set up. This document does not domain and have a mutual trust set up. This document does not
specify a mechanisms for authorization between the DNCA Diameter specify a mechanisms for authorization between the DNCA Diameter
peers. It is assumed that the DNCA Diameter peers are provided with peers. It is assumed that the DNCA Diameter peers are provided with
sufficient information to make an authorization decision. The sufficient information to make an authorization decision. The
information can come from various sources, for example the peering information can come from various sources, for example the peering
devices could store local authentication policy, listing the devices could store local authentication policy, listing the
identities of authorized peers. identities of authorized peers.
Any mechanism or protocol providing control of a NAT-device, and DNCA
is an example of such a control mechanism, could allow for misuse of
the NAT-device given that it enables the definition of per-
destination or per-source rules. Misuse could include anti-
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 end points 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 end point. In addition one could setup 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.
13. Acknowledgements 13. Acknowledgements
The authors would like to thank Miguel A. Garcia, Jouni Korhonen, The authors would like to thank Wesley Eddy, Miguel A. Garcia, Jouni
Matt Lepinski, Avi Lior, Chris Metz, Pallavi Mishra, Lionel Morand, Korhonen, Matt Lepinski, Avi Lior, Chris Metz, Pallavi Mishra, Lionel
Hannes Tschofenig, Shashank Vikram, Greg Weber, and Glen Zorn for Morand, Hannes Tschofenig, Shashank Vikram, Greg Weber, and Glen Zorn
their input on this document. for their input on this document.
14. Change History (to be removed prior to publication as an RFC) 14. Change History (to be removed prior to publication as an RFC)
Changes from -00 to -01 Changes from -00 to -01
a. new values for Result-Code AVP used - instead of Experimental- a. new values for Result-Code AVP used - instead of Experimental-
Result AVP Result AVP
b. added support for transport specific binding (UDP/TCP) b. added support for transport specific binding (UDP/TCP)
skipping to change at page 43, line 17 skipping to change at page 43, line 35
c. Nomenclature change: From DNCA Agent/Manager to DNCA Diameter c. Nomenclature change: From DNCA Agent/Manager to DNCA Diameter
peers identifying the location where they reside (NAT-controller peers identifying the location where they reside (NAT-controller
or NAT-device) or NAT-device)
d. IANA consideration Section format changes d. IANA consideration Section format changes
e. Updated security section (included considerations directly, e. Updated security section (included considerations directly,
rather than referring to Diameter QoS similarities). rather than referring to Diameter QoS similarities).
Changes from -08 to -09
a. expanded on the need for an SP controlling the maximum number of
bindings of an end point (see introduction section)
b. added a paragraph in the security section outlining general mis-
uses of NAT-control (non specific to DNCA), with DNCA being an
example of such a NAT-control protocol
c. editorial changes
15. Normative References 15. Normative References
[ETSIES283034] [ETSIES283034]
ETSI, "Telecommunications and Internet Converged Services ETSI, "Telecommunications and Internet Converged Services
and Protocols for Advanced Networks (TISPAN),Network and Protocols for Advanced Networks (TISPAN),Network
Attachment Sub-System (NASS),e4 interface based on the Attachment Sub-System (NASS),e4 interface based on the
Diameter protocol.", September 2008. Diameter protocol.", September 2008.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
 End of changes. 14 change blocks. 
21 lines changed or deleted 69 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/