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

[Alvaro Retana <[e-mail]>]

On August 8, 2019 at 6:12:24 PM, Juliusz Chroboczek ([e-mail]) wrote:

...

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

But that doesn’t cover IPv4 properly.

Are you saying that if both an IPv4 and IPv6 network-layer is available
then IPv6 should be preferred?  I think that would be a good statement to
make.

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

Not if you make it optional.


>> - §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 brought this comment up because the text says that “Plan MUST be 0”.

There are (I think) two different cases:

- Plen doesn’t make sense, IPv4/57, for example.  This is clearly malformed.

- Plen doesn’t matter.  In the case of AE = 0 in a Route Request, does it
really matter what Plen is set to?  IOW, if the request is ignored then no
routes are provided…

Going back to the use of MUST.   I think consistency is important.  In this
case, there’s no explicit text saying that for AE = 1 Plen MUST be <=32.  I
then think it is ok to not make normative the setting for AE = 0.  s/Plen
MUST/Plen must


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

Ok.  While I still think that not filtering out link-local routes is a
vulnerability, please at least mention it: “An implementation may consider
filtering useless information…or should provide configuration filters….
These are the considerations to do so (or not): potential too much garbage…”


Thanks!

Alvaro.