Re: [babel] Shepherd Review of draft-ietf-babel-source-specific-04

[Donald Eastlake <[e-mail]>]

Hi,

On Wed, Apr 10, 2019 at 5:57 PM Juliusz Chroboczek <[e-mail]> wrote:

> ...

Babel is a distributed algorithm, and its correctness relies on all nodes
> in a routing domain behaving correctly.  There are many ways in which
> a buggy or malicious node can disrupt a Babel network, and an
> implementation is not required to detect most of them.  (The most common
> in production is a node that announces a route but doesn't actually
> forward packets, e.g. due to a mis-configured firewall.)
>

While it is true that the protocol data stores and state machines and other
aspects of behavior at the ends of the wire are important, the IETF has
always had a particularly sharp focus on the bits on the wire. It seems
reasonable to have a specification that won't fall over even if it gets a
"routing" packet that's junk. And it is a traditional desiderata in routing
protocols in the IETF that in a network with mixed implementations, you
can't originate a bad routing packet from a node and have a persistent loop
or conceivably even scattered persistent loops form in your network.


> What Donald is requesting here is that we add a requirement that every
> implementation should detect one particular (and rather unlikely) instance
> of incorrect behaviour, and work around it.  I don't necessarily agree
> with this requirement, but I am willing to put it in if the implementation
> cost is low enough.


I don't think I'm necessarily requesting that, at least not in all cases.
For example, if you are parsing a TLV it would be reasonable to set a flag
when you see a valid Source Prefix sub-TLV and just remember the prefix
specified, overwriting any previous source prefix seen in that TLV. Such a
parser can distinguish between no Source Prefix sub-TLVs and one or more
such sub-TLVs and, if there are any, will remember the prefix in the last
one. But it does not "detect" if there are more than one.

In any case, as long as the same packet will be interpreted in the same way
by different routers, I'm fine with whatever reasonable unambiguous
interpretation method is easiest to implement.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   [phone] (cell)
 1424 Pro Shop Court, Davenport, FL 33896 USA
 [e-mail]

...
>
> -- Juliusz
>