Re: [radext] Implementation inventions

[Alan DeKok <[e-mail]>]

On Aug 24, 2023, at 5:17 AM, Alexander Clouter <[e-mail]> wrote:
>> I see there’s an item about keeping User-Name consistent (which is definitely important!), but we also need other solid ways to tie auth to acct.  I think this is vital for broader adoption of paid Wi-Fi roaming.
> 
> CUI I think gets you there.

  If it works.  If Class works, that's nice, too.

  If you don't have either of them, then RFC 2866 pretty much has no requirement that the attributes in Accounting-Request are in any way related to a previous Access-Request.

  The sum total of its requirements are:

      If the Accounting-Request packet includes a Framed-IP-Address,
      that attribute MUST contain the IP address of the user.  If the
      Access-Accept used the special values for Framed-IP-Address
      telling the NAS to assign or negotiate an IP address for the user,
      the Framed-IP-Address (if any) in the Accounting-Request MUST
      contain the actual IP address assigned or negotiated.

  So it's technically valid for the User-Name, NAS-Port, NAS-Port-ID, NAS-Identifier, etc. to all be different.

  In practice, servers treat the User-Name as unique, because nearly all sites limit simultaneous logins.  After that, servers go to great lengths to correlate the random data in Accounting-Request with the random data in Access-Request.  And then hope that the guesses it makes are correct.

  Is it time to standardize 2866 in order to fix this?  Apparently the subject of RFC2866 being "informative' and not "standard" has come up at the IESG.  People not familiar with the history of RADIUS boggled at just how bad it was.

>> I think clearer guidelines on Acct-Session-Id and Acct-Multi-Session-Id (and their inclusion in auth requests) could address this.
> 
> Maybe some wording around suggested uses of Acct-Session-Id (MAY in Access-Request) and Class (SHOULD in Access-Accept) would be helpful.
> 
> Would it be out of place to describe strategies here for implementors[1] on how to deal with awful vendor kit:

  Yes.

>  1. try Acct-Session-Id
>  2. sob a little and try Class
>  3. get stiff drink and reconcile sliding window and MAC/CUI/...

  I'd suggest User-Name + <waving hands> some NAS information.  The user is unlikely to have more than one session on the same NAS (barring Acct-Multi-Session-ID)

>  4. get whole bottle of stiff liquor and reconcile sliding window and MAC/username/...
>  5. ...
>  N. flip table

  N+1: file bug reports with vendor and get told "the RFCs allow this behavior"

  I'm putting text into the "deprecate" document which addresses this harmful attitude.

> The problems of each strategy would be needed too with the vain hope that we can push the crap back uphill where it came from....we can hope.
> 
> Cheers
> 
> [1] Hat tip on the friendly advice and "this seems to work in the field" to RFC5080 section 2.1.2 (Request-ID Supplementation) that details "here is how to track in flight EAP sessions".

  All of that came from implementation experience.

  This issue is best seen recently on EMU, with 7170bis.  No one implemented 7170, and it still got published.  Ten years later, we discovered that almost all of it was wrong.

  I think the IETF should do a much better job of requiring that standards be implemented.  And not as theoretical / toy implementations.  But in actual shipping product which works in the real world.

  Alan DeKok.