Re: 6man w.g. last call for <draft-ietf-6man-default-iids-11.txt>

[Lorenzo Colitti <[e-mail]>]

Brian,

I will concede that there might be theoretical threats involving ephemeral
link layer addresses and non-IP protocols that we have not yet thought of.
However, the key thing to note is that even if these threats exist, their
impact is limited in time. By contrast, any threat involving a stable IP
address, in addition to being much easier to carry out because it's
available off-link, causes permanent impact because the stable address
never changes.

So if you think about it, your argument is actually in favour of link layer
address randomization, not against it. Assuming that the link layer address
will leak sometimes (here's a real-world example that's affects a lot more
people than IPX: captive portal redirect URLs that contain the MAC address
in the clear), it's much safer for that link address to be ephemeral than
to be permanent.

As to your statement that "whether people use stable IIDs is an operational
choice we can only leave to site operators" - this document is not leaving
it to site operators.

Let's all always keep in mind that the current text of the draft says that
on every network, hosts SHOULD configure an IPv6 address that never changes
until the end of time. I think that recommendation is irresponsible.

Cheers,
Lorenzo

On Fri, May 20, 2016 at 5:43 AM, Brian E Carpenter <
[e-mail]> wrote:

> On 19/05/2016 18:10, Lorenzo Colitti wrote:
> > On Thu, May 19, 2016 at 2:19 PM, Alissa Cooper <[e-mail]>
> wrote:
> >
> >> The draft makes just about a clear a statement in this vein as is
> possible:
> >>
> >> "By default, nodes SHOULD NOT employ IPv6 address generation schemes
> >>    that embed the underlying link-layer address in the IID.”
> >>
> >> Note that this statement does not prohibit anything, nor does it make a
> >> normative (in the moral sense) judgment. It just states the
> recommendation,
> >> which is the point of the document.
> >>
> >> I appreciate that not everyone on the list agrees with this
> >> recommendation. But I find the claim that this recommendation is
> unclear to
> >> be difficult to understand. That is, I can’t think of a way to convey
> the
> >> same recommendation that would be clearer. If you can, please suggest
> text.
> >>
> >
> > Alissa,
> >
> > I don't think anybody is claiming that the recommendation itself is
> > difficult to understand. What is difficult to understand is how the
> > document justifies that claim.
> >
> > It looks like the main argument used to justify this recommendation is
> > major privacy risks. But embedding a link layer identifier into an IP
> > address is not a major [1] privacy risk. It is only embedding a *STABLE*
> > link-layer address that is a major privacy risk.
> >
> > Recommending that link-layer address be embedded only if they are
> ephemeral
> > would address the privacy concerns just as well as (or maybe even better)
> > than the approach proposed in this document.
> >
> > I think what people are do not understand is why this document recommends
> > one but not the other. I certainly don't.
> >
> > Cheers,
> > Lorenzo
> >
> > [1] I argue that cross-referencing IPX traffic to IP traffic is not a
> major
> > privacy risk because IPX is so uncommon.
>
> I only chose that example because it's an obvious one. Do we know all the
> contexts
> in which a MAC address may appear in an off-link packet? I doubt it.
>
> A privacy risk doesn't have to be "major" to be important. If we are
> concerned
> about massive-scale surveillance, where the opponent is using Hadoop and
> machine
> learning technologies to glean information, minor risks become
> significant. So
> I support the draft as it stands: any case in which a layer 2 identifier is
> embedded *in clear* in a higher layer identifier is a bad thing, even if
> it's
> a temporary and pseudo-random bit string.
>
> [I hadn't remembered that RFC1958 already said that ;-)]
>
> I think this is completely orthogonal to whether stable IIDs should be used
> by clients at all - that's an operational choice that we can only leave to
> site
> operators.
>
> Regards
>    Brian
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>