Subject: [radext] Summary of Where we are with Fragmentation

From: Sam Hartman <[email-masked]>
Date: Thu, 14 Mar 2013 11:20:18 -0400

Hi.
we've had a lot of messages on fragmentation. Here's where we are in my
understanding.
Please correct me if I'm wrong.

1) Alex's draft supports fragmentation through existing proxies. Alex,
Alan, and I believe this is important to support.
Peter said a while back that he's not opposed to having a way to do this
but support through existing proxies is not his focus because that
support doesn't support arbitrary command codes such as accounting.

2) Alan, Jim Schaad, Margaret Wasserman and I believe it is strongly
desirable to use large packets to handle fragmentation when using TCP or
TLS. Peter supports this with his fragmentation inquery concept.

3) Peter would like to support fragmentation over UDP in a manner that
supports all command codes. As a consequence this doesn't work with
existing proxies. This is is fragmentation data concept. Peter believes
the overhead of setting up TCP may be too high for some situations.

4) I don't support fragmentation data because I believe TCP/TLS is
sufficient of a solution in cases where you are willing to upgrade
equipment. Peter's solution will be much harder to standardize. In
addition, I don't think the overhead of TCP connection establishment is
significant with tuned equipment.

5) Alan doesn't support the fragmentation data concept from Peter's
proposal. I don't remember the reasons he cites.

6) Alex's draft involves reassembley both at the IP layer because
packets larger than MTU are sent as well as reassembley at the RADIUS
layer (it's a fragmentation mechanism after all.) I believe this is
inherent when you want to support existing proxies. However, it does
have transport implications that make it desirable to use an alternative
mechanism when you can upgrade equipment.  In my mind I'm not being
critical of Alex's draft; I'm just trying to scope when it makes sense.

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Thu, 14 Mar 2013 17:47:10 +0100

Hi Sam,

see my comment inline, please.

> critical of Alex's draft; I'm just trying to scope when it makes sense.
Well, the idea is to maintain chunk size below PMTU, hence there would 
no need to reassemble at IP layer and thus we avoid UDP fragmentation. 
That's one of the reasons why we don't want to interfere with RADIUS-EAP 
which already fills RADIUS packets up to the PMTU.

Regards,
Alejandro

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

---

From: Sam Hartman <[email-masked]>
Date: Thu, 14 Mar 2013 13:19:05 -0400

How do you plan to figure out what the path mtu is?

---

From: Alan DeKok <[email-masked]>
Date: Thu, 14 Mar 2013 13:58:39 -0400

> How do you plan to figure out what the path mtu is?

  Telephone.  Or email.

  The MTU should be settable by the proxy.  The administrator then plays
with it until it works.

  I've spent some time reading up on UDP PTMU discovery.  In short, it
doesn't work well in IPv4.  It's worse in IPv6.

  Pretty much all of the UDP applications I've seen turn PMTU discovery
off.  Enabling it means that the kernel may do PMTU discover on every
packet sent by the application.  That's bad.

  Alan DeKok.

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Thu, 14 Mar 2013 19:09:36 +0100

Hi Sam,

it seems to be several RFC dealing with that specific problem (4821, 
1191, 1981). Sorry if I'm assuming they work, but actually they don't. I 
assumed that was somehow trivial.

Regards,
Alejandro

---

From: Sam Hartman <[email-masked]>
Date: Thu, 14 Mar 2013 14:18:57 -0400

>>>>> "Alan" == Alan DeKok <[email-masked]> writes:

    >> How do you plan to figure out what the path mtu is?

    Alan>   Telephone.  Or email.

No, but if multiple proxies are involved, how do you get the information
to the other side of the path.

--Sam

---

From: Alan DeKok <[email-masked]>
Date: Thu, 14 Mar 2013 14:24:56 -0400

> to the other side of the path.

  The same way people do now.  Email or telephone. :(

  It's ugly and non-scalable, but it works.

  A workable PMTU discovery would involve some kind of multi-proxy
capability negotiation.

  Or, everyone sets PMTU to 576 octets, and hopes for the best.

  Alan DeKok.

---

From: Sam Hartman <[email-masked]>
Date: Thu, 14 Mar 2013 14:32:38 -0400

Alan> Sam Hartman wrote:
    >> No, but if multiple proxies are involved, how do you get the
    >> information to the other side of the path.

    Alan>   The same way people do now.  Email or telephone. :(

That doesn't seem realistic.
Consider a case like eduroam.
I have a path that goes from a->b->c->d

It seems reasonable for the operators of a and b to call each other.
But how does a learn the mtu between c and d?

Phone or e-mail don't seem like reasonable options for that.

---

From: Alan DeKok <[email-masked]>
Date: Thu, 14 Mar 2013 16:30:08 -0400

> That doesn't seem realistic.

  It's not.

> But how does a learn the mtu between c and d?

  We need a way for RADIUS servers to exchange MTU for specific paths.
This information probably needs to be part of a capabilities exchange,
and / or a RADIUS routing protocol.

  Alan DeKok.

---

From: Peter Deacon <[email-masked]>
Date: Thu, 14 Mar 2013 23:59:22 -0700 (Pacific Daylight Time)

> support doesn't support arbitrary command codes such as accounting.

I am not opposed to Alex's draft in principal assuming constraint of 
working with existing proxies that can't be upgraded.

> the overhead of setting up TCP may be too high for some situations.

I don't have a negative opinion of TCP setup time.

Prefer UDP since there are no delays or dependencies on flight of other 
requests.  No head of line where RTO effects a queue of requests rather 
than a single request.  Tend to identify with sentiments of RFC 2865 
section 2.4.

On the other hand Fragment-Data wins no prize for round trip efficiency or 
congestion avoidance.

> sufficient of a solution in cases where you are willing to upgrade

A problem here is if you don't provide an analogue for UDP with the same 
capabilities then TCP and UDP universes cannot be bridged.

It was intended to be separable so implementors can decide the best 
approach (TCP and or UDP) for their needs.

> equipment. Peter's solution will be much harder to standardize. In

Is this because there are two options (TCP and Fragment-Data) or something 
about Fragment-Data?

regards,
Peter

---

From: Sam Hartman <[email-masked]>
Date: Mon, 18 Mar 2013 08:23:23 -0400

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

    Peter> I don't have a negative opinion of TCP setup time.

    Peter> Prefer UDP since there are no delays or dependencies on
    Peter> flight of other requests.  No head of line where RTO effects
    Peter> a queue of requests rather than a single request.  Tend to
    Peter> identify with sentiments of RFC 2865 section 2.4.

If you want this behavior, open multiple TCP requests or propose RADIUS
over SCTP.

With regard to Alex's draft and the MTU issue, I stand behind my claim
that it will tend to involve fragmentation at multiple layers.  There's
no way to learn the MTU that is currently being proposed.  In addition,
because the protocol is lock-step, there is a significant penalty to
limiting the size of transmitted packets.

I think both Peter's fragmentation data approach and Alex's draft will
require significant transport review because they both propose protocols
with complex MTU/congestion/fragmentation/performance characteristics.
In the case of Alex's draft I expect the conclusion will be that there's
no better option that works with existing proxies. With respect to
Peter's fragmentation data, I believe the analysis is that UDP is the
wrong option for what he's trying to do and we have multiple better
transport options available.

--Sam

---

From: Alan DeKok <[email-masked]>
Date: Mon, 18 Mar 2013 09:33:58 -0400

I agree with SAM here.  Re-implementing TCP over UDP is a horrible
idea.  The only reason to use it is the limitations of existing proxy
networks.

  Alan DeKok.

---

From: Peter Deacon <[email-masked]>
Date: Mon, 18 Mar 2013 08:37:47 -0700 (Pacific Daylight Time)

> If you want this behavior, open multiple TCP requests or propose RADIUS

I agree these are alternatives.

> with complex MTU/congestion/fragmentation/performance characteristics.

While I understand why this issue is being raised I don't understand what 
makes Alex's upcoming draft different than EAP and operational experience 
applicable to its use.

> transport options available.

UDP is what is actually being used.  I don't have the luxury of ignoring 
it.

regards,
Peter

---

From: Alan DeKok <[email-masked]>
Date: Mon, 18 Mar 2013 14:46:57 -0400

Peter Deacon wrote:
> While I understand why this issue is being raised I don't understand
> what makes Alex's upcoming draft different than EAP and operational
> experience applicable to its use.

  Many uses of EAP are EAPoL.  EAP over RADIUS is really using RADIUS as
a replacement for Ethernet.  As such, any expectations about the
transport layer are pretty much zero.  It gets a packet from A to B.
Mostly.  Most of the time.

  The fragmentation proposals are doing transport of bulk data.  As
such, they're really competing with TCP.

  RADIUS is a horrible replacement for TCP.  It's only being proposed
here (IMHO) as a temporary migration path.  Once the proxies do RADIUS
over TCP, *and* allow for 64K RADIUS packets, the fragmentation
proposals become less relevant.

  Alan DeKok.

---

From: Peter Deacon <[email-masked]>
Date: Mon, 18 Mar 2013 12:30:39 -0700 (Pacific Daylight Time)

>  The fragmentation proposals are doing transport of bulk data.  As such, 
> they're really competing with TCP.

What is different about the semantics of transporting EAP over RADIUS 
compared with Alex's draft?

On the surface they both appear to me to have the same properties.  If I 
am missing something any hints/clue would be much appreciated.

Both are transported blindly thru proxies without regard for intermediate 
MTU considerations.

Both are lock step, both give the sender full control over amount of data 
to be transmitted at a time.

If they are the same I would just expect operational experience (positive 
or negative) from widely deployed experience with EAP to also be directly 
applicable to Alex's draft.

> proposals become less relevant.

Horrible is an opinion not a reason.  You still have to deliver to/from 
clients which far outnumber server implementations.

regards,
Peter

---

From: Alan DeKok <[email-masked]>
Date: Mon, 18 Mar 2013 15:37:42 -0400

> compared with Alex's draft?

  I explained that in my previous message.

> clients which far outnumber server implementations.

  The use-cases for abfab are largely dealing with RADIUS servers.
Access points likely won't be sending SAML assertions.

  If the systems need to send bulk data over RADIUS, they will upgrade.
 For now, upgrading RADIUS servers is easier than upgrading clients.
It's also a first step.  There's no point in upgrading clients until the
RADIUS servers support TCP.

  Alan DeKok.

---

From: Peter Deacon <[email-masked]>
Date: Mon, 18 Mar 2013 13:27:50 -0700 (Pacific Daylight Time)

>  I explained that in my previous message.

I reread your message and did not see the relevance.  The client 
retransmits in lock step the same as Alex's.  Ethernet properties are 
irrelevant.

What is the average expected size of SAML data to be transported?

>From draft-perez-radext-radius-fragmentation-05 Section 5.
"It is RECOMMENDED that the limits be set to a few tens of kilobytes"

Transporting >=2048 bit public keys and certificate chains over EAP adding 
all the round trips to negotiate methods and handshake seems to be a 
pretty good approximation of handling data both in terms of maxing out MTU 
and dealing with about the same number of round trips.

I'm not saying this is good or bad I'm just trying to understand the major 
differences that prevent EAP being used to reason about the properties of 
Alex's draft.

regards,
Peter

---

From: Alan DeKok <[email-masked]>
Date: Mon, 18 Mar 2013 18:13:34 -0400

> retransmits in lock step the same as Alex's.  Ethernet properties are

  I explained why they're not.

> I'm not saying this is good or bad I'm just trying to understand the
> major differences that prevent EAP being used to reason about the
> properties of Alex's draft.

  I did *not* say anyone was prevented from using EAP like that.  *I*
used EAP like that.

  Can you explain why you keep straw-manning me?

  Supplicants *can't* do TCP, because they have no net access.  So any
EAP transport is *allowed* to be horrible, because it's no worse than
Ethernet.

  RADIUS servers *can* do TCP, so horrible transports are use only when
there is no alternative.

  I don't *care* that Alex's draft is no worse (or better) than EAP.  A
better alternative exists: TCP.  Therefore we should use it.  The only
reason to *not* use TCP is implementation delays.

  Alan DeKok.

---

From: Peter Deacon <[email-masked]>
Date: Mon, 18 Mar 2013 16:29:48 -0700 (Pacific Daylight Time)

> reason to *not* use TCP is implementation delays.

I think there is a misunderstanding in what has been asked.  In the 
context of my question I am not concerned with:

What can or can't do TCP
Which protocol is better
Why protocol x is better than protocol y
Why x implements y while z implements c

The only question or observation I wish to make is that Alex's scheme 
whatever you may think of it looks a lot like EAP over RADIUS in terms of 
lock step, maximum fragment size, rough number of round trips and presence 
of proxies forwarding up to maximum fragment size.

To the extent comments about the properties of Alex's fragmentation scheme 
are being discussed specifically the following concerns expressed by Sam:

"draft will require significant transport review because they both propose 
protocols with complex MTU/congestion/fragmentation/performance 
characteristics."

"Alex's draft and the MTU issue, I stand behind my claim that it will tend 
to involve fragmentation at multiple layers.  There's no way to learn the 
MTU that is currently being proposed."

My observation or question is could we look toward current widespread 
deployment of RADIUS/EAP to help understand these concerns with respect to 
Alex's fragmentation scheme only?

Again I am not making any determinations and I understand EAP is more 
conversational than bulk transfer and there are different constraints 
however the MTU issue especially I believe could benefit from operational 
experience with RADIUS/EAP.

regards,
Peter

---

From: Sam Hartman <[email-masked]>
Date: Mon, 18 Mar 2013 20:08:12 -0400

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

    Peter> To the extent comments about the properties of Alex's
    Peter> fragmentation scheme are being discussed specifically the
    Peter> following concerns expressed by Sam:

    Peter> "draft will require significant transport review because they
    Peter> both propose protocols with complex
    Peter> MTU/congestion/fragmentation/performance characteristics."

    Peter> "Alex's draft and the MTU issue, I stand behind my claim that
    Peter> it will tend to involve fragmentation at multiple layers.
    Peter> There's no way to learn the MTU that is currently being
    Peter> proposed."

    Peter> My observation or question is could we look toward current
    Peter> widespread deployment of RADIUS/EAP to help understand these
    Peter> concerns with respect to Alex's fragmentation scheme only?

Yes. 
I think that will help us.

---

From: Alan DeKok <[email-masked]>
Date: Mon, 18 Mar 2013 20:09:00 -0400

> Why x implements y while z implements c

  OK.

> whatever you may think of it looks a lot like EAP over RADIUS in terms
> of lock step, maximum fragment size, rough number of round trips and
> presence of proxies forwarding up to maximum fragment size.

  Yes, they look very similar.

> To the extent comments about the properties of Alex's fragmentation
> scheme are being discussed specifically the following concerns expressed
> by Sam:
> 
> "draft will require significant transport review because they both
> propose protocols with complex MTU/congestion/fragmentation/performance
> characteristics."
> 
> "Alex's draft and the MTU issue, I stand behind my claim that it will
> tend to involve fragmentation at multiple layers.  There's no way to
> learn the MTU that is currently being proposed."
> 
> deployment of RADIUS/EAP to help understand these concerns with respect
> to Alex's fragmentation scheme only?

  No.

  We can point to EAP over RADIUS and say that fragmentation will
*mostly* work.

  The transport people don't care.  They will describe it as a horrible
hack, and they will be right.  They will point out that we can use TCP
instead of fragmentation, and they will be right.

  The only defense is to say it's a temporary measure meant to work with
existing implementations.  The transport people will ensure that the
fragmentation draft has big warnings saying it's a terrible idea that
will destroy the Internet and should be removed ASAP.  (I'm only
slightly exaggerating)

> however the MTU issue especially I believe could benefit from
> operational experience with RADIUS/EAP.

  Of course.

  The traditional RADIUS response to MTU issues is to stick your fingers
in your ears and say <la la la la la>

  Alan DeKok.

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 18 Mar 2013 17:30:17 -0700

It is unclear to me how much looking at this will help.  My understand
(possibly wrong) is that the EAP fragmentation issue has as much to do with
the MTU size on the network between the client and NAS as anything else.
This is going to be frequently smaller than the MTU size between the NAS and
the server and thus becomes a huge gating factor that has nothing to do with
internet congestion itself.  The choice of making EAP do the fragmentation
rather than having the NAS do it is a trade off in terms of where the
complexity lies (i.e. just with the people who talk EAP) rather than having
it occur on every protocol that is between clients and NAS boxes.

Jim

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Sam Hartman
> Sent: Monday, March 18, 2013 5:08 PM
> To: Peter Deacon
> Cc: [email-masked]; Alan DeKok
> Subject: Re: [radext] Summary of Where we are with Fragmentation
>

---

From: Stefan Winter <[email-masked]>
Date: Tue, 19 Mar 2013 09:24:53 +0100

Hi,

> Both are transported blindly thru proxies without regard for
> intermediate MTU considerations.
> 
> Both are lock step, both give the sender full control over amount of
> data to be transmitted at a time.
> 
> If they are the same I would just expect operational experience
> (positive or negative) from widely deployed experience with EAP to also
> be directly applicable to Alex's draft.

That's just not correct: the maximum size of EAP-Message in EAPoL in a
RADIUS packet is not "in full control of the sender" - it is limited by
the L2 MTU between supplicant and the pass-through authenticator.

In practice, this means: 1500 Bytes for Ethernet; some have been
experimenting with 21xx for the wireless medium, but that rarely works.

1500 Bytes of EAP-Message usually do trigger UDP fragmentation; but even
with a fair number of attributes added by RADIUS besides the core
EAP-Message, they don't exceed 4096 Bytes and thus don't require
RADIUS-level packet fragments. I.e. it's a non-issue.

BTW, the operational experience with UDP fragmentation in eduroam is far
from perfect: EAP types which tend to fill the L2 MTU to the max
sometimes won't authenticate because somewhere along the path, UDP
fragments are erroneously discarded (well, many instances of that some
years ago; meanwhile we test these things and so have found most of the
ill firewalls which do that).

The problems with UDP frags make many IdPs send their EAP
server-to-supplicant with EAP-Message <= 1024 Bytes; so that even adding
RADIUS attributes to the packet will stay below typical UDP
fragmentation thresholds. That's "better safe than sorry" but decreases
efficiency - more roundtrips.

Back in the day (IETF 69!) I argued that working on a RADIUS MTU
discovery to prevent UDP fragmentation would be a good thing. I have
meanwhile given up on the hope that it will be specified *and* actually
work; I believe that human energy is better spent in fixing broken
firewalls to make UDP fragmentation work in the first place.

So, in short: for EAPoL

- UDP fragmentation is a (purely operational) issue
- RADIUS total packet size fragmentation is not

Greetings,

Stefan Winter

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et
de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473