Re: [babel] Benjamin Kaduk's No Objection on draft-ietf-babel-applicability-09: (with COMMENT)
Juliusz Chroboczek <jch@irif.fr> Sat, 17 August 2019 19:19 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 1627E1200CD; Sat, 17 Aug 2019 12:19:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, 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 GIkD7D1QvrTG; Sat, 17 Aug 2019 12:19:51 -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 D1B2212006D; Sat, 17 Aug 2019 12:19:50 -0700 (PDT)
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/82085) with ESMTP id x7HJJjhT014354; Sat, 17 Aug 2019 21:19:45 +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 C5C42295CC; Sat, 17 Aug 2019 21:19:48 +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 UJ5Km4ShcMTB; Sat, 17 Aug 2019 21:19:47 +0200 (CEST)
Received: from pirx.irif.fr (82-64-141-196.subs.proxad.net [82.64.141.196]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 488FA295CA; Sat, 17 Aug 2019 21:19:47 +0200 (CEST)
Date: Sat, 17 Aug 2019 21:19:47 +0200
Message-ID: <87v9uvha5o.wl-jch@irif.fr>
From: Juliusz Chroboczek <jch@irif.fr>
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: The IESG <iesg@ietf.org>, draft-ietf-babel-applicability@ietf.org, Donald Eastlake <d3e3e3@gmail.com>, babel-chairs@ietf.org, babel@ietf.org
In-Reply-To: <156521443702.8388.9968706791861758093.idtracker@ietfa.amsl.com>
References: <156521443702.8388.9968706791861758093.idtracker@ietfa.amsl.com>
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]); Sat, 17 Aug 2019 21:19:46 +0200 (CEST)
X-Miltered: at korolev with ID 5D585351.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)!
X-j-chkmail-Enveloppe: 5D585351.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 : 5D585351.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/babel/BApCakfhpscSZ9BwV7gkI0d7MgA>
Subject: Re: [babel] Benjamin Kaduk's No Objection on draft-ietf-babel-applicability-09: (with COMMENT)
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.29
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: Sat, 17 Aug 2019 19:19:53 -0000
> When a use case calls for all nodes to participate in the IGP (as > opposed to just connecting to a local point of access and letting that > router run the IGP, there may be privacy considerations regarding the > mobility/connectivity of individual nodes in the information conveyed > over the routing protocol. It would be good to acknowledge that such > use cases may exist (or disclaim applicability to them) in this > document. Done. > Section 1.1 > It's probably worth expanding DSDV on first use. Done. > Section 2.2 > (side note: this is probably just me coming from an abstract > math/topology background and not a routing background, but the term > "non-transitive link" puzzles me a little bit. My understanding of the > non-transitivity property is that if A has a link to B, and B has a link > to C, then it's not necessarily the case that A can get traffic to/from > C via B. But that seems like more of a property of the node policy or > other constraints on B than of any particular link. I can live with > being puzzled, here, but if there's a quick explanation, I'd be > interested in hearing it.) It's a relationship between interfaces. Interface I can speak to interface J at the link layer. A transitive, symmetric link technology is a technology that guarantees that that relationship is an equivalence relation. 10BASE5 guarantees that this is the case by construction -- two stations can speak to each other if they are on the same coax. 802.11 in ad-hoc mode doesn't, here's some ASCII art for your greatest enjoyment: I X K X is an obstacle . X . . . . . J > Section 2.3 > All of the extensions designed to date interoperate with the base > protocol and with each other. This, again, is a consequence of the > protocol design: in order to check that two extensions to the Babel > protocol are interoperable, it is enough to verify that the > interaction of the two does not violate the base protocol's > assumptions. > As another reviewer noted, "interoperable" doesn't seem like quite the > right word; "compatible" seems potentially more appropriate, or perhaps > "usable with each other". Disgree. > Section 2.4.3 > Babel's loop-avoidance mechanism relies on making a route unreachable > after a retraction until all neighbours have been guaranteed to have > acted upon the retraction, even in the presence of packet loss. > Unless the optional algorithm described in Section 3.5.5 of > [RFC6126bis] is implemented, this entails that a node is unreachable > for a few minutes after the most specific route to it has been > retracted. [...] > Section 3.5.5 of draft-ietf-babel-rfc6126bis-07 seems to discuss two > different mechanismis to guarantee that no neighbor is using the current > node as next-hop for prefix P. (1) is that the operation being referred > to here, and (2) if so, should this be "one of the mechanisms"? > Basically, I'm not sure I'm chasing the reference in the way intended. Clarified. > Section 5 > I think we need to couch the "most deployments" language with something > like "at the time of this writing" -- there's no guarantee that it will > remain true in perpetuity. Done. > Given, e.g., https://www.krackattacks.com/, it's unclear to me that it's > reasonable to continue to claim that WPA2 provides a way to secure a > link layer. (WPA3 is not shaping up to do much better, given > https://www.schneier.com/blog/archives/2019/04/vulnerabilities_7.html .) I'm leaving it as it stands notwithstanding -- it's not this document's goal to describe best practices for WiFi security. -- Juliusz
- [babel] Benjamin Kaduk's No Objection on draft-ie… Benjamin Kaduk via Datatracker
- Re: [babel] Benjamin Kaduk's No Objection on draf… Juliusz Chroboczek