Subject: [radext] [[email-masked]] New Version Notification for draft-hartman-radext-bigger-packets-00.txt

From: Sam Hartman <[email-masked]>
Date: Mon, 21 Oct 2013 15:57:57 -0400

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)
I don't think the complexity of his approach is needed for solving the
part of the problem I would like to see solved.

I believe this draft compliments draft-ietf-radext-radius-fragmentation
and would like to see my draft and that draft go forward.

Comments welocme.

Subject: New Version Notification for draft-hartman-radext-bigger-packets-00.txt
From: [email-masked]
To: Sam Hartman <[email-masked]>, "Sam D. Hartman" <[email-masked]>
Date: Mon, 21 Oct 2013 12:50:06 -0700

A new version of I-D, draft-hartman-radext-bigger-packets-00.txt
has been successfully submitted by Sam Hartman and posted to the
IETF repository.

Filename:	 draft-hartman-radext-bigger-packets
Revision:	 00
Title:		 Larger Packets for Remote RADIUS over TCP
Creation date:	 2013-10-21
Group:		 Individual Submission
Number of pages: 13
URL:             http://www.ietf.org/internet-drafts/draft-hartman-radext-bigger-packets-00.txt
Status:          http://datatracker.ietf.org/doc/draft-hartman-radext-bigger-packets
Htmlized:        http://tools.ietf.org/html/draft-hartman-radext-bigger-packets-00

Abstract:
   The RADIUS over TLS experiment described in RFC 6614 has opened
   RADIUS to new use cases where the 4096-octet maximum RADIUS packet
   proves problematic.  This specification extends the RADIUS over TCP
   experiment to permit larger RADIUS packets.  This specification
   compliments other ongoing work to permit fragmentation of RADIUS
   authorization information.

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

---

From: Alan DeKok <[email-masked]>
Date: Mon, 21 Oct 2013 16:55:33 -0400

> and would like to see my draft and that draft go forward.

  I think it's a good start.  I'd prefer capability negotiation, as it's
more robust.  But it also opens another can of worms which is better
left closed.

  Alan DeKok.

---

From: Peter Deacon <[email-masked]>
Date: Mon, 21 Oct 2013 17:29:35 -0700 (Pacific Daylight Time)

On Mon, 21 Oct 2013, Sam Hartman wrote:

> RFC 6613-based transports including RFC 6614. This draft is 
> intentionally designed to be minimal: no capability negotiation as an 
> example.

> My draft is intentionally simpler than Peter's approach (or the part of 

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.

> 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

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Tue, 22 Oct 2013 09:56:30 +0200

> and would like to see my draft and that draft go forward.

Sam,

thank you for this contribution, I think it is a better choice for 
situations where keeping the infrastructure untouched is not a MUST.

I have one comment. In the text, you state that:

Clients will not typically be able to adjust and resend requests when
    this error is received.

Having that expectation in mind, and wondering what the actual impact of 
just dropping the entire session is, wouldn't it be more simple to just 
send an Access-Reject code with the new attribute indicating the reason 
(eg. packet over 3500 octets), instead of defining a new code? The 
client would be able to re-start the session using smaller packets, 
RADIUS fragmentation or just desisting from it.

Of course, this would require to start over with the current session. 
But since you don't really expect clients to dynamically re-adjust 
packet size, that there might be a negotiation capability, and that 
there would probably exists a federation agreement... what is the real 
impact of just dropping the session?

Regards,
Alejandro
>
>
> _______________________________________________
> radext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/radext

---

From: "Satyanarayana Danda (sdanda)" <[email-masked]>
Date: Mon, 28 Oct 2013 05:58:08 +0000

I would like to second Alan to look at capability negotiation framework for these kind of extensions to be wel negotiated.

Thanks
Satya

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alan DeKok
Sent: Tuesday, October 22, 2013 2:26 AM
To: Sam Hartman
Cc: [email-masked]
Subject: Re: [radext] [[email-masked]] New Version Notification for draft-hartman-radext-bigger-packets-00.txt

> and would like to see my draft and that draft go forward.

  I think it's a good start.  I'd prefer capability negotiation, as it's more robust.  But it also opens another can of worms which is better left closed.

  Alan DeKok.