[Dime] FW: SECDIR review of draft-ietf-dime-nat-control-07
"Romascanu, Dan (Dan)" <dromasca@avaya.com> Wed, 09 March 2011 16:49 UTC
Return-Path: <dromasca@avaya.com>
X-Original-To: dime@core3.amsl.com
Delivered-To: dime@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D8763A6938 for <dime@core3.amsl.com>; Wed, 9 Mar 2011 08:49:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.555
X-Spam-Level:
X-Spam-Status: No, score=-102.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4gzS46PDhQF6 for <dime@core3.amsl.com>; Wed, 9 Mar 2011 08:49:54 -0800 (PST)
Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 64D2F3A6930 for <dime@ietf.org>; Wed, 9 Mar 2011 08:49:54 -0800 (PST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvYAAFMtcU2HCzI1/2dsb2JhbACYKo47dKR5ApkWgn+CYgSQDA
X-IronPort-AV: E=Sophos;i="4.62,291,1297054800"; d="scan'208";a="268588635"
Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 09 Mar 2011 11:51:10 -0500
X-IronPort-AV: E=Sophos;i="4.62,291,1297054800"; d="scan'208";a="614017907"
Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 09 Mar 2011 11:51:10 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 09 Mar 2011 17:50:58 +0100
Message-ID: <EDC652A26FB23C4EB6384A4584434A0402D7B429@307622ANEX5.global.avaya.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: SECDIR review of draft-ietf-dime-nat-control-07
Thread-Index: AcveXoAI4/NYzV6BSlyRghF9Op12ZQAG6YMw
From: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
To: dime@ietf.org
Subject: [Dime] FW: SECDIR review of draft-ietf-dime-nat-control-07
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Mar 2011 16:49:55 -0000
-----Original Message----- From: Matt Lepinski [mailto:mlepinsk@bbn.com] Sent: Wednesday, March 09, 2011 3:33 PM To: draft-ietf-dime-nat-control.all@tools.ietf.org; iesg@ietf.org; secdir@ietf.org Subject: SECDIR review of draft-ietf-dime-nat-control-07 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 accomplished. 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 properties.) 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
- [Dime] FW: SECDIR review of draft-ietf-dime-nat-c… Jouni Korhonen
- [Dime] FW: SECDIR review of draft-ietf-dime-nat-c… Romascanu, Dan (Dan)
- Re: [Dime] FW: SECDIR review of draft-ietf-dime-n… Frank Brockners (fbrockne)