OSPFv3 auth problem

[Joakim Tjernlund]

On Mon, 2021-03-15 at 15:59 +0100, Ondrej Zajicek wrote:
> 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.

What about IPv4? Does it also need some tweaking is this case?

  Jocke