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

[Fernando Gont <[e-mail]>]

Hi, Jinmei,

On 20/2/19 16:44, 神明達哉 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".  

I'm also pretty sure about that.


> 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.

What I'm saying is that, security-wise, as long as there are multiple
vectors to perform the same sort of attack, an attacker need not exploit
one specific vector.

e.g., if I was up for performing a DoS in ND, I'd have so many different
options that I wouldn't care if you patched one specific vector.




> 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.

I agree I could have employed different wording.



> 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.

Completely agree.

Thanks!

Best regards,
-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492