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

Brian Weis <bew@cisco.com> Mon, 19 April 2010 06:15 UTC

Return-Path: <bew@cisco.com>
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 5DB5C3A6AB1; Sun, 18 Apr 2010 23:15:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.299
X-Spam-Level:
X-Spam-Status: No, score=-9.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, RCVD_IN_DNSWL_HI=-8]
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 5J0PBTG-56lm; Sun, 18 Apr 2010 23:15:11 -0700 (PDT)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 59F9E3A6845; Sun, 18 Apr 2010 23:15:11 -0700 (PDT)
Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAA6Ry0urR7Ht/2dsb2JhbACbdXGgPpkIhRAEgzI
X-IronPort-AV: E=Sophos;i="4.52,234,1270425600"; d="scan'208";a="517137168"
Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 19 Apr 2010 06:15:03 +0000
Received: from stealth-10-32-244-210.cisco.com (stealth-10-32-244-210.cisco.com [10.32.244.210]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o3J6F2Hf010436; Mon, 19 Apr 2010 06:15:03 GMT
Message-Id: <4CCE7D8C-DECC-479D-89F6-FCA316050ADC@cisco.com>
From: Brian Weis <bew@cisco.com>
To: secdir@ietf.org, iesg@ietf.org
Content-Type: text/plain; charset="US-ASCII"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Sun, 18 Apr 2010 23:15:02 -0700
X-Mailer: Apple Mail (2.936)
Cc: draft-ietf-nsis-rmd@tools.ietf.org, nsis-chairs@tools.ietf.org
Subject: [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: Mon, 19 Apr 2010 06:15:12 -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.

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