Re: [homenet] Benjamin Kaduk's No Objection on draft-ietf-homenet-babel-profile-06: (with COMMENT)
On Wed, Jul 18, 2018 at 04:30:17PM +0200, Juliusz Chroboczek wrote: > >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. Well, this is a non-blocking comment, so I do not intend to hold up the document for it. > > 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. An understandable concern; thanks for clarifying. (Again, this was non-blocking, so I defer to your judgment.) -Benjamin ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Benjamin Kaduk's No Objection on draft-ietf-homenet-babel-profile-06: (with COMMENT)
>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 homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
[homenet] Benjamin Kaduk's No Objection on draft-ietf-homenet-babel-profile-06: (with COMMENT)
Benjamin Kaduk has entered the following ballot position for draft-ietf-homenet-babel-profile-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-homenet-babel-profile/ -- COMMENT: -- Section 2.1 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. 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". 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. (Whether there are enough cases where it's valid to do so that would provide enough use cases for this document perhaps will need to wait for deployment experience.) 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. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
