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