Skip to content

sm: include Inband-Security-Id in CEA when TLS upgrade accepted#246

Closed
tridentsx wants to merge 1 commit into
fiorix:mainfrom
tridentsx:fix/245-cea-inband-security-id
Closed

sm: include Inband-Security-Id in CEA when TLS upgrade accepted#246
tridentsx wants to merge 1 commit into
fiorix:mainfrom
tridentsx:fix/245-cea-inband-security-id

Conversation

@tridentsx

Copy link
Copy Markdown
Contributor

When the server accepts Inband-Security-Id=1 from a CER and has TLSConfig set, echo the AVP in the success CEA. Without this, the initiating peer cannot know TLS was accepted and disconnects before the TLS handshake begins.

Per RFC 3588 §6.2, the CEA must contain the negotiated Inband-Security-Id so both peers agree on whether to proceed with TLS.

Fixes #245

When the server accepts Inband-Security-Id=1 from a CER and has
TLSConfig set, echo the AVP in the success CEA. Without this, the
initiating peer cannot know TLS was accepted and disconnects before
the TLS handshake begins.

Fixes fiorix#245
@fiorix

fiorix commented May 10, 2026

Copy link
Copy Markdown
Owner

Closing — the post-CER/CEA TLS upgrade feature this builds on (#243) was reverted in #244 per @vingarzan's RFC 6733 §5.6 / §6.10 feedback on #238. The pre-existing TLS-on-listen path (TLS handshake before any Diameter messages) remains the spec-compliant approach. If a legitimate need for in-band TLS negotiation surfaces, please discuss on #238 first.

@fiorix fiorix closed this May 10, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

sm: CEA missing Inband-Security-Id AVP during TLS upgrade negotiation

2 participants