[Babel-users] Babel to standard

[Juliusz Chroboczek]

The goal of this mail is to list what I think are the issues with the
current experimental Babel specification, RFC 6126, that should be fixed
before Babel can be standardised, as well as improvements that I think are
not needed.  I'll wait a few days to see if consensus emerges, then I'll
write up the results.

This mail is crossposted between the babel at ietf and babel-users mailing
lists.  I've directed replies to babel at ietf, to which you're encouraged to
subscribe:

    https://www.ietf.org/mailman/listinfo/babel


MUST be fixed
=============

Incorrect port number
---------------------

The RFC gives an incorrect port number.  There is an erratum to RFC 6126
to this effect.

Garbage collecting routes
-------------------------

RFC 6126 doesn't say when a route entry is garbage collected.  The answer
is -- it doesn't matter, just don't do it too early, but this needs to be
stated explicitly.

More precisely, a route entry SHOULD be garbage collected some time after
it is retracted and blackholed (as described in Section 3.5.5), a couple
of minutes is enough.  That is a SHOULD, since nothing bad will happen if
you don't -- you'll just run out of memory at some point.

(Do people think that this deserves an erratum?)

Ignoring extra data
-------------------

Section 4.3 is clear that extra data after the end of the contents of
a TLV MUST be silently ignored.  However, two respectable implementors
(Denis and Markus) got that wrong, so this needs to be made more
prominent.


Editorial changes
=================

Merging extensions into the base spec
-------------------------------------

Which, if any, of the currently defined extensions should be merged into
the base spec?  My opinion is that the extension mechanism should be
merged, but that the actual extensions should remain separate documents.

Describing the route selection algorithm
----------------------------------------

RFC 6126 states that designing a route selection algorithm for Babel is an
open research problem.  While this is still true, there should be an
informative appendix that describes the trivial algorithm (just pick the
route with the lowest metric) and the time-sensitive algorithm used since
version 1.4.0 of babeld since it is simple and appears to work well in
practice.

Including suggested metric values
---------------------------------

While suggested values for metrics on lossy links are described in
Appendix A.2.2, no such values are described for lossless links
(Appendix A.2.1).

Changing "metric" to "primary metric"
-------------------------------------

Babel is able to carry additional metrics in extension TLVs; the metric
used in the Metric field is merely the "primary metric", the one that is
used for loop avoidance and ensures interoperability between different
extensions (which can always fall back to the primary metric).  This
should be made clear in the base spec, especially if the extension
mechanism is merged.

Deprecating wildcard requests
-----------------------------

Wildcard requests are useful for debugging, but we now know that they
SHOULD NOT be used in normal operation.  Say that an implementation MUST
limit the rate at which it honours such requests, and recommend that they
SHOULD NOT be sent.

Rethinking recommendations about seqno requests
-----------------------------------------------

Loosen Section 3.8.2.1 -- the "SHOULD be multicast over all of the node's
attached interfaces" is what the reference implementation does, but the
spec should allow more parsimonious implementations.  This is far from
trivial to write.

Incompatible protocol changes
=============================

A Babel packet carries a protocol number, which it is possible to increase
if the protocol needs to change in an incompatible version.  I'd be
opposed to doing that, since it would severely impact the installed base
of Babel routers, and could cause a split in the community, as has
unfortunately happened with the OLSR community.

Using a wider primary metric
----------------------------

It has been suggested that the current 16 bits are not sufficient.
However, an extended metric can be as wide as will fit in a sub-TLV (255
octets).  The Babel-Z (diversity routing) metric, for example, has variable
width.

Unless you intend to put 65536 routers in a row, there is no need to
extend the primary metric.

Adding mandatory and transitive bits, as in BGP
-----------------------------------------------

There is currently no way to mark a sub-TLV of an Update TLV as mandatory,
as in BGP.  This has forced us to design the source-specific extension as
using a separate TLV, which is not very elegant.  However, the
source-specific extension would still have required new TLVs for requests.

Mandatory and transitive bits would make it easier to design an extension
that does BGP-style communities that are suitable for filtering, a feature
that has been requested by both the Italian and Slovenian communities.

I believe that the doubtful benefits that this provides do not justify an
incompatible protocol change.

Making source-specific routing part of the base spec
----------------------------------------------------

Source-specific routing uses its own set of TLVs, which are distinct from
the base protocol's TLVs.  Merging the two kinds of TLVs would yield
a slightly cleaner protocol, but would require putting source-specific
routing in the base spec.  I like small specs.

Removing prefix compression
---------------------------

Joel dislikes prefix compression.  I'm not sure I like it myself, but it
yields a massive traffic reduction in typical IPv6 networks, and costs
very little code.

Security considerations
=======================

There are at least four known ways to secure the Babel protocol:

  * lower-layer security (e.g. put a frightening guy or gal with
    a truncheon in front of each Ethernet plug, or use 802.1X);
  * HMAC authentication (RFC 7298);
  * Stenberg-style authentication (move everything to unicast except
    hellos, use DTLS);
  * use the replay protection from RFC 7298 together with statically keyed
    IPsec.

There are different tradeoffs between these techniques (reuse of existing
libraries vs. compact code, authentication only vs. privacy, etc.), so the
current plan is to implement them all and let the community decide.  I am
therefore strongly opposed to putting any security mechanism in the base
spec.