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

[Enke Chen <[e-mail]>]

Hi, Bernard:

In this case it is more like a "wart removal" than a "heart transplant" :-)

Regards,  -- Enke

On 4/24/17 2:20 PM, Bernard Aboba wrote:
> 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 <[e-mail] <mailto:[e-mail]>> 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: [e-mail] <mailto:[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] <mailto:[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 <https://www.ietf.org/internet-drafts/draft-dekok-radext-request-authenticator-00.txt>
>     > Status:         https://datatracker.ietf.org/doc/draft-dekok-radext-request-authenticator/ <https://datatracker.ietf.org/doc/draft-dekok-radext-request-authenticator/>
>     > Htmlized:       https://tools.ietf.org/html/draft-dekok-radext-request-authenticator-00 <https://tools.ietf.org/html/draft-dekok-radext-request-authenticator-00>
>     > Htmlized:       https://datatracker.ietf.org/doc/html/draft-dekok-radext-request-authenticator-00 <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 <http://tools.ietf.org>.
>     >
>     > The IETF Secretariat
>     >
> 
> 
>     _______________________________________________
>     radext mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/radext <https://www.ietf.org/mailman/listinfo/radext>
> 
> 
> 
> 
> _______________________________________________
> radext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/radext
>