[babel] Unicast Hellos?

Juliusz Chroboczek <jch@irif.fr> Sun, 28 May 2017 21:31 UTC

Return-Path: <jch@irif.fr>
X-Original-To: babel@ietfa.amsl.com
Delivered-To: babel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F157F129494 for <babel@ietfa.amsl.com>; Sun, 28 May 2017 14:31:06 -0700 (PDT)
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 hh22z5jbGKv8 for <babel@ietfa.amsl.com>; Sun, 28 May 2017 14:31:05 -0700 (PDT)
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 79EC2120046 for <babel@ietf.org>; Sun, 28 May 2017 14:31:05 -0700 (PDT)
Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/56228) with ESMTP id v4SLV3X8026304 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for <babel@ietf.org>; Sun, 28 May 2017 23:31:03 +0200
Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/56228) with ESMTP id v4SLV3UP007801 for <babel@ietf.org>; Sun, 28 May 2017 23:31:03 +0200
Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id D0D97EB201 for <babel@ietf.org>; Sun, 28 May 2017 23:31:03 +0200 (CEST)
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 gMbql1l1kfa3 for <babel@ietf.org>; Sun, 28 May 2017 23:31:02 +0200 (CEST)
Received: from trurl.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id C62E3EB200 for <babel@ietf.org>; Sun, 28 May 2017 23:31:02 +0200 (CEST)
Date: Sun, 28 May 2017 23:31:02 +0200
Message-ID: <87bmqck6sp.wl-jch@irif.fr>
From: Juliusz Chroboczek <jch@irif.fr>
To: babel@ietf.org
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 [IPv6:2001:660:3301:8000::1:2]); Sun, 28 May 2017 23:31:03 +0200 (CEST)
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Sun, 28 May 2017 23:31:03 +0200 (CEST)
X-Miltered: at korolev with ID 592B4197.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)!
X-Miltered: at potemkin with ID 592B4197.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)!
X-j-chkmail-Enveloppe: 592B4197.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/<jch@irif.fr>
X-j-chkmail-Enveloppe: 592B4197.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 : 592B4197.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000
X-j-chkmail-Score: MSGID : 592B4197.000 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000
X-j-chkmail-Status: Ham
X-j-chkmail-Status: Ham
Archived-At: <https://mailarchive.ietf.org/arch/msg/babel/oeuZyGAE2XCLoeHQwrs3b0qLE8E>
Subject: [babel] Unicast Hellos?
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "A list for discussion of the Babel Routing Protocol." <babel.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/babel>, <mailto:babel-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/babel/>
List-Post: <mailto:babel@ietf.org>
List-Help: <mailto:babel-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/babel>, <mailto:babel-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 28 May 2017 21:31:07 -0000

Dear list,

As I may have mentioned before, we at Babel Towers are planning to work on
Stenberg-style security for Babel during the month of July.  While we can
start the work without unicast Hellos (Hellos will be unprotected, big
deal, and RTT estimation will break), it would of course be better if we
had a complete design for unicast Hellos so that we can implement both at
the same time.

We did discuss some of the issues about unicast Hellos back in Chicago,
and at the risk of boring my audience, please allow me to reiterate (my
understanding of) our conclusions:

  1. There are two natural ways of encoding unicast Hellos: by using the
     Reserved field of the existing Hello, or by defining a new TLV.  The
     latter has a more graceful failure mode in the presence of legacy
     implementations, the former seems more elegant to some.  Since we're
     already breaking compatibility with the Mandatory bit, I'm okay with
     either choice.  (There is also one unnatural way -- using a carefully
     crafted sub-TLV -- but I don't think we're going to do that.)

  2. There is some confusion about the meaning of Interval in the presence
     of unicast Hellos: does it carry a promise of sending another Hello
     of any type, or does it carry a promise of sending a Hello of the
     same type.  If the latter, then I can see a need for an interval-less
     Hello.  (Interval=0 is a reasonable way to encode that.)

  3. The majority opinion appears that Unicast Hellos carry a Seqno, just
     like multicast ones.  My proposal to make them Seqno-less was soundly
     trashed.

  4. Unicast Hellos require new link-quality estimation algorithms.  In
     the spirit of RFC 6126, I intend that said algorithms will not be
     normative -- implementation advice will be given in the relevant
     appendix to the spec.  I am volunteering to do some serious
     experimentation.

As mentioned in a previous mail, I'll be only marginally available until
9 June, but fairly active after that date.  I would be overwhelmed with
joy if people could write down and implement their proposals by that date.

-- Juliusz