RFC 7217 ("A Method for Generating Semantically Opaque Interface
Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)") is
sort of relevant. From the introduction of that document, which
describes drawbacks of traditional IPv6 SLAAC addresses:
o Since the resulting Interface Identifiers are constant across
networks, the resulting IPv6 addresses can be leveraged to track
and correlate the activity of a host across multiple networks
(e.g., track and correlate the activities of a typical client
connecting to the public Internet from different locations), thus
negatively affecting the privacy of users.
That drawback translates pretty much directly to the 48-bit MAC
CLIENT-IDENTIFIER variant in draft-tale-dnsop-edns0-clientid.
For the dnsmasq use case, I would guess there's a CPE router/gateway
device involved, in which case the CPE device has a unique
device-specific value burned in (e.g., a WAN-facing MAC address, or
serial number) which could easily be hashed together with the client's
MAC address to produce a stable but opaque identifier specific to the
particular CPE device involved. (That is, if the client device travels
to a different network gatewayed by a CPE device implementing the same
scheme, the identifier generated would be different, because the CPE
device has a different WAN-facing MAC address.) So, the cloud would
still wind up executing the PII -> policy translation, but you take the
'P' out of 'PII', and don't need to store any extra state on the CPE
device.
Ted Lemon wrote:
> It would be nice if there were an RFC to point to that used a method that
> didn't include PII. For the use cases of which I am ware, there is no
> need to identify individual devices: only policies. What's lacking is a
> way to do this in the home router, so the PII winds up getting exported to
> the cloud not because that's necessary to accomplish the filtering but
> because it's the only available place where the translation from
> PII->policy can be done in practice. Unfortunately, solving _that_
> problem is definitely out of scope for DNSOP.
>
> On Thu, Jul 20, 2017 at 7:00 PM, George Michaelson <g...@algebras.org> wrote:
>
> > I probably will not carry the WG with me on this, but I find myself
> > thinking the PII aspect of client-ID makes it a wider-internet
> > question and we might have views as a WG, and promote questions as a
> > WG, but I think the "final call" on this is something which needs more
> > than WG approval.
> >
> > Its a big question. I'd actually welcome adoption on many levels, but
> > that isn't to pre-empt that it goes to WGLC. I think we need to
> > formalize the issues and take them out of the WG for review and
> > discussion.
> >
> > documenting current practice is ok btw, but .. PII.
> >
> > -G
> >
> > _______________________________________________
> > DNSOP mailing list
> > DNSOP@ietf.org
> > https://www.ietf.org/mailman/listinfo/dnsop
> >
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
--
Robert Edmonds
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
