> -----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? [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? > [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
