Re: [v6ops] SLAAC renum: Problem Statement & Operational workarounds

[Owen DeLong <[e-mail]>]

> On Oct 27, 2019, at 10:14 , Ted Lemon <[e-mail]> wrote:
> 
> On Oct 27, 2019, at 11:05 AM, Philip Homburg <[e-mail] <mailto:[e-mail]>> wrote:
>> If you think that this is an important thing to fix, feel free to 
>> talk about it. But why in this discussion? SEND doesn't do anything for
>> flash renumbering. From an operational point of view, RA-guard is much
>> more attractive then SEND. So it is not clear to me that there is any
>> need for SEND. But I could be wrong. In any case, if there is a need
>> to discuss SEND we could do that separately.
> 
> I think you missed my point.  You can’t do flash renumbering by advertising a prefix with a valid lifetime of zero, because that will be ignored by hosts.   If it were not ignored by hosts, it would be a very effective DoS vector.    And so if you want to be able to flash deprecate a route, you need some way to validate that the deprecation is coming from the same source as the route.   Hence my suggested “limited SEND”.
> 
> Limited SEND would not be hard to implement.   Yes, it would be marginally harder than just saying that hosts should accept flash deprecation of prefixes.   But nobody with any sense is going to implement that in their IP stack, so in practice if you want this to work, you need some way to do flash deprecations that doesn’t create a massive attack vector.

It’s only a DOS vector if the attacker is already on-LAN.

I recognize that there are environments where that is expected behavior (e.g. Coffee Shop Wifi, University networks, etc.),but
it’s not the case for the average residential CPE and residential LAN segments.

In the vast majority of situations where I would expect hostile hosts to be likely to be on LAN, I don’t think I’d be using
SLAAC for address assignment in the first place. Most likely, I’d want stateful DHCP in such instances.

Owen