Re: [v6ops] Question regarding RA-Guard evasion (ND and extension headers)

[David Farmer <[e-mail]>]

On 6/23/11 15:30 CDT, Ted Lemon wrote:
> On Jun 23, 2011, at 2:36 AM, Mikael Abrahamsson wrote:
>> I don't see how it can be fixed. Short of encrypting all traffic
>> and pre-distributing keys, ethernet can't be fixed without the
>> "bandaids" you seem to call the measures being used widely to
>> assure ethernet can in fact be used securely.
>
> There probably is no single solution.   But let's consider the
> solution Mark proposed: use the fact that you control the
> infrastructure to control the flow of packets on the network in such
> a way that rogue RAs cannot reach leaf nodes.   The reason I object
> to this solution, in addition to the fact that it breaks multicast,
> is that it's a firewall solution: the client doesn't know it's safe,
> and as soon as it connects to a network that's not protected in this
> way, it's vulnerable.   But the model of using infrastructure control
> as a credential is interesting.

I don't think of RA-Guard and DHCP-Guard filters as security measures, 
they are simply network management and operations techniques.  They 
don't make the network more secure, but they can make operating some 
networks much easier.  They probably also can make some networks more 
reliable and usable too.  But, calling them more secure is probably a 
stretch.

A quick story; 6 years ago we replaced our network and implemented IPv4 
DHCP-Guard filters on all access ports on our network, doing this 
eliminated about 300 trouble tickets a year from rogue IPv4 DHCP servers 
showing up on our network, home routers used as cheep switches without 
disabling DHCP, Internet connection sharing software on laptops, etc... 
  Between staff time to track down the offending devices and lost 
productivity of the effected users, lets use a conservative average cost 
of $500 an incident, that is $150K a year of cost savings to the 
University.  This didn't make our network one bit more secure, it is 
still a wide open network that anyone can use, but it is now cheaper to 
run and provides a more reliable and usable service to our users.

This draft is need, if nothing else to let people know about this issue, 
and if we can find an acceptable way to mitigate the issue great, but 
classic RA-Guard is still a very effective network management and 
operations technique, with or without mitigation of this issue. 
Unintentional rogue RAs are big issues in a LAN environment of any 
substantial size.  However, without mitigation of this issue, RA-Guard 
is not an effective network security technique. It can't deal with 
malicious rouge RAs that are a security threat.

> Is there a way that someone who is not running 802.1x can demonstrate
> that they control layer 2?   It seems to me that for most examples of
> Layer 2 that we care about, the answer is probably yes.   So then if
> the secure link to the router can be used to communicate a secret,
> and the network can provide that secret back to the user in a way
> that a rogue RA agent could not do, then the end node can
> discriminate between rogue RAs and legitimate RAs.
>
> E.g., suppose we have a WiFi network secured with WPA.   WPA uses an
> X.509 cert to establish the identity of the WPA server.   If the
> private key authenticated by the cert is used to sign the secret the
> client provides, then the client can be sure that the router it is
> talking to is controlled by the same entity that controls WPA.
> Since WPA is tied directly to the infrastructure, that's proof that
> the router is managed by the infrastructure provider.

OH... That's an intriguing idea, use 802.1x to securely feed SEND.  That 
might even make using SEND practical in an open network environment like 
a University.  Its a massing protocol layering violation, but most 
things in the security realm are.

> Another solution that would work well in the case of
> frequently-visited networks would be the model that ssh uses: keep a
> list of good routers.   When you connect to a wire, prefer routers on
> the "good" list to new routers.   If no RAs come from routers on the
> "good" list, then you need a heuristic to decide whether or not a new
> router is good.   The mechanism I described in the previous paragraph
> could be used to handle some exceptional cases; other heuristics
> could be used to handle cases where the link is not secured in any
> way: if I try to establish secure connections, and those connections
> turn out to be exposed to MITM attacks, then the router (and hence,
> the RA from that router) are not trustworthy.
>
> The problem with this stuff is not that it's impossible.   It's that
> it's not simple.   If you want your communications to be secure, you
> have to secure them.   If all your communications are secure, then a
> rogue RA can only do two things: deny service, or allow an attacker
> to do traffic analysis and/or cryptanalysis that would not otherwise
> be possible.

Yep, if you secure your communications then these issues are only 
network management and operational issues, not security issues. However, 
depending on the network, you still might want to use RA-Guard to 
prevent such operational issues.

-- 
===============================================
David Farmer               Email:[e-mail]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota	
2218 University Ave SE	    Phone: [phone]
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================