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 8:59:16 AM, Juliusz Chroboczek ([e-mail]) wrote:

Juliusz:

Hi!

Thank you for being so responsive!

In some cases below you’re indicating actions you’ve taken (clarified,
merged the text, etc.).  I’ll wait for the updated document. :-)

> (B) Error Handling

> Many sections of the document describe functionality, or even Normatively
> mandate it, but there is no discussion about Error Handling.

In most cases, no explicit check is necessary, or even possible. In other
cases, the TLV is ignored, which is the general approach taken in Babel
with unparseable TLVs. I've added explicit error handling in cases where
I find it suitable.

Unparseable (as in unreadable, unrecognized, etc.) TLVs are not the same as
what I’m pointing to here.  The case I’m pointing out is where the behavior
is not as expected: the text mandates something, but the receiver gets
something else.


...

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

This is a requirement for the sender. When the receiver notices that the
seqno has increased, it cannot possibly know how many requests the sender
has reaceived in the meantime.

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



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

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


...

> - §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 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)?


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

As a point of reference, OSPFv3 doesn’t allow the advertisement of
link-local addresses as destinations.  I strongly suggest Babel do the same
thing.


> (C) Mandatory Bit

> §4.4: "The most-significant bit of the sub-TLV, called the mandatory
bit..."
> The most significant bit of which part of the sub-TLV? As written, that
bit
> would be the first one in the Type, which corresponds to the text in the
IANA
> section. Please be specific.

This was a typo, noticed by Éric Vyncke. The most-significant bit of the
sub-TLV *Type*.

The sub-TLV value consists of the whole 8 bits. TLV numbers 0 through 127
are non-mandatory, 128 through 255 are mandatory.

> In the IANA considerations section, please include the whole registry in
the
> table to avoid confusion.

I'm confused. Wouldn't that force me to do a number of downrefs?

No…I think the references to draft-chroboczek-babel-diversity-routing (and
the other drafts) can be Informative.


> Note that because of the mandatory bit, the 128-239 range should be
> Reserved...but it is currently marked as Unassigned.

No, this range is unassigned. Mandatory but unassigned.

> Even worse, value 128 is assigned already
[draft-ietf-babel-source-specific].

That is correct. The source prefix is a mandatory TLV. Value 128 has
nothing to do with Pad1, which has value 0.

This was not clear to me either…thanks for clarifying!

Because the use of the bit is explained as a bit then my interpretation was
that any sub-TLV could set the bit…

I think it would be better if in §4.4 the text described a mandatory
sub-TLV, not just a mandatory bit.  Perhaps:

   The most-significant bit of the sub-TLV type (the bit with value 80

   hexadecimal), called the mandatory bit, determines if the sub-TLV is

   mandatory or not.  An unknown sub-TLV MUST be silently ignored, and the
rest

   of the TLV is processed normally.  If an unknown mandatory sub-TLV is

   received, then the whole enclosing TLV MUST be silently ignored (except
for

   updating the parser state by a Router-Id, Next-Hop or Update TLV, see

   Section 4.6.7, Section 4.6.8, and Section 4.6.9).

Also, please label the registry so that it is easier for everyone going
forward to identify the range for mandatory sub-TLVs.  I know you’re the
Designated Expert in the registry…but better to cover all the bases. ;-)

Thanks!

Alvaro.