Subject: Re: [Emu] TEAP Comments

From: "Hao Zhou (hzhou)" <[email-masked]>
Date: Tue, 29 Jan 2013 16:57:18 +0000

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" <[email-masked]> 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: [email-masked] [mailto:[email-masked]] On Behalf Of
>>> Jim Schaad
>>> Sent: Wednesday, November 07, 2012 4:48 PM
>>> To: [email-masked]
>>> 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
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/emu
>>
>>_______________________________________________
>>Emu mailing list
>>[email-masked]
>>https://www.ietf.org/mailman/listinfo/emu
>