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.

Are you thinking something like this?

diff --git a/proto/ospf/hello.c b/proto/ospf/hello.c
index d094f934..dc3bc912 100644
--- a/proto/ospf/hello.c
+++ b/proto/ospf/hello.c
@@ -253,6 +253,10 @@ ospf_receive_hello(struct ospf_packet *pkt, struct ospf_iface *ifa,
 
     neighbors = ps->neighbors;
     neigh_count = (plen - sizeof(struct ospf_hello3_packet)) / sizeof(u32);
+    if (rcv_options & OPT_AT)
+      n->options |= OPT_AT;
+    else
+      n->options &= ~OPT_AT;
   }
 
   if (rcv_helloint != ifa->helloint)