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. 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. 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. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
