OSPFv3 auth problem

[Ondrej Zajicek]

On Mon, Mar 15, 2021 at 02:25:18PM +0000, Kenth Eriksson wrote:
> I believe the "options" of the neighbor object is only updated as a
> result of NEIGHBOR_EXSTART. If the authentication is enabled after
> unauthenticated neighbor adjacency, then this does not result in a new
> NEIGHBOR_EXSTART. Thus the options of the neighbor object is stuck 0x113,
> and not the updated to 0x513 (i.e. OPT_AT) resulting in that OSPF packets
> are becoming dropped in procedure ospf_pkt_checkauth3 since auth_present
> is zero.

Yes, you are right. If iface is configured to not use auth, adjacency is
established (n->options are set to not include OPT_AT) and then
reconfigured to use auth, adjacency is kept (because Hello packets
are authenticated) but LSUpd and others are ignored (because there
is no OPT_AT flag in n->options).

RFC 7166 is vague about updating OPT_AT flag, and basic OSPFv2/v3 RFC
just describing setting n->options from DBDes during NEIGHBOR_EXSTART.

> If I manually kick the FSM when authentication is changed  by
> doing ISM_DOWN-> ISM_UP then this works as expected (see pseudo code
> below). I believe there is some logic missing when changing the autype?
> Can this be done in some more fine granular way? 

I think that the best solution would be to update OPT_AT flag in
n->options based on received Hello packets. Will make a patch.

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