[secdir] Security review of draft-ietf-6man-enhanced-dad-12

"Hilarie Orman" <ho@alum.mit.edu> Mon, 02 February 2015 23:49 UTC

Return-Path: <hilarie@purplestreak.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 077CF1A8823; Mon, 2 Feb 2015 15:49:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id ncd9RnkV0f3M; Mon, 2 Feb 2015 15:49:23 -0800 (PST)
Received: from out02.mta.xmission.com (out02.mta.xmission.com []) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 946221A89FE; Mon, 2 Feb 2015 15:48:22 -0800 (PST)
Received: from in02.mta.xmission.com ([]) by out02.mta.xmission.com with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from <hilarie@purplestreak.com>) id 1YIQj5-0004qp-E3; Mon, 02 Feb 2015 16:48:19 -0700
Received: from [] (helo=sylvester.rhmr.com) by in02.mta.xmission.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from <hilarie@purplestreak.com>) id 1YIQj4-0001qW-Aq; Mon, 02 Feb 2015 16:48:19 -0700
Received: from sylvester.rhmr.com (localhost []) by sylvester.rhmr.com (8.14.4/8.14.4/Debian-2ubuntu1) with ESMTP id t12NmCem002008; Mon, 2 Feb 2015 16:48:12 -0700
Received: (from hilarie@localhost) by sylvester.rhmr.com (8.14.4/8.14.4/Submit) id t12NmCNI002007; Mon, 2 Feb 2015 16:48:12 -0700
Date: Mon, 02 Feb 2015 16:48:12 -0700
Message-Id: <201502022348.t12NmCNI002007@sylvester.rhmr.com>
From: Hilarie Orman <ho@alum.mit.edu>
To: iesg@ietf.org, secdir@ietf.org, draft-ietf-6man-enhanced-dad@tools.ietf.org
X-XM-AID: U2FsdGVkX18/vrTRocqi2ULT9RAM/Rbi
X-SA-Exim-Mail-From: hilarie@purplestreak.com
X-Spam-DCC: XMission; sa05 1397; Body=1 Fuz1=1 Fuz2=1
X-Spam-Combo: ********;iesg@ietf.org, secdir@ietf.org, draft-ietf-6man-enhanced-dad@tools.ietf.org
X-Spam-Timing: total 440 ms - load_scoreonly_sql: 0.03 (0.0%), signal_user_changed: 2.6 (0.6%), b_tie_ro: 1.94 (0.4%), parse: 0.55 (0.1%), extract_message_metadata: 5.0 (1.1%), get_uri_detail_list: 1.76 (0.4%), tests_pri_-1000: 3.1 (0.7%), tests_pri_-950: 1.31 (0.3%), tests_pri_-900: 1.03 (0.2%), tests_pri_-400: 25 (5.7%), check_bayes: 24 (5.4%), b_tokenize: 6 (1.5%), b_tok_get_all: 11 (2.5%), b_comp_prob: 2.6 (0.6%), b_tok_touch_all: 1.80 (0.4%), b_finish: 0.62 (0.1%), tests_pri_0: 393 (89.3%), tests_pri_500: 6 (1.3%), rewrite_mail: 0.00 (0.0%)
X-SA-Exim-Version: 4.2.1 (built Wed, 24 Sep 2014 11:00:52 -0600)
X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com)
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/_xGSQcbitvrnpaHBLfuGwkK1ZFc>
Subject: [secdir] Security review of draft-ietf-6man-enhanced-dad-12
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Hilarie Orman <ho@alum.mit.edu>
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, 02 Feb 2015 23:49:26 -0000

Security review of Enhanced Duplicate Address Detection 

Do not be alarmed ...
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.

Enhanced DAD (duplicate address detection) is intended to help network
administrators with some debugging and measurement functions by
allowing IPv6 routers to detect that the network has been configured
for loopback testing.  Without this new feature, routers would treat
the recurring messages (the looped-back messages) as evidence of an
address duplication.  Currently, such an error should result in
disabling the interface until manual commands are entered.

The goal is to define a simple and reliable way for routers to detect
that loopback is in effect.  During the loopback testing, the
detection of duplicate addresses will not result in disabling the

The proposed detection method, as mentioned in the Security
Considerations, results in a new kind of attack, one in which
duplicate addresses are allowed because an attacker can easily imitate
or disable the loopback messages.  The authors believe that SEND and
SAVI protect against these attacks.  If these are not already in
place, an administrator must ask if the benefits of loopback are worth
the increased risk of operating, at least temporarily, without DAD.  If
not, then is it worth the trouble of adding additional protections?

The document intends to describe an algorithm and a state machine, but
it does not have the terse language and diagrams that one would expect
to accompany the prose descriptions.  It does not explicitly describe
what constitutes loopback detection.

There is a grammo in the following crucial sentence:
   If there is a collision because two nodes using the same Target
   Address in their NS(DAD) and generated the same random nonce, then
   the algorithm will incorrectly detect a looped back NS(DAD) when a
   genuine address collision has occurred. 

I think that the sentence can be repaired by changing "using" to
"used".  With that, we implicitly get the definition of loopback
detection: seeing two NS(DAD) messages with the same Target Address
and the same Nonce.  There is also a time window for the detection.

The document refers to the normal (non-loopback) case of duplicate
address detection as leading to the "DAD failed state".  This term
occurs almost nowhere else in the world.  It may be the case that an
interface in a failed state is not usually further qualified by the
cause; maybe this draft should avoid the term.  "Disabled because of
DAD" perhaps?

In section 5, I am confused by this statement:
   Any other network that follows the same trust model MAY use the
   automated actions proposed in this section.
The problem is that as nearly as I can tell, there is only one such
action in the section, the one in the immediately preceding sentence.

It seems to me that the time interval for detection might be usefully
replaced by a message count.  This is because the probability of
a nonce collision is the defining security metric, and that will
depend on the size of the nonce space and the number of messages
in the possible collision window.  The minimum nonce size is 48 bits,
a collision would be expected once in 16 million messages.  I suppose
that might happen on a very busy network with a small address space.