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

Alan said:

"Note that I'm *not* proposing a change to the Id field, or to much else in
the protocol."

[BA] +1 to that.

RADIUS is 25+ years old, and given the pace of change on the Internet, one
can make a case that protocol age is somewhat akin to "dog years".

That would make RADIUS 175 years old!

Changing the Id field in RADIUS is somewhat akin to attempting a heart
transplant on a 175 year-old.

While some doctor might try this (more as a "cash-ectomy" than a legitimate
procedure), let's not pretend that it is in the best interest of the
patient.

Carry on!

On Mon, Apr 24, 2017 at 1:00 PM, Alan DeKok <aland@freeradius.org> wrote:

>   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: internet-drafts@ietf.org
> > 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" <aland@freeradius.org>
> >
> >
> > 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
> >
>
>
> _______________________________________________
> radext mailing list
> radext@ietf.org
> https://www.ietf.org/mailman/listinfo/radext
>
>