Jim: Thanks for the detailed review comments. Response inline below. Will try to submit a new rev with these changes soon.
> >On 11/15/12 3:24 PM, "Jim Schaad" <i...@augustcellars.com> wrote: > >>Expanding on the issues so that you have full descriptions of the problem >>from the last message >> >>1. When either an EMSK or MSK is not present in the Crypto-Binding TLV, >>there is no way to indicate this. At the f2f it was said that this was >>going to be by setting it to all zeros. If this is the case, then it >>does >>need to be noted that there is a 1 in 2^n chance that it will signal the >>wrong thing leading to an error in binding being generated. It might be >>better to steal bits from the Sub-Type octet instead. >[HZ] We will add a flag bit in sub-type to indicate presence of EMSK >and/or MSK MAC. >> >>2. I find that I have probably not correctly understood when the S bit >>is >>set. I have been setting the S bit on all fragments (but not fragment >>responses) of the original Start request and Start response. I have >>since >>found text that says it is only sent from the server to the peer. It >>would >>be nice to have the one direction comment in the description of the flags >>as >>well (section 4.1) >[HZ] Will add a sentence to clarify. > >> >>3. I would like to have the description of the L bit in section 4.1 >>expanded to state the following: >> - It MUST be present for the first fragment of a fragmented message >> - It MUST NOT be present for any other message >> >>The first can be found in section 3.7 (if you hunt) but the second is not >>stated anywhere >[HZ] Will add that. > >> >>4. I would like to have the description of the O bit in section 4.1 >>expanded to state the following: >> - It MUST be present only in the initial request and response messages. >> - If the initial message is fragmented, then it MUST be present only on >>the >>first fragment. >[HZ] Looks ok. Will add. > >> >>5. I don't think point 3 below needs expansion, but I may be too close >>to >>it. If you disagree please let me know. [HZ] Sounds reasonable. Will add an error TLV with new error code for the signaling mechanism. >> >>Jim >> >> >>> -----Original Message----- >>> From: emu-boun...@ietf.org [mailto:emu-boun...@ietf.org] On Behalf Of >>> Jim Schaad >>> Sent: Wednesday, November 07, 2012 4:48 PM >>> To: emu@ietf.org >>> Subject: [Emu] TEAP Comments >>> >>> I just wanted to make sure that the mail list had at least the basics >>>of >>what I >>> mentioned in the f2f today >>> >>> 1. The document does not appear to have an indicator that the EMSK was >>>or >>> was not used to generate a confirmation value. I have not done a final >>check >>> that this is true but I did try and find it a couple of times >>> >>> 2. The flags on the outer packet need to be defined a bit better. >>> a) is the S bit set only on the first fragment of the first message >>>or >>on all >>> fragments of the first message >>> b) are the two length bits set only on the first message in a >>fragment >>> sequence or can they be on any of the messages in a fragment sequence >>> (but the values must then be the same in all fragment messages) >>> c) Can the O bit be set only in the first piece of a fragment, or >>could it be in >>> the last one without being in any previous one >>> d) Should the L bit never be set on a non-fragmented message since >>>it >>is >>> redundant >>> >>> 3. There needs to be a signaling mechanism when running inner EAP >>> messages to say that >>> a) that this is a reliable transport and therefore there should be >>no-retries >>> b) If a packet is dropped on the floor by somebody, then some type of >>> signaling mechanism needs to be created to signal this to the other >>>party. >>> Also there should be text saying that re-sending the message does not >>> necessarily make sense as the packet would probably just be re-dropped >>> again >>> c) There needs to be some type of policy on the server for what to do >>for >>> either failing or continuing a validation - for example should a new >>>EAP >>> method be tried in this case. > > >>> >>> Jim >>> >>> >>> _______________________________________________ >>> 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 > _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
