Re: [homenet] Benjamin Kaduk's No Objection on draft-ietf-homenet-babel-profile-06: (with COMMENT)

[Benjamin Kaduk <[e-mail]>]

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