Re: Changes in version 8 resulting from comments in: Re: Retransmission of I2 messages

[Matthijs Mekking <matthijs@NLnetLabs.nl>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

marcelo bagnulo braun wrote:
> 
> El 11/12/2006, a las 10:02, Matthijs Mekking escribió:
> 
>> Hi,
>>
>> I have a question about the proto draft. In section 7.12, the draft says
>>  "If the initiator does not receive an R2 message after I2_TIMEOUT time
>> after sending an I2 message it MAY retransmit the I2 message" and "Thus
>> the initiator SHOULD fall back to retransmitting the I1 message when
>> there is no R2 received after retransmitting the I2 message
>> I2_RETRIES_MAX times."
>>
>> I am concerned about keywords MAY and SHOULD in section 7.12. If an
>> implementation decides not to implement these retransmissions, then
>> according to the protocol specification, the fall back to retransmitting
>> I1 messages would never occur (because this SHOULD happen after
>> I2_RETRIES_MAX retransmissions of I2). If the I2 is not accepted by the
>> responder, and no retransmissions are sent, than the context would stay
>> in I2-SENT, and is never able to reach ESTABLISHED.
>>
>> I think the host MAY retransmit I2 messages, but MUST fall back after a
>> certain amount of time, to avoid this deadlock situation. The same
>> applies for retransmitting I2bis messages.
>>
> 
> I have rephrased this section  in order to clarify this.
> 
> the section is now:
> 
> If the initiator does not receive an R2 message after I2_TIMEOUT
> time after sending an I2 message it MAY retransmit the I2 message, using
> binary exponential backoff and randomized timers.
> The Responder Validator option might have
> a limited lifetime, that is, the peer might reject Responder Validator
> options
> that are older than VALIDATOR_MIN_LIFETIME to avoid replay attacks. In
> the case that
> the initiator decides not to retransmit I2 messages or in the case that the
> initiator still does not recieve an R2 message after
> retransmitting I2 messages I2_RETRIES_MAX times,
> the initiator SHOULD retransmit the I1 message.
> 
> Hope this clarifies this issue

This is ok, although I think the last sentence must be "the initiator
MUST fallback to retransmitting the I1 message":

1. "the initiator SHOULD retransmit the I1 message" can be read as:
"retransmit one I1 message, stay in I2-SENT". However, I think the
context must also fallback to the state I1-SENT, because R1 messages (in
reply to I1) are discarded when in I2-SENT.

2. The keyword SHOULD implies that there might be a valid reason not to
fallback to retransmitting the I1 message. However, I think there is no
valid reason to do so, and doubting if this keyword should be MUST.

Matthijs Mekking
matthijs@NLnetLabs.nl
NLnetLabs/Radboud University
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFF79sYNiaStnTWEtYRAjiPAJ4+0YDsm24v35kgMDcSms9AOUBVygCdEDIa
wIHVlYrHUV1EeNWMTELnKVw=
=/zI4
-----END PGP SIGNATURE-----