[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: DISCUSS: draft-ietf-radext-fixes
Alan DeKok <mailto:aland@nitros9.org> allegedly scribbled on Monday,
July 02, 2007 2:15 PM:
> Glen Zorn (gwz) wrote:
>>> Not enforcing the monotonic requirement means that servers would
>>> need to keep a cache of recently used Identifiers for each NAS
>>> IP/UDP.
I didn't actually write this, David did.
...
>> Only if we assume that a) there is no capabilities exchange between
>> clients & servers or b) that RADIUS servers have virtually no
>> intelligence. If a server noticed that every single identifier
>> coming from a given client was 1 greater than the last over an hour
>> or so, couldn't it reasonably assume that the client was behaving in
>> the recommended fashion & process that client's requests in the more
>> efficient manner?
>
> As opposed to caching packets keyed by (source IP, source port, Id)
> for no more than 30 seconds?
>
> You're proposing keeping long-lived state to track Identifiers as a
> way to avoid keeping short-lived state to track Identifiers. It's an
> novell idea, but I don't see the benefit.
Your cache takes a minimum of 7 bytes/client/request. My flag can be a
bit set to 0 at start up -- if an non-increasing Identifier is ever
seen, flip the bit & fall back to the more expensive method.
>
> Alan DeKok.
--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>