[secdir] secdir review of draft-ietf-savi-fcfs-09.txt

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Mon, 09 May 2011 13:46 UTC

Return-Path: <j.schoenwaelder@jacobs-university.de>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90490E0692; Mon, 9 May 2011 06:46:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.186
X-Spam-Level:
X-Spam-Status: No, score=-103.186 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vnU0LuDY7SWB; Mon, 9 May 2011 06:46:33 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 6A9CBE0659; Mon, 9 May 2011 06:46:30 -0700 (PDT)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id B952620BDD; Mon, 9 May 2011 15:46:28 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id R5STOA8ANXCg; Mon, 9 May 2011 15:46:28 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id EE21720BDB; Mon, 9 May 2011 15:46:27 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 171EE1871160; Mon, 9 May 2011 15:46:21 +0200 (CEST)
Date: Mon, 9 May 2011 15:46:21 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: iesg@ietf.org, secdir@ietf.org, draft-ietf-savi-fcfs.all@tools.ietf.org
Message-ID: <20110509134619.GA38866@elstar.local>
Mail-Followup-To: iesg@ietf.org, secdir@ietf.org, draft-ietf-savi-fcfs.all@tools.ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: [secdir] secdir review of draft-ietf-savi-fcfs-09.txt
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 09 May 2011 13:46:34 -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.

--

My first question was triggered by text on page 8:
 
   [...] Before creating a SAVI
   binding in the local SAVI database, the SAVI device will send a NSOL
   message querying for the address involved.  Should any host reply to
   that message with a NADV message, the SAVI device that sent the NSOL
   will infer that a binding for that address exists in another SAVI
   device and will not create a local binding for it.

Now, that sounded like it is easy to DoS new devices simply by
generating fake NADV messages. Later in section 3, it seems you only
accept NADV messages from trusted ports. If my reading is correct,
then a better wording might be:

   [...] Before creating a SAVI
   binding in the local SAVI database, the SAVI device will send a NSOL
   message querying for the address involved.  Should any host 
   _on a trusted port_
   reply to
   that message with a NADV message, the SAVI device that sent the NSOL
   will infer that a binding for that address exists in another SAVI
   device and will not create a local binding for it.

But then I am not sure whether it is really practical to assume that
NADV messages always come from a trusted port.

--

My second question concerns the construction of the prefix list. One
option is to learn prefixes by listening to Router Advertisements. Is
there a way to make SAVI do bad things by announcing bogus prefixes?

--

My third question concerns this statement in the security considerations:

   The other type of attack is when an attacker manages to create state
   in the SAVI device that will result in blocking the data packets sent
   by the legitimate owner of the address.  In IPv6 these attacks are
   not an issue thanks to the 2^64 addresses available in each link.

The second sentence makes this sound like a non-issue but it seems to
be correct only if devices uniformly pick random addresses out of the
full 2^64 address space. If for whatever reason I can guess with a
decent likelihood an address, it looks like SAVI becomes a tool to
help me with denying service for such an address.

--

Editorial nits:

- p10: s/because the connect/because they connect/  (twice)
- p10: s/through validating port/through validating ports/
- p11: s/prefixes.A/prefixes. A/
- p13: s/may due/may be due/
- p13: s/packets has been/packets have been/
- p18: s/relay/rely/
- p24: s/coalition/collision/
- p26: s/case fixed/case of fixed/

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>