[radext] A proposal to allow more than 256 packets on any connection

[Alan DeKok <[e-mail]>]

  I've written a draft to allow more than 256 packets on any connection.  Note that I'm *not* proposing a change to the Id field, or to much else in the protocol.

  The document is a first draft, and doesn't cover some of the protocol details.  But the concept is very simple:

a) use Status-Server to negotiate the new functionality (see below for details)

b) allow clients to use Request Authenticator as a unique key for packets, in addition to src/dst ip/port, Code, and Id

  i) For Access-Request packets, Request Authenticator is a bunch of random numbers, which is fine.

  ii) for other packet types Request Authenticator is the signature of the packet contents and the secret.  So if the contents are the same, the Request Authenticator is the same.  If the contents are different, it's different.

c) have the server send a new attribute: Original-Request-Authenticator in response packets.  This allows clients to correlate responses with requests, using the key mentioned in (b), above.

  For negotiation, a client sends Status-Server containing Original-Request-Authenticator of all zeroes.  If the server has the functionality, it sends a response containing Original-Request-Authenticator with value copied from the original Request Authenticator.

  All other packet signing / Id management stays the same.

  I think this is the minimal possible change to RADIUS which solves the underlying problem.  As such, I hope it's also the least contentious.

  To do for the spec:

- more text on how Original-Request-Authenticator works in response packets

- more text on why this works for all packet types

- make the text less hacky (it was written in less than a day, after the concept was worked out)

- get WG review (I don't think we can achieve consensus quickly on this)

  Alan DeKok.

> Begin forwarded message:
> 
> From: [e-mail]
> Subject: New Version Notification for draft-dekok-radext-request-authenticator-00.txt
> Date: April 24, 2017 at 3:48:56 PM EDT
> To: "Alan DeKok" <[e-mail]>
> 
> 
> A new version of I-D, draft-dekok-radext-request-authenticator-00.txt
> has been successfully submitted by Alan DeKok and posted to the
> IETF repository.
> 
> Name:		draft-dekok-radext-request-authenticator
> Revision:	00
> Title:		Correlating requests and replies in the Remote Authentication Dial In User Service (RADIUS) Protocol via the Request Authenticator.
> Document date:	2017-04-24
> Group:		Individual Submission
> Pages:		14
> URL:            https://www.ietf.org/internet-drafts/draft-dekok-radext-request-authenticator-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-dekok-radext-request-authenticator/
> Htmlized:       https://tools.ietf.org/html/draft-dekok-radext-request-authenticator-00
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-dekok-radext-request-authenticator-00
> 
> 
> Abstract:
>   RADIUS contains a one-octet Identifier field which is used to
>   correlate requests and replies.  This field limits the number of
>   outstanding requests to 256.  Experience shows that this limitation
>   is problematic for high load systems.  This document proposes to use
>   the Request Authenticator field as an additional unique identifier.
>   The replies can then be correlated to requests by copying the Request
>   Authenticator from the request to a new attribute in the response,
>   called the Original-Request-Authenticator.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
>