Subject: Is DAD really needed for SEND?

From: "James Kempf" <[email-masked]>
Date: Tue, 1 Jul 2003 09:12:53 -0700

Supposing that SEND nodes use CGAs, is DAD really required?

CGAs eliminate the possibility of DoS attack, and configuration conflicts
would occur only if two nodes have the same public key. I suppose an
implementation with a faulty random number generator could run into this
problem, but it seems extremely unlikely, and quickly self correcting, since
a customer would quickly report the problem. Calculations on the probability
of collision for standard IID-based host prefixes show it is something like
10^-12, with CGA, it should be even less.

If that's true, then the only case where a conflict could occur is with
nonSEND nodes. Wouldn't it be sufficient for a SEND node to monitor the
solicited node multicast address and respond to any attempt by a nonSEND
node to claim the address? A nonSEND node could persist in a DOS style
attack, but the SEND node could just change its public key for addresses.

Comments?

            jak

--------------------------------------------------------------------
To unsubscribe from this list, send email with "UNSUBSCRIBE" in the
body to <[email-masked]>.
Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html
--------------------------------------------------------------------

---

From: Greg Daley <[email-masked]>
Date: Wed, 02 Jul 2003 09:57:15 +1000

Hi James,

I understand your question but will be interested
in keeping DAD until IPv6 reviews RFC-2462.

> attack, but the SEND node could just change its public key for addresses.

With CGA the chance of collisions is small
unless there are implementation issues in the choice of
modifier or public key (which may not be reported quickly
unless diagnostic tools like DAD are used).

With the non-SEND nodes, I think that we have to assume that
DAD defenses against CGA addresses from non-CGA nodes are
attempted DoS attacks (and should be logged as such,
without acting on them).  The NS/NA security mechanisms
on SEND nodes should be useful when proving a right to own
an address.

I think that we have to remember that DAD is not just to avoid
collisions, but also to report them.

Greg

---

From: Alper Yegin <[email-masked]>
Date: Tue, 01 Jul 2003 18:42:15 -0700

> 10^-12, with CGA, it should be even less.

How does using CGA reduces the chances of collision?

Alper

---

From: "Nick 'Sharkey' Moore" <[email-masked]>
Date: Wed, 2 Jul 2003 13:41:28 +1000

On 2003-07-01, Alper Yegin wrote:
> > 
> > Calculations on the probability

Well, I don't think it'd reduce it any further than any other method
which produces a strongly random suffix, but I could be wrong ...

Mainly, it'd get rid of the chance of accidental misconfiguration,
or broken PRNGs.

-----Nick

---

From: "James Kempf" <[email-masked]>
Date: Wed, 2 Jul 2003 08:18:27 -0700

> How does using CGA reduces the chances of collision?

Because the probability of two nodes getting the same randomely generated
key is low. I haven't worked through the numbers to check whether it is
lower than for IID-based prefixes. That would depend on the properties of
the random number generator, I assume.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Wed, 2 Jul 2003 08:24:02 -0700

> Mainly, it'd get rid of the chance of accidental misconfiguration,

Right, that's the idea.

If the probability of getting a collision for CGAs is less than or equal to
what it is for IID-based identifiers, and you remove any probability of DoS
attack or misconfiguration, then one must question the point of going
through a heavy-weight, time consuming procedure to verify an address when
the probability that this process will fail due to BER on the link is higher
than the probability of an address collision.

It seems like overengineering to require DAD in that case.

            jak

---

From: "Nick 'Sharkey' Moore" <[email-masked]>
Date: Thu, 3 Jul 2003 01:49:13 +1000

G'day Jak and co ...

On 2003-07-02, James Kempf wrote:
>
> [...] the probability that this process will fail due to BER on the
> link is higher than the probability of an address collision.

Ummm.  P(collision) is still > P(collision) * P(packet-loss)^2,
the process can't really 'fail' except in the case of a collision.
I know what you mean though.

> It seems like overengineering to require DAD in that case.

I think I agree with you.  This may come as a surprise given all
the fuss over Optimistic DAD, but that's really a form of
skipping-DAD-in-the-hopes-of-good-RNG-but-recovering-in-case-it-isn't.

My question would be: what is the correct behaviour of a SEND-DAD
node in the case of a collision?  Alert the user?  Cease using
that address but continue defending it?  Cease defending it
but continue using it?  Burst into flames?

Also:  are there any SEND configuration screwups which would make
this collision more likely than 1:2^62, assuming that the odds
of human fallibility are _way_ higher than this? 
(eg: accidentally using the same key twice, etc, like I say I
know relatively little about SEND and CGA)

-----Nick

---

From: Jari Arkko <[email-masked]>
Date: Thu, 03 Jul 2003 00:29:14 +0300

> know relatively little about SEND and CGA)

I would say there are such possibilities. Good implementations
might perhaps prevent this (e.g. by not accepting any user-given
keys as input -- but the copied harddrive would still get you
this failure mode).

Also, I think the likelihood of a collision is roughly the
same whether you generate a direct random number or whether
you generate some random bits, turn them into an RSA key, and
then hash the result.

Anyway, I think a SEND node, upon detecting a collision, should
stop using the address, but not necessarily fail the interface
or burst into flames ;-)

One practical approach for us to deal with the DAD issue in
SEND is that we take the "secure ND" and "optimize DAD" problems
separately. That is, SEND takes IPv6 as-is, now. Then an
extension is built later to provide security for optimistic
DAD.

--Jari

---

From: "James Kempf" <[email-masked]>
Date: Wed, 2 Jul 2003 15:00:35 -0700

> but continue using it?  Burst into flames?

The draft says a SEND node should try three times before giving up. So I
would say that it should generate another key and try again. If it fails
three times, then the node is probably under attack and should report that
to somebody who can figure out if that's so.

            jak

---

From: Alper Yegin <[email-masked]>
Date: Wed, 02 Jul 2003 15:48:35 -0700

> the random number generator, I assume.

As long as both schemes produce 62bits starting from a random number, I
cannot see how CGA-based address is less likely to collide (unless one is
using a bad RNG with non-CGA, which would make this an apples-to-bad_apples
comparison). 

Your earlier point was that collisions are less likely with SEND, hence we
can turn off DAD. I think your basic assumption is not correct.

Regarding turning off DAD, I see people comparing the address collision
possibility to chances of a lightning striking the host, or packet loss in
wireless links, etc. Really, what is the lowest probability below which we
should be willing to take the risk for simplicity and performance? Anyways,
I think this issue is not for this WG to tackle......

Alper

---

From: "Nick 'Sharkey' Moore" <[email-masked]>
Date: Thu, 3 Jul 2003 11:51:53 +1000

> keys as input -- but the copied harddrive would still get you

Well, that's going to make it difficult to estimate the
actual collision probability then ...

> you generate some random bits, turn them into an RSA key, and

Yes, I'd believe so.  For a strongly random generator, eg: 
a hardware RNG or an entropy-pool PRNG, the results should be
equivalently well-distributed.

> stop using the address, but not necessarily fail the interface

It's tricky to say, I mean if you're willing to stop does that
mean you should have an equivalent of 'tentativeness'?  Or
just use the address, and if you receive a 'defensive' NA at
any time then regard the address as suspect and move as soon
as practical.

> extension is built later to provide security for optimistic

Yeah, the Optimistic DAD draft is still looking for a home,
but it probably isn't SEND!  I'm happy to include SEND considerations
in the draft though, if there need to be any.  At the moment
the Optimistic DAD draft states "[...] a suffix MUST be chosen
based on a strongly random algorithm [...]", and if I updated
that to read "[...] a suffix MUST be chosen based on a strongly 
random algorithm or well-distributed hash function [...]" it'd
fit right in with SEND/CGA otherwise unmodified, I think.

-----Nick

---

From: Jari Arkko <[email-masked]>
Date: Thu, 03 Jul 2003 10:17:43 +0300

> Yeah, the Optimistic DAD draft is still looking for a home,

I hope it finds a home soon, otherwise it might lose its
good spirit and turn into a Pessimistic DAD, maybe even become
a Homeless DAD ;-(

> fit right in with SEND/CGA otherwise unmodified, I think.

That sounds very good. Since Optimistic DAD is being worked on
while we already know about SEND, it makes sense to include
SEND compatibility or considerations in the draft. Hopefully
we can make the final design decisions for SEND in Vienna,
so SEND can become stable.

You may need to add also some processing rules, I'm not
quite sure exactly how much Optimistic DAD changes ND.
Perhaps the collision action details or something like
that is different wrt to base ND or base SEND.

--Jari