Re: [STDS-802-Privacy] IPv6 Privacy addressing resource issues
Hi Pascal,
Thanks for your detailed reply - you've highlight a number of important resource consumption issues.
Responses inline.
On 2 Oct 2014, at 10:06, Pascal Thubert (pthubert) wrote:
> Hi Piers,
>
> I expected that you were alluding to that thread. You'll note that the IETF has reacted to that sort of issue, that was injected by RFC 4941, with the new recommendations in RFC 7217. With the new rule, the IPv6 address would be opaque, the IID (the host piece) would depend on both the MAC address and the subnet in a non-reversible fashion. This was, the node has a stable IPv6 address in a given subnet, even if it comes and goes, sleeps or wakes up.
>
I knew of RFC7217 but I wasn't aware of many clients that have implemented it. It seems that RFC4941 is pretty prevalent these days - I've seen it in iOS, and its been in Desktop OSes for a long time.
> This behavior is critical to keep the network stable. Let us see why in more details:
>
> Over the years, and for reasons related to security, authorization and broadcast storms control, work such as SAVI at the IETF has led to the addition of more and more state in the network. That state relates the MAC address with all sort of other information, including location (which switch, which port), addressing (which IPv4 and IPv6 addresses), authorization (that MAC address is authorized in the network and can be used to perform such and such actions) etc...
>
I'm not familiar with SAVI - But after a brief look at RFC7039 it seems that a SAVI binding anchor may take the form of a wireless security association which could be independent of the MAC address.
> This information is used for instance to cancel harmful multicast over the wireless medium, such as address lookups, that are effectively flooded to all nodes at the lowest possible speed, even though in theory they could be limited for IPv6 to multicast groups. Multicast cancellation in the switches and wireless controllers fabric is critical today to maintain wireless stable in large L2 domains.
>
Yes I understand that broadcast and multicast can be quite a problem - as you say it typically uses a lower symbol rate which uses up more network time slots.
> The role of a SAVI switch is in particular to prevent the theft of an address by a third party node, typically identified by its MAC address. If the node changes its MAC address but an IP address is conserved (one OS is known to reform an RFC4941 address daily, but will keep that address valid for a week), implementations that are deployed today by multiple switch vendors may respond improperly to what looks like an appropriation attack by another node and drop the traffic.
>
This last issue is something that would be useful to understand when and how often it might occur.
> If a node goes to sleep, and refreshes all its IP and MAC addresses at the same time when it wakes up, the switch fabric will just see a brand new node and will mostly be transparent. If the practice generalizes, though, devices going to sleep very frequently will end up clogging the SAVI tables in the switches, again leading to denial of service. As the article points out, TCAM entries are expensive and limited resources. So rapidly, there will be a need that the device notifies the network that the old resources are no more in-use, at a minimum, through some form of registration process with a sensible lifetime.
>
It comes down to how one decides on the issue of whether a new node has arrived, or an existing node has changed it's MAC. The existing node probably can't reasonably expect any better treatment than a new node at the link layer, but there could be higher level crypto authentication that may be re-established more rapidly for a existing node.
> We have the same memory concern with the IPv4 addresses as we have with IPv6, and the same need that the IPv4 should be renewed when the MAC is changed so as to differentiate from an attack on an IP address from a different node. There is a catch, though: the amount of IPv4 addresses in the air will probably stay roughly the same since they are obtained from DHCP, so the switch will always be able to cleanup state associated with a deprecated MAC address when the IPv4 address is reattributed by the DHCP server. But the number of IPv6 addresses is (to all practical purposes) unbounded, and we'll only be able to time out the state that were created on obsolete MACs and eventually destroy the wrong state to make room.
>
Yes although DHCPv6 could be used to limit IPv6 address usage provided arbitrary host-ID are filtered.
> All in all, changing the MAC address while the node is connected to an IP subnet creates a risk of an involuntary DOS attack against the switches and the TCAMs, along the lines suggested by the article. When we reach the limits, we'll probably bar the additional clients and the effect will rebound for the most part on the clients that do this MAC address renewal thing. A solution that allows the device to detect that it is on a same link or not, and compute the same MAC address when on a same link along lines similar as RFC 7217, could be welcome.
>
> Finally, the 6LoWPAN compression depends on whether the IPv6 address is formed plainly from EUI-64, so it often is. Changing the MAC is such networks will impact the whole chain of routing states, etc... Randomizing MAC addresses in sensors would have to be done very carefully in such a constrained environment where the inflation of state is just not acceptable.
>
Sure - there's often a compromise to be made between privacy and other factors such as power which are more of an issue in IoT.
Cheers,
Piers
> Cheers,
>
> Pascal
>
>> -----Original Message-----
>> From: Piers O'Hanlon [mailto:p.ohanlon@xxxxxxxxx]
>> Sent: jeudi 2 octobre 2014 10:13
>> To: STDS-802-PRIVACY@xxxxxxxxxxxxxxxxx
>> Subject: [STDS-802-Privacy] IPv6 Privacy addressing resource issues
>>
>> Hi all,
>>
>> In yesterday's telecon I mentioned a post I'd read regarding privacy
>> addressing related resource overload - On MIT's CSAIL network (with
>> comments added from well known IETF people like Brian Carpenter):
>>
>> http://blog.bimajority.org/2014/09/05/the-network-nightmare-that-ate-my-
>> week/
>>
>> Piers
>>
>>