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