IETF 122, Bangkok
Friday, March 21, 2025, 13:00 - 14:30 ICT (6:00 - 7:30 GMT/UTC)
Chairs: Margaret Cullen
Valery Smyslov
Note taker: Janfred, Q
draft-ietf-radext-radiusdtls-bis
We are almost done with (D)TLS. All the TODOs are gone! 🎉
All open discussions should be addressed, speak now or forever hold your
peace.
Move from Reject with Error-Cause to Protocol-Error packets. These won't
be forwarded by proxies.
Post-TLS-handshake client authentication has been barred - it causes too
much of a posibility for fuck-ups. mTLS only is the way.
TLS needs rekeying for very long running sessions. Security
considerations to be a SHOULD for this?
Once we have any final changes from this session, WGLC time?
Extended Key Update: update long term rekeying keys?
https://datatracker.ietf.org/doc/draft-ietf-tls-extended-key-update/
Is the rekeying a MUST or a SHOULD? Probably a SHOULD, there might be
other mechanisms an operator uses against long running sessions.
Protocol-Error may have uses in other documents. We should consider it
in RADIUS over UDP as well.
draft-janfred-radext-radius-congestion-control
RADIUS currently doesn't deal very well with congestion in the middle of
a proxy network. Too much traffic in one place on the chain affects
everyone.
Current options: reject_delay - keeps request ID allocated across the
whole chain, impatient clients may retry anyway; more immediate rejects
further up the chain, still can create a high load
Suggested solution: responses can have a Response-Delay or Request-Block
attribute. Anyone in the chain can add these attributes.
Attribute actions are honoured at the latest compatible step in the
proxy chain.
This isn't really congestion control in the usual sense. Its mostly a
mitigation for overloaded proxy networks.
Is this a problem worth solving, or do we need a more general solution?
Bikeshed on name needed. What about general capability negotiation in
RADIUS?
Summary of ML discussion: this is probably helpful, especially in the
context of Eduroam.
This is more about preventing abuse which can lead to overload, than
dealing with direct system overload.
Valery: We can send out a WGLC, so the people that wait for the WGLC to
read the documents actually do read them.
Mark presenting.
Alan: Not withstanding 6929, if you publish this as informational as
documentation what WBA uses, that is fine, if you want to publish it as
standard, 6929 applies
RFC2866 does not forbid changing the connect-info attribute for
subsequent accounting packets, but also does not say that it is allowed
Sri presenting.
Alan: Looking at IANA: There is a PEN for 802.11. It's a private
enterprise number, you can do anything you want with it if it's yours.
Other pointer is RFC8044, to look at the
Sri: We want one document, so can we do it here?
Alan: You can publish an informational and ask radext to review it.
Q: Document seems ok, and probably better to have it as independent
submission, if you want it published quickly.
Small nit: for country code you mandate length of 2 characters, that's
mabye not always too, make it variable length
Valery (as individual): If you ask radext for adoption, then you lose
control over the document, because then radext would have change
control, just consider this.
Alan:
Alan presenting.
Janfred: I suggest that the Protocol-Error should be standards track and
not experimental.
We still have four documents open in the WG, but expect to have a WGLC
for that before the next IETF, and after they have been submitted, the
charter would be fulfilled.
To recharter the chairs would like to see drafts that would be possible
work items.
Sri: It's always hard to open up new WG, so maybe the group should stay
open, because RADIUS is still used and needs maintainence?
Valery: So basically a maintainance WG? Would need to discuss this with
ADs.