Subject: [mobile-ip] draft on random interface identifiers available

From: Ignacio Soto Campos <[email-masked]>
Date: Mon, 04 Feb 2002 16:51:46 +0100

Hi all,

    We have submitted the draft "Random generation of interface
identifiers" that is available from:

http://www.ietf.org/internet-drafts/draft-soto-mobileip-random-iids-00.txt

The abstract is included below. Comments are welcomed.

Abstract

   This document evaluates the use of random numbers to generate the
   interface identifier part of an IPv6 address on mobile environments,
   where Duplicate Address Detection (DAD) mechanisms are expensive.
   We have estimated the probability of having an address duplication
   using this mechanism and we conclude that the IPv6 addresses created
   in this way could be used without previously doing DAD to test the
   uniqueness of the address in a link.

Best regards,

Ignacio

---

From: Francis Dupont <[email-masked]>
Date: Wed, 06 Feb 2002 11:55:07 +0100

From the end of the conclusion:
 Whether DAD should be performed after or it can be avoided, needs further
 study.  For now, we think that performing DAD after joining the link
 is needed.

=> in fact there is no real difference between to perform after
or to avoid: if there is a duplicate you are simply dead...
Personnaly I don't like things which mostly work and IMHO the
best solution is to put the control of to do or not DAD in the hands
of the user because of the special situations (*partial* lists:
 - universal interface IDs which are known to be really universal
  (MAC addresses of NICs not found in the trash can)
 - PPP (two nodes so collisions are not so frequent, and IPv6CP
  manages the two interface IDs and guarantees they are different)).
The only thing important (and done in the MIPv6 I-D) is to remove
the absolute requirement for DAD.

Regards

[email-masked]

PS: I'd prefer to see a proposal for building universal IIDs for EMEI
(does someone share this opinion? We have a lot of GSM experts in the
building :-)

---

From: Ignacio Soto Campos <[email-masked]>
Date: Wed, 06 Feb 2002 13:13:32 +0100

Francis,

> or to avoid: if there is a duplicate you are simply dead...

Actually, we don't think that the situation is as bad as being dead.
If you are able to detect the duplication and to generate a new
interface identifier, you just have suffered an interruption in your
communication (which we agree it can be serious enough
to make your established communications to time out).

Besides, performing DAD after allows you, for example, to detect
the duplicate address pro-actively when communications are
not established. Even when communications are established,
performing DAD allows you to improve your recovery time. Whether
this is worth the cost of doing it, is what we propose to discuss.

> the absolute requirement for DAD.

The MIPv6 I-D states:

  "After forming a new care-of address, a mobile node MAY perform
   Duplicate Address Detection [27] on that new address to confirm its
   uniqueness.  However, doing so represents a tradeoff between safety
   (ensuring that the new address is not used if it is a duplicate
   address) and overhead..."

Our draft tries to asses how safe is to avoid DAD before using
IPv6 addresses created from random numbers. We think this is
interesting because is a concrete method to create the interface
identifiers and a quantification of the risks involved in using the
resulting addresses before doing DAD.

> (does someone share this opinion? We have a lot of GSM experts in the

Universal unique IIDs for IPv6 addresses is an interesting subject, have
you any idea of any steps to its implementation?

Regards,

    Marcelo and Ignacio

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 6 Feb 2002 15:35:09 +0100 (CET)

This is an IPv6 WG topic - why don't we move it there?

> or to avoid: if there is a duplicate you are simply dead...

Question is who and how many are dead.
If one node has been around communicating for a while and a new node
appears that has a duplicate address with the first we can choose between:
1. Have both be disrupted - presumably to the extent they can pick
   new addresses they will both need to do so.
2. Have one be disrupted
   a. Have the new guy be disrupted
   b. Have the old node be disrupted

Only if you think #1 makes sense it is true that after vs. before makes
no difference.
But Duplicate Address Detection as defined does 2a.

   Erik

---

From: Francis Dupont <[email-masked]>
Date: Wed, 06 Feb 2002 15:41:06 +0100

=> just try it... There is a race condition between the two nodes
with the same address, in general none wins (any packet goes to the
wrong node :-).

=> don't forget the other node... With IPv6 NUD helps to recover
but each time I saw this kind of problems (in IPv4) it caused real damage!

=> my answer is simple: please don't play Russian roulette with my network!
   
   Universal unique IIDs for IPv6 addresses is an interesting subject,

=> they are a far better solution too because if the source of the IID
is not really unique something at the link-layer should break too
(for instance duplicate MAC addresses).

   have you any idea of any steps to its implementation?
   
=> MAC addresses (MAC-48 -> EUI-48 -> EUI-64 -> IID) have the property,
in GSM or UMTS IMEIs have it (I just need the time to write an I-D).
I don't know for ESNs in USA, 3GPP2 documents are not very clear,
ESNs are a bit short and are involved into security (in this case the
3GPP has done a far better job than the 3GPP2).

Regards

PS: I already saw a case where DAD avoided a disaster: DAD *is* useful!

---

From: Francis Dupont <[email-masked]>
Date: Wed, 06 Feb 2002 16:25:26 +0100

=> I agree!

=> without DAD the result is #1, in general they are so disrupted than
at least one picks a new address and the situation recovers after
some timeouts (short timeouts in IPv6 because of NUD).

   2. Have one be disrupted

=> 2a is the best solution so DAD is good. I never got it in a real
situation for IPv4 when there is no DAD, in general the result is #1
and sometimes 2b (simply because there is someone who looks at what happens).

Regards

PS: I don't want a new DAD or not DAD discussion. I prefer a globally
unique vs. probably unique one with who should do the choice/where should
be the control, etc. I.e. more operational topics, DAD is an operational
tool, its theoretical aspect is no more than the birthday paradox (i.e.
IMHO has no interest).

---

From: Alberto García <[email-masked]>
Date: Wed, 6 Feb 2002 17:22:03 +0100

Well, in my opinion, the relevant point in this discussion is the following:
In the MIPv6 draft it has been pointed out that

What I would like to know from the mobile IP working group is if the benefit
from avoiding the interruption of the communication after a handover caused
by DAD pays for the possibility of address collision (with a computed
probability of 6 users out of 1.000.000.000 affected in a year by an address
collision if all of them perform 140 handovers per day in networks
containing 500 interfaces).

If this probability is yet considered too high, then I wonder if the
tradeoff stated in the MIPv6 draft is a strong one.

Regarding to the globaly unique vs. probably unique discussion, I agree in
general, but I do not know if this topic is enough close in time for waiting
for it. Additionally, I think that it raises some privacy concerns that
could be problematic for obtaining consensus.

Regards

> -----Mensaje original-----
> De: [email-masked]
> [mailto:[email-masked]]
> Enviado el: miércoles, 06 de febrero de 2002 16:25
> Para: Erik Nordmark
> CC: [email-masked]; [email-masked];
> [email-masked]
> Asunto: Re: [mobile-ip] draft on random interface identifiers available
>
>
>  In your previous mail you wrote:
>

---

From: Alberto García <[email-masked]>
Date: Wed, 6 Feb 2002 17:38:59 +0100

> De: Erik Nordmark [mailto:[email-masked]]
> Enviado el: miércoles, 06 de febrero de 2002 15:35
> Para: [email-masked]

If the question is how many are affected, perhaps we could also consider
that when you do perform DAD, all the mobile hosts in every handover always
suffer interruptions in their communication, while in the other case, only
the two that collide are affected. It is also true that when you perform DAD
only the mobile hosts suffer the interruption, while not performing DAD can
also affect the fixed hosts on the network.
What's the best option?

By the way, your comment suggests that DAD should be performed at least
after the handover, in order to recover the connection correponding to the
oldest host in the network, in order to reduce the damage of address
collision. However, the fact that both hosts are affected by not performing
DAD was included in the probability estimation.

Regards

---

From: Alexandru Petrescu <[email-masked]>
Date: 07 Feb 2002 10:40:34 +0100

Hi Alberto and thanks for this reflection.  I have a tangent remark
with respect to numbers, please take it as my own personal view.

> containing 500 interfaces).

This argument looks so compelling, probability results say indeed a
lot.  To be even more convincing, I think it should take into
consideration at least one other factor: 30% of the users employ a
widespread implementation of this random generator.  With this in
mind, how much should one rely on the _corectness_ of the respective
implementation comparing to how much one relies on the corectness of
probability results.

Please note that I don't question in any way the text in the draft,
people certainly had reasons when they put it there.

Alex

---

From: Pekka Savola <[email-masked]>
Date: Fri, 8 Feb 2002 17:10:35 +0200 (EET)

> http://www.ietf.org/internet-drafts/draft-soto-mobileip-random-iids-00.txt

I'll add my 0.02c even though these have probably been at least partially 
covered now.

General note about methodology: I'd suggest putting the derivation of 
probabilities into an appendix.

5.  Security Considerations.

   This draft does no introduce new security risks.  What's more, random
   generation of interface identifiers can enable improved anonymity
   features by allowing interface identifier generation each time a node
   joins a new link, what can prevents tracing.

==> Heard about privacy extensions? :-)
 
-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

---

From: "marcelo bagnulo" <[email-masked]>
Date: Fri, 8 Feb 2002 18:24:40 +0100

> De: Pekka Savola [mailto:[email-masked]]
> Enviado el: viernes, 08 de febrero de 2002 16:11

agreed, a reference to privacy extensions should be included in this
section. We should also include a reference to CGA.

thanks, m

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 12 Feb 2002 12:45:49 +0100

> The abstract is included below. Comments are welcomed.

To describe how "random generation" of interface identifiers can be
done properly, you might want to cite RFC 1750.  Due to the nature of
this, using only network traffic as a source of randomness might not
be perfect, I'm not sure if it is worth making a note of this.

---

From: Ignacio Soto Campos <[email-masked]>
Date: Tue, 12 Feb 2002 20:43:12 +0100

Hi Simon,

> done properly, you might want to cite RFC 1750.  Due to the nature of

Yes, you are right, this RFC about how to generate random numbers
is interesting information for our draft.

Thanks for your feedback.

Ignacio