Re: [radext] Extended IDs

[Alan DeKok <[e-mail]>]

> On Dec 13, 2017, at 1:34 AM, Jakob Heitz (jheitz) <[e-mail]> wrote:
> 
> Once we are arguing "It doesn't work when there's bugs or misconfigs",
> then we've sunk pretty low.

  Insults aren't appropriate.

  Discussing how the proposal behaves in the event of misconfiguration is entirely appropriate.  In fact, that discussion can strongly influence the design of a solution.

> But now that we're there, here is a more
> likely bug: Retransmission with a new request-authenticator.
> draft-dekok will interpret that as an entirely new request.

  That's not how RADIUS works. 

  Quoting RFC 2059, from 1997:

      ... For retransmissions where the
      contents are identical, the Identifier MUST remain unchanged.

      Note that if Acct-Delay-Time is included in the attributes of an
      Accounting-Request then the Acct-Delay-Time value will be updated
      when the packet is retransmitted, changing the content of the
      Attributes field and requiring a new Identifier and Request
      Authenticator.

  See also RFC 5080, as I suggested in an earlier response.

  If a packet is a *retransmission*, then all of it's contents are the same.  Including the header.  So both drafts will see the packet as a duplicate, as per RFC 5080 Section 2.2.2.

  If the packet contents are not the same, then it's not a retransmission.  And going back to 20 year-old standards, the Request Authenticator (among other fields) also changes.

> That is why keeping the id and authenticator separate is cleaner.

  Both drafts behave identically in the situation when a duplicate packet is retransmitted.  Both drafts behave identically when the packet contents change.

  And in both situations, both drafts follow the existing RADIUS standards.

  Please go back and read the standards to see how RADIUS works.

  Alan DeKok.