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 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. > >> > > >> > > >> >> > > >> >> >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. > >> > > >> >[JLS] - see note above about finding the start of the Outer TLV data > >> >block on the first pair of messages. > >> > > >> >> > > >> >> > > >> >> >_______________________________________________ > >> >> >Emu mailing list > >> >> >Emu@ietf.org > >> >> >https://www.ietf.org/mailman/listinfo/emu > >> > > > _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
