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

Benjamin Kaduk <> Fri, 20 July 2018 03:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 74CA3130E12; Thu, 19 Jul 2018 20:02:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rWmEvNF9Ghf6; Thu, 19 Jul 2018 20:02:27 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EB18A130E18; Thu, 19 Jul 2018 20:02:26 -0700 (PDT)
X-AuditID: 12074424-8e9ff70000005b6a-eb-5b5150c11813
Received: from ( []) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 01.EE.23402.1C0515B5; Thu, 19 Jul 2018 23:02:25 -0400 (EDT)
Received: from (OUTGOING-AUTH-1.MIT.EDU []) by (8.13.8/8.9.2) with ESMTP id w6K32N9L010011; Thu, 19 Jul 2018 23:02:24 -0400
Received: from ( []) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by (8.13.8/8.12.4) with ESMTP id w6K32GeV010728 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 19 Jul 2018 23:02:21 -0400
Date: Thu, 19 Jul 2018 22:02:15 -0500
From: Benjamin Kaduk <>
To: Juliusz Chroboczek <>
Cc:,,, The IESG <>,
Message-ID: <>
References: <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.9.1 (2017-09-22)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprKKsWRmVeSWpSXmKPExsUixCmqrHswIDDa4M0mG4tJf38yWry6sp3N Yvrr38wW7xcdYrGY8Wcis8X81mVsDmweL/vnMHosWfKTyWPxlreMAcxRXDYpqTmZZalF+nYJ XBmP5ixmLDglUHH8vmADYztvFyMnh4SAicSff2fYuxi5OIQEFjNJnJx2ghXC2cgosX7aTKjM VSaJgx0fWUBaWARUJea96WcFsdkEVCQaui8zg9giQPbyac/AGpgFuhkldn66yw6SEBbIlXjz fyVTFyMHBy/Qvq+zfUHCQgLZEmdmXAObwysgKHFy5hOw+cwCWhI3/r0EK2cWkJZY/o8DJMwp oCGx9sl0sFWiAsoSe/sOsU9gFJiFpHsWku5ZCN0LGJlXMcqm5Fbp5iZm5hSnJusWJyfm5aUW 6Zrr5WaW6KWmlG5iBIU1u4vKDsbuHu9DjAIcjEo8vAy3A6KFWBPLiitzDzFKcjApifJeuggU 4kvKT6nMSCzOiC8qzUktPsQowcGsJMI74S1QjjclsbIqtSgfJiXNwaIkzpu7iDFaSCA9sSQ1 OzW1ILUIJivDwaEkwdvlHxgtJFiUmp5akZaZU4KQZuLgBBnOAzQ8B6SGt7ggMbc4Mx0if4rR mGPD8qmTmDn+vAeSQix5+XmpUuK8T0FKBUBKM0rz4KaBUpNE9v6aV4ziQM8J80aCVPEA0xrc vFdAq5iAVklX+4KsKklESEk1MG6IXbBR9u/90kaFZs7nNt/LmteYZq0546+eO/2K67nCpYya m/s0vsTfqjCvj1vxbue1yr+O76U/22x45J9h8293ig+vabu6j17hpFjPMzwbrlj0Lz+Sfmxj 5dIf0QbCXZ3HoqqOz3uYY7e28u5r589qYhN2VJ2o1s9fpdsT/UUqWNu2hmWnuxJLcUaioRZz UXEiAESvGEooAwAA
Archived-At: <>
Subject: Re: [homenet] Benjamin Kaduk's No Objection on draft-ietf-homenet-babel-profile-06: (with COMMENT)
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: IETF Homenet WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 20 Jul 2018 03:02:33 -0000

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