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

From: [email-masked] (Bernard Aboba)
Date: Sat, 2 Aug 2003 13:28:42 -0700 (PDT)

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/