Re: [radext] Extended IDs

[Alan DeKok <[e-mail]>]

On Nov 30, 2017, at 9:02 PM, Jakob Heitz (jheitz) <[e-mail]> wrote:
> 
> I generally don't like overloading a field with different semantics,

  I do agree it's weird.. but it *is* the minimal possible change to the protocol.

> because if one of the semantics needs to change in the future, the dependency
> on the other semantic will complicate the change.

  I'm not sure what that means... we are absolutely *not* going to change the meaning of the Request Authenticator field.  Doing so would mean RADIUS would be changed into something else entirely.

> For that reason, I prefer draft-chen-radext-identifier-attr-02.
> I do like some of the detailed discussion of the issues in
> draft-dekok-radext-request-authenticator-02.
> I think the final document should include some of these discussions.

  One large point for me is the subject of "conflicting packets".  i.e. what does a RADIUS server do when it's currently processing one packet, and it receives another one with the same src/dst ip/port, code, and ID?

  All of the specs are silent on this topic, despite implementations having to handle such a corner case.  So far as I can tell, all implementations have chosen a similar solution.  Even RFC 5080 ignores this topic... despite FreeRADIUS (among others) have explicit code to handle this situation.

  It was thinking about these "conflicting packets" that led me to my draft.  What if they *weren't* discarded / rejected, and instead the server could process them? 

  The conclusion was not only that it was possible, but that it wasn't much work, and wasn't a large change to the RADIUS protocol.  It just requirements agreement between the client and server to just behave differently.

  In contrast, adding an extended ID as an attribute to every packet is arguably changing the RADIUS header... while pretending we're not changing the RADIUS header.  We've avoided that for 20+ years because it's a slippery slope to just changing all of RADIUS...

  Alan DeKok.