Subject: [eap] Proposed resolution to Issue 162: Minimum MTU not defined

From: Bernard Aboba <[email-masked]>
Date: Tue, 5 Aug 2003 23:52:14 -0700 (PDT)

The text of Issue 162 is enclosed below.  The proposed fix is as follows:

In section 3.1, Change:

"[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:

"[4] Minimum MTU.  EAP is capable of functioning on lower
layers that provide an EAP MTU size of 1020 octets or greater.

EAP does not support path MTU discovery, and fragmentation and
reassembly is not supported by EAP, nor by the methods
defined in this specification: the Identity (1),
Notification (2), Nak Response (3), MD5-Challenge (4),
One Time Password (5), Generic Token Card (6)
and expanded NAK Response (254) Types.

Typically, the EAP peer obtains information on the EAP MTU from the
lower layers and sets the EAP frame size to an appropriate value.
Where the authenticator operates in pass-through mode, the
authentication server does not have a direct way of determining
the EAP MTU, and therefore relies on the authenticator to provide
it with this information, such as via the Framed-MTU attribute,
described in [RFC3579], Section 2.4.

While methods such as EAP-TLS [RFC2716] support fragmentation
and reassembly,  EAP methods designed originally for use within PPP
(where a 1500 octet MTU is guaranteed for control frames
(see [RFC1661], Section 6.1) may lack fragmentation and reassembly
features.

EAP methods can assume a minimum EAP MTU of 1020 octets, in the
absence of information provided by the lower layer.  EAP methods SHOULD
include support for fragmentation and reassembly if their payloads
can be larger than this minimum EAP MTU.

EAP is a lock-step protocol,  which implies a certain inefficiency
when handling fragmentation and reassembly.  Therefore if the
lower layer supports fragmentation and reassembly
(such as where EAP is transported over IP), it may be
preferrable for fragmentation and reasembly to occur in the
lower layer rather than in EAP.   This can be accomplished by
having the lower layer provide an artificially large EAP MTU to
EAP, causing fragmentation and reassembly to be handled within the
lower layer."

After the first paragraph in Section 5.1, add:

"Some EAP implementations piggy-back various options into the Identity
Request after a NUL-character. An EAP implementation SHOULD NOT assume
that an Identity Request or Response can be larger than 1020 octets
in the absence of other information."

Add to the 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 1020 octets. The length
of the human readable message SHOULD therefore be at most 1015 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

---

From: Jari Arkko <[email-masked]>
Date: Wed, 06 Aug 2003 10:40:44 +0300

> EAP, causing fragmentation and reassembly to be handled within the

Very good.

> in the absence of other information."

How about a paragraph break between the two sentences? The above
left me wondering whether you meant that we can go over 1020 octets
if there are not options ("other information") after the NUL.

> of the human readable message SHOULD therefore be at most 1015 octets."

Ok.

--Jari

---

From: John Vollbrecht <[email-masked]>
Date: Wed, 06 Aug 2003 17:00:56 -0400

nice -- this seems good to me.

-- John