New RIP MD5 interface option to avoid sequence check

[Ondrej Zajicek]

On Mon, Oct 03, 2022 at 04:20:51AM +0200, Olivier Benghozi via Bird-users wrote:
> Hello,
> 
> I'm currently using RIP/Ripng with md5 auth with some Cisco/Juniper and Quagga gears.
> I'm looking to switch from quagga to Bird(2).
>
> I would have a feature request about the RIP MD5 sequence number check
> (RFC rule, implemented by BIRD, is: accept only increasing sequence
> numbers, or accept lower only if restarting at 0).
>
> In our current usecase, end-to-end interfaces are not contiguous, and
> it happens that some various cases (like powercuts at one end) can lead
> to a situation when one dead RIP speaker comes back to life before full
> end to end connectivity is restored BUT before route expiration at the
> other side: therefore the received seqnumber starts at something higher
> than 0 but lower than the previous known one, so the routing will just
> fail.

I see the issue. RIP assumes that implementations should keep their (and
neighbor's) sequence numbers persistenly so they are always monotonic,
but BIRD does not do that (and as it seems others neither). BIRD at least
try to use real time as basis for sequence numbers, so in most cases it
would use increasing sequence number even after restart.

One question - if u understand it correctly, if the situation you
described happens, BIRD just ignores received packets (with wrong CSN -
crypographic sequence number), which leads to timeout and removal of
neighbor entry, after that new neighbor entry is created, stored neighbor
CSN is reset and new CSN is accepted, so routing is reestablished.

Does this happen or does it end with persisten failure?


> Quagga doesn't check seqnumbers at all, Cisco gears don't seem to, and Juniper gears have a hidden option to disable this check (no-check-sequence).
> So we would have use/need for a config option (probably at the interface level), to avoid the received crypto sequence number check (therefore md5 is just a way to avoid transmitting the clear password on the wire).
> 
> Apart for the new option definition, the actual check is in master/proto/rip/packets.c, I guess that the check in current line 391 would have to include an additional «&& new_option_isnt_defined» to avoid yelling about a sequence number too low...
> line 391:   if ((rcv_csn < n->csn) && (rcv_csn || n->uc))
> 
> What about such an additional feature ?

Will look at it.

-- 
Elen sila lumenn' omentielvo

Ondrej 'Santiago' Zajicek (email: santiago at crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."