Re: RFC8064 implemented in linux ?

[Mark Smith <[e-mail]>]

On Sat., 29 Jun. 2019, 02:36 Martin Hunek, <[e-mail]> 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.
>

It's intended to be implemented on all SLAAC implementations, not just
hosts.

That includes routers, and it explicitly includes Link Local addresses.

That is so that Link Local addresses of routers are both auto-generated and
stable across interface module swaps.




> I can see need for privacy with global addresses


RFC8064 (indirectly RFC 7217) is not about privacy addresses.

They're the opposite use case - persistent, stable addresses, entirely
independent of or only loosely coupled to hardware e.g. device backplane
slot.


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. Reactions to reasons from RFC8064:
> As network operator, I can still correlate network activity by accounting
> in RADIUS or just mirror access port and track it based on L2 addresses.
> There is no location tracking possible with LL address as prefix fe80::
> would not tell any more or less about location with or without randomized
> suffix. Address scanning is still not needed as all I need is ask at all
> nodes multicast address and I get a list of addresses in local segment.
> Only real reason why I would like to hide device vendor+model is so called
> "device-specific vulnerability exploitation". But still I can just listen
> on the line waiting for traffic and then just connect to port 80 or 443 and
> it would just happily tell. But OK, if someone thinks that it is really
> needed and that it would be beneficial to cover vendor+model instead of
> doing proper firewall...
>
> 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. You could argue that there
> is DUID for that and you would be right - in theory. But I have seen
> routers which generated random DUID on every boot (UBNT), that of course
> was major problem so only static thing left was LL address, which was
> EUI64. Other thing I seen were custom DHCPv6-PD hooks, which extracted MAC
> from some DUID types, made LL address from that and placed record for
> delegated prefix paired with computed LL address as destination. And I've
> seen clients which hides DUID so well that easiest way how to get it is
> packet snooping and manual link reset.
>
> So when there would not be predictable LL address on WAN interface, I
> would not be able to make static routing records in routing table based on
> value written on customer CPE - the MAC address. So no more prefix
> reservation based on phone customer support, we would have to go trough
> provisioning of CPE prior installation.
>
> Another "solution" would be to make dynamic routing table and when I'm
> giving customer /56, I can reduce it to /120 so I can encode 64b of random
> ID into prefix. Hopefully just an idea for April fool's RFC:
>
> Address scheme would than look like:
> /29 from RIR -> 3b for MANs
> /32 for my MAN -> 8b for POPs
> /40 for POP -> 8b for interface+VLAN
> /48 for interface/VLAN -> 64b left for client LL suffix to provide static
> pool
> /112 would be max prefix length for customer or /120 when "legacy" devices
> on segment.
>
> All that because router could get tracked on local link? By whom? Network
> operator would still be able to track every connection and they often must
> by law. By the way network operator still must be able to deliver packets
> to router so it needs to keep track of router's addresses/prefixes. Only
> real "benefit" RFC8064 brings to network operators would be a headache.
>
> Because similar privacy related solution we are actually forced to go from
> SLAAC to DHCPv6 for server addresses because we cannot tell what IPv6
> address server would have, so either no AAAA+PTR records (DDNS is not an
> option) or we would have to provision every server to use EUI64.
>
> Long story short, RFC8064 needs a bis that it MUST NOT be used on routers.
> Otherwise it could bring real problems to real networks. All for purely
> theoretical issue router could have with its privacy.
>
> I hope that I didn't offend anyone, I couldn't help myself.
>
> Regards,
> Martin
>
> PS: If you read it up to this point, than you are real good. :-)
>
> Dne pátek 28. června 2019 13:49:29 CEST, Alexandre Petrescu napsal(a):
> > Is RFC8064 implemented in linux, with kernels 4.x, on openwrt? (in
> > addition to BSD).
> >
> > I am asking because the IPWAVE WG IPv6-over-OCB document is not
> > implemented in BSD. IPv6-over-OCB is implemented extensively on linux.
> >
> > The IPv6-over-OCB document suggests a 'transition time' to migrate from
> > current embedded platforms that do LL addresses formed from hardwired
> > MAC addresses (linux kernel 4.x openwrt) to future software where the LL
> > addresses are formed from more random IID (RFC8064).
> >
> > The Transport Area review of this document demands a value for this
> > 'transition time'.  My speculation, without knowing the current
> > implementation status of RFC8064 on openwrt with kernels 4.x, is that
> > the value of 'transition time' nears 5 years.
> >
> > Alex
> >
> >
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>