> REQ5: a Homenet implementation of Babel MUST use metrics that are of > a similar magnitude to the values suggested in Appendix A of > RFC 6126bis.
> "MUST" and "similar magnitude" are not a great pairing. Fixed. This is now "must", the exact values are still SHOULD. > I agree with the secdir reviewer that the link classification is > important, and would suggest a that SHOULD become MUST for "if it is > unable to determine whether a link is wired or wireless, it MUST > make the worst-case hypothesis". I most humbly disagree. Babel is sufficiently robust to survive misassignment, the consequence will be sub-optimal routing, and only if mis-assignment happens on both ends of a wireless link, and only in non-trivial topologies. I think the consequences are sufficiently benign for us to afford leaving some latitude to implementers. > Section 4 > I always worry a little bit about the ability to classify links as > "trusted", but there are probably cases where it's valid to do so. I agree that HNCP edge detection is not satisfactory, but that's the best we've got right now, and it's time we moved forward. Hopefully the security work will progress so that we can make crypto the default at some point, thus making this issue moot, but I request that this document should not be held up waiting for the security work to complete. > I do wonder whether it's worth enumerating the "upper-layer security > protocol"s that HNCP and Babel support, as there are tradeoffs among > the PSK/PKI/TOFU options that the implementor may need to consider. Since this document is intended for standards track, I worry that an enumeration will be taken as exhaustive, and limit the choices of the WG. -- Juliusz _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
