Re: [babel] Alvaro Retana's Discuss on draft-ietf-babel-rfc6126bis-12: (with DISCUSS and COMMENT)

[Juliusz Chroboczek <[e-mail]>]

>> - §3.8.1.2: "A node MUST NOT increase its sequence number by more than 1 in 
>> response to a seqno request." 

> Ahh…I see.  The increase MUST NOT be more than 1 per request.  That part was
> not clear to me.

Ah, I think I see the problem: "in response" is ambiguous.  I'll change it
to "in reaction".

>> - §4: "A Babel packet MUST be sent as the body of a UDP datagram, with 
>> network-layer hop count set to 1..." 

>     This is a requirement for the sender. No receiver side check is required 
>     or even possible. 
 
> Well, if the received TTL > 1 then the receiver knows something is wrong.

Sure, but there's not much that this check buys you.

> Please take a look at rfc5082 and consider using that mechanism instead.

That's what ND does, right?

It was considered (in the dark times before Babel was at IETF), and
rejected.  We behave like RIPng and OSPFv3: we use link-local addresses
with a TTL of 1, and require checking that the source address of
a received packet is link-local.

At any rate, changing it at this stage would break compatibility with the
installed base, which would be the death of Babel.

>> - §4.6.10: "...if AE is 0 (in which case Plen MUST be 0 and Prefix is of 
>> length 0)." 

>     No clarification is necessary here, just like no clarification is 
>     necessary that for an IPv4 address, plen <= 32. 

> What do you mean by “no clarification is necessary”?

I'll add a mention, but I believe it is redundant.

No explicit mention that IPv4 routes with a prefix length of 57 are
malformed and must be ignored.  That's because IPv4 routes have a maximum
prefix length of 32.

Analoguously, AE 0 has a maximum prefix length of 0, and it si redundant
to mention explicitly that AE 0 routes must not have a plen of 57.

> I understand why the values are 0.  What I’m asking for is what should the
> receiver do if AE = 0 and Plen = n (any number other than 0)?

It's a malformed prefix.  You ignore the TLV, just like you would ignore
a TLV that announces 1.2.3.4/57.

>> - §4.6.10/§4.6.11: Is AE 3 a valid value in a request? I assume it isn't.
>> What should a receiver do if AE = 3. 

>     This case is allowed -- there's nothing in the protocol that disallows 
>     announcing routes within fe80::/64. Of course, it would be silly to do so. 

> Silly doesn’t mean that someone won’t try it…and may end up filling up someone
> else’s table with garbage.  I think this is a vulnerability.

Sure.  I agree with you that a robust implementation of Babel should
filter out fe80::/64, ff00::/8, as well as 0/8, 127.0.0.1/32 and 224.0.0/24.
I just don't agree this filter needs to be hardwired in the protocol
specification, it's an implementation detail and should be configurable.

A case in point: babeld used to filter out Class-E addresses, and then
this happened:

  https://alioth-lists.debian.net/pipermail/babel-users/2018-December/003492.html

> As a point of reference, OSPFv3 doesn’t allow the advertisement of link-local
> addresses as destinations.

OSPFv3, like all link-state protocols, requires uniform filtering rules
within an area, so it makes sense to standardise a default set of
filtering rules.  Babel, like any distance-vector protocol, has no such
limitation (nodes with different filtering rules will interoperate just
fine), so it's much more reasonable to leave filtering to the implementation.

-- Juliusz