[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Defining and updating CT(peer)



Hi Shinta,


El 02/03/2006, a las 9:46, Shinta Sugimoto escribió:


-- Receiving I1 packets in I1-SENT state

In this case, we are in the case of simultaneous shim6
context establishment. In this case the draft states that
CT(peer) is set to the value contained in the received I1
message. Again, this would open the door to the
considered DoS attack. Since the hosts will receive a R2
message later anyway, the proposed solution is to set
CT(peer) only upon the reception of the R2 message (which
must be validated with the nonce)

Proposed change: not  setting CT(peer) upon the reception
of I1 in I1-SENT  state but do it upon the reception of R2

I agree.

I also think it's fine to keep the optimization in case of
concurrent context exchange (replying to I1 with R2).


yes, this is kept as it was, the only change is that the definition/update of the CT(peer) is performed when the R2 packet is received

...

- Receiving I2 packets in ESTABLISHED state

No action is performed upon the reception on an I2
packet with a different CT(peer) in ESTABLISHED state
However, this needs to be changed in order to support
context recovery, since we are in the case where the
peer is trying to establish a context that the local
node has already available. So, upon the reception of
a I2 message for a context that is in ESTABLISHED
state, the node needs to verify the validator, and the
relation between the source locator and the source
identifier (i.e. HBA/CGA check) and if it succeeds,
then it must update CT(peer) and eventually the other
information related to the context e.g. the locator set

Question: does this means that we update the existent
context with the new information or that we create a
new context with the new information and we let the
old context to age and expire?

I think the former choice is fine. (see below)

Proposed change: upon the reception of an I2 message
in ESTABLISHED state, the validator and ULID-locator
context is verified and the context state information
(CT(peer) and Ls(peer)) is updated

I think above is fine.  In such case (a responder receives
I2 message from an initiator) in ESTABLISHED state, it
implies that the context was lost (for some reason) at the
peer (initiator).  So, it seems that holding the old
context does not make much sense.

yes


- 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?



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

  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


thanks again for your in depth review