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

"Hemant Singh (shemant)" <shemant@cisco.com> Thu, 05 February 2015 18:20 UTC

Return-Path: <shemant@cisco.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA3C71A0AF1; Thu, 5 Feb 2015 10:20:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jGOde0mcRc08; Thu, 5 Feb 2015 10:20:12 -0800 (PST)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3D8A1A19F7; Thu, 5 Feb 2015 10:20:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5138; q=dns/txt; s=iport; t=1423160410; x=1424370010; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=m4uFlEDeJYKlWp+YEBSQdszkkYfu8LEmNbPHMHQe7Go=; b=YTHwVEc+lQGg2Teay9gDQhaUWmS0eBuZB2aP8B41jbxFyDPAjesV+ysS EQvB4esLgkK4BEogXXyIT60ke7bpMFVer7BOnVSI2XDRHZmbazomjjfZL 3Vm1Bf87HfW0Uux7hzqwLEhP2Kyl9x04N4Non0tHLfFayd22OWZhqgIqQ E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AiUFAOGz01StJA2G/2dsb2JhbABaDoJ4gSsEyDsCgSdDAQEBAQF9hAwBAQEEOksGAQgOAwQBAQsUCTkUCQkBBAESCIgl1wsBAQEBAQEBAwEBAQEBAQEBGo9HPoMQgRMFjTWBY4pDgwOOUSKBfYE0PW+BAiQefgEBAQ
X-IronPort-AV: E=Sophos;i="5.09,525,1418083200"; d="scan'208";a="393770916"
Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-3.cisco.com with ESMTP; 05 Feb 2015 18:20:09 +0000
Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t15IK9ST024176 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Feb 2015 18:20:09 GMT
Received: from xmb-rcd-x06.cisco.com ([169.254.6.166]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0195.001; Thu, 5 Feb 2015 12:20:08 -0600
From: "Hemant Singh (shemant)" <shemant@cisco.com>
To: Hilarie Orman <ho@alum.mit.edu>, "iesg@ietf.org" <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>, "draft-ietf-6man-enhanced-dad@tools.ietf.org" <draft-ietf-6man-enhanced-dad@tools.ietf.org>
Thread-Topic: Security review of draft-ietf-6man-enhanced-dad-12
Thread-Index: AdBBcFoFMMircgorSuCR6l3hvDlnEw==
Date: Thu, 5 Feb 2015 18:20:08 +0000
Message-ID: <75B6FA9F576969419E42BECB86CB1B891568FC44@xmb-rcd-x06.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.131.71.110]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/6X6HTz0IyDtPDRuo2bPFC7KzzWo>
Subject: Re: [secdir] Security review of draft-ietf-6man-enhanced-dad-12
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
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: Thu, 05 Feb 2015 18:20:25 -0000
X-List-Received-Date: Thu, 05 Feb 2015 18:20:25 -0000

Hilarie,

Thanks for the review.  Please see in line below.

>-----Original Message-----
>From: Hilarie Orman [mailto:ho@alum.mit.edu] 
>Sent: Monday, February 02, 2015 6:48 PM
>To: iesg@ietf.org; secdir@ietf.org; draft-ietf-6man-enhanced-dad@tools.ietf.org
>Subject: Security review of draft-ietf-6man-enhanced-dad-12

>Security review of Enhanced Duplicate Address Detection
>draft-ietf-6man-enhanced-dad-12

>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 interface.

>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?

Then the sending node, before initiating the deliberate Loopback circuit testing, can disable DAD on the interface.  Any other protection is likely a whole new RFC if SEND is not used. 

>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.

Will make the change.

>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.  

That is why "DAD-failed state" is defined in the Terminology section. 

>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?

It's not important what specific term is used and far as a term is defined. 

>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.

Ok, will replace all "actions" with "action".

>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.

We have used existing time intervals from RFC 4862 and RFC 4861.  The time interval is defined in RFC 4862 which says if a DAD probe is issued the sender waits for 2 seconds during which if no NA or the same DAD probe is received at the sender, the sender puts the Target Address to assigned state.  The Enhanced DAD algorithm uses time intervals defined in RFC 4861 which is the RetransTimer waiting how long and stopping the probe.   We acknowledge the nonce collision and have addressed the issue in the 2nd paragraph of section 4.  

Regards,

Hemant