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

Re: Defining and updating CT(peer)



marcelo bagnulo braun wrote:

-- Receiving I1 packets in I1-SENT state
[...]
i think we are fine if we keep the optimization i.e. the host sends a R2 as a reply to the received I1 but it waits until the reception of that R2 packet to define the CT(peer), ok?

That might make sense.

I was thinking that having I1 always result in a R1 (independent of any state) would certainly be easier to describe. But that would probably mean that the case of crossing I1s end up resulting in 8 packets being exchanged.

So the optimization to return a R2 in this case makes sense.

-- Receiving I1 packets in I2-SENT state
[...]
I think we can keep the exchange as it is, i.e. the host replies with an R2, but the difference is that it defines CT(peer) upon the reception of the R2 packet and not upon the reception of the I1 packet, ok?

ok

Question: does this mean that we can skip verifying anything against the existing context state? (such as checking that the locators are part of Ls(peer) and Ls(local))

well we are checking that the CGA/HBA corresponds to the ULID of the existing context and the the signature/locator set of the HBA corresponds to that CGA/HBA

So should we uniformly avoid checks on Ls(peer) for the reception of messages that we verify using CGA/HBA in any case?

what we are not checking is that the locators used in this packet belong to the existent Ls(peer), but i don't think we need that, since we are verifying that the ULID matches and the CGA/HBA is associated with the ULID, and this should be enough to allow the peer to redefine the Ls(peer)

ok

   Erik