Re: 6renum alive again? [A common problem with SLAAC in "renumbering" scenarios]

[Tim Chown <[e-mail]>]

On 20 Feb 2019, at 19:44, 神明達哉 <[e-mail]<mailto:[e-mail]>> wrote:

At Wed, 20 Feb 2019 02:03:52 -0300,
Fernando Gont <[e-mail]<mailto:[e-mail]>> wrote:

> 10.1.  Address Configuration
>
>    o  RA Prefix Lifetime Limitation
>
>       Section 5.5.3 of [RFC4862] states "If the received Valid Lifetime
>       is greater than 2 hours or greater than RemainingLifetime, set the
>       valid lifetime of the corresponding address to the advertised
>       Valid Lifetime."  So when renumbering, if the previous
>       RemainingLifetime is longer than two hours, it is impossible to
>       reduce a prefix's lifetime to less than two hours.  This
>       limitation is to prevent denial-of-service attacks.
>
> This seems a flaw in RFC4862 to me. Me, I think ND security boils down
> to: modulo some basic sanity checks, you trust the RAs, or you don't.
> There's not much of a point in sanitizing the Prefix Lifetimes and then
> honoring Router Lifetimes of 0, or even blindly trusting RAs that would
> make you configuring addresses from invalid prefixes, RAs that might
> override your preferred router with one with higher preference, etc.

I don't remember precisely how we decided to introduce this
restriction in RFC2462 (it first appeared in 2462, not 4862), but I'm
at least pretty sure everyone understood that "ND security boils down:
you trust the RAs, or you don't".  It should be just that it's not
necessarily always all-or-nothing (with which we would never have to
worry about neighbor cache exhaustion or bother to introduce RA guard,
for example) but about providing a safety net when its benefit is
deemed to outweigh the cost.  In the case of the "two hour rule", I
guess (again, I don't remember the precise discussion at that time)
the consensus was that the resulting address stability against
operational errors or minor mischief is worth adding the additional
complexity to the protocol; no one naively assumed that's a strong
security measure against determined attacks.

As usual in such a case, different people can have a different sense
of balance, so it's not surprising if someone disagrees with this
consensus.  So I don't think it's necessarily a "flaw" in the spec
simply because you have a different view on this particular tradeoff.
On the other hand, it's possible that we now might reach a different
conclusion if we had this discussion today: people may revise their
opinions, actual experiments and/or technology evolution may suggest
revising the original tradeoff considerations, etc.  If you think
that's the case, you can always start revising the spec with a "The
two hour rule in SLAAC is considered harmful" draft.

The two hour rule way predates RFC 6104/6105 and the "RA Guard" functionality common in at least enterprise switches today.  And it says "two hours unless the RA is authenticated", so the "impossible" quoted above isn't strictly true, but in practice, we also see how widespread the required SeND deployment to do that is...).

With RA Guard on the table, whether you'd want to relax the two hour rule would presumably depend on how important you feel it is to protect against misconfigurations of genuine RAs.

Tim