> I agree with whoever it was that said there is not enough explanation > of the threat model in this draft. The result is that I really can't > evaluate whether the proposed solution is complete or adequate. >From my point of view there are two vectors through which you can attack HNCP - as mentioned. First is auto-border-discovery (if you happen to use it) and second is attacking the protocol itself.
For #2 the effects of most of the attacks one can probably think of i.e. spoofing, replay, ... as well as simply pretending to be an HNCP/IGP pariticipating router (i.e. speak the protocols regularly) can both lead to various forms of manipulation of the HNCP state. Since the algorithms on top (at least the ones currently defined) are mostly distributed / consensus-based in nature you can pretty much mess with the state without attacking a specific router's HNCP traffic and by just pretending to be a homenet router yourself. Besides most standard end-to-end security solutions cover authentication, encryption, replay protection etc. so should cover most of the attack vectors on the unicast channel which leaves us with the multicast channel which is explained in the draft. TBH replies like "it's not what I expected" or "not enough explanation" doesn't really help if you don't give an explanation or any other form of pointer on how the draft can be improved or what is missing in your mind. As for security of the homenet: The draft briefly mentions securing other protocols like IGPs and the issues with that and proposes that HNCP manages a PSK for them (since thats what IGPs tend to support in terms of authentication). Besides that I don't really want to cover the whole homenet in this draft since this draft should probably be merged with the HNCP main draft at some point. That doesn't me I'm against a separate generic homenet threats draft if anyone volunteers to write one. Cheers, Steven _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet