Last Call Review of draft-ietf-dime-nat-control-

Request Review of draft-ietf-dime-nat-control
Requested rev. no specific revision (document currently at 17)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2011-03-08
Requested 2011-02-26
Authors Frank Brockners, Shwetha Bhandari, Vaneeta Singh, Victor Fajardo
Draft last updated 2011-03-11
Completed reviews Secdir Last Call review of -?? by Matt Lepinski
Tsvdir Last Call review of -?? by Martin Stiemerling
Assignment Reviewer Matt Lepinski 
State Completed
Review review-ietf-dime-nat-control-secdir-lc-lepinski-2011-03-11
Review completed: 2011-03-11


[I apologize if you received this message twice]

I have reviewed this document as part of the security directorate's 

ongoing effort to review all IETF documents being processed by the

IESG.  These comments were written primarily for the benefit of the 

security area directors. Document editors and WG chairs should treat 

these comments just like any other last call comments.

This document defines a Diameter application whereby a Diameter NAT 

Control Application (DNCA) server (either a AAA server or a Network 

Access Server) can control a DNCA client (either a NAT or NAPT device). 

For example, the DNCA server can determine the number of port bindings 

available to a given host, cause the allocation of particular NAT 

bindings, define the external address pool used for by the NAT device, 

or generate reports used for accounting purposes.

The principle security concern is that an unauthorized (or 

unauthenticated) DNCA server could effect a denial of service of attack 

on any or all hosts using a NAT/NAPT device in several ways. (E.g., an 

unauthorized server could exhaust resources in the NAPT device, set 

maximum bindings to zero for all hosts, provide a set of external 

addresses that are in use elsewhere in the network, etc.) An additional 

concern is that an unauthenticated DNCA client could provide incorrect 

reporting data to the DNCA server to prevent correct accounting within 

the system. Therefore, the NAT control application requires mutual 

authentication, authorization of the DNCA server, and integrity 

protection of the Diameter messages in the DNCA interaction. 

Additionally, the application may require confidentiality depending on 

the deployment scenario and, particularly, how authorization is 


The Security Considerations section of the document claims that security 

considerations are essentially the same as in the Diameter QoS (RFC 

5866). I agree with the authors that the security concerns for Diameter 

NAT Control are very similar to the security concerns for Diameter QoS, 

but I think the additional layer of indirection is not helpful to the 

reader. (In particular, the NAT Control Application has no dependencies 

on the Diameter QoS document. Therefore it is reasonable to believe that 

an implementer of Diameter NAT Control may not be familiar with the 

Diameter QoS document.) I would recommend that the authors add 

additional text explaining why mutual authentication, server 

authorization, and message integrity are required (copying a bit of text 

from RFC 5866 may be appropriate). Then I would recommend that the 

authors cite the Diameter specification (RFC 3588) for a discussion of 

how IPsec or TLS can be used to obtain these security properties. (To 

me, this seems preferable to sending a reader to RFC 5866 for discussion 

of required security properties, which in turn sends the reader to RFC 

3588 for an information on the use of IPsec or TLS to achieve these 


Finally, the end of the security considerations section claims that 

"Authorization between DNCA Agent and

   DNCA Manager is beyond the scope of this document". I understand 

that the authors do not want to mandate a particular mechanism for 

making an authorization decision. That being said, providing some 

guidance as to how a DNCA client would determine if a DNCA server were 

authorized to issue NAT control commands. I imagine in practice that the 

way authorization is accomplished is that the NAT/NAPT device stores a 

local authorization policy. (E.g., the device stores a list of server 

identities that authorized, and then once the server has been 

authenticated its identity can be checked against the list). At the very 

least having text analogous to first paragraph of RFC 5866 Section 11 

would be helpful (RFC 5866 says the device making the authorization 

decision needs to have sufficient information to make this decision and 

then provides examples of where this information would come from.)

- Matt Lepinski