**Session Date/Time:** 21 Jul 2025 10:00

# radext

## Summary

This radext meeting covered several topics including the status of the radius DTLS BIS draft, congestion control mechanisms, protocol error handling, and the potential use of QUIC as a transport protocol for RADIUS.  The main focus was on the DTLS BIS document and moving it to working group last call. There was discussion on retransmissions, accounting delay time vs event timestamp, and feedback on the draft.  Presentations were also given on solutions for RADIUS congestion control, a proxy BCP, and improved RADIUS signaling using protocol error messages, and the possibility of using QUIC as transport.

## Key Discussion Points

*   **RADIUS DTLS BIS:**
    *   Resolved issues: Tuple vs. connection ID, IP address policies, CN validation, different clients behind NAT, 4-tuple to 5-tuple
    *   Open issues: DTLS retransmissions, general retransmissions, accounting delay time vs. event timestamp.
    *   DTLS retransmissions: Discussion on DTLS 1.3 requirements and need for expert input. The current spec requires servers to reprocess retransmissions of cached responses through the DTLS stack.
    *   General retransmissions: Clarification needed on allowable retransmissions at the application layer, especially for accounting stop packets.
    *   Accounting delay time vs. event timestamp: Recommendation against using accounting delay time for RADIUS TLS clients due to potential transport delays.
    *   Consideration was given to moving to working group last call.
    *   Post-quantum encryption testing was performed on RATSEC. There's significantly more traffic with ML-DSA.
*   **RADIUS Congestion Control (Request Block and Response Delay):**
    *   Problem: Misbehaving supplicants sending excessive requests.
    *   Goal: Automated mitigation to improve RADIUS proxy fabric robustness.
    *   Questions: Problem validity, solution effectiveness, load reduction, under/overblocking, blocking criteria, need for a RADIUS routing protocol.
    *   Consider inclusion in a proxy BCP document.
    *   Discussion of the idea to block clients that are misbehaving.
*   **RADIUS Proxy BCP:**
    *   Addressing issues with RADIUS proxying beyond the original 2865 specification.
    *   Documenting ad hoc solutions and best practices.
    *   Collection of problems, effects, and recommended solutions.
*   **RADIUS Protocol Error (Improved Signaling):**
    *   Addressing situations where packets are silently discarded.
    *   Adding a protocol message indicating inability to process a request.
    *   Application to proxies and scenarios like accounting database unavailability.
    *   Discussions of the desire to consolidate signaling into single messages.
*   **RADIUS over QUIC:**
    *   Exploring QUIC as a transport protocol for RADIUS.
    *   Potential benefits: efficiency, multiple streams, head-of-line blocking avoidance, connection migration, built-in security.
    *   Operational considerations: configuration mechanism, no retransmission over different QUIC connections, UDP port reservation.
    *   Concern about Wi-Fi access point IP address changes was raised.

## Decisions and Action Items

*   **RADIUS DTLS BIS:**
    *   Update the draft to clarify text regarding DTLS retransmissions and server/client behavior.
    *   Start working group last call, tentatively for two weeks after one week following the meeting.
*   **RADIUS Congestion Control:**
    *   Continue discussion and gather more operator input on observed issues and current fixes.
*   **RADIUS over QUIC:**
    *   Continue discussion on the mailing list.

## Next Steps

*   Authors to address open issues and incorporate feedback into updated drafts.
*   RADEXT chairs to schedule further discussion on the mailing list.
*   Working group to proceed to working group last call for RADIUS DTLS BIS.