Re: [radext] [[e-mail]] New Version Notification for draft-hartman-radext-bigger-packets-00.txt

[Peter Deacon <[e-mail]>]

On Mon, 21 Oct 2013, Sam Hartman wrote:

> I've written a draft that proposes expanding the maximum packet size for 
> RFC 6613-based transports including RFC 6614. This draft is 
> intentionally designed to be minimal: no capability negotiation as an 
> example.

> A few details such as the registration of code points are left out, but 
> I believe the draft is complete enough to evaluate the technical 
> approach.

> My draft is intentionally simpler than Peter's approach (or the part of 
> it that deals with this)

The way my draft is structured one can simply provide a non-default 
administrative option at each peer enabling large packets.  No new command 
codes or attributes required.

> I don't think the complexity of his approach is needed for solving the 
> part of the problem I would like to see solved.

Don't know how much the following matters for your uses - some things to 
think about.

Section 3.

With TCP any number of RADIUS requests could be in-flight before RADIUS 
server even sees a request to react.  When a connection is dropped client 
can't always even be sure what request if any closure was in response let 
alone why.

In response to closure specifically and the "too big" code in general how 
long should client think bigger-packets is not supported by server?  next 
connection? forever?


RFC6613 allows implementation to close TCP connection in response to 
unknown code.  This "MAY" cause a client not supporting bigger-packets to 
disconnect on receipt of the "too big" code.  This unfortunately is a good 
example why I don't support this language in RFC6613.

2. "Clients MAY silently discard a packet greater than some
    configured size"

How does this work?  For example I'm authenticating someone and 
Access-Accept is too big.  Do I assume access-reject?  Keep waiting for 
the response that is not too big?

regards,
Peter