Re: I-D Action: draft-ietf-6man-default-iids-04.txt

[Mark Smith <[e-mail]>]

On 11 July 2015 at 14:13, Christian Huitema <[e-mail]> wrote:
> On Friday, July 10, 2015 1:41 PM, Brian E Carpenter wrote:
>
>>> How do you see RFC 7217 playing into the above? One of the arguments
>>> for that draft was that network security folks wanted stable, but not
>>> EUI-64-based, IPv6 addresses for things like ACLs. Randomizing MAC
>>> addresses, and then re-generating the corresponding IPv6 addresses,
>>> seems to take us back to the RFC 4941 state-of-the-art.
>>
>> It's a dilemma. As far as I can see, there's a real difference between end-user systems (even
>> within an enterprise network), where privacy arguments might dominate, and servers, where
>> stability and ACL arguments might dominate. I'm thinking that for privacy-sensitive systems,
>> we'll have to use a firewall penetration solution rather than ACLs.
>
> I think we need to educate the enterprise IT managers. Right now, they consider only one facet of the problem, the need to manage a variety of devices. So they make sure that devices have stables addresses, because using these as stable identifiers is very convenient. But then, by doing that, they also facilitate tracking of these device's traffic outside the enterprise, which is the other facet of the problem.  And I am afraid that IT managers are not taking that second facet in consideration.
>
> One possibility is to have devices with different behaviors "inside" and "outside." For example, use a stable MAC address at the office, and a random one on the road. That solves some of the problem, but the stable addresses can still be tracked if the user does TCP connections "from the inside to the outside."
>

I think Multipath TCP would make this a much harder problem when using
mobile multihomed hosts e.g., smartphones. Application MPTCP
connections can survive crossing from "inside" to "outside" and
vice-versa.

A stable "Inside" identifier can be correlated with random "outside"
identifiers either via concurrent MPTCP subflows that use the same 32
bit MPTCP token, across different networks, or when the host's
addresses are announced to the MPTCP peer via MPTCP optons, even if
the "inside" address/identifier isn't reachable by the MPTCP peer.

Using global MAC addresses as asset numbers won't be a reliable as it
used to be, as they're not as globally unique as they would have been
in the past. Based on some research HD Moore did a couple of years
ago, there are more 6 million instances of one "globally unique" MAC
address, and 4 other instances where a "globally unique" MAC address
has been duplicated more and many more than 100 000 times. Summary of
the top 10 occurrences here:

https://www.ietf.org/mail-archive/web/ipv6/current/msg17109.html

It would be more reliable for enterprises to be assigning their own
device asset numbers/identifiers rather than relying on manufacturer
assigned ones. I think it would be best that these asset
numbers/identifiers are at a layer above IP, so that if IP addresses
or MAC addresses change or aren't unique for any reason, the
identity/asset number of the device doesn't change.

Regards,
Mark.







> -- Christian Huitema
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------