Subject: [radext] Short draft on using larger packets for TLS fragmentation

From: Sam Hartman <[email-masked]>
Date: Sun, 07 Jul 2013 22:28:43 -0400

There seems to be consensus on the idea that TCP level fragmentation is
the right way to fragment TLS when you can afford to change the proxies.
In fact, we may even have consensus that since RADSEC is experimental
that it's reasonable to assume that people who need fragmentation and
RADSEC can upgrade their proxies.

I'm tempted to write a short draft that revises RADSEC, permits larger
RADIUS messages and introduces a mechanism for saying that  you cannot
respond to a request without being able to send a larger fragment.

This does not provide negotiation nor does it provide support for the
proxy unmodified case.  However at least as I've been reading the WG
discussion, we all seem to agree this is the best approach when it is
possible.  Also, such a draft would not preclude using a future
negotiation mechanism and could work well along-side Alex's draft.

I'd kind of like to get to noises of support soon if I'm going to put
this together.  I understand the 00 deadline has been removed but I'd
rather publish sooner than later.

If this is published I'd like this to be consider as part of the
fragmentation discussion.  It's been brought up a number of times.

---

From: Peter Deacon <[email-masked]>
Date: Mon, 8 Jul 2013 08:46:23 -0700 (Pacific Daylight Time)

> respond to a request without being able to send a larger fragment.

Only concern with this approach UDP compatibility is lost.

> negotiation mechanism and could work well along-side Alex's draft.

My draft addresses TCP limits (4.2) while concurrently providing for UDP 
interop (4.1) should it be desired.

Those who see no value in UDP interop can elect not to implement Section 
4.1.

Section 4.2 provides for larger messages via TCP and communicating message 
limits.  It's not even necessary to support 4.2 command code and 
attributes to communicate message limits.  Support for large messages is 
allowed to be an administrative option provided it is not enabled by 
default.

regards,
Peter

---

From: Sam Hartman <[email-masked]>
Date: Mon, 08 Jul 2013 12:24:28 -0400

>>>>> "Peter" == Peter Deacon <[email-masked]> writes:

    Peter> On Sun, 7 Jul 2013, Sam Hartman wrote:

    Peter> Section 4.2 provides for larger messages via TCP and
    Peter> communicating message limits.  It's not even necessary to
    Peter> support 4.2 command code and attributes to communicate
    Peter> message limits.  Support for large messages is allowed to be
    Peter> an administrative option provided it is not enabled by
    Peter> default.

Yeah, I was taking 4.2 out of your draft as inspiration.
I agree my approach does not of itself give UDP interop.
However, this approach works well either with your approach or Alex's
approach, but seems to be close enough to WG agreement that we might be
able to move on it this year.
Once we get consensus on a broader solution I think it can fit in.

I don't promise to use the same framing as your section 4.2, but your
contributions to this discussion particularly in that section are very
much on my mind in terms of what we're trying to accomplish.

I'm trying to separate out what we seem to have agreement on so that I
can start shipping code.