OSPFV3:When the SAID of the Authentication Trailer is different, a neighbor is formed.

[lijinxianglogo]

Description

node A：
key-id 30

nodeB：
key-id 10

The neighbor status is full

Version

FRRouting 9.1 (localhost.localdomain) on Linux(3.10.0-1127.el7.x86_64).
Copyright 1996-2005 Kunihiro Ishiguro, et al.
configured with:
    '--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu' '--program-prefix=' '--disable-dependency-tracking' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib64' '--libexecdir=/usr/libexec' '--localstatedir=/var' '--sharedstatedir=/var/lib' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--sbindir=/usr/lib/frr' '--sysconfdir=/etc/frr' '--localstatedir=/var/run/frr' '--disable-static' '--disable-werror' '--enable-irdp' '--enable-multipath=256' '--enable-vtysh' '--enable-ospfclient' '--enable-ospfapi' '--enable-rtadv' '--enable-ldpd' '--enable-pimd' '--enable-pim6d' '--enable-pbrd' '--enable-nhrpd' '--enable-eigrpd' '--enable-babeld' '--enable-vrrpd' '--enable-user=frr' '--enable-group=frr' '--enable-vty-group=frrvty' '--enable-fpm' '--enable-watchfrr' '--disable-bgp-vnc' '--enable-isisd' '--enable-rpki' '--enable-bfdd' '--enable-pathd' '--enable-snmp' 'build_alias=x86_64-redhat-linux-gnu' 'host_alias=x86_64-redhat-linux-gnu' 'PKG_CONFIG_PATH=:/usr/lib64/pkgconfig:/usr/share/pkgconfig'

How to reproduce

Follow the description to reproduce

Expected behavior

unable to form neighbors

Actual behavior

Neighbors formed normally

Additional context

https://www.rfc-editor.org/rfc/rfc6506

Checklist

• I have searched the open issues for this bug.
• I have not included sensitive information in this report.

[lijinxianglogo]

@ton31337 can you help me？

[aceelindem]

This is a valid problem and I have a fix. Refer to RFC 7166, section 4.6:

The receiving interface's OSPFv3 SA is located using the SA ID in the
received AT. If the SA is not found, or if the SA is not valid for
reception (i.e., current time < KeyStartAccept or
current time >= KeyStopAccept), the OSPFv3 packet is dropped.

[lijinxianglogo]

This is a valid problem and I have a fix. Refer to RFC 7166, section 4.6:

The receiving interface's OSPFv3 SA is located using the SA ID in the received AT. If the SA is not found, or if the SA is not valid for reception (i.e., current time < KeyStartAccept or current time >= KeyStopAccept), the OSPFv3 packet is dropped.

Thank you very much for your help my friend

[aceelindem]

This issue can be closed - it is fixed.

[lijinxianglogo]

commit: 3f359d7