Re: Rogue RA WGLC

[Thomas Narten <narten@us.ibm.com>]

I agree with Bob's comments.

Upleveling, the difficulty I have with this document is that it mostly
just expands on the obvious -- namely that RAs do bad things when they
come from intruders or misconfigured sources.

About SEND, it says:

   3.2.  Secure Neighbor Discovery

   The SeND [4] protocol provides a method for hosts and routers to
   perform secure Neighbor Discovery.  At present there are very few
   SeND implementations available, and SeND is perceived as a complex
   protocol to deploy.  It is also likely that not all scenarios will be
   able to use SeND, for various reasons.  In particular SeND may be
   best suited for fully managed enterprise networks, rather than those
   where administrative control is not present.

This really needs to be expanded upon. The document later suggests that
SEND is really the best/most promising fix.

Consequently, we really should have a better technical explanation
than "perceived as complex", which is a non-technical way of
dismissing something without having to actually justify the statement.

If SEND has real issues with getting implemented/deployed, we should
explain what they are so we can figure out what to do about
them. Otherwise, this document should more strongly encourage people
to implement SEND, as the best way to fix the problems outlined in the
document.

I also agree that the vulnerabilities that are highlighted here are
pretty much the same in DHCP. I think one document that covers both
would be better, so as not to give the false impression (if that is
indeed the conclusion) that DHCP has advantages from a security
perspective.

Bob Hinden <BOB.HINDEN@nokia.com> writes:

> Hi,

> Some comments on <draft-chown-v6ops-rogue-ra-02.txt>.

> Bob

> ----------

> A class of solution that is missing from the draft is NAC (Network  
> Access Control) devices that look for bogus traffic (RAs in this case)  
> and have the ability to disable or quarantine the device by  
> controlling the appropriate switch port.  This is a hybrid of some of  
> the methods suggested in the draft.

> I think the discussion in the document of using DHCPv6 as a solution  
> to rogue RA problem overstates the utility of this as a possible  
> solution as it only moves the problem.  DHC has the same class of  
> problems rogue DHC servers, misconfigured DHC servers, etc., etc.  We  
> haven't seen this as much in DHCPv6, but it's only a matter of time as  
> it's very common in IPv4.  Just ask a university ISP what happens when  
> the students appear in the fall and plug in their own WLAN AP in the  
> their dorm room.  A zillion rogue DHC servers.

> It would be nice to make this clearer in the draft.

> I think it would make sense to expand the draft to cover both Rogue  
> RAs and Rouge DHCPv6 servers as I think we will need solutions for  
> both protocols and the problems are very similar.

> Bob