Subject: [babel] A few words about the design of Babel: neighbour association

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 01 Nov 2017 00:10:59 +0100

Hi,

I thought I'd give a few hints about the design of Babel and explain what
I think it is that bothers Denis.  Please bear with me, and let me lecture
a little.

Implementability is an important feature of a network protocol, and one
that is often neglected.  The main criterion in the design of Babel was
ease of implementation: the original plan was to finish implementing Babel
in one week-end.  Babel turned out way more complex than originally
envisioned: it was meant to be RIP improved, not some fancy loop-avoiding
protocol.  (Think IGRP rather than EIGRP.)
 
Still, some of the originally envisioned implementability remains.  The
main technnques that are used to make the protocol easy to understand and
implement include:

  - no state machines: all of Babel's state is encapsulated in the data
    structures and timers described in Section 3.2; receiving a message
    causes the data structures to be updated and some action taken,
    there is no implicit state;

  - no overloading of TLVs: for example, Hello TLVs are for reverse
    reachability, Updates are for route acquisition; you don't assume
    reverse reachability just because you got an Update;

  - minimum interaction between subprotocols: when you receive an Update,
    you update the route table, with no consideration for the reachability
    status of the neighbour.

Of course, at some point you need to glue the pieces together, and that
happens in Sections 3.5.2, 3.7, and 3.8 (metric computation, route
selection, and origination of requests respectively).  Not suprisingly,
these are the tricky bits of the protocol, and the ones that I spent the
most time understanding and tweaking.

Now, having a modular protocol is fine, but it breaks down once you add
security: a security extension needs to consider the security of the
protocol as a whole, and hence there is some tension between modularity
and security (just like there is tension between modularity and
performance -- think of all the cool things people do when they decide to
ignore protocol layering).  In other words, security requires tightly
coupled global state, and Denis found the loose state of Babel lacking.

What Denis is suggesting is that we tighten the state in the core
protocol, most notably require a more reliable neighbour acquisition
procedure.  David, Toke and myself, the people who have actually
implemented Babel, are keen on keeping the loose coupling in the core
protocol, since we're not convinced that all possible security mechanisms
will require the same form of tighter coupling.  We argue that if an
extension needs tighter coupling, the extension itself should either put
stronger constraints on the state of the protocol, or define a new set of
tightly coupled state.

-- Juliusz