[secdir] Security review of http://www.ietf.org/id/draft-ietf-nsis-qos-nslp-17.txt
Ran Canetti <canetti@tau.ac.il> Fri, 27 November 2009 16:15 UTC
Return-Path: <canetti@tau.ac.il>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A25CE3A69C0; Fri, 27 Nov 2009 08:15:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.764
X-Spam-Level:
X-Spam-Status: No, score=0.764 tagged_above=-999 required=5 tests=[BAYES_50=0.001, SARE_RECV_BEZEQINT_B=0.763]
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 JOueMAObYIrH; Fri, 27 Nov 2009 08:15:58 -0800 (PST)
Received: from doar.tau.ac.il (gate.tau.ac.il [132.66.16.26]) by core3.amsl.com (Postfix) with ESMTP id 6BB0B3A6970; Fri, 27 Nov 2009 08:15:57 -0800 (PST)
Received: from [10.0.0.2] (bzq-80-27-10.red.bezeqint.net [82.80.27.10]) by doar.tau.ac.il (Postfix) with ESMTP id F2021BEF8; Fri, 27 Nov 2009 18:15:49 +0200 (IST)
Message-ID: <4B0FFB32.5090303@tau.ac.il>
Date: Fri, 27 Nov 2009 18:15:46 +0200
From: Ran Canetti <canetti@tau.ac.il>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: secdir <secdir@ietf.org>, nsis@ietf.org
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Fri, 27 Nov 2009 09:12:14 -0800
Subject: [secdir] Security review of http://www.ietf.org/id/draft-ietf-nsis-qos-nslp-17.txt
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 27 Nov 2009 16:28:13 -0000
*** 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. The document describes the NSIS signaling layer protocol, for signaling QOS reservations. The document builds on extensive ground work in the NSIS WG - in particular a requirements document (RFC 3726), a security threats document (RFC 4081), and a framework document (RFC 4080). Indeed, overall the document seems well thought out. I didn't find any issues with the proposed protocol in of itself. Here are some general remarks/thoughts that came to mind, and some nits: - regarding the NJT analogy (section 7.2) - on the NJT all payments are made to a single entity, thus this "pricing by distance" is easy. On the internet there are multiple independent business entities (eg, ISPs)... Does the protocol provide a way for the client to avoid having to setup business relationship separately with each server on the way? (Note that this is different from letting the traffic go through without QOS negotiation with each router on the way - Ideally the client should not even have to be aware of all the entities on the way. This does not seem compatible with the model where there is a single entity that's associated with a session, and this entity has to establish a relationship with each netwrok on the way.) -A very basic security issue with QOS is how the client (either at the data origin or destination) gets an assurance that the reservation was made (ie, that he got what he paid for). I havnt found mentioning of this issue in 4081. - Another issue is the need for authentication of the data packets. Deploying QOS without proper authentication of each and every QOS packet is dangerous... beyond the issue of correct charging, there is the danger that lack of authetication for QOS protected packets may adversely affect all traffic on the Internet, even non-QOS related traffic: without authentication, it may be possible to flood the network with rogoue high priority packets. Nits: - section 2: Why do SIDs need to be "cryptographically random"? (whatever this term means...) uniqueness (with high probability) seems enough. - might be good to explain the differences from RSVP (or point to where these are explained.) Best, Ran