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

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 18 Jul 2018 16:30:17 +0200

>    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

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 19 Jul 2018 22:02:15 -0500

> 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.

> 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