RFC Errata

Errata Search

Source of RFC  
Summary Table Full Records

Found 1 record.

Status: Held for Document Update (1)

RFC 7585, "Dynamic Peer Discovery for RADIUS/TLS and RADIUS/DTLS Based on the Network Access Identifier (NAI)", October 2015

Source of RFC: radext (sec)

Errata ID: 4991
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT

Reported By: Alan DeKok
Date Reported: 2017-04-07
Held for Document Update by: Benoit Claise
Date Held: 2017-07-27

Throughout the document, when it says:


The document describes how to look up realms, but doesn't describe what to do after that. i.e. are the lookups cached? Are the lookups done for every request that comes in?

This gives little guidance for an implementor.

I suggest leveraging the "logical AAA routing table" described in RFC 7542 Section 3. In short form:

* a client MUST maintain a table of known dynamic realms.

* the table MUST be keyed by the realm name, and the contents MUST be server-specific information as described in RFC 7542 Section 3

* when a realm is being looked up, the realm SHOULD be inserted into the table with a "pending" flag, so subsequent requests during the lookup process do not cause additional lookups to be made

* if server validation fails, the realm SHOULD be updated with a "failed" state and a TTL, so that subsequent requests do not cause additional lookups for a period of time. No server information should be stored for this entry. i.e. the realm is marked as "failed", the corresponding server MUST NOT be marked as "failed". This prevents attacks where a malicious actor could point their realm to an unknowing third-party server, and cause poorly implemented proxies to mark it "failed".

* if server validation succeeds, the realm MUST be updated with a "live" state (and a TTL), so that subsequent requests go to the same server without additional lookups

* if server validation succeeds, all realms in the TLS "subject alternative names" presented by the server SHOULD be inserted into the realm table, all pointing to the same server definition, so that subsequent requests for those other realms do not cause additional lookups to be made.

* servers which have been dynamically looked up MUST NOT be added to any global pool of servers. i.e. the lookup is always "realm -> server", and not "There's a known server at this IP address"

I thought we had a short discussion of some of these topics on RADEXT, but I can't find it in the archives.

I think these comments are substantial enough to warrant "wait for document update". I just wanted to ensure they weren't lost.

Report New Errata

Advanced Search