Re: Defining and updating CT(peer)

[Shinta Sugimoto <shinta@sfc.wide.ad.jp>]

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