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
