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
