Subject: [babel] Babel to standard

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 12 Aug 2015 01:16:29 +0200

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@ietf and babel-users mailing
lists.  I've directed replies to babel@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.

---

From: "Russ White" <[email-masked]>
Date: Tue, 11 Aug 2015 21:02:14 -0400

> 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.

I would agree with this assessment -- the extension mechanism should be
merged in the base doc, but any actual extensions should be managed
separately. I would say each proposed extension needs a pretty clear use
case, a specification, and then an implementation report (if available), and
possibly some form of deployment experience draft (if available).

Smaller, more focused chunks are better than the long many page documents
we've been seeing a lot of recently.

> 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.

Yes, definitely. Note that choosing a route across two metrics is, as I
understand it, unsolvable. This is the reason EIGRP uses the K values to
merge the metrics the user would like to actually deploy into a single
metric. Note also there needs to be some way to prevent oscillation between
the control plane and the data plane when you start playing with delay,
bandwidth utilization, etc., in the real world. These are nasty problems.

> Incompatible protocol changes
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.

A protocol version? It would be simpler to have some sort of capabilities
negotiation here, possibly.

> Adding mandatory and transitive bits, as in BGP
using
> a separate TLV, which is not very elegant.  However, the source-specific
> extension would still have required new TLVs for requests.
> 
that
> has been requested by both the Italian and Slovenian communities.
> 

I would disagree... It's better to have some way for a device receiving an
update if it should ignore and potentially send an error, or if it should
try and process. If you don't have mandatory bits, then you don't have a way
to error out of a neighbor relationship. This means the receiver can either
just bounce the relationship and refuse to peer, which is really hard to
troubleshoot, or it can accept and ignore, which can also be really hard to
troubleshoot.

> 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.

I would keep the specs separate, myself.

> therefore strongly opposed to putting any security mechanism in the base

I would allow separate development in this area -- but it does need to be
done. I would look at requirements and solutions, and make a single
decision. Otherwise you fragment the implementations, as not every one of
these is as easy to implement as it might seem, and you might find holes
that need to be fixed in all four at some point. A single solution is
better, IMHO.

:-)

Russ

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 12 Aug 2015 03:36:21 +0200

I've reordered your comments.

> I would say each proposed extension needs a pretty clear use case,
> a specification, and then an implementation report (if available), and

That's not the way we work, here at Babel Towers.  We don't usually
develop an extension without an actual feature request from our users, and
we never freeze the protocol until we have both working code and
deployment experience.  We're very serious about that.

> negotiation here, possibly.

That's not how Babel works.  A Babel router simply ignores any routes it
doesn't grok.  In other words, capability negotiation happens at route
granularity, not at neighbour relationship granularity.

> Note that choosing a route across two metrics is, as I understand it,
> unsolvable. This is the reason EIGRP uses the K values to merge the
> metrics

A given router must use a single metric (at least in the absence of
TOS-specific routing and similar), granted, but distinct routers may use
different metrics.  This is analogous to routing policies in BGP.

> Note also there needs to be some way to prevent oscillation between the
> control plane and the data plane when you start playing with delay,

Absolutely.  We have worked really hard on stability, this is described in
detail in

   Baptiste Jonglez, Matthieu Boutier (PPS), Juliusz Chroboczek.
   A delay-based routing metric.  Unpublished draft.  2014.
   http://arxiv.org/pdf/1403.3488

-- Juliusz

---

From: Henning Rogge <[email-masked]>
Date: Wed, 12 Aug 2015 10:38:50 +0200

On Wed, Aug 12, 2015 at 3:23 AM, Russ White <[email-masked]> wrote:
> done.

I know that the OLSRv2 document was delayed by a long time because we
had planned to put security into a second document.

> I would look at requirements and solutions, and make a single

The problem is that the selected solution heavily depends on the
network you plan to deploy.

See here for the "compromise" that were used for OLSRv2:
https://tools.ietf.org/html/rfc7181#section-23.5

We should get a security AD involved before we decide "this is enough
for Standard Track Babel" and get an unpleasant surprise.

Henning Rogge

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 12 Aug 2015 11:37:42 +0200

CC restricted to babel@ietf

> https://tools.ietf.org/html/rfc7181#section-23.5

This section is being widely ignored in the wild, as far as I can tell.

The main effect of the insistence of the security people on MTI security
mechanisms is to train the users and implementers to ignore MUST
requirements in standard track RFCs.  I would like the security people to
make an empirical review of the effects of their actions before continuing
with this nonsense.

(DLEP, I'm looking at you.)

-- Juliusz

---

From: Henning Rogge <[email-masked]>
Date: Wed, 12 Aug 2015 12:21:32 +0200

> This section is being widely ignored in the wild, as far as I can tell.

Yes...

I have implemented the security extensions far later than the core
code and I don't think the suggested "shared secret HMAC" security is
more useful than pure layer-2 hop-by-hop security. And I definitely do
not suggest activating the shared-key security by default.

Especially because layer-2 security (e.g. WPA2 for 802.11 adhoc mode)
also provides security for the user traffic.

> make an empirical review of the effects of their actions before continuing

*sigh*

> (DLEP, I'm looking at you.)

Yes, its even worst in the DLEP case because DLEP has no "over the
air" component and is "node local".

Henning Rogge

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Wed, 12 Aug 2015 18:29:27 +0000

On 8/12/15, 4:38 AM, "babel on behalf of Henning Rogge"
<[email-masked] on behalf of [email-masked]> wrote:

Hi!

>network you plan to deploy.

This is an excellent point ‹ not just related to security, but in general.

The applicability ‹ what problem will Babel solve?  Where is it expected
to be used?  Etc. ‹ is of great importance to scope whatever effort is
done going forward.  IMHO, that should be one of the first things that are
discussed ‹ maybe the specifics are obvious to everyone on the list, but
they still need to be documented.

Thanks!

Alvaro.

---

From: Denis Ovsienko <[email-masked]>
Date: Thu, 13 Aug 2015 22:37:50 +0100

> Merging extensions into the base spec 

Let me second this. A right-focused specification is much easier to work with.

-- 
    Denis Ovsienko

---

From: "Russ White" <[email-masked]>
Date: Tue, 11 Aug 2015 21:23:05 -0400

the

route
version

if
to
routers,

using
that

the
slightly

:-)

Russ