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
