Re: RFC8064 implemented in linux ?

[Fernando Gont <[e-mail]>]

Hello, Martin,

On 2/7/19 15:53, Martin Hunek wrote:
> Dne úterý 2. července 2019 14:39:34 CEST jste napsal(a):
>> On 28/6/19 17:35, Martin Hunek wrote:
>>> Hi Alex, hi all,
>>> 
>>> I hope that this mail would not be breach to Code of Conduct,
>>> but this is straight from network's operator heart. :-)
>>> 
>>> I hope that RFC8064 would never be implemented on any router. As 
>>> would be operational nightmare.
>>> 
>>> I can see need for privacy with global addresses as it is clear
>>> that individuals could be easily tracked over the internet when
>>> using EUI-64 suffixes. It is not so obvious with stationary
>>> servers, but OK - you could remotely detect vendor and model of
>>> hardware, so yes if you really need to hide that it is
>>> reasonable.
>>> 
>>> When client need to generate LL address with other method then 
>>> EUI-64, that is for me hard to grasp.
>> 
>> Using predictable numeric identifiers is bad practice. See e.g.: 
>> https://tools.ietf.org/html/draft-gont-predictable-numeric-ids-03
>> 
> Sorry, but this is your opinion not a fact. What is the thread of
> predictable IID used in *Link-Local* address?

What the referenced I-D shows is that whenever we have employed
predictable IDs, that has led to problems. That is a fact, not opinion.

And the fact that we have had to fix each numeric ID in each protocol
piecemeal is a sad story we should learn from, rather than something we
want to repeat.



> I can see reasons behind not using EUI-64 together with global
> addresses but not with LLs. There is no point of hiding LL address
> from your operator. I can still get both MAC and LL address, but
> instead of just taking picture of MAC sticker on your CPE (or from
> DHCPv4), I would need to eavesdrop on your line. I can imagine that
> it would be more of the privacy breach, than knowing your CPE LL
> address from your MAC...

I assume you are referring only to routers, right? -- Because Windows
has not employed the traditional SLAAC scheme (embedding mac addresses
in the IID) for a long time.




>>> Lastly the case of router (OpenWRT): Why would I need to use
>>> anything else than EUI-64? As network operator I need address
>>> that is static (on WAN interface at least), so I can do reliable
>>> static leases if customer wants them.
>> 
>> Not sure what you are referring to. LLs are not leased. RFC8064 is
>> about *autoconfigured* addresses.
>> 
> Sure the LL addresses are not leased, but network prefix is leased to
> them. At least that is a result of either DHCPv6-PD or manual lease
> in the routing table.

If the DUID is based on the MAC address, why would you care about the LL
address, anyway?




>> Besides, RFC7217 addresses are meant to be stable. Depending on
>> the implementation, they may even be stale across NIC
>> swaps/replacement.
>> 
> If every device on link would use a same method, which would allow to
> predict with absolute probability, LL address based on MAC address
> and maybe some other variables known to operator (as in EUI-64 case),
> I would have nothing against that.
> 
> But in case of RFC7217 there is: F(): Unknown to operator because
> every implementation can use different hash function. Prefix: Known
> to operator. Net_Iface: Unknown to operator. Network_ID: Known for
> WAN link to operator. DAD_Counter: Known to be initially 0. 
> secret_key: Pseudorandom - unknown to operator.
> 
> F(), Net_Iface could be somehow guested when you know MAC address so
> you know vendor + model if you also know software version. But there
> is still secret_key. So as network operator I'm not capable to say
> which LL address device would have just by looking on the box and
> reading MAC address from it. I would need to unbox it, connect it to
> network and read its address from wireshark.

If for some reason you use some other algorithm (e.g., the traditional
one) to generate addresses, override the default.


> Long story short, back in days prior any privacy addresses where all
> IIDs fould be generated by EUI-64, I would be able to tell which
> address would be used by which device. This makes process of doing
> manual entries to routing table easy. When you know which prefix you
> want to assign to CPE and you know CPE's MAC you know also CPE's LL
> address and it is all you need to make record in routing table. With
> RFC8064 and BYOD policy you are screwed.

You might consider this a feature. The goal is indeed to improve privacy
by default.


-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492