RADEXT WG Agenda

IETF 126, Vienna

Wednesday, July 22, 2026, 14:00 - 15:30 CET (12:00 - 13:30 GMT/UTC)

Chairs: Margaret Cullen
Valery Smyslov

Note taker: Janfred Rieckers

Administrivia and WG Status

Chairs, 5 min

Regarding recharter: Last Block position from IESG was lifted shortly
before IETF126. Charter has now passed IESG review, will now be sent to
IAB for review, hopefully 2-3 weeks from now.

RadSec: RADIUS over Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)

Janfred, 10 min

draft-ietf-radext-radiusdtls-bis

Deprecating Insecure Practices in RADIUS

Alan, 5 min

draft-ietf-radext-deprecating-radius

Question from Alan to WG: Should we add rate limiting?
Margaret: not sure, most issues are not relevant to ratelimiting, it's
more to mandate exponential backoff for retries.
Alan: Most of this comes from supplicants, so the NAS should detect this
and rate-limit login attempts.
Mark: we need advice on rate limiting, we don't have it in any document
up until now.
Alan: Also an issue for IEEE or WiFi Aliance
Margaret: Should be per-userdevice-rate limiting, not per-NAS limiting
Alan: Would argue to also add per-NAS limits.

A Review of RADIUS Security and Privacy

Alan, 5 min

draft-ietf-radext-review-radius

Margaret: This and the previous doc haven't been through WGLC, so we
should get these to WGLC as soon as possible, hopefully have them done
by IETF127.

Standardising Protocol-Error

Alan, 5 min

draft-dekok-protocol-error

Fabian: Tested corner cases during hackathon. Draft should define which
errors are permanent and which are recoverable. There are cases where
retrying in a few seconds it might work. In TLSbis it says that silently
discard is still allowed if you are out of resources, so need to keep in
mind that there are still cases where a packet will not get a response.

Mark: CoA at least has a NAK request not routable
Alan: Question what to do where (e.g., CoA-NAK or Protocol-Error if a
CoA is not routable)
Margaret: Strong in favor of transient/non-transient errors.
Alan: Document has number ranges for permanent/proxy/temporary failures.

Margaret: also talk about rate limiting
Alex:
Fabian: Regarding Permanent/transient: If the error is "unless the
configuration fails, a packet with the same contents will fail again",
then this is permanent, a malloc error or similar should be transient.
Alan: Maybe include a config version in Protocol error
Margaret: Maybe include this in Status-Server instead of protocol-error,
so it can be polled

QUIC Transport for Network Telemetry

Alan, 5 min

draft-netana-opsawg-telemetry-over-quic

Chris:
Mark: With (D)TLS-bis is there even the need?
Alan:
Margaret: We shouldn't have two different ways to do RADIUS over TLS,
should there should be clear explanation when to use which.
Alan: Document is an initial thought, primary objective is administrator
simplicity, have one
Fabian: Strongly object to this. Only advantage is to have one
certificate for everything. A working group should not define a
transport for protocols outside of their "jurisdiction".
Alan: Idea is not to define quic-specific issues with RADIUS transport,
idea is more to have one common umberella
Margaret: For RADIUS-over-quic we didn't have consensus to work on it in
the WG, but still interested, if people are willing to work on it and
deploy it it would be interesting.
Alexander: I'm ok with this. the one endpoint is the NAS that has RADIUS
accounting, netflows, ... and the other end is just a concentrator that
consumes all this accounting data, so this
Alan: Idea is that every protocol already has quic support, this only
defines how to do it over one single quic connection.
Fabian: Assumption that every telemetry protocol goes to one single
endpoint is not true (from my experience), every telemetry has a
different server that consumes it.

Accounting overload with AP roaming

Alan, 5 min

Mark: This is a suggestion on how to implement a NAS?
Alan: Yes. We have the Proxy-BCP document, the Periodic-Update could be
added to that and make it to a RADIUS-BCP.
Mark: Session-ID?
Alan: Session-ID is the overall session, could still get
Accounting-Start/Stop for every AP connect/disconnect with the same
Session-ID.
Mark: For emergency access: Does this trigger a new Session? Could be a
good time to understand the different requirements for Accounting, and
what should be visible.
Valery: Will there be a draft?
Alan: Maybe, first get the deprecation/review document out, maybe even
protocol-error, and only after write a new draft for this.

A syntax for the RADIUS Connect-Info attribute used in Wi-Fi networks

Mark, 5 min

draft-grayson-connectinfo

Margaret (as Chair): We already did a pre-adoption call, there was
consensus to adopt, will adopt as soon as recharter is complete.

RADIUS WBA Vendor-Specific Attributes for Wi-Fi Network Quality Metric Reporting

Mark, 5 min

draft-grayson-radext-wba-wifi-quality-metrics

Question for WG: Best approach? WG document, publish over ISE, not RFC
at all?
Margaret: Many have vendor-specific attributes, not sure if there are
RFCs for these type of publications, maybe another way of publication is
better?
Mark: at least microsoft with the MPPE keys
Alan: There also is ADSL VSA, so not common but not unusual
Fabian: Specifying data in the AP. Transmitted in Accounting?
Mark: Transmitted in Access and/or Accounting
Joey: Strongly support this way to communicate this telemetry, working
with large operators. Question: Concerns about WBA VSA, is there a
different AVP/... to have it not tied to WBA, might carry more weight if
it is not vendor-specific.
Mark: Then question for WG: Would radext specify an extended attribute?

Alan:
Valery (as Chair): You as author can decide which approach you choose,
if standards track you may loose change control in the WG process
Margaret (as Chair): ISE will not publish a document about RADIUS
attributes without talking to radext WG, so if not standards track
document, then why should this be ISE and not WBA published?
Alan: If this is beyond WBA-specific scope, there is benefit in
publishing it in IETF

Closing

Chairs, 5 min

Automatically generated minutes:

(https://ietfminutes.org/minutes/ietf126/radext.html)

Session Date/Time: 22 Jul 2026 12:00

RADEXT

Summary

The RADEXT working group met at IETF 126 to discuss several active
drafts, security deprecations, protocol errors, and upcoming efforts.
Key updates included progress on the RADIUS/(D)TLS-bis (RadSec)
specification, which has resolved all IESG discuss points and is nearing
finalization. The group also discussed the status of its rechartering
process, which has cleared the IESG and is expected to be approved by
the IAB in mid-August. This recharter will unblock several pending
documents for adoption. Other topics included rate limiting, protocol
error handling, telemetry over QUIC, periodic accounting updates, and
wireless network quality metrics.

Key Discussion Points

1. Working Group Status and Rechartering

• Speaker: Valery Smyslov
• Slides: Chairs' deck
• Valery Smyslov reported that the blocking position on the new
  charter has been lifted after removing sentences regarding the
  explicit review of attributes from other SDOs.
• The AD, Christopher Inacio, confirmed that the charter has cleared
  the IESG and is with the Secretariat for external review. It is
  expected to be officially approved by mid-August.
• Once the recharter is finalized, several Cisco and other pending
  drafts that have already completed pre-adoption calls can be
  immediately adopted as working group documents.

2. Update on RADIUS/(D)TLS-bis (RadSec)

• Speaker: Jan-Frederik Rieckers
• Slides: Update on RADIUS/(D)TLS-bis (RadSec)
• Discussion:
  • Jan-Frederik Rieckers presented updates between -15 and -17.
    All IESG discuss points have been resolved, including adding an
    ALPN section for compatibility with RFC 9525, removing the path
    MTU discovery paragraph, adding a detailed rationale for event
    timestamp versus accounting delay time in the appendix, and
    addressing the DTLS connection ID discuss.
  • Eric Vyncke raised a non-blocking comment regarding the use of
    "should" without explanations of when they can be ignored.
    Christopher Inacio (AD) noted that authors should address as
    many as reasonable, leaving the exact level of detail to
    editorial control.
  • Fabian raised comments about defining client and server behavior
    for invalid certificates (i.e., closing the connection) and
    managing connection closure post-TLS handshake without
    triggering immediate, aggressive reconnection storms.
  • Margaret Cullen and Jan-Frederik Rieckers agreed that these
    changes are largely editorial/clarifying and do not alter the
    core specification. The chairs will verify these final updates
    on the mailing list before advancing the document.

3. Deprecating Insecure Practices in RADIUS

• Speaker: Alan DeKok
• Slides: Deprecating Insecure Practices
• Draft: draft-ietf-radext-deprecating-radius
• Discussion:
  • Alan DeKok outlined updates on tunnel passwords (which suffer
    from low entropy despite shared secret protection) and the
    addition of rate-limiting text.
  • A discussion ensued regarding how to handle clients that flood
    servers with rapid, automatic retries upon receiving rejections.
    Margaret Cullen, Mark, and Alan DeKok discussed the necessity of
    client-side exponential backoff. Because client behavior is
    difficult to enforce, the consensus was to recommend that NAS or
    proxy devices perform rate limiting and that access-rejects are
    delayed slightly to mitigate storms.

4. A Review of RADIUS Security and Privacy

• Speaker: Alan DeKok
• Slides: Review of RADIUS Security
• Draft: draft-ietf-radext-review-radius
• Discussion:
  • This document was split from the main deprecation draft to keep
    both manageable.
  • Recent updates include text on security implications when
    forwarding inner-tunnel data (after terminating TLS) and a
    security analysis of CHAP, reinforcing that CHAP is essentially
    plain-text equivalent due to its reliance on MD5.
  • Margaret Cullen requested that both this draft and
    draft-ietf-radext-deprecating-radius be prepared for Working
    Group Last Call (WGLC) once the next updates are posted in
    August.

5. Protocol-Error

• Speaker: Alan DeKok
• Slides: Protocol-Error
• Discussion:
  • This draft addresses the issues associated with silently
    discarding invalid packets, proposing a formal "protocol error"
    response to improve network stability.
  • Live interoperability testing is planned for August, with
    findings to be reported before the next IETF meeting.
  • Fabian noted that the draft needs to clearly distinguish between
    permanent errors (which should stop client retries) and
    transient errors (e.g., temporary resource depletion or
    transient uplink failure).
  • Margaret Cullen highlighted the danger of amplification attacks
    if protocol error responses are not rate-limited.
  • Alexander Clouter suggested utilizing configuration versioning
    or opaque tokens to signal when a configuration change has
    occurred. Alan DeKok agreed to add an opaque token to the
    document to allow administrators to signal configuration state
    changes.

6. QUIC Transport for Network Telemetry

• Speaker: Alan DeKok
• Slides: QUIC Transport for Network Telemetry
• Discussion:
  • Alan DeKok presented this as a "for your information" item from
    the OPSAWG. The proposal aims to wrap multiple telemetry
    protocols (such as IPFIX and RADIUS Accounting) under a single
    secure QUIC transport to simplify administration and certificate
    management.
  • Fabian and Margaret Cullen expressed concern about combining
    distinct protocols onto a single transport stream, noting that
    different telemetry protocols have different properties and
    targets.
  • Margaret Cullen emphasized that the RADEXT working group
    currently has no consensus or active interest in defining
    RADIUS-over-QUIC, and that establishing standalone RADIUS over
    QUIC must precede any multiplexed transport efforts.

7. Accounting Status Type = Periodic Update

• Speaker: Alan DeKok
• Slides: Acct-Status-Type = Periodic-Update
• Discussion:
  • To reduce the signaling overhead caused by frequent roaming
    between uncoordinated access points (which triggers consecutive
    accounting start/stop cycles), Alan DeKok proposed a new
    Periodic-Update accounting status. This allows APs to
    aggregate and report roaming metrics periodically.
  • Mark suggested that this could be incorporated into a Best
    Current Practice (BCP) document (such as a NAS BCP or Proxy
    BCP).
  • Alan DeKok indicated that he intends to draft a document on this
    topic once the core security and deprecation drafts are
    advanced.

8. Connect-Info Updates

• Speaker: Mark
• Slides: Connect-Info radext IETF126
• Discussion:
  • Mark presented the updated draft, which has been reorganized to
    remove non-connection-related key-value pairs based on previous
    working group feedback.
  • The syntax has already seen real-world adoption, notably
    integrated into OpenRoaming and deployed by Helium across 17,000
    access points to facilitate RSSI-based authorization.
  • The working group has already supported adoption of this draft;
    it will be formally adopted as a working group document
    immediately after the rechartering process completes.

9. WBA Quality Metrics

• Speaker: Mark
• Slides: WBA-Quality-Metrics radext IETF126
• Discussion:
  • This new draft (draft-00) addresses the non-connection metrics
    that were stripped from the Connect-Info draft, defining them as
    Vendor-Specific Attributes (VSAs) under the Wireless Broadband
    Alliance (WBA) enterprise code.
  • The draft introduces complex/nested attribute structures to
    represent per-radio metrics (such as RTT, channel utilization,
    and noise).
  • The group discussed the appropriate publication venue. Joey
    Padden and Michael Sym (via chat) advocated for standardizing
    these attributes within the IETF/IANA space to encourage broader
    OEM adoption.
  • Margaret Cullen and Alan DeKok noted that while the WBA can
    publish these independently, bringing them to the IETF for
    standards-track publication would require the working group to
    adopt, review, and potentially refine the complex data types.

Decisions and Action Items

• RADIUS/(D)TLS-bis: Jan-Frederik Rieckers to apply the editorial
  changes proposed by Fabian regarding invalid certificates and
  connection closures. The chairs will verify consensus on these
  changes via the mailing list before advancing the document.
• Deprecating Insecure Practices & RADIUS Security Review: Alan
  DeKok to submit updated versions of
  draft-ietf-radext-deprecating-radius and
  draft-ietf-radext-review-radius in August.
• Protocol-Error: Alan DeKok to update the draft to incorporate
  opaque configuration tokens and differentiate between transient and
  permanent error categories.

Next Steps

• Working Group Last Calls (WGLC): The chairs plan to initiate
  WGLCs for both draft-ietf-radext-deprecating-radius and
  draft-ietf-radext-review-radius shortly after the August
  updates are published.
• Rechartering: The new charter is expected to be approved by the
  IAB by mid-August. Once approved, the chairs will formally adopt the
  Connect-Info draft and outstanding Cisco/Sri drafts.
• Protocol Interoperability: Live testing of the Protocol-Error
  specifications is scheduled for August, with results to be shared
  before IETF 121.