I think an optional length of Outer TLV field (controlled by the flag bit)
would be preferable.
On 10/9/12 7:37 PM, Jim Schaad i...@augustcellars.com wrote:
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
-Original Message-
From: Hao Zhou (hzhou) [mailto:hz...@cisco.com]
Sent: Tuesday, October 09, 2012 12:46 PM
To: Jim Schaad; emu@ietf.org; draft-ietf-emu-eap-tunnel-
met...@tools.ietf.org
Subject: Re: [Emu] More comments for eap-tunnel-method
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.
On 10/9/12 3:31 PM, Jim Schaad i...@augustcellars.com wrote:
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
-Original Message-
From: Hao Zhou (hzhou) [mailto:hz...@cisco.com]
Sent: Tuesday, October 09, 2012 11:43 AM
To: Jim Schaad; emu@ietf.org; draft-ietf-emu-eap-tunnel-
met...@tools.ietf.org
Subject: Re: [Emu] More comments for eap-tunnel-method
Jim:
Please see comments inline below.
On 10/8/12 1:11 AM, Jim Schaad i...@augustcellars.com wrote:
-Original Message-
From: Hao Zhou (hzhou) [mailto:hz...@cisco.com]
Sent: Thursday, October 04, 2012 2:56 PM
To: Jim Schaad; emu@ietf.org; draft-ietf-emu-eap-tunnel-
met...@tools.ietf.org
Subject: Re: [Emu] More comments for eap-tunnel-method
Jim:
Thanks for the review. Please see my comments below.
On 9/30/12 2:01 PM, Jim Schaad i...@augustcellars.com 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.
[JLS] I am not clear - are you saying that the first sever message
sent 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.
[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.
[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.
[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?
[HZ] I don't know if current TLS
