Subject: [Emu] Martin Stiemerling's Discuss on draft-ietf-emu-eap-tunnel-method-07: (with DISCUSS)

From: "Martin Stiemerling" <[email-masked]>
Date: Thu, 08 Aug 2013 12:24:11 -0700

Martin Stiemerling has entered the following ballot position for
draft-ietf-emu-eap-tunnel-method-07: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-emu-eap-tunnel-method/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Two points about Section 3.7. "Fragmentation"
- Both ends have to wait for either each fragment or fragment ack to
arrive. However, the timers on how to long to wait before giving up
waiting for fragments or acks are missing. 

- how does the sending TEAP entity determine what the maximum
transmission unit (MTU) of the path is?

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Fri, 9 Aug 2013 23:20:30 +0000

> http://datatracker.ietf.org/doc/draft-ietf-emu-eap-tunnel-method/

[Joe] Retransmission and timeout behavior for EAP is discussed in the EAP RFC 3748 Section 4.3. 

> transmission unit (MTU) of the path is?

[Joe] Typically EAP receives MTU information from the lower layer.  This is described in EAP RFC 3748 section 3.1.

---

From: Sam Hartman <[email-masked]>
Date: Wed, 14 Aug 2013 16:16:00 -0400

>>>>> "Joseph" == Joseph Salowey (jsalowey) <[email-masked]> writes:

    Joseph> [Joe] Retransmission and timeout behavior for EAP is
    Joseph> discussed in the EAP RFC 3748 Section 4.3.

Echoing Joe's point, we over in abfab (draft-ietf-abfab-gss-eap) would
be really unhappy if EAP method specs started discussing timeouts.

---

From: Martin Stiemerling <[email-masked]>
Date: Tue, 20 Aug 2013 17:47:58 +0200

Hi Joe,

Sorry for the delayed response -- I have been away for my vacation.

>> - Both ends have to wait for either each fragment or fragment ack
>> to arrive. However, the timers on how to long to wait before giving
>> up waiting for fragments or acks are missing.
>>
>

The cited section describes retransmission and the associated timeouts 
for complete messages, but **not** fragments!

RFC 3748 says clearly in Section 1:
"Fragmentation is not supported within EAP itself; however, individual 
EAP methods may support this."

I assume TEAP is an EAP method that has to write-up how fragmentation is 
handled, isn't it?

> [Joe] Typically EAP receives MTU information from the lower layer.
> This is described in EAP RFC 3748 section 3.1.

Ok, I am fine to clear this position if you add a pointer to RFC 3748, 
Section 3.1 -- as a reminder for the implementers where to look for 
guidance.

   Martin

-- 
[email-masked]

NEC Laboratories Europe
NEC Europe Limited
Registered Office:
Athene, Odyssey Business Park, West End  Road, London, HA4 6QE, GB
Registered in England 2832014

---

From: Martin Stiemerling <[email-masked]>
Date: Tue, 20 Aug 2013 17:49:18 +0200

Hi Sam,

> be really unhappy if EAP method specs started discussing timeouts.

It is not about the EAP timeouts for whole messages, but timeouts for 
fragments are not defined in RFC 3748 and must be defined somewhere, as 
well as, what happens if timeouts are exceeded for fragments.

   Martin

NEC Laboratories Europe
NEC Europe Limited
Registered Office:

---

From: Sam Hartman <[email-masked]>
Date: Sat, 24 Aug 2013 09:41:00 -0400

>>>>> "Martin" == Martin Stiemerling <[email-masked]> writes:

    Martin> Hi Sam,
    >> 
    >> Echoing Joe's point, we over in abfab (draft-ietf-abfab-gss-eap)
    >> would be really unhappy if EAP method specs started discussing
    >> timeouts.

    Martin> It is not about the EAP timeouts for whole messages, but
    Martin> timeouts for fragments are not defined in RFC 3748 and must
    Martin> be defined somewhere, as well as, what happens if timeouts
    Martin> are exceeded for fragments.

If an inner method supports fragmentation, then each fragment is a
"whole EAP message," in your terminology quoting RFC 3748.

More particularly, the interface between EAP and a lower layer says that
EAP methods hand EAP a message.
The EAP state machine gets a timeout from the lower layer as defined in
RFC 3748.
The EAP state machine uses the retransmit behavior in RFC 3748.

It's possible that a method has internally fragmented some larger (we'll
call these fragmentables for the moment) messages into the EAP messages
handed to EAP by the method.
If so, then EAP has no way to know whether these are fragments or
whether the method simply doesn't support fragmentation.
At the EAP layer, messages are messages.
The difference between messages and fragmentables is only visible within
a method.

The abstract interface of EAP does not permit methods to influence the
retransmission behavior, nor for messages generated from fragmentation
to have different retransmission behavior than anything else.

I understand that the EAP state machine RFC is informational, but take a
look there; it's quite obvious the sorts of things that will break if
you try and have retransmission behavior discussed in method specs.  If
there's something wrong with RFC 3748, fix in an update to that spec and
in updates to the state machines.
However, other than being quite inefficient, I think the retransmission
behavior of EAP is fine.