Re: Defining and updating CT(peer)

[marcelo bagnulo braun <marcelo@it.uc3m.es>]

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