Subject: [Roll] privacy enhanced l2 addresses and parent selection in ROLL

From: Michael Richardson <[email-masked]>
Date: Tue, 19 Jul 2016 09:29:31 -0400

Pascal spoke today in 6man concerning the process of providing privacy
enhanced addresses in 6man, and how LLNs typically use their 2-byte short
addresses for layer-2, and also for forming L3 addresses.
Pascal mentioned that 2-byte addresses can be dhcpv6 assigned and therefore
unrelated to the EUI-64.  (Of course, many just use the bottom two bytes of
the EUI-64, and don't do DAD or ND at all.. Let's agree they are not to spec)

I was thinking about the dhcpv6 process.  In order to do it in a route-over
mesh, the route-over mesh needs to be up in order to get traffic to the
DHCPv6 server.  That means that the DAG has been formed using EUI-64 derived
link local addresses.

Afterward, the 6LNs will allocate a 2-byte v6 address from the dhcpv6 server,
and will then set their L2 address based upon that.    I think that this is
not specified anywhere...?

But, the thing that got to write this email (while doing my IETF96 laundry),
is the parent selection process.  Do we need to have a way for an RPL parent
to say in it's DIO, "I know you see me as fe80::1234, but you knew me before
as fe80::1234:56fe:ff78:abcd", such that there could be a seamless and
efficient transition to the new 2-byte addresses?

Perhaps it's good enough that the node, having been allocated a 2-byte L2
address, does a gratitous NA where it announces it's EUI64 LL address with
it's 2-byte L2 address?  How does that sit security-wise?  Have we just
encouraged the network to accept gratuitous L2 address spoofing?

How does this interact with Back-Bone Router EARO processing?

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Robert Moskowitz <[email-masked]>
Date: Tue, 19 Jul 2016 16:32:12 +0200

If the transition can be augmented by an ephemeral public key, and some 
parameters, perhaps, in dhcpv6, this could work as you indicated in a 
safe manner.

On 07/19/2016 03:29 PM, Michael Richardson wrote:
> _______________________________________________
> 6lo mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lo

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 19 Jul 2016 14:57:34 +0000

For the sake of things I said assigned and said that this assignment plays the role that was expected from DHCP but not really delivered of getting temporary addresses. 

The rest is my French: Using DHCP to assign them is interesting but beyond my intent.

Regards,

Pascal

> Le 19 juil. 2016 à 16:05, Michael Richardson <[email-masked]> a écrit :
> 
>

---

From: Paul Duffy <[email-masked]>
Date: Wed, 20 Jul 2016 13:27:08 +0200

> DHCPv6 server.  That means that the DAG has been formed using EUI-64 derived

Confirming.  Assuming non storing RPL ... are you thinking the LBR is 
maintaining the DAG with link local addresses?

---

From: Michael Richardson <[email-masked]>
Date: Wed, 20 Jul 2016 07:49:24 -0400

Robert Moskowitz <[email-masked]> wrote:
    > If the transition can be augmented by an ephemeral public key, and
    > some parameters, perhaps, in dhcpv6, this could work as you indicated
    > in a safe manner.

If we are doing per-link keying, and we transition our address, and we can
propogate the L2-security upwards, then I agree that this transition could be
secured.   I'm still thinking that we might need a L3-RPL level signal
which would be secured.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 21 Jul 2016 04:32:39 -0400

{following up to roll only}

    > maintaining the DAG with link local addresses?

No, I'm not. I'm thinking that it maintains it wants to ultimately record
using GUA addresses which are derived from 2-byte short link-layer addresses.

Giving an example from my test setup:

parent with (ethernet, not 802.15.4 EUI48 of 10:00:00:64:64:23)
parent# ip -6 route show
        2001:db8:1:0:1200:ff:fe66:6602 via fe80::1000:ff:fe66:6602 dev eth1
                            src 2001:db8:1:0:1200:ff:fe64:6423  metric 1024

child with (ethernet, not 802.15.4 EUI48 of 10:00:00:66:66:02)
child# ip -6 route show
      2001:db8:1::/48 via fe80::1000:ff:fe64:6423 dev eth1
                      src 2001:db8:1:0:1200:ff:fe66:6602  metric 1024

(this is a non-grounded DODAG, so no default route, just a route to
the prefix announced)

I would expect a non-storing implementation (which I don't have yet) to look
something like this on the parent:

dagroot# ip -6 route show
        2001:db8:1:0:1200:ff:fe66:6602
                            via fe80::1000:ff:fe66:6602,
                                2001:db8:1:0:1000:ff:fe66:7702,
                                2001:db8:1:0:1000:ff:fe88:9902
                            dev eth1
                            src 2001:db8:1:0:1200:ff:fe64:6423  metric 1024

The point is that once "parent" gets itself a 2-byte short address, and
generates some new LL and GUA addresses, I would expect this to look like:

parent# ip -6 route show
        2001:db8:1::6602 via fe80::6602 dev eth1
                            src 2001:db8:1::6423  metric 1024

child# ip -6 route show
      2001:db8:1::/48 via fe80::6423 dev eth1
                      src 2001:db8:1::6602  metric 1024

So I'm asking if we need to do something to *encourage* this transition, or
the trickle refresh is enough; to get the child to pick the short-form of the
parent, we might have to consider the short form "better" from a parent
selection point of view.  That would be a parent change, and that might
trigger unnecessary DAOs, yet this is not actually a parent change.