Subject: [rrg] ILNP Identifiers

From: RJ Atkinson <[email-masked]>
Date: Mon, 14 Jun 2010 10:30:36 -0400

(META: I've corrected the Subject to actually describe the
topic of this note.  I wish more people would do the
same -- so that Subject: lines reflect the actual topic
discussed by the note. :-)

1) As Joel and Tony have already noted, there is never a
requirement to use local-scope Identifier values.

2) Local-scope Identifier values exist only because there
are some (relatively small) user communities that desire
to use non-global Identifiers of various kinds.

3) The EUI-64 syntax is carefully designed to make it easy
to distinguish a local-scope Identifier from a global-scope
Identifier, so there is no protocol issue lurking here.

DISCUSSION:

Now, all that said, I don't see why this is suddenly
confusing to anyone.  All of the above is also true 
for IPv6 Interface Identifiers, which are also based 
on EUI-64, have some deployment.  Separately, IPv6
is purportedly widely understood and apparently has
some growing deployment.

In fact, the big difference between IPv6 and ILNPv6
(or ILNPv4 which also uses EUI-64 Identifiers) is that
the Identifier names the *interface* for IPv6, and
names the *node* for ILNP.  This semantic change is
absolutely crucial, because this change is what permits
IP sessions to remain up even though a correspondent
node's subnetwork point of attachment (SNPA) changes.

Clearly, node mobility is hugely simpler when a
global-scope ID value is used.  The ILNP specifications
say that normally a global-scope ID is used, while
allowing individuals that want to use some local-scope
ID to do so.  Again, no one is ever required to use
a local-scope ID value.

That noted, mobility can work fine with a local-scope 
ID, because the session Nonce permits differentiation 
of different nodes using the same (e.g. local-scope) 
ID values.  Implementations of ILNP are required to use 
cryptographically-random Nonce values, so an off-path 
attacker won't be able to predict a nonce value externally.

Existing IPv4 and IPv6, including Mobile IPv4/IPv6, 
are vulnerable to a wide range of on-path attacks 
unless IPsec is used to protect the IP session.  IPsec 
for ILNP works well even in the presence of changed 
node location, unlike currently deployed IPsec, and 
can be used to eliminate the threat of an on-path attacker.  
So there is no loss of security in moving from IP to ILNP,
or in moving from Mobile IPv* to ILNP mobility, or 
in moving from existing multi-homing methods to
ILNP multi-homing methods.

Yours,

Ran Atkinson

---

From: Dae Young KIM <[email-masked]>
Date: Tue, 15 Jun 2010 08:50:47 +0900

On Mon, Jun 14, 2010 at 11:30 PM, RJ Atkinson <[email-masked]> wrote:
> confusing to anyone.

Hi, Ran,

Thanks for the re-summary. At least, I didn't say it confusing. It was
only that I misunderstood the possible locality scope of identifier,
the scope being a locator(subnet) not a site.

> attacker won't be able to predict a nonce value externally.

In this scenario, do you also mean a case when the node moves off its
original subnet around in a given site or even across sites?

I think that's even possible even with such a local ID since

   o EUI-64 is rarely duplicate, and even in such a case
   o the Nonce will distinguish connections with the same value of endpoint ID.

If this should be possible, I'd rather use local ID, for then I could
eliminate one infrastructural element managing/governing/distributing
the global IDs.

-- 
DY

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 14 Jun 2010 20:14:32 -0400

On 14  Jun 2010, at 19:50 , Dae Young KIM wrote:
>  I'd rather use local ID, for then I could

There is no "management" needed for global-scope IDs.
Similarly, there is no need to distribute them as
they are normally built-in at the factory today
(and for the past 20 years or so).  Also, governance
is equally not an issue.

Pretty much every computing device anyone has today, 
even the hand-held ones, already have at least one 
IEEE EUI-64 in them, burned into ROM at the factory.  

This is one of the reasons that global-scope EUI-64 
values are the ideal source of node Identity.

If a device already has (for example -- this is NOT
an exhaustive list) either a wired Ethernet port,
a wireless Ethernet port, other IEEE 802.* port,
Bluetooth port, or mobile telephone interface
(CDMA or GSM), then the device already has its own
EUI-64 (or most probably a few of EUI-64 values).

Yours,

Ran

---

From: Dae Young KIM <[email-masked]>
Date: Tue, 15 Jun 2010 09:25:47 +0900

> EUI-64 (or most probably a few of EUI-64 values).

Aha.. Then, you meatn EUI-64 by your global ID. You could have just
said that more clearly.

And perhaps you also mean,

   - If, in a very rare case of EUI-64 collision due to mal-practice
of some manufacturers, you could distinguish the connections thanks to
the nonce.

   - By a local ID, you rather mean the case where users would use
other ID values than EUI-64.

Correct?

-- 
DY

---

From: Dae Young KIM <[email-masked]>
Date: Tue, 15 Jun 2010 09:28:43 +0900

> Aha.. Then, you meatn EUI-64 by your global ID. You could have just

Like

  "ILNP usese EUI-64 numbers as global IDs."

-- 
DY