Re: [radext] [Technical Errata Reported] RFC7585 (4991)

  Me causing trouble again. :(

  I think this all makes sense, and I didn't see anywhere in the RFC were these issues were discussed.

> On Apr 7, 2017, at 11:36 AM, RFC Errata System <rfc-editor@rfc-editor.org> wrote:
> 
> The following errata report has been submitted for RFC7585,
> "Dynamic Peer Discovery for RADIUS/TLS and RADIUS/DTLS Based on the Network Access Identifier (NAI)".
> 
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=7585&eid=4991
> 
> --------------------------------------
> Type: Technical
> Reported by: Alan DeKok <aland@freeradius.org>
> 
> Section: GLOBAL
> 
> Original Text
> -------------
> 
> 
> Corrected Text
> --------------
> 
> 
> Notes
> -----
> 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.
> 
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party  
> can log in to change the status and edit the report, if necessary. 
> 
> --------------------------------------
> RFC7585 (draft-ietf-radext-dynamic-discovery-15)
> --------------------------------------
> Title               : Dynamic Peer Discovery for RADIUS/TLS and RADIUS/DTLS Based on the Network Access Identifier (NAI)
> Publication Date    : October 2015
> Author(s)           : S. Winter, M. McCauley
> Category            : EXPERIMENTAL
> Source              : RADIUS EXTensions
> Area                : Operations and Management
> Stream              : IETF
> Verifying Party     : IESG
> 
> _______________________________________________
> radext mailing list
> radext@ietf.org
> https://www.ietf.org/mailman/listinfo/radext