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

[Mark Smith <[e-mail]>]

On 14 May 2016 1:29 PM, "Lorenzo Colitti" <[e-mail]> wrote:
>
> On Sat, May 14, 2016 at 12:00 PM, Brian E Carpenter <
[e-mail]> wrote:
>>
>> Because if someone is trying to correlate different types of my traffic,
>> let's say something sent over IPX and something sent over IPv6, the task
>> will be made easier if the lower 48 bits are the same in both types of
>> traffic. (Obviously, someone on-link can use ND to correlate MAC address
>> and IP address, so we're talking about someone observing off-link
packets.)
>
>
> That seems extremely unlikely to happen in practice, given that the vast
majority of hosts either don't have an IPX stack at all or have it disabled
by default, and embedding a MAC address in a protocol payload is not very
useful so people tend not to do it.
>
> By contrast, here is one weakness that is pretty much mandated by this
draft as written: because addresses have to be stable, any remote attacker
anywhere on the Internet that ever exchanges a packet with that host can
track it every time the host visits the same network, *forever*, with no
recourse. Section 3 point 1.
>

Already fixed, RFC6724:

"5. Changed the default recommendation for Source Address Selection Rule 7
to prefer temporary addresses rather than public addresses, while providing
an administrative override (in addition to the application-specific
override that was already specified). This change was made because of the
increasing importance of privacy considerations, as well as the fact that
widely deployed implementations have preferred temporary addresses for many
years without major application issues."

Most hosts that will use these addresses as source addresses for their
packets are unlikely to move around and will value stability - servers
providing services to clients and router and other infrastructure devices'
interfaces.

If a client hosts use these types of addresses for their out bound
connection source addresses, then privacy addresses have been actively
switched off for some reason or are not and have never been available (e.g.
router interfaces). In other words, a conscious choice has been made to
disable privacy. That may or may not be a good idea in that context and in
others' external opinion, however we can't stop people doing stupid things,
we've just got to encourage them to do the right thing either implicitly or
explicitly by choosing good defaults.

This is a better default than EUI-64 based IIDs for when privacy addresses
aren't used or available (by choice).

Regards,
Mark.

> Either we fix that or we stop asserting that this draft is motivated by
privacy considerations.
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>