RE: rogue RA problem statement

["Chip Popoviciu (cpopovic)" <cpopovic@cisco.com>]

Adding a few points to those mentioned by Janos ... <c></c> 

-----Original Message-----
From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On
Behalf Of Mohacsi Janos
Sent: Tuesday, February 12, 2008 10:55 AM
To: Tim Chown
Cc: v6ops@ops.ietf.org
Subject: Re: rogue RA problem statement




On Tue, 12 Feb 2008, Tim Chown wrote:

> (subject line updated)
>
> On Mon, Feb 11, 2008 at 10:04:03AM -0800, Fred Baker wrote:
>>
>>   The RA discussion
>>     draft-chown-v6ops-rogue-ra if Tim updates it
>>     draft-vandevelde-v6ops-ra-guard
>
> Hi,
>
> On the rogue RA problem statement, Stig and I don't feel there is much

> point in an update at this stage, and also that presenting the same 
> issue for a 3rd time would be beneficial.
>
> Looking back on IETF70 minutes (I wasn't there) they say:
> 	http://tools.ietf.org/wg/v6ops/minutes
>
> which boils down to 'use SEND' on one hand, and some support from 
> Iljitsch and Francis on the other.
>
> We're seeing more instances of the problem being reported, e.g. on the
> Internet2 list yesterday as a result of the Joint Techs meeting.
>
> We're seeing the problem resurface on our own network (some 1500
dual-stack
> hosts on wired and wireless access).   The most recent last week was a
> Vista machine that somehow didn't pick up the real online RA, and 
> chose to become a 6to4 router as a result (apparently... we'll try to 
> recreate this one).
>
> I think there's various underlying issues here.
>
> 1) Not everyone will deploy SEND, in fact maybe very few networks
will.
> It would be useful for some SEND fud to perhaps be wiped away, since 
> at present it seems 'up there' with Authenticated DHCP for deployment 
> as far as the people I ask reply.
>

<c>
The solutions proposed are not intended to replace SEND but rather
complement it wherever possible. I think that, if nothing else, the
RA-guard options would help SEND in securing a varied set of
environments and deployments.
</c>

> 2) Rogue RAs can happen for various accidental or malicious reasons,
so
> monitoring your link for 'bad' RAs is prudent regardless.   We've
looked
> at rafixd and are working on some improvements to that as a monitoring
> and possibly corrective tool.    This can be rolled into monitoring as
> per ndpmon, perhaps.   So these are new things that should be
detectable.
>

<c>
This is part of some of the solutions proposed by Gunter's draft. It
could however be extended to have devices just monitor and report rather
than take action.

Best Regards,
Chip
</c>

> 3) There are 'simple' fixes that could be made available today, e.g. a

> switch option to en/disable RAs inbound per switch/stack or per port, 
> which would help just as MLD snooping can do, or DHCP blocking today.

For this one we proposed with Gunter in draft-vandevelde-v6ops-ra-guard.

>
> 4) The issues with RAs are why people seem keen to use DHCPv6, and the

> same people do ask about DHCPv6 default router options (regardless of 
> the (lack of) security with DHCPv6 itself).

Currently the DHCPv6 is rather loosely integrated in most of the
operating systems....

Maybe one option would be combining the two drafts....

Best Regards,
 		Janos