Hi, On Thu, 23 Jun 2011 16:30:37 -0400 Ted Lemon <[email protected]> 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: Just to be clear, I wasn't suggesting the methods commonly used in ETTH networks is a universal solution. It seems to me that organisations that would care the most about malicious RAs are SPs. Yet they're already likely to have or put measures in place that naturally mitigate that risk as well as achieving other goals that they have such as traffic billing. So malicious RAs may not be as as much of a threat to them as people might think. Implementing these sorts of measures are just a natural cost of business, because it is part of ensuring your service is available, and ensuring one customer has limited ability to disrupt another's service. Enterprise networks may be most concerned about accidental RAs, as they typically tend to have more control over what hosts can do because they operate them, rather than the customers in the SP case. As Ray mentioned, if the cost of implementing RA guard is prohibitive, some enterprises might just accept the risk and consequences of an occasional accidental RA. Are there other contexts that I haven't identified? The reason I've thought about these contexts is that proposals such as universally preventing fragmentation in ND is a one-size-fits-all approach to the problem that probably can't be reversed if chosen. > 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. > This is basically Secure Neighbor Discovery (SeND) with the addition of key distribution via the 802.1x. I'm not sure the combination exists or is possible, I've been meaning to look into it for a while. > 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. > Agree with it not being simple. A secure protocol to authenticate RAs already exists - SeND. The problem with it is the lack of implementations and the key distribution problem. Since we know that methods such as RA guard aren't really "properly secure" and can't be, I think it is important to not to have unrealistic security expectations of them. Regards, Mark. -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
