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
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
Precedence: list

Hilarie,

Thanks for the review.  Please see in line below.

>-----Original Message-----
>From: Hilarie Orman [mailto:ho@alum.mit.edu]=20
>Sent: Monday, February 02, 2015 6:48 PM
>To: iesg@ietf.org; secdir@ietf.org; draft-ietf-6man-enhanced-dad@tools.iet=
f.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 ongoin=
g effort to review all IETF documents being processed by the IESG.  These c=
omments were written >primarily for the benefit of the security area direct=
ors.  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 adm=
inistrators with some debugging and measurement functions by allowing IPv6 =
routers to detect >that the network has been configured for loopback testin=
g.  Without this new feature, routers would treat the recurring messages (t=
he looped-back messages) as evidence of an >address duplication.  Currently=
, such an error should result in disabling the interface until manual comma=
nds 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 dupl=
icate 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 all=
owed because an attacker >can easily imitate or disable the loopback messag=
es.  The authors believe that SEND and SAVI protect against these attacks. =
 If these are not already in place, an administrator >must ask if the benef=
its of loopback are worth the increased risk of operating, at least tempora=
rily, without DAD.  If not, then is it worth the trouble of adding addition=
al >protections?

Then the sending node, before initiating the deliberate Loopback circuit te=
sting, can disable DAD on the interface.  Any other protection is likely a =
whole new RFC if SEND is not used.=20

>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 acco=
mpany the prose >descriptions.  It does not explicitly describe what consti=
tutes 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.=20

>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 th=
e 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". =20
>This term occurs almost nowhere else in the world. =20

That is why "DAD-failed state" is defined in the Terminology section.=20

>It may be the case that an interface in a failed state is not usually furt=
her qualified by the cause; maybe this draft should avoid the term.  "Disab=
led because of DAD" perhaps?

It's not important what specific term is used and far as a term is defined.=
=20

>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 repl=
aced by a message count.  This is because the probability of a nonce collis=
ion is the defining security >metric, and that will depend on the size of t=
he 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 w=
ith 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 sen=
der waits for 2 seconds during which if no NA or the same DAD probe is rece=
ived 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 s=
ection 4. =20

Regards,

Hemant=20