Re: [secdir] Secdir review of draft-ietf-nsis-rmd-19

"Georgios Karagiannis" <karagian@cs.utwente.nl> Wed, 21 April 2010 08:24 UTC

Return-Path: <karagian@cs.utwente.nl>
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 5DE5B3A6976; Wed, 21 Apr 2010 01:24:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.096
X-Spam-Level: **
X-Spam-Status: No, score=2.096 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545]
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 QyqVzZ8GD-Xo; Wed, 21 Apr 2010 01:24:42 -0700 (PDT)
Received: from denhaag.ewi.utwente.nl (denhaag.ewi.utwente.nl [130.89.10.11]) by core3.amsl.com (Postfix) with ESMTP id 1A3AF3A68F5; Wed, 21 Apr 2010 01:24:41 -0700 (PDT)
Received: from ewi977 (ewi977.ewi.utwente.nl [130.89.12.129]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id o3L8NTEa012934; Wed, 21 Apr 2010 10:23:40 +0200 (MEST)
From: "Georgios Karagiannis" <karagian@cs.utwente.nl>
To: "'Brian Weis'" <bew@cisco.com>, <secdir@ietf.org>, <iesg@ietf.org>
References: <4CCE7D8C-DECC-479D-89F6-FCA316050ADC@cisco.com>
Date: Wed, 21 Apr 2010 10:23:36 +0200
Message-ID: <000301cae12b$f796f7f0$810c5982@dynamic.ewi.utwente.nl>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <4CCE7D8C-DECC-479D-89F6-FCA316050ADC@cisco.com>
Thread-Index: Acrfi1700whOF+HqQA66edw2yq4qCQBoA7Mg
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (denhaag.ewi.utwente.nl [130.89.10.11]); Wed, 21 Apr 2010 10:23:48 +0200 (MEST)
X-Mailman-Approved-At: Wed, 21 Apr 2010 07:09:51 -0700
Cc: draft-ietf-nsis-rmd@tools.ietf.org, nsis-chairs@tools.ietf.org
Subject: Re: [secdir] Secdir review of draft-ietf-nsis-rmd-19
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: Wed, 21 Apr 2010 08:24:43 -0000

Dear Brian

Thank you very much for reviewing and sending us the very useful comments!

We will work out the comments, but due to some problems that 
some of the co-authors have associated with the traveling situation 
in Europe we will need some more days to fulfill this activity.

Best regards,
Georgios

 

> -----Original Message-----
> From: Brian Weis [mailto:bew@cisco.com] 
> Sent: maandag 19 april 2010 8:15
> To: secdir@ietf.org; iesg@ietf.org
> Cc: nsis-chairs@tools.ietf.org; draft-ietf-nsis-rmd@tools.ietf.org
> Subject: Secdir review of draft-ietf-nsis-rmd-19
> 
> 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 describes an NSIS QoS Model for networks that 
> use the Resource Management in Diffserv (RMD) concept. It 
> describes RMD-QOSM, which are new payloads sent using the 
> GISP signaling mechanism, where the new payloads request or 
> reserve resources. A number of data flows are discussed, 
> depending on whether nodes within a network boundary 
> participate in the protocol or not.
> 
> The Security Considerations section covers the following topics:
> - Byzantine adversaries (i.e., participants taken over by an
> adversary) are a general problem, but this section intends to 
> discuss additional threats as a result of the new protocol. 
> There is an extensive discussion of on-path and off-path 
> adversaries, which seems to intend to be addressing Byzantine 
> adversaries.
> - RMD-QOSM is claimed to be lightweight, with different 
> routers allowed certain operations dependant on the role a 
> router plays in the system. E.g., only Ingress/Egress nodes 
> are allowed to initiate certain signaling messages.
> - RMD-QOSM "relies on the security support that is provided 
> by the bounded end-to-end session, which is running between 
> the boundaries of the RMD domain", but doesn't mandate that 
> security support.
> 
> The existing text is helpful, but not sufficient. The 
> following points are suggestions to improve this section.
> 
> 1. The statement at the beginning of Security Considerations 
> discusses adversaries taking over a router, but the new 
> threats are not very clear. Are the authors considering that 
> security associations are revealed, that reservation data 
> routed to a particular router can be changed or forged, or 
> something else?
> 
> 2. The trust model used by RMD-QOSM is hinted at in the 
> discussion of on-path and off-path adversaries, but a 
> discussion of exactly what devices are trusted and what 
> they're trusted to do would be helpful.  
> For example, is every interior router in the network is 
> trusted to handle any particular RESERVE or RESERVE` message? 
> If not, then how are the paths setup so that only authorized 
> routers will see a particular message? On the other hand, if 
> routing is used to route the messages then it would seem that 
> any router must be authorized to handle messages happened to 
> be routed to them -- but then it isn't clear that there can 
> be a difference between an "on-path" and "off- path" adversary.
> 
> 3. Another dimension of trust model is the fact that 
> ingress/egress routers seem to trust each other more than 
> they trust interior nodes.  
> This seems evidenced by the fact that RESERVE messages 
> (Figure 24) don't seem to be intended to be modified by the 
> interior routers. In the case of probes, I would expect that 
> this would be especially important, but probes do not seem to 
> be specifically discussed in this section.
> 
> 4. There don't seem to be any actual security requirements or 
> recommendations made on GIST messaging. As such, it isn't 
> clear that attackers that have not taken over a participant 
> (i.e., a man in the  
> middle) are in any way foiled. I would expect to see more MUSTs and   
> SHOULDs in this section regarding message security.  There 
> are statements in the I-D such as "In the situation a 
> security association exists" and "If we assume that the 
> RESERVE/RESPONSE is sent with hop- by-hop channel security". 
> There should be some description of the threats to the 
> messaging by a non-participant, and stating what available 
> mechanisms MUST or SHOULD be used.
> 
> 5. Since roles seem to be an important part of the security 
> considerations, it would be helpful to see  discussion of the 
> different threats & requirements on the ingress/egress 
> routers and the internal routers in their different roles.
> 
> 6. An important service of RMD-QOSM is admission control, but 
> there doesn't seem to be any discussion of how the ingress 
> routers determine whether or not reservation requests given 
> to them are valid. I would have thought that is of particular 
> importance, but if it's considered out of scope this section 
> might mention that fact.
> 
> Hope that helps,
> Brian
>