On 14.9.2014, at 17.48, Michael Thomas <[email protected]> wrote: > On 09/14/2014 02:04 AM, Markus Stenberg wrote: >> On 13.9.2014, at 23.30, Brian E Carpenter <[email protected]> >> wrote: >>> >>> All true (as are the subsequent comments by Acee and Michael). >>> But the fact remains that we can't assume L2 is secure in the >>> normal case, which is a much worse situation than we traditionally >>> assumed for wired networks. >> Ok, so your stance is that we can’t assume secure L2, but neither can we do >> anything useful without fully encrypted traffic. >> >> As fully encrypted traffic is not an option (computational overhead, >> not-so-littleconf on routers and probably impossible on current hosts), >> what, exactly, do you propose then? Not deploy routed home networks at all >> until we can assume L2 security? > I think you're throwing up your hands way too prematurely. I don't know what > "fully encrypted traffic" > means in this context. If you're talking about the router-router signaling > traffic itself (eg, ospf), symmetric > crypto (eg, aes+sha256 -- note all you might need is just integrity too) adds > trivial process load these > days. Public key operations are similarly a drop in the bucket these days > when used sparingly (eg, for > enrollment, session establishment, etc). Modern router boxes are not microvax > 1's with two fat ethernet > ports, after all.
Like I stated earlier in my email, if you do not assume secure L2, just securing router-to-router traffic does little to protect the homenet. Quote: … anything else (e.g. using home resources, using home internet access, pretending to be uplink and performing MITM, the list goes on) would be still possible and I do not see the point. Also, if we assume the home user does not bother to set up L2 security for their home infra (notably wireless), what are the odds they set up HNCP in a secure manner? I wouldn’t bet on it. > Also: I think that HNCP needs to take care of HNCP and not worry about > boiling the homenet security > ocean. Even if we end up with layers of crypto via L2. That's ok. > Last, without actually knowing what threats/attacks we're trying to defend > against, it's *way* to early > to say how much configuration might be required. Remember: WPA2 requires the > input of exactly one > passphrase per SSID. That is manifestly not an insurmountable burden. And > that's just for starters: we > may be able to get away with leap of faith kinds of enrollment depending on > the threats which may require > minimal user intervention (eg: “should I do this, Y|n”). Well, please write up on how you think this could be ‘easily’, without some sort of magic provisioning/hardware that cannot be assumed to be always available. (For example, Apple does nice enough user experience for configuring Airport stuff, but it works nicely if and only if both your hosts and routers are from same vendor. Not applicable here.) > So the real job here is to consider what the threats are first and foremost > before making blanket > statements about l2, l3, processor speed, etc, etc. Certainly. Routers themselves (regardless of what protocol traffic they are sending) as _endpoints_ of traffic constitute only minor part of attack surface of your typical home network. Let’s consider the parties involved: upstream router on ISP side - no crypto with them in typical case for foreseeable future home routers - ok, fine, we can probably do something about them hosts - cannot assume really crypto, except maybe L2 (e.g. WPA2 or even less likely 802.1x/MACSec) Here’s few threats and how to mitigate them from the last IETF slides (http://www.ietf.org/proceedings/90/slides/slides-90-homenet-8.pdf slide 3): 1. fake ISP (=> active MITM, active packet snooping) As upstream router isn’t authenticated (DHCPv6 + RAs indicate it is an upstream router, nothing else), only littleconf about where upstream routers can appear protects from this. (and-or fictional DHCPv6 authentication using ISPs.) 2. access to home resources (~DoS, unprivileged access) As hosts are not authenticated (if we can’t assume secure L2 of some kind), nothing to be done here. 3. someone actively mutating in-home routing state (=> active MITM, DoS) Yes, this could be addressed by just securing router-to-router traffic. [1]/[2] are not affected by _any_ magic you throw in HNCP, and it presents exactly same threats and more besides what is in [3]. Cheers, -Markus _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
