Re: [secdir] secdir review of draft-ietf-v6ops-rogue-ra

[Tim Chown <[e-mail]>]

On 9 Jun 2010, at 18:01, Samuel Weiler wrote:

> Thanks for the explanation re: why the malicious RA text was removed.
> 
> On Thu, 3 Jun 2010, Tim Chown wrote:
> 
> [reordering text for ease of reading]
> 
>>> Second, I'm surprised that the only end-host based solutions are staticly-configured packet filters (3.7) and delays (3.9).  Why not simply "try, try again": accept multiple RAs, see which ones work, and discard (or at least don't use) the rest?
>> 
>> On your second point, yes, in theory, but you're pretty much stepping into multihomed host solutions which are rather out of scope for this draft.  For genuine multiple RAs (or RAs with multiple prefixes) there's also RFC3484 address selection.  What our draft basically says is that unintended RAs can cause 'badness', and here are some solutions to them that enterprise administrators could apply.
> 
> I'm not convinced that "test before use" is necessarily equivalent to multihoming.  And the doc is already covering some host-based mitigations (in 3.7 and 3.9).  Why discard this one?

Fair point Sam.   I think 3.9 (wait before use) was a suggestion from one IETF WG meeting, which really isn't that practical, so could actually be quite reasonably dropped.   The original aim of the draft was to cite practical steps an administrator could take, but 3.2 (RA snooping/RA Guard), 3.4 (use SeND) and 3.11 (add options to DHCPv6) are all methods that are also, as yet, not available.   So we could add your suggestion.

One consideration in 'test before use' though is that connectivity might work, from a user/application perspective, but it might not work as intended or with undesirable consequences/side effects, e.g. via an unintended VLAN or router.

Tim