Subject: Re: [Emu] More comments for eap-tunnel-method

From: "Hao Zhou (hzhou)" <[email-masked]>
Date: Thu, 4 Oct 2012 21:55:39 +0000

Jim:

Thanks for the review. Please see my comments below.

On 9/30/12 2:01 PM, "Jim Schaad" <[email-masked]> wrote:

>1.  Should the Message Length field be present if the TLS Data field is
>absent?
[HZ] According to the text in the draft, the message length field should
only be present if the L bit is set, usually for fragmented packets. In
those cases, the TLS data field will be present, not absent. The only case
TLS data will be absent is when empty TEAP packet it is used to
         indicate TEAP acknowledgement for either a fragmented message,
         a TLS Alert message or a TLS Finished message. So the message
length field is not needed. We can clarify that in the draft.

>
>2.  There is nothing to say which TLVs can and cannot occur in the Outer
>TLVs in any easily findable method.  Either a table or the string outer in
>descriptions would be helpful.  As an example,  does the Authority-ID TLV
>in
>the outer TLV make sense?
[HZ] We will add that table.
>
>3.  I have gone through the fragmentation and did an implementation rather
>than just reading it.  The questions that I have on it now are slightly
>different.  Do TLVs need to be on a fragment boundary? Or do we just build
>the entire message, fragment it into convenient sizes regardless of the
>actual content of the message contents and sent the pieces across?  If so
>then the text should probably be re-written to be clearer.  Specifically,
>the message length is not useful for allocating the buffer on the first
>round trip of messages where one can have a TLV added in to the content.
>[HZ] Message length covers the whole TEAP packet even if fragmented. TLVs
>do not need to be on a fragment boundary. Just build the whole message
>contents and send the pieces across. We will provide some text to clarify
>this.
>
>
>_______________________________________________
>Emu mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/emu

---

From: "Jim Schaad" <[email-masked]>
Date: Sun, 7 Oct 2012 22:11:44 -0700

> -----Original Message-----
> From: Hao Zhou (hzhou) [mailto:[email-masked]]
> Sent: Thursday, October 04, 2012 2:56 PM
> To: Jim Schaad; [email-masked]; draft-ietf-emu-eap-tunnel-
> [email-masked]
> Subject: Re: [Emu] More comments for eap-tunnel-method
> 
> Jim:
> 
only
> be present if the L bit is set, usually for fragmented packets. In those
cases,
> the TLS data field will be present, not absent. The only case TLS data
will be
> absent is when empty TEAP packet it is used to
length
> field is not needed. We can clarify that in the draft.
> 

[JLS]  I am not clear - are you saying that the first sever message sent
with just TLVs cannot be fragmented?

[JLS]  There is a potential issue in the way that the Message Length field
is described.  For finding the location of the Outer TLVs it provides the
length of the TLS Data field, but the internal description says that it
gives the length of the message data in the event of a fragmented message.
If the first client response message is both fragmented on length and
contains TLVs, then the message length field must be the length of the TLS
data in order to find the Outer TLV data but that means it is not the length
of all of the fragmented data.  This is not an issue after the first pair of
messages as the Outer TLVs are no longer allowed at that point.

[JLS] I presume that the Length needs to be present only if the message is
fragmented as a hint to the receiver on the length of the buffer to allocate
as I don't remember any error checks that the length of the message match
the re-constructed message from the fragments (and if it did then the
previous paragraph makes that faulty).  Should there be an error check on
the message length w/ the length of the re-constructed buffer?

> >
> >2.  There is nothing to say which TLVs can and cannot occur in the
> >Outer TLVs in any easily findable method.  Either a table or the string
> >outer in descriptions would be helpful.  As an example,  does the
> >Authority-ID TLV in the outer TLV make sense?
> >3.  I have gone through the fragmentation and did an implementation
> >rather than just reading it.  The questions that I have on it now are
> >slightly different.  Do TLVs need to be on a fragment boundary? Or do
> >we just build the entire message, fragment it into convenient sizes
> >regardless of the actual content of the message contents and sent the
> >pieces across?  If so then the text should probably be re-written to be
> >clearer.  Specifically, the message length is not useful for allocating
> >the buffer on the first round trip of messages where one can have a TLV
> added in to the content.
> >[HZ] Message length covers the whole TEAP packet even if fragmented.
> >TLVs do not need to be on a fragment boundary. Just build the whole
> >message contents and send the pieces across. We will provide some text
> >to clarify this.

[JLS] - see note above about finding the start of the Outer TLV data block
on the first pair of messages.

---

From: "Hao Zhou (hzhou)" <[email-masked]>
Date: Tue, 9 Oct 2012 18:42:54 +0000

Jim:

Please see comments inline below.

>with just TLVs cannot be fragmented?
[HZ] No, they can be fragmented. However, currently, Outer TLVs are only
allowed in the first 2 messages in TEAP exchanges, 1st server to peer with
TEAP start, and 2nd message client to server with Client_hello. It is
unlikely the first server message will have lots of outer TLVs that needs
the fragmentation (only one or two outer TLV is being defined so far). The
2nd message from client to server with client _hello might if the ticket
extension is too big, but unlikely.
 
>messages as the Outer TLVs are no longer allowed at that point.
[HZ] The message length is the total length of the TEAP packet if
fragmented, to provide a hint for the peer to allocate the buffer. The
start of the outer TLV can be calculated from the EAP message length and
length field inside the TLS data, not dependent on the Message Length
field. The current draft text in Section 4.1 Outer TLVs description
incorrectly refers to message length field, will need to be corrected.
Since Outer TLVs only occur in the first 2 TEAP exchanges, the TLS data is
one type and relatively simple,  it should not be too hard to figure out
the start.
>the message length w/ the length of the re-constructed buffer?
[HZ] I don't know if current TLS implementations do check for that error.
Message length is only used for a hint. The EAP-TLS RFC doesn't cover that
either. Thought it did provide more detailed description of the message
length and L bit description, something we could use for the TEAP draft.

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 9 Oct 2012 12:31:15 -0700

There does not seem to be anything in the TEAP document about the length of
the TLS data.   Are you suggesting that one should crack the TLS data blob
to find the length of that data blob?

Jim

> Sent: Tuesday, October 09, 2012 11:43 AM
> >> >1.  Should the Message Length field be present if the TLS Data field
> >> >is absent?
> >[JLS]  I am not clear - are you saying that the first sever message
> >sent with just TLVs cannot be fragmented?
unlikely
> the first server message will have lots of outer TLVs that needs the
> fragmentation (only one or two outer TLV is being defined so far). The 2nd
> message from client to server with client _hello might if the ticket
extension
> is too big, but unlikely.
> 
> >
> >[JLS]  There is a potential issue in the way that the Message Length
> >field is described.  For finding the location of the Outer TLVs it
> >provides the length of the TLS Data field, but the internal description
> >says that it gives the length of the message data in the event of a
> fragmented message.
> >contains TLVs, then the message length field must be the length of the
> >TLS data in order to find the Outer TLV data but that means it is not
> >the length of all of the fragmented data.  This is not an issue after
> >the first pair of messages as the Outer TLVs are no longer allowed at
> >that point.
fragmented,
> to provide a hint for the peer to allocate the buffer. The start of the
outer
> TLV can be calculated from the EAP message length and length field inside
> the TLS data, not dependent on the Message Length field. The current draft
> text in Section 4.1 Outer TLVs description incorrectly refers to message
> length field, will need to be corrected.
one
> type and relatively simple,  it should not be too hard to figure out the
start.
> >
> >[JLS] I presume that the Length needs to be present only if the message
> >is fragmented as a hint to the receiver on the length of the buffer to
> >allocate as I don't remember any error checks that the length of the
> >message match the re-constructed message from the fragments (and if it
> >did then the previous paragraph makes that faulty).  Should there be an
> >error check on the message length w/ the length of the re-constructed
> >buffer?
> >> >Outer TLVs in any easily findable method.  Either a table or the
> >> >string outer in descriptions would be helpful.  As an example,  does
> >> >the Authority-ID TLV in the outer TLV make sense?
> >> >rather than just reading it.  The questions that I have on it now
> >> >are slightly different.  Do TLVs need to be on a fragment boundary?
> >> >Or do we just build the entire message, fragment it into convenient
> >> >sizes regardless of the actual content of the message contents and
> >> >sent the pieces across?  If so then the text should probably be
> >> >re-written to be clearer.  Specifically, the message length is not
> >> >useful for allocating the buffer on the first round trip of messages
> >> >where one can have a TLV
> >> added in to the content.
> >> >message contents and send the pieces across. We will provide some
> >> >text to clarify this.
> >
> >[JLS] - see note above about finding the start of the Outer TLV data
> >block on the first pair of messages.
> >
> >> >
> >> >

---

From: "Hao Zhou (hzhou)" <[email-masked]>
Date: Tue, 9 Oct 2012 19:45:44 +0000

That is the current thinking, and the only concrete use case for Outer TLV
now is in the 1st message from server to peer with no TLS data. I am ok
with adding another optional TLS data length field.

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 9 Oct 2012 16:37:28 -0700

I would be really against the idea that I needed to crack the TLS data blob
to figure this out.   Either adding a length for the TLS data field, or a
length of the Outer TLV data would be preferable to me.  If you did the
second, then it would only affect processing on the first two messages.

Jim

> Sent: Tuesday, October 09, 2012 12:46 PM
with
> adding another optional TLS data length field.
> 
> >> >> >1.  Should the Message Length field be present if the TLS Data
> >> >> >field is absent?
> >> [HZ] No, they can be fragmented. However, currently, Outer TLVs are
> >>only  allowed in the first 2 messages in TEAP exchanges, 1st server to
> >>peer with  TEAP start, and 2nd message client to server with
> >>Client_hello. It is
> >unlikely
> >>fragmentation (only one or two outer TLV is being defined so far). The
> >> >provides the length of the TLS Data field, but the internal
> >> >description says that it gives the length of the message data in the
> >> >event of a
> >> fragmented message.
> >> >If the first client response message is both fragmented on length
> >> >and contains TLVs, then the message length field must be the length
> >> >of the TLS data in order to find the Outer TLV data but that means
> >> >it is not the length of all of the fragmented data.  This is not an
> >> >issue after the first pair of messages as the Outer TLVs are no
> >> >longer allowed at that point.
> >> TLV can be calculated from the EAP message length and length field
> >>inside  the TLS data, not dependent on the Message Length field. The
> >>current draft  text in Section 4.1 Outer TLVs description incorrectly
> >>refers to message  length field, will need to be corrected.
> >> >[JLS] I presume that the Length needs to be present only if the
> >> >message is fragmented as a hint to the receiver on the length of the
> >> >buffer to allocate as I don't remember any error checks that the
> >> >length of the message match the re-constructed message from the
> >> >fragments (and if it did then the previous paragraph makes that
> >> >faulty).  Should there be an error check on the message length w/
> >> >the length of the re-constructed buffer?
> >> Message length is only used for a hint. The EAP-TLS RFC doesn't cover
> >>that  either. Thought it did provide more detailed description of the
> >>message  length and L bit description, something we could use for the
> >>TEAP draft.
> >> >
> >> >
> >> >> >
> >> >> >2.  There is nothing to say which TLVs can and cannot occur in
> >> >> >the Outer TLVs in any easily findable method.  Either a table or
> >> >> >the string outer in descriptions would be helpful.  As an
> >> >> >example,  does the Authority-ID TLV in the outer TLV make sense?
> >> >> >3.  I have gone through the fragmentation and did an
> >> >> >implementation rather than just reading it.  The questions that I
> >> >> >have on it now are slightly different.  Do TLVs need to be on a
> fragment boundary?
> >> >> >Or do we just build the entire message, fragment it into
> >> >> >convenient sizes regardless of the actual content of the message
> >> >> >contents and sent the pieces across?  If so then the text should
> >> >> >probably be re-written to be clearer.  Specifically, the message
> >> >> >length is not useful for allocating the buffer on the first round
> >> >> >trip of messages where one can have a TLV
> >> >> added in to the content.
> >> >> >TLVs do not need to be on a fragment boundary. Just build the
> >> >> >whole message contents and send the pieces across. We will
> >> >> >provide some text to clarify this.
> >> >

---

From: "Hao Zhou (hzhou)" <[email-masked]>
Date: Wed, 10 Oct 2012 18:10:02 +0000

I think an optional length of Outer TLV field (controlled by the flag bit)
would be preferable.