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

Benjamin Kaduk <kaduk@mit.edu> Fri, 20 July 2018 03:02 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74CA3130E12; Thu, 19 Jul 2018 20:02:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rWmEvNF9Ghf6; Thu, 19 Jul 2018 20:02:27 -0700 (PDT)
Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB18A130E18; Thu, 19 Jul 2018 20:02:26 -0700 (PDT)
X-AuditID: 12074424-8e9ff70000005b6a-eb-5b5150c11813
Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 01.EE.23402.1C0515B5; Thu, 19 Jul 2018 23:02:25 -0400 (EDT)
Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id w6K32N9L010011; Thu, 19 Jul 2018 23:02:24 -0400
Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (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 <kaduk@mit.edu>
To: Juliusz Chroboczek <jch@irif.fr>
Cc: homenet-chairs@ietf.org, bs7652@att.com, homenet@ietf.org, The IESG <iesg@ietf.org>, draft-ietf-homenet-babel-profile@ietf.org
Message-ID: <20180720030215.GB92448@kduck.kaduk.org>
References: <152578801016.16097.3912115934408683828.idtracker@ietfa.amsl.com> <877els39c6.wl-jch@irif.fr>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <877els39c6.wl-jch@irif.fr>
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: <https://mailarchive.ietf.org/arch/msg/homenet/NzJ374tIfk1qbhPJmwj5rMd8Enw>
Subject: Re: [homenet] Benjamin Kaduk's No Objection on draft-ietf-homenet-babel-profile-06: (with COMMENT)
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: IETF Homenet WG mailing list <homenet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/homenet>, <mailto:homenet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/homenet/>
List-Post: <mailto:homenet@ietf.org>
List-Help: <mailto:homenet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/homenet>, <mailto:homenet-request@ietf.org?subject=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.)

-Benjamin