OSPFv3 auth problem

[Kenth Eriksson]

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

/* AUTHENTICATION */
  if (ifa->autype != new->autype)
  {
    OSPF_TRACE(D_EVENTS, "Changing authentication type of %s", ifname);
    ifa->autype = new->autype;

    ...
    ospf_iface_sm(ifa, ISM_DOWN);
    ospf_iface_sm(ifa, ISM_UP);
  }

Thanks,
Kenth

-----Original Message-----
From: Bird-users <bird-users-bounces at network.cz> On Behalf Of Joakim Tjernlund
Sent: den 11 mars 2021 16:50
To: santiago at crfreenet.org
Cc: bird-users at network.cz
Subject: Re: OSPFv3 auth problem

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.


On Thu, 2021-03-11 at 15:06 +0000, Joakim Tjernlund wrote:
> On Thu, 2021-03-11 at 15:50 +0100, Ondrej Zajicek wrote:
> > On Thu, Mar 11, 2021 at 12:35:40PM +0000, Joakim Tjernlund wrote:
> > > We have a ring of routers(5 of them) running unnumbered pppoe links between them. Adding OSPF authentication (auth trailer) works OK.
> > > However, removing OSPFv3 on ONE interface causes big problem in 
> > > some cases, we loose auth in the whole ring and routing is then kaputt for all routers.
> > >
> > > We have noted that some PDUs(like LS update) are sent without auth 
> > > trailer so the receiving nodes complains with "ospfv3_2: Authentication failed for nbr 0.0.139.1 on p1-1-3-1-4 - missing authentication trailer (0)"
> > >
> > > OSPFv3 Hello is OK though, it still has its auth trailer.
> >
> > Hmm, that is strange. There is difference between Hello and LSUpd in
> > OSPFv3 Auth receiver code, but not in sending code. That is essentially:
> >
> >   if (ifa->autype != OSPF_AUTH_CRYPT)
> >     return;
> >
> >   ... attach auth trailer ...
> >
> >
> > > Any ideas?
> >
> > LSUpd packets do not contain explicit flag whether they use OSPFv3 
> > auth trailer. Such information is stored in neighbor structure based 
> > on received DBDes packet. So 'missing authentication trailer' for 
> > LSUpd really means that such neighbor structure says 'no auth'. But 
> > that should not happen as that DBDes packet would be rejected.
> >
> > One idea is that DBDes packets intended for one iface 
> > (non-authenticated) were sent to a different iface (authenticated) 
> > and they poisoned neighbor structure with 'no auth' info.
> >
> > You say 'loose auth in the whole ring', i can imagine that it will 
> > break adjacent links, but it will really break even non-adjacent links?
> >
>
> Yes, it takes some time(about 30 min) though before the whole ring is gone.
> All nodes are seeing "missing authentication trailer" msg.

I should mention that a birdc restart/configure(on each node) will correct the problem.