Subject: RE: [mobile-ip] FMIPv6 Address confusion

From: Soliman Hesham <[email-masked]>
Date: Fri, 27 Jun 2003 02:24:51 -0400

> What I am trying to say is that we need some means against 
 > the address collision. In the Koodli's new text, the scan of ND 
 > cache improves the chances of expeditiously detecting duplicates.
 > I think that it is one possible solution although it does not solve 
 > the problem completely.

=> I didn't dispute that it was a possible solution. And
I'm happy for it to go into the draft. 

 > In your mail, you obviously mentioned that optiDAD can solve 
 > the address collision gracefully. Is it possible without some message
 > (e.g., Hi/HAck and FNA/NAAck)? 

=> Yes.

   Don't you mind the misdirected 
 > packets in case address collision?

=> If it has a probability of 10^-15 then no I 
don't mind, because it will be discovered in
1 sec and fixed. Remember that the exact same thing
can happen without a handover if the DAD message is lost
on an unreliable wireless link. What is the probability
of the DAD message being lost on a wireless link?
I bet you it's orders of magnitude higher than
address collision, when good RNGs are used or when
MAC addresses are used to generate iids.

Hesham

 > Youn-Hee

---

From: "Youn-Hee Han" <[email-masked]>
Date: Fri, 27 Jun 2003 16:53:09 +0900

> I'm happy for it to go into the draft. 

Good. It is neccessary.
 
> 1 sec and fixed. Remember that the exact same thing
                  ^^^^ no!
I don't agree. It cannot be fixed, but just detected.
During 1 sec, packets from NAR are incorrectly
delivered to another node. It is not possible to fix or 
recover it. 

> MAC addresses are used to generate iids.

Yes. I also agree that the probability of address collision is 
very low in many cases. However, I think that we need to prepare 
some means (or an alternative protocol) against the address collision,
because no one can assert that the probability is always below 10^-15
in all cases.

Regards,

Youn-Hee

---

From: Brett Pentland <[email-masked]>
Date: Fri, 27 Jun 2003 18:13:47 +1000

> delivered to another node. It is not possible to fix or 
A few packets may be delivered incorrectly, but the situation will 
stabilise and the correct node reassert its claim on the address.  When 
used appropriately, this situation will be extremely rare and in any 
case causes no long term damage.  Applications have to be able to deal 
with the possibility of a few lost packets anyway.

> because no one can assert that the probability is always below 10^-15
But there will be many cases where the probability of collision *is* 
extraordinarily low - e.g. addresses generated from good random number 
generators.  Why should devices that do use addresses with this property 
be burdened with unecessary complexity?

> Youn-Hee 
Cheers,
Brett.

---

From: "Xiaoming Wang" <[email-masked]>
Date: Fri, 27 Jun 2003 17:46:15 +0900

Hi, Hesham and YounHee,

> delivered to another node. It is not possible to fix or

At this point, I agree with YounHee. Only arrived at the new link can MN
detect duplication of NCoA by NS/NA. Therefore incorrect delivery on NAR
will not be detected for the whole L2 handover of MN, i.e. from MN sending
out FBU on the previous link to PAR, to MN detecting duplication of NCoA on
the new link.

For recovery, MN can send an another FBU to PAR on the new link, but after
successful configuration of a new NCoA, to inform PAR of its new NCoA. It
takes at least 1 second for successful DAD and a certain time for FBU to be
delivered from MN on the new link to PAR. Am I right?

Therefore, incorrect delivery on NAR will last for quite a long time: L2
handover time, plus 1 second of DAD time, plus delivery time of FBU.  This
is the most terrible thing we should avoid.

xiaoming

---

From: "Youn-Hee Han" <[email-masked]>
Date: Fri, 27 Jun 2003 22:22:50 +0900

Brett wrote:

> stabilise and the correct node reassert its claim on the address.  

A few packet? I don't agree. In the scenario shown by Hesham, so many 
(uncountable!) packets can be delivered to the incorrect node because NAR
has already had an NC entry of the incorrect node at the address collision case.

> When used appropriately, this situation will be extremely rare and in any 
> case causes no long term damage.  

Yes. Your words "When used approproately..." should be added in order 
for the scenario to work well. You used it already. 

> Applications have to be able to deal 

So many packets are not lost, but delivered to another node. It's a big problem.

> be burdened with unecessary complexity?

Why should we restrict that the devices must use good RNGs for FMIP?

Regards,
Youn-Hee

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 27 Jun 2003 13:27:02 -0700

> with the possibility of a few lost packets anyway.

this is an unbelievable trivilisation of a problem...

and I needless to say, I strongly disagree.

Vijay

---

From: Brett Pentland <[email-masked]>
Date: Mon, 30 Jun 2003 14:22:14 +1000

> and I needless to say, I strongly disagree.

How so?  What sort of problem are we talking about?  If as an MN that 
has just arrived on a link we wrongly assume that we can use an address 
and send off a BU, our CN sends some packets that end up at the node we 
collided with.  If we had a TCP session and the node we collided with 
sends a reset, we lose our connection even if we managed to chose 
another address and send off a new BU.  This is not good, but how big a 
problem is it?

The likelyhood of this kind of event needs to be considered when 
deciding how concerned we should be.  As Nick has noted later in this 
thread, even on a link with 5000 other active nodes, the probabilty of a 
collision is of the order of 10^-12.

I'm sorry if my email trivialised the act of misdirecting packets, and 
if the consequences are much more dire than I understand, then please 
let me know. However, when Optimistic DAD is used with good RNGs, the 
chances of a problem seem so low that I don't think we should be greatly 
concerned.

Brett.

---

From: "James Kempf" <[email-masked]>
Date: Mon, 30 Jun 2003 09:46:15 -0700

Brett,

> collision is of the order of 10^-12.

The issue isn't the liklihood of collision when everything is working fine,
it is the liklihood when it isn't. After all, the BER on DSL is 10^-9, on
wireless it can be considerably higher, so the liklihood of a DAD packet
being dropped due to a bit error is, in general, higher than the liklihood
of a collision.

The problem is that if someone's node is misconfigured or there's a
deliberate attack in an attempt to deny the victim an address, the
probability of collision becomes 1. Estimating the probability of an attack
or misconfiguration is possible but a lot harder, and would require
collecting data and analyzing it.

            jak

---

From: "Nick 'Sharkey' Moore" <[email-masked]>
Date: Tue, 1 Jul 2003 09:01:47 +1000

G'day James,

> being dropped due to a bit error is, in general, higher than the liklihood

Thanks for the numbers there, that's worth knowing.  I'd been trying
to find a reference to that for 802.11 ...

Because Optimistic DAD makes it practical to stay Tentative longer,
and to send more DAD 'probe' NAs, it can actually INCREASE the
probability of collision detection.

> collecting data and analyzing it.

RFC2461-DAD has no provision whatsoever for prevention of DoS by
misconfiguration or enemy action.  Optimistic DAD was not an attempt
to solve this problem, but it doesn't make it any worse either.

-----Nick

---

From: "Nick 'Sharkey' Moore" <[email-masked]>
Date: Tue, 1 Jul 2003 09:10:31 +1000

On 2003-06-30, Vijay Devarapalli wrote:
> 
> many specifications including the current ND specifications
> try to avoid this. they go to the extent of making DAD 
> mandatory whatever mechanism you use to configure your address.
> they also specify drastic actions like disabling the interface
> when something like this happens.

Yeah, because they're designed (a) to base their suffixes on IID,
which doesn't change and (b) for non-mobile hosts.  For example,
2462 specifies that in the event of failure "the node SHOULD log a
system management error", which sounds a lot more like a UN*X
box than a mobile phone to me!

> > but how big a problem is [breaking connections due to collision]?
> 
> I dont know. I have always considered it a big deal. but would
> love to be told that I am wrong.

Well, a lot of the time higher-layer protocols will recover, or
the user will retry.  So, in general, it's not the end of the 
world so long as it's a rare event.  See, yet again, the statistical
analysis in draft-soto-mobileip-random-iids-00 ...
<http://www.watersprings.org/pub/id/draft-soto-mobileip-random-iids-00.txt>.

Note that as per James' email in this thread, there is a possibility
that DAD will fail to detect a collision due to packet loss anyway.
At least Optimistic DAD has recovery mechanisms.

-----Nick