--- 1/draft-ietf-radext-dtls-00.txt	2010-10-12 17:16:18.000000000 +0200
+++ 2/draft-ietf-radext-dtls-01.txt	2010-10-12 17:16:18.000000000 +0200
@@ -1,20 +1,20 @@
 
 Network Working Group                                         Alan DeKok
 INTERNET-DRAFT                                                FreeRADIUS
 Category: Informational
-<draft-ietf-radext-dtls-00.txt>
-Expires: April 8, 2011
-8 October 2010
+<draft-ietf-radext-dtls-01.txt>
+Expires: April 12, 2011
+12 October 2010
 
                   DTLS as a Transport Layer for RADIUS
-                       draft-ietf-radext-dtls-00
+                       draft-ietf-radext-dtls-01
 
 Abstract
 
    The RADIUS protocol [RFC2865] has limited support for authentication
    and encryption of RADIUS packets.  The protocol transports data "in
    the clear", although some parts of the packets can have "hidden"
    content.  Packets may be replayed verbatim by an attacker, and
    client-server authentication is based on fixed shared secrets.  This
    document specifies how the Datagram Transport Layer Security (DTLS)
    protocol may be used as a fix for these problems.  It also describes
@@ -35,21 +35,21 @@
    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."
 
    The list of current Internet-Drafts can be accessed at
    http://www.ietf.org/ietf/1id-abstracts.txt.
 
    The list of Internet-Draft Shadow Directories can be accessed at
    http://www.ietf.org/shadow.html.
 
-   This Internet-Draft will expire on April 8, 2011
+   This Internet-Draft will expire on April 12, 2011
 
 Copyright Notice
    Copyright (c) 2010 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
@@ -72,23 +72,24 @@
    3.1.  Protocol Disambiguation .............................    9
 4.  Connection Management ....................................   10
    4.1.  Server Connection Management ........................   10
       4.1.1.  Table Management ...............................   10
    4.2.  Client Connection Management ........................   11
 5.  Processing Algorithm .....................................   12
 6.  Diameter Considerations ..................................   14
 7.  IANA Considerations ......................................   14
 8.  Security Considerations ..................................   14
    8.1.  Legacy RADIUS Security ..............................   14
-9.  References ...............................................   15
-   9.1.  Normative references ................................   15
-   9.2.  Informative references ..............................   16
+   8.2.  Network Address Translation .........................   15
+9.  References ...............................................   16
+   9.1.  Normative references ................................   16
+   9.2.  Informative references ..............................   17
 
 1.  Introduction
 
    The RADIUS protocol as described in [RFC2865], [RFC2866], and
    [RFC5176] has traditionally used methods based on MD5 [RFC1321] for
    per-packet authentication and integrity checks.  However, the MD5
    algorithm has known weaknesses such as [MD5Attack] and [MD5Break].
    As a result, previous specifications such as [RFC5176] have
    recommended using IPSec to secure RADIUS traffic.
 
@@ -614,20 +615,44 @@
    cryptographically secure pseudo-random number generator (CSPRNG).
    For example, a reasonable key may be 32 characters of a SHA-256 hash
    of at least 64 bytes of data taken from a CSPRNG.  If this method
    seems too complicated, a certificate-based TLS method SHOULD be used
    instead.
 
    The previous RADIUS practice of using shared secrets that are minor
    variations of words is NOT RECOMMENDED, as it would negate nearly all
    of the security of DTLS.
 
+8.2.  Network Address Translation
+
+   Network Address Translation (NAT) is fundamentally incompatible with
+   RADIUS.  RADIUS uses the source IP address to determine the shared
+   secret for the client, and NAT hides many clients behind one source
+   IP address.
+
+   The migration flag described above in Section 3 is also tracked per
+   source IP address.  Using a NAT in front of many RADIUS clients
+   negates the function of the flag, making it impossible to migrate
+   clients in a secure fashion.
+
+   In addition, port re-use on a NAT gateway means that packets from
+   different clients may appear to come from the same source port on the
+   NAT.  That is, a RADIUS server may receive a RADIUS/DTLS packet from
+   a client IP/port combination, followed by the reception of a
+   RADIUS/UDP packet from that same client IP/port combination.  If this
+   capability were allowed, it would permit a downgrade attack to occur,
+   and would negate all of the security added by RADIUS/DTLS.
+
+   As a result, RADIUS clients SHOULD NOT be located behind a NAT
+   gateway.  If clients are located behind a NAT gateway, then a secure
+   transport such as DTLS MUST be used.
+
 9.  References
 
 9.1.  Normative references
 
 [RFC2865]
      Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote
      Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
 
 [RFC3539]
      Aboba, B. et al., "Authentication, Authorization and Accounting