Re: [homenet] comments on babel-profile-03

Juliusz Chroboczek <jch@irif.fr> Sun, 19 November 2017 16:05 UTC

Return-Path: <jch@irif.fr>
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 4DAE9120727 for <homenet@ietfa.amsl.com>; Sun, 19 Nov 2017 08:05:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 EwTExassBmfU for <homenet@ietfa.amsl.com>; Sun, 19 Nov 2017 08:05:53 -0800 (PST)
Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (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 37348126DFE for <homenet@ietf.org>; Sun, 19 Nov 2017 08:05:53 -0800 (PST)
Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/75695) with ESMTP id vAJG5jfU022177; Sun, 19 Nov 2017 17:05:45 +0100
Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 0F382EB21F; Sun, 19 Nov 2017 17:05:45 +0100 (CET)
X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr
Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id 1s_9t4byd1l4; Sun, 19 Nov 2017 17:05:44 +0100 (CET)
Received: from trurl.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id C1255EB216; Sun, 19 Nov 2017 17:05:43 +0100 (CET)
Date: Sun, 19 Nov 2017 17:05:43 +0100
Message-ID: <87y3n2ntig.wl-jch@irif.fr>
From: Juliusz Chroboczek <jch@irif.fr>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Cc: "homenet@ietf.org" <homenet@ietf.org>
In-Reply-To: <9d3963f1-68a4-6925-f8b5-282be6f15787@cs.tcd.ie>
References: <9d3963f1-68a4-6925-f8b5-282be6f15787@cs.tcd.ie>
User-Agent: Wanderlust/2.15.9
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Sun, 19 Nov 2017 17:05:45 +0100 (CET)
X-Miltered: at korolev with ID 5A11ABD9.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)!
X-j-chkmail-Enveloppe: 5A11ABD9.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/<jch@irif.fr>
X-j-chkmail-Score: MSGID : 5A11ABD9.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000
X-j-chkmail-Status: Ham
Archived-At: <https://mailarchive.ietf.org/arch/msg/homenet/4HB3xXsYnV6ofWx2MHCvEpDT1sk>
Subject: Re: [homenet] comments on babel-profile-03
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.22
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: Sun, 19 Nov 2017 16:05:55 -0000

> I re-read babel-profile-03 and have a few comments (below)
> offered as a WG participant (i.e. chair hat off) as part of
> WGLC.

Thanks, this is appreciated.

> - Req5: Is "MUST be... of a similar magnitude..." clear enough?

Yes.  Minor tweaks to metrics don't cause suboptimal routing -- if one
router vendor chooses 64 as the cose of a wired link, and another uses 96,
then one hop is still preferred to two hops, which is what matters at the
end.

On the other hand, if one router vendor picks a cost of 1 and another one
chooses 256, then bad routing will occur.  Here, the costs are not of
similar magnitude.

The reason we don't want to be too precise here is that we want to
encourage vendors to experiment with smarter out-of-the-box metrics.  For
example, a vendor that cares about powerline ethernet should be allowed to
do something smart to prefer Ethernet to powerline.

> - 2.2: I'm not sure this entire section is useful. If there is
> something specific we'd like to avoid (at a MUST NOT or NOT
> RECOMMENDED level), it'd be better to say exactly what.

"Non-recommendations" are just MAYs.  Perhaps the term is badly chosen, if
you have a better suggestion, I'm listening.

What this section says is basically "if you want to be smart, that's cool,
but if you're in a rush, don't bother, it's not expected to be
particularly useful in a home network".  Let me know if you have
suggestions to make it clearer.

> - NR2: I don't see the point of that. If

See above.  The point here is the rationale -- we're explaining why the
smarter metric computation algorithms are not going to matter in a home
network.

> - section 3: "...using the existing redistribution mechanisms"
> could maybe do with a reference for seme well known OS.

I think redistribution is a standard term -- it's used by Quagga and by
Cisco, at least.

> - NR3: I don't see what is not required here, that seems like a
> straightforward 2119 MAY statement

Yes.  See above.

> - section 4: "only susceptible" seems like overstatment.  If
> babel picks up routes from the OS and then annouces those,

[...]

> - section 4: "secured at a lower layer" includes links with no
> security (in reality), is that right?

[...]

> - section 4: "trusted X" is not a good term unless you say
> who/what is trusting whom/what for what. So, s/trusted
> links/links/ would be better.

[...]

> - section 4: The security properties here seem to be directly
> and wholly dependent on nodes being able to safely identify
> interfaces into the categories in 5.1 of 7788. I need to do
> some more reading to convince myself that that's a good thing
> to assume.

[...]

> If there are weaknesses in that assumption, then it'd be better to call
> those out here,

[...]

> - section 4: I dislike the plan of assuming lower layer security

[...]

You're right on all counts, as usual.  However, this document is called
"Homenet Babel Profile", it's not called "Security Considerations for the
Homenet Protocol Suite".

I think the right thing to do would be to replace all of Section 4 with
a single sentence that says

  "This document describes the profile of Babel that is implement in
  Homenet implementations and the interaction between HNCP and Babel.  It
  does not in any way change the security properties of those two protocols."

and let somebody competent write another document, called "Security
Considerations for the Homenet Protocol Suite".  Is that a plan?

-- Juliusz