New RIP MD5 interface option to avoid sequence check

[Olivier Benghozi]

Hi Ondrej,

about your question, I didn't test yet with BIRD (yes, it's a shame...), I had a look at the code instead to see if the sequence numbers were checked or not (and they are).
What I can say is that we observed one (closed source router vendor starting with a J, a few years ago at least, with «by default» config and without their hidden config command) implementation in which the routes were permanently down. One would expect that if the normal RIP speaker is not there anymore, after the holdtime all tracks of it would be removed from memory and therefore the «new» speaker (new instance of it, actually) would be trust, but it wasn't the case (must wait holdtime without any MD5 RIP packets containing the route to have it really forgotten and be able to have something working again).


regards,
Olivier

> Le 4 oct. 2022 à 19:19, Ondrej Zajicek <santiago at crfreenet.org> a écrit :
> 
> 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.


-- 
*Ce message et toutes les pièces jointes (ci-après le "message") sont 
établis à l’intention exclusive des destinataires désignés. Il contient des 
informations confidentielles et pouvant être protégé par le secret 
professionnel. Si vous recevez ce message par erreur, merci d'en avertir 
immédiatement l'expéditeur et de détruire le message. Toute utilisation de 
ce message non conforme à sa destination, toute diffusion ou toute 
publication, totale ou partielle, est interdite, sauf autorisation expresse 
de l'émetteur*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20221014/1bf79e95/attachment.htm>