Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Backport cisco-authentication password support #16871

Closed

Conversation

aapostoliuk
Copy link
Contributor

Backport cisco-authentication password support

Volodymyr Huti and others added 6 commits September 19, 2024 11:02
Implemented:
- handling 8 char long password, aka Cisco style.
- minimal error inidication routine
- test case, password change affects conection

Signed-off-by: Volodymyr Huti <[email protected]>
Taking over this development from FRRouting#14788

This commit addresses 4 issues found in the previous PR

1) FRR would accept messages from a spoke without authentication when FRR NHRP had auth configured.
2) The error indication was not being sent in network byte order
3) The debug print in nhrp_connection_authorized was not correctly printing the received password
4) The addresses portion of the mandatory part of the error indication was invalid on the wire (confirmed in wireshark)

Signed-off-by: Dave LeRoy <[email protected]>
Co-authored-by: Volodymyr Huti <[email protected]>
Freeing auth-token does not set nifp->auth_token to NULL.
Explicitly set auth_token to NULL when deleting auth config in order
for write config logic to succeed.

Fix bug FRRouting#16359

Signed-off-by: Dave LeRoy <[email protected]>
The nhrp_peer_forward() routine was not explicitly handling the
Authentication Extension in the switch statement and instead fell
through to the default case which checked whether this was an
unhandled Compulsory extension and errored out, never forwarding
the Resolution Request.

Fix bug FRRouting#16371

Signed-off-by: Dave LeRoy <[email protected]>
When an NHRP server was forwarding a message, it was copying all
extensions from the originally received packet. The authentication
extension must be regenerated hop by hop per RFC2332. The copied
auth extension had an incorrect length. This fix checks for the
auth extension when copying extensions and omits the original
packet auth and instead regenerates a new auth extension.

Fix bug FRRouting#16466

Signed-off-by: Dave LeRoy <[email protected]>
For compatibility with frr-reload, a command
"no tunnel protection [vici profile PROFILE [fallback-profile FALLBACK]]"
was added.

Signed-off-by: aapostoliuk <[email protected]>
@donaldsharp
Copy link
Member

We typically do not allow backports of features.... Why do we need to have this feature in older versions?

Copy link
Member

@Jafaral Jafaral left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

like @donaldsharp said, bug fixes only.

@aapostoliuk aapostoliuk closed this Oct 2, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants