Hi Marcelo,
Please find a few more comments below.
On Thu, 2 Mar 2006 12:06:18 +0200
marcelo bagnulo braun <marcelo@it.uc3m.es> wrote:
...[snip]...
- Receiving I2 packets in I1-SENT state
This scenario is the case of simultaneous context
establishment and the draft states that the context
state remains unchanged (waiting for the R2 message)
so no problem in this case and no change is required.
I assume the above case is depicted in Figure 26 in the
protocol document <draft-ietf-shim6-proto-03.txt>.
However, I need some clarification here. Let me expand a
little bit: According to the protocol draft, when a host
detects concurrent context establishment (e.g. receiving I2/I2bis
message in I1-SENT state), it replies with R2 message and wait
until it receives R2 message from the peer for state transition
from I1-SENT to ESTABLISHED. But I wonder why the state
transition should be deferred until receipt of R2 message.
Does it help ruling out some sort of security threat ?
no as far i can tell,
i think you can do it either way, either you update CT(peer) and move
to ESTABLISHED state at the reception of the I2 or at the reception of
R2
Do you see any reason why prefer either one of them?
I'd prefer the first choice (not to wait until receipt of R2) because
it simply requires less latency. If R2 message from the peer is lost,
another cycles of round-trip delay may be needed.
In addition, I think there is an important issue in the
choice of CT when sending R2 message in reply to I2/I2bis
message. That is, the CT(responder/local) to be included
in R2 message must be consistent with the CT(initiator/local)
which had been included in the I1 message. Otherwise, the
end hosts may be confused which CT(peer) to use for establishing
the context.
right, but this would be derived from the fact that the I2 message is
received in I1-SENT state i.e. there is already state for this ULID
pair context so the CT(local) is already defined (which was included
in
the I1 packet) hence the same one must be used for the R2 packet
Ok, I see. As far as the host maintains state information per ULID
pair
there should be no concern.
Maybe some texts are needed in Section 7.11
with regard to the treatment of CT value to be included in
R2 message.
I am not sure about this.
As i mention, the CT(peer) information is associated to the context
state itself.
But i don't have strong preferences for this
No need for the texts I think. Thanks for the clarification.
Regards,
Shinta