Subject: Re: [eap] Discussion of Issue 162: Minimum MTU Not Defined

From: John Vollbrecht <[email-masked]>
Date: Mon, 04 Aug 2003 11:58:03 -0400

The minimum MTU is an interesting question.  I think I agree with Bernard.

Here is what is seems to me.

1. EAP does not have a way of dynamically knowing how big it max frame may 
be, based on MTU or anything else

2. EAP methods MAY or SHOULD do Fragmentation, but don't know what size to 
fragment to

3. Different lower layers may have different MTU

4. So, to be sure an EAP method runs on every lower layer, it must fragment 
at the Minimum MTU

5.  If the Minimum MTU is smaller than the actual MTU, some methods will 
fragment unnecessarily, causing performance problems

So, the alternatives seem to be

a. Set a Minimum MTU that supports all the desired lower methods (possibly 
excluding some?)
or
b. Allow an implementation to configure a Minimum MTU which methods would 
note and fragment to support.

The first seems simpler.  The second provides better ability to tune 
performance and function.  In either case, if a method does not support as 
low a fragmentation level as required by the lower layer it will not work.

I think this is probably a method implementation issue, and should be 
included as a method requirement or limit.

I lean to allowing implementation flexibility.  What do others think?

A straw man for sake of discussion might say something like:
"
Methods MUS support "minimum=?", fragmenting if required,  and MAY support 
configurable fragmentation at lower level to support smaller lower layer 
MTU and higher level to support performance on larger MTUs.  If 
Configurable MTU is supported the implemetation SHOULD notify the user if 
the configured MTU is too large for the lower layer.
"

--On Saturday, August 2, 2003 1:28 PM -0700 Bernard Aboba 
<[email-masked]> wrote:

> The text of Issue 162 is enclosed below.  Here is the proposed change and
> some commentary:
>
> "Minimum MTU. The EAP layer, the EAP Identity method,
> EAP Notification method and the NAK responses do NOT support
> fragmentation and reassembly. "
>
> [BA] Recommend adding EAP OTP, GTC and Challenge-MD5 to this list.
>
> EAP methods designed originally
> for use within PPP (where a 1500 byte MTU is guaranteed for
> control frames [RFC1661]) also lack fragmentation and reassembly features.
>
> [BA] It is true that the methods defined in RFC 2284 also do not support
> fragmentation and reassembly.  Since we don't have specifications for
> many methods that have been allocated type codes since then, it is hard to
> say whether the statement above is true or not.  Certainly EAP TLS [RFC
> 2716] does support fragmentation.
>
> Question: Is a 1500 byte MTU really guaranteed for control frames?  I seem
> to recall situations where only a 576 octet MTU was available.  My
> suggestion is that the above sentence be changed to "may lack
> fragmentation and reassembly features".
>
> "The lower layer transporting EAP MUST therefore be capable of carrying
> EAP frames of up to 1400 bytes unfragmented. Note also that EAP is a
> lock-step protocol, which implies a certain inefficiency when doing
> fragmentation and reassembly. The lower layer therefore SHOULD
> provide fragmentation and reassembly services."
>
> [BA] I don't know that we can impose this requirement on lower layers
> necessarily.  After all, the lower layers are what they are.  Suggest that
> the MUST be changed to a SHOULD.  Recommend that the last sentence be
> deleted.  Lower layers typically don't provide fragmentation and
> reassembly services, since that's an IP layer function.
>
> "Some implementations of EAP tend to piggy-back into an Identity
> Request or Response various options after a NUL-character. An EAP
> implementation SHOULD NOT assume that usernames or displayable messages
> over 1024 bytes in Identity Requests or Responses will work in all
> environments."
>
> [BA] Why is the limit only 1024 octets for Identity and a different number
> for other requests?
>
> Overall, my comment is that I'd prefer to recommend that methods assume a
> certain minimum MTU and that they MUST support fragmentation and
> reassembly if it is possible that frames can exceed this minimum MTU size.
> My overall impression was that we might have to live with a minimum MTU as
> low as 576 octets.
>
>
>
> ---------------------------------------------------------------------
> Issue 162: Minimum MTU Not Defined
> Submitter name: Lauri Tarkkala
> Submitter email address: [email-masked]
> Date first submitted: July 21, 2003
> Reference:
> http://mail.frascone.com/pipermail/public/eap/2003-July/001507.html
> Document: EAP-04
> Comment type: T
> Priority: S
> Section: Various
> Rationale/Explanation of issue:
>
> The current RFC2284bis draft does not define a minimum MTU that EAP
> methods can rely on. At least the following EAP methods do not
> do fragmenting:
> - Identity
> - Notification
> - MD5-Challenge
> - .. etc
> (- and Nak, which is not a method, but anyway)
>
> Currently the "minimum MTU" is "inherited" from PPP (1500 bytes),
> but all uses of EAP do not conform to this (e.g. PPPoe).
> A minimum MTU must be defined such that embeddings of EAP into
> other protocols will be such that implementations of these
> methods will always operate correctly. There are also
> the implied architectural limitations, which will cut
> across any system architecture which contains EAP:
>
> - Maximum identity length (unfragmented MTU - headers bytes -
>   maximum length of piggy-backed option settings)
> - Maximum notification length
>
> The defined minimum MTU should be defined to be as large
> as possible, due to the lossage implied when doing
> fragmentation/reassembly in a lock-step
> protocol. Note also that the composite protocol
> architecture may be doing fragmentation/reasembly
> in both the EAP transport and the EAP method, if
> the usage is improper.
>
> The proposed solution is in a nutshell:
> - Define that minimum frame size that can be sent/received unfragmented
>   by EAP as X bytes.
> - State the maximum notification length as X - headers.
> - State the maximum identity req/resp lengths as
>   Y = X - headers - possible options
> - State that because EAP is a lock-step protocol and if latency
>   is important and methods with large frames are used, the
>   EAP transport protocol SHOULD provide fragmentation and
>   reassembly services for frames upto 2^16 bytes.
> - Initial proposal of X as 1400 bytes. If somebody knows any protocols
>   that use EAP with MTU's then I'm sure we'd all like to hear about it.
>
> Hopefully somebody has the relevant experience from all EAP
> implementations to specify better values for X and Y than in the text
> below (1400 and 1024 respectively).
>
> Requested change:
>
> In section 3.1 ("Lower layer requirements") add below.
>
> "[4] MTU known a-priori.  The EAP layer does not support
> fragmentation and reassembly.  However, EAP methods SHOULD be capable of
> handling fragmentation and reassembly.  As a result, EAP is
> capable of functioning across a range of MTU sizes, as long as
> the MTU is known a-priori.  EAP does not support path MTU discovery."
>
> to
>
> "[5] Minimum MTU. The EAP layer, the EAP Identity method,
> EAP Notification method and the NAK responses do NOT support
> fragmentation and reassembly. EAP methods designed originally
> for use within PPP (where a 1500 byte MTU is guaranteed for
> control frames [RFC1661]) also lack fragmentation and reassembly features.
> The lower layer transporting EAP MUST therefore be capable of carrying
> EAP frames of up to 1400 bytes unfragmented. Note also that EAP is a
> lock-step protocol, which implies a certain inefficiency when doing
> fragmentation and reassembly. The lower layer therefore SHOULD
> provide fragmentation and reassembly services."
>
> ... and Change the numbering of the following items from [5] -> [6] and
> [6] -> [7].
>
> After the first paragraph in "Section 5.1" add:
>
> "Some implementations of EAP tend to piggy-back into an Identity
> Request or Response various options after a NUL-character. An EAP
> implementation SHOULD NOT assume that usernames or displayable messages
> over 1024 bytes in Identity Requests or Responses will work in all
> environments."
>
> Add to first paragraph in "Section 5.2" the sentences:
>
> "Note that the maximum length of a notification messages that can be used
> reliably in all EAP implementations is 1400 bytes. The length
> of the human readable message SHOULD therefore be at most 1395 bytes."
>
> --
> Lauri Tarkkala
> SSH Communications Security Corp
> http://www.ssh.com/
> _______________________________________________
> eap mailing list
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/eap

_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 4 Aug 2003 09:59:04 -0700 (PDT)

> be, based on MTU or anything else

Since the EAP layer doesn't support fragmentation, the MTU is only
relevant to an EAP method that supports fragmentation.

Also, where EAP is run over the Internet, the MTU would need to be
determined by path-MTU discovery and/or set to a large value if the intent
is to handle fragmentation via a reliable transport (TCP, SCTP) or via IP
fragmentation.

But there *are* mechanisms by which the MTU, once determined can be
utilized by EAP methods.  Existing implementations do this.

If we are talking about EAP over a link layer, then on the peer the link
layer MTU can be passed up to the EAP method which can adjust its frame size,
assuming that it supports fragmentation.  Things are trickier on the
authentication server.  It can determine the appropriate EAP MTU from the
NAS-Port-Type attribute as well as the Framed-MTU attribute.  For 802.1X
and PPP this is Framed-MTU - 4;  for other NAS-Port-Type values the
calculation might be different.

> 2. EAP methods MAY or SHOULD do Fragmentation, but don't know what size to

I would say SHOULD do fragmentation and SHOULD make use of MTU information
passed from the lower layer.

> 3. Different lower layers may have different MTU

Yes.

> 4. So, to be sure an EAP method runs on every lower layer, it must fragment

An EAP method needs to support fragmentation if its frames can be larger
than the minimum MTU.  But I don't agree that it needs to fragment if it
knows that the MTU is large enough so that fragmentation isn't required.

> fragment unnecessarily, causing performance problems

This is not required.

> a. Set a Minimum MTU that supports all the desired lower methods (possibly

Not sure what a "lower method" is.  Do you mean "lower layer"?  The
purpose of setting a minimum MTU is so that methods can determine whether
they need to support fragmentation or not.  For example, EAP Archie does
not support fragmentation -- but depending on the minimum MTU, adding
support might be appropriate.

> note and fragment to support.

It is undesirable to force fragmentation to a minimum MTU when the actual
MTU is known to be larger.

---

From: John Vollbrecht <[email-masked]>
Date: Mon, 04 Aug 2003 15:43:25 -0400

--On Monday, August 4, 2003 9:59 AM -0700 Bernard Aboba 
<[email-masked]> wrote:

> > 1. EAP does not have a way of dynamically knowing how big it max frame
> > may be, based on MTU or anything else
>
> layer MTU can be passed up to the EAP method which can adjust its frame
> size, assuming that it supports fragmentation.  Things are trickier on the
Should we include such mechanisms to pass MTU to the method in either 
2284bis or EAP-SM?  I think it could be a reasonable option.

> > 2. EAP methods MAY or SHOULD do Fragmentation, but don't know what size
> > to fragment to
>
as you point out, fragmentat only if needed.  And fragment to a standard 
"minimum" or to what is passed from the lower layer.

> > 4. So, to be sure an EAP method runs on every lower layer, it must
> > fragment at the Minimum MTU
>
yes
> > fragment unnecessarily, causing performance problems
yes - if MTU is passed, then fragmentation can be to the passed value, not 
the minimum.

> > a. Set a Minimum MTU that supports all the desired lower methods
> > (possibly excluding some?)
>
> Not sure what a "lower method" is.  Do you mean "lower layer"?
yes
> The
agree

> > b. Allow an implementation to configure a Minimum MTU which methods
> > would note and fragment to support.
>
agree - my issue is how it know how big it is

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 4 Aug 2003 16:01:25 -0700 (PDT)

> 2284bis or EAP-SM?  I think it could be a reasonable option.

I'd suggest that we should at least describe what is within the realm of
possibility and provide some advice on what implementations should do.  In
practice, we've seen quite a few interoperability problems result from
ignoring the MTU.  For example, there are RADIUS implementations that
attempt to send 16K EAP-TLS frames over an 802.11 link :)

> "minimum" or to what is passed from the lower layer.

Right -- if no information is available, the default assumption is the
minimum MTU.  Otherwise use what is passed from the lower layer.

> agree - my issue is how it know how big it is

Yes. That's what we've got figure out: what is the minimum MTU for EAP if
no other information is available?
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: John Vollbrecht <[email-masked]>
Date: Mon, 04 Aug 2003 20:19:52 -0400

--On Monday, August 4, 2003 4:01 PM -0700 Bernard Aboba 
<[email-masked]> wrote:

.
.
.

> no other information is available?
and how to describe what is passed to the EAP method.  It sounds like you 
have a good handle on this from what you described earlier.  Should there 
be an interface to the method describing a variable that it can check to 
see if an MTU is available?

do people think the spec should also include operational info, like how to 
decide what to pass the method?  For example, if the MTU can be determined 
by the lower layer then everything could be automatic if the method can 
deal with the MTU it gets.  If the lower layer is not able to send the MTU, 
should the MTU be configurable?