RADEXT WG Agenda

IETF 123, Madrid

Monday, July 21, 2025, 12:00 - 13:00 CEST (10:00 - 11:00 GMT/UTC)

Chairs: Margaret Cullen, Valery Smyslov

Note taker: Alexander Clouter

Administrivia and WG Status

(Datagram) Transport Layer Security (D)TLS Encryption for RADIUS (Janfred, 20 min)

draft-ietf-radext-radiusdtls-bis

Janfred went through his slides. 3 new versions since the last IETF
meeting.

Decision that CN for validation is forbidden for servers but for clients
it is acceptable.

Open issues:

1. DTLS retransmissions

• seeking some DTLS experise to determine what to do with the
  requirement that epoch/keying data must be the same on
  retransmission
  • though maybe we could ignore this
  • implementation does not match (DTLS) spec

1. Retranmissions (general)

2. Event-Timestamp / Acct-Delay-Time

• author view is current text is good to be left in as the current
  spec allows it, but does not encourage use of Acct-Delay-Time

Margaret

• would like to make sure all issues are nailed down
• looking if people after the meeting think we are now at the point
  over moving to WG Last Call

Valery

• there is enough time to obtain feedback
• opinion that there are not outstanding serious issues

Alan

• good plan
• things Acct-Delay-Time does need to be in this document to improve
  implementation
  • but this does need to go also in a Proxy BCP

Hekki

• (reports implementation experience)
• for PQE traffic increases both in terms of octets and messages sent
• will share findings on the mailing list

Margaret

• original documents did not consider proxies, in particular when
  there are transport changes (TLS -> UDP, UDP -> TCP, ...)
• as this was always a problem, and that this document is updating
  that (a hop-by-hop) maybe it should not go here
• Could go into the proxy document by Alan instead

Janfred

• should we remove this (Acct-Delay-Time vs Event-Timestamp) from the
  document?

Margaret

• we should be careful in where we draw the line and what we should
  include. We have to re-read the document.
• Not for removal as something is needed, but not to be fully
  described here

Q (re: DTLS transmissions)

• application retransmissions would be seen as new packets by the DTLS
  stack

Hannes

• retransmission is about the handshake, not application

Janfred

• so that means we can ignore it

Q

• Yes, ignore it, just leave it to the DTLS stack

Janfred

• Then I will apply some small changes, push a new version, and then
  we can start the WGLC

Margaret

• week on Wednesday (two weeks) do the WGLC

Hekki/Valery

• push out to four weeks as most of Europe is now on holiday

Methods for Mitigation of Congestion and Load Issues on RADIUS Servers (Janfred, 10 min)

draft-janfred-radext-radius-congestion-control

Idea originated from the RADIUS 'retreat' workshop in March.

Manual interventions have been found not as helpful as they could be.

Call to operators to provide feedback if they see this as a problem

• what current solutions used and how effective are they?

Margaret:

• sees 10k/min from a single supplicant to infrastructure she works on
• not international attack, just a quirk of supplicant implementations
  that do not back off
• current solution they use is rate limiting
• related, should we do a RADIUS routing protocol, though this is not
  one to resolve this

Alan

• for 20+ years RADIUS routing has be proposed but nothing
  materialized
• 92%+ traffic is rejects according to a large operator he spoke with
  at the RADIUS workshop

Q

• would be interesting and useful to be able to push this signalling
  all the way back to the access port (AP or switch port)
  • the port could then ignore the device for N minutes as the home
    server is going to block it

Proxy Best Practices for the Remote Authentication Dial In User Service (RADIUS) Protocol (Alan, 10 min)

draft-dekok-proxy-bcp

Has been documenting on the WG wiki a collecting of problems around
proxy implementations.

Wants to describe 30 years of experience to prevent others repeating
mistakes.

Standardising Protocol-Error (Alan, 8 min)

draft-dekok-protocol-error

aka "Better signalling"

Proxies would most benefit from this.

Does not expect there to be any push back here, document only requires
some updates.

Margaret

• agrees from the RADIUS workshop that this was a described problem
• does not want to see this just end up resulting sending two packets
  to the far end which is ignoring the signalling anyway

Alan

• this could be part of the existing reply
• could include congestion control in there (Protocol-Error) too but
  would be valuable to include in the Access-{Accept,Reject} too
  • for example signalling in the Access-Accept "I'm okay for
    authentication, but send your accounting elsewhere...""

Eliot

• where do you think the line is between 'Capabilities' and this

Alan

• conclusion back in 2012 with his capabilities draft was that it was
  hard to see value in something difficult to implement
• manual meat-space 'admin' seems to be good enough between two hops

Janfred

• sees two parts to this, hop-by-hop and end-to-end

RADIUS over QUIC (Changwang, 7 min)

draft-yl-radext-quic-transport

Margaret:

• Do we need a different document for RADIUS over QUIC, what are the
  material differences
• This should not replace over TLS

Q

• TLS is baked into QUIC
• the problem is there are streams in QUIC so a

Changwang:

• QUIC has many advantages and it would be benefical to use it

Q

• how does mobility help in the RADIUS space, what deployment is
  mobility useful

Changwang:

• the user could move

Q

• but the user is not in control of RADIUS

Valery

• lets move the discussion to the list

• Closing