Subject: Re: [6lowpan] SLLA option in NS

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 1 Jun 2010 08:59:47 +0200

Hi Erik

> I don't see how the additional complexity of oDAD makes anything
different
> in 6lowpans; as I stated in an earlier email I think it is impossible
to detect
> duplicate EUI-64's in a 6lowpan.

[Pascal] Yes,  I've read that part and I'm afraid I partially disagree.
Partially because it depends what you're fighting against. To fight
against attacks is difficult and probably requires crypto.
OTOH, if the most probably cause of dups is  erroneous config or forged
hardware, and we are looking at preventing that sort of error, then a
simple boot-time random can help tremendously.
The simplest method is to place the boot-time random in all
registrations. A registration with the wrong random fails. More complex,
and slightly more secure, place it in the first registration and then
include it in a signature.
The consequence is that a device with no permanent memory that reboots
will have to wait for the end of its current registration before it can
reregister.
Once we detect the error, the real trouble is to define the backup
strategy. What does the node do then?

Pascal

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 01 Jun 2010 00:19:38 -0700

On 05/31/10 11:59 PM, Pascal Thubert (pthubert) wrote:
> registrations. A registration with the wrong random fails.

So a host with EUI-64=X boots, and uses boot-time-random=Y. Registers 
with a lifetime of say three days.
Then the host is rebooted, comes back up and uses boot-time-random=Z.

Then it will fail to register its EUI-64-based, since it will be a 
duplicate.

The issue is that the information used to identify the node (to tell two 
nodes apart) must be in stable storage.
That probably means that a spoofed/cloned host would duplicate that 
information as well.

Hence adding more information doesn't seem to help.

> More complex,

That seems broken. One could envision a scheme where the first 
registration involves creating some key that becomes shared between the 
host and the network. But such a case I think we MUST require that they 
key be stored in stable storage on both the host and the routers.

But before we embark on creating some new and complex scheme for doing 
this, it would make sense to understand the security aspects of the 
whole network. It might not make any sense to merely try to secure the 
DAD and the registrations, if the L2 network is completely open. And if 
the L2 network is secure, then it might not add anything to try to 
secure the DAD/registrations.

> strategy. What does the node do then?

If DAD fails for a short address, then the host should try a different 
short address. Ditto if it is a RFC 4941 temporary address.

    Erik

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 1 Jun 2010 13:23:31 +0200

Hi Erik

> > OTOH, if the most probably cause of dups is  erroneous config or
> > forged hardware, and we are looking at preventing that sort of
error,
> > then a simple boot-time random can help tremendously.
with
> a lifetime of say three days.
duplicate.
> 
> The issue is that the information used to identify the node (to tell
two nodes
> apart) must be in stable storage.
> > will have to wait for the end of its current registration before it
> > can reregister.
> 
registration
> involves creating some key that becomes shared between the host and
the
> network. But such a case I think we MUST require that they key be
stored in
> stable storage on both the host and the routers.

[Pascal] In the simplest instance I expected to use the rnd as a simple
correlator, though.
But if it helps to call it a key let's call it that way. We seem to have
problems with agreeing on names :)

> this, it would make sense to understand the security aspects of the
whole
> network. It might not make any sense to merely try to secure the DAD
and
> the registrations, if the L2 network is completely open. And if the L2
network
> is secure, then it might not add anything to try to secure the
> DAD/registrations.
> 
short
> address. Ditto if it is a RFC 4941 temporary address.

[Pascal] I was asking about the EUI-64 based address. A node registers,
and the router says no.
Like I said, most probable cause are misconfig and silicon forgery.
What's next for this node?

Seems to me that the devices can use a random 64-bit Identifier and try
again, at least to be able to notify.

Pascal

---

From: Yoav Ben-Yehezkel <[email-masked]>
Date: Tue, 1 Jun 2010 14:39:20 +0300

Hi,

The think I don't understand is why would the registration of a node with
specific EUI-64 would be responded with a router saying no?

A node that resets without NVM would do just that (register with same
EUI-64 that the router has) - shouldn't the router provide it with the
same short address it assigned it before?

Thanks,
Yoav

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Pascal Thubert (pthubert)
Sent: Tuesday, June 01, 2010 2:24 PM
To: Erik Nordmark
Cc: [email-masked]
Subject: Re: [6lowpan] SLLA option in NS

Hi Erik

error,
with
duplicate.
two nodes
registration
the
stored in

whole
and
network
short

Pascal
_______________________________________________
6lowpan mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/6lowpan

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 01 Jun 2010 05:00:11 -0700

On 06/ 1/10 04:23 AM, Pascal Thubert (pthubert) wrote:

 >> [...]

I think you are missing or ignoring my point about stable storage. That 
is the key point - not the name.

> [Pascal] I was asking about the EUI-64 based address. A node registers,

Please read 6lowpan-nd-09.

A 6LR doesn't say no for an EUI-64 based address because we assumes 
EUI-64 are globally unique, hence no duplicates can exist by definition.

And as I outlined in an email earlier, I believe forgeries/spoofs/clones 
are undetectable in 6lowpan networks.

> Like I said, most probable cause are misconfig and silicon forgery.

The EUI-64 shouldn't be configurable; it should come from the factory.

    Erik

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 1 Jun 2010 15:26:43 +0200

Erik, 

We're in a loop. 

I thought you agreed that a random (that you called a key) was a simple
and good enough tool to differentiate 2 nodes that would be using a same
address, EUI based or not.

We agree that the random (key) would be better stored in persistent
memory, whenever possible.

I agree with your point that the node does not need to know what the LR
does with the LBR, that's backend stuff.

I agree with your other point that the LR can respond quickly yes to
registration and then kill it later for a number of reasons.

My point is that one such reason could be that a back end check  with
the LBR says that this address is a actually a dup, as detected by a
different random.

Pascal

> From: Erik Nordmark [mailto:[email-masked]]
> Sent: Tuesday, June 01, 2010 2:00 PM
> To: Pascal Thubert (pthubert)
> Cc: Tetsuya Murakami; [email-masked]
> > [Pascal] In the simplest instance I expected to use the rnd as a
> > simple correlator, though.
> > But if it helps to call it a key let's call it that way. We seem to
> > have problems with agreeing on names :)
> 
> I think you are missing or ignoring my point about stable storage.
That is the
> key point - not the name.
> 
> > [Pascal] I was asking about the EUI-64 based address. A node
> > registers, and the router says no.
> 
> And as I outlined in an email earlier, I believe
forgeries/spoofs/clones are
> undetectable in 6lowpan networks.
>

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 01 Jun 2010 10:29:51 -0700

> address, EUI based or not.

Incorrect. I said I see no benefit in adding any random bits.

    Erik