RE: rogue RA problem statement

["Deepak Bansal (NETWORKING)" <dbansal@windows.microsoft.com>]

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

Vista will not become a 6to4 router unless ICS is enabled on it. Hence, I suspect that the Vista machine in discussion here somehow had ICS enabled on it.

-----Original Message-----
From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Mohacsi Janos
Sent: Tuesday, February 12, 2008 7: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.
>
> 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.
>
> 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