[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/>