Subject: [eap] minimum MTU undefined

From: [email-masked] (Lauri Tarkkala)
Date: Mon, 21 Jul 2003 20:16:03 +0300

Minimum MTU not defined.

Submitter name: Lauri Tarkkala
Submitter email address: [email-masked]
Date first submitted: 2003-07-21
Reference: 
Document: RFC2284bis
Comment type: 'T'
Priority: 'S'
Section:
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 upto 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/

---

From: [email-masked] (Jari Arkko)
Date: Wed, 30 Jul 2003 20:23:46 +0300

> methods will always operate correctly. There are also

I agree.

> - Maximum notification length 

Yep.

>   that use EAP with MTU's then I'm sure we'd all like to hear about it.

Sounds good!

--Jari