Re: [babel] Benjamin Kaduk's No Objection on draft-ietf-babel-applicability-09: (with COMMENT)

[Juliusz Chroboczek <[e-mail]>]

> 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