[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, 09 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/>
- [secdir] secdir review of draft-ietf-savi-fcfs-09… Juergen Schoenwaelder