Re: RFC 5006 and draft-ietf-v6ops-rogue-ra-01

[Roque Gagliano <[e-mail]>]

Hi Tim,

My comment still stands. You can also have "badness" (just using your words) in other ICMPv6 ND options:  Source link-layer address or MTU or Nonce or Timestamp options.... The rogue RA document up to now only focused on the Prefix Information option.

Probably the core is that the definition in the P2 of section 1 of what a "bogus" or "bad" RA in the context of the document should be improved.

Regards,
Roque.


On Jun 10, 2010, at 2:33 PM, Tim Chown wrote:

> Hi Roque,
> 
> The draft is focused on rogue RAs as that has been an operational issue for us in our dual-stack enterprise for quite some time.   The potential for additional forms of 'badness' to come from RA-based DNS configuration are worth noting, but the mitigations in general are the same.     There may be some additional mitigation methods specific to the DNS option/configuration.
> 
> While we do run tools to detect various forms of NDP 'abuse' on our network, e.g. use of the THC toolkit, we don't (yet) see evidence of that.    The rogue RA problem is far more heavily observed and cited and thus having a consolidated informational problem statement that also describes some potential mitigations focused on that problem is, we believe, useful.   Malicious rogue RAs are quite rare - ones caused by Windows ICS, accidental misconfiguration or devices being moved where their role changes (e.g. 6to4 router at home, client at work) are far more common.   But then we're in a CS dept, so our users tend to be more 'creative'.
> 
> We released ramond (http://ramond.sourceforge.net/) as an enhancement to rafixd as one tool for people to use.   RA Guard also has good potential.
> 
> Tim
> 
> On 10 Jun 2010, at 10:26, Roque Gagliano wrote:
> 
>> Sorry,
>> 
>> I should have said NDP options and not ICMPv6 options.
>> 
>> Roque.
>> 
>> On Jun 10, 2010, at 11:15 AM, Roque Gagliano wrote:
>> 
>>> Hi Tim,
>>> 
>>>> We could add text about this.   That would involve some mention of the problem in Section 1 (introduction), perhaps a brief discussion as an extra point in Section 5, and adding the mitigation mentioned in draft-ietf-6man-dns-options-bis-02 of disabling the host from processing DNS options in the RA (assuming the host implementation supports that of course, which isn't a MUST in the draft as far as I can see).   Other than that, I think the text in the draft about rogue RA 'badness' is generic enough to cover bad DNS information.   I'm happy to work with Stig on such text if it's deemed useful, and won't hold up publication too much more.
>>>> 
>>>> I note that draft-ietf-6man-dns-options-bis-02, which passed 6man WG last call, makes no reference to the rogue RA draft in its own security discussion, and also no mention of RA Guard.
>>>> 
>>> 
>>> Why would the dns-option be different from any other ICMPv6 option in this draft context? I would keep the text generic on reference to ICMP options.
>>> 
>>> Roque
>>> 
>>>> Tim
>>> 
>> 
> 
>