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:[email protected]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE Phone: 612-626-0815
Minneapolis, MN 55414-3029 Cell: 612-812-9952
===============================================
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
