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