Markus Stenberg <markus.stenb...@iki.fi> wrote:
markus> What the draft does not cover is what is the assumption about
markus> security of protocols within it. If HNCP is run only over either
markus> physically or cryptographically secured link layer, there are no
markus> real extra requirements for HNCP.
markus> So, question time:
markus> 1) Can we assume secure L2 and/or appropriate device
markus> configuration by the manufacturer/ISP(/user)? (This is what I can
markus> assume in my own home.)
I think that we can assume that wired links are secure.
The only time we care if wireless is secured is when we want to form an
adjacency over the wireless link. I think it is acceptable to refuse
to form an adjancency over an insecured wireless link.
I think it is acceptable to do some kind of TOFU (using IPsec with IKEv2
even) point to point across wired links, and having done that, if there
is an adjancy later possible between those two devices over what would
otherwise be an insecure link, that the previously exchanged keys work.
That means one can plug two routers together with a cable, and then
separate them, knowning that the two routers will remain "entangled"
(I'm making allusions to http://en.m.wikipedia.org/wiki/Quantum_entanglement)
I further suggest that if two routers have wireless that they might well
have a WPA2/PSK available to them, and that they can and SHOULD use something
derived from that key to authenticate each other. Could be over IKEv2, yes.
markus> 2) If not, should the solution be some sort of pre-shared key
markus> scheme? (If not, please explain your alternative solution.)
If we assume the abovekey, we could use it to derive a pre-shared key for a
multicast IPsec SA using AH. Can we assume, declare, that if you don't know
the key, that you skip the AH header, and process the HNCP that is inside as
if it wasn't secured at all? We wanted to do that for SEND, but there were
IPsec implementations that could do that, because we overspecified AH back in
2401. Given that home routers are purpose built boxes, and not generic
random hosts, perhaps we can specify this behaviour.
markus> 2.1) And if so, should it be manually keyed IPsec (multicast
markus> prevents e.g. IKE)? (This is what is in the draft currently.)
Yes, if we can make this AH assumption of skipping, so that we can get TOFU
to work.
markus> 2.2) Or should we roll our own in-HNCP scheme?
No.
I realize that there is an issue with cable modems and FTTH systems such that
the ISP boundary can be hard to recognize. I propose that HNCP use scope-5
multicast, and that we try to convince the Broadband forum that it's cable
modems should drop scope-5 multicast, if they see it. Further, we have the
heuristic that if we saw DHCPv6PD on that interface, it might be an ISP.
(If we also saw DHCPv6PD, and we saw authenticated HNCP, then it is internal)
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | network architect [
] m...@sandelman.ca http://www.sandelman.ca/ | ruby on rails [
--
Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works
-= IPv6 IoT consulting =-
pgpqn07qm0khx.pgp
Description: PGP signature
_______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
