marcelo bagnulo braun wrote:
# Level of security targeted
-- The proposed level of security for this operation is that CT(peer)
is only updated when the shim control message that
requests so contains a token that proves prior contact and that
the source locator can be verified that it is securely bound
to the source ULID of the context, does this seems a
reasonable requirement?
Sounds like a reasonable requirement.
# Analysis of different packet processing
-- Receiving I1 packets in ESTABLISHED state
In case that a host receives a I1 packet for a context that
is in the ESTABLISHED state, the draft assumes that the peer
has lost context and triggers the context recovery mechanism,
which consists in updating the CT(peer) to the one contained
in the I1 packet and then sending an R2 packets.
I guess this is too weak.
Probably we need to improve this, dropping the optimization
and requiring the full 4-way exchange in this scenario. This
means updating the CT(peer) only on I2 packets. This would
have the additional cost that it would take 2 more packets
to create the loss context in this case.
Suggested change: drop optimization for this case and go
for R1, I2, R2 procedure
So in this case the host would behave as if the context was in IDLE
state (not create/update any state and sending an R1).
-- 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
ok.
Should the host *send* a R2 packet, or send an R1 in this case?
-- Receiving I1 packets in I2bis-SENT state
Similar to the previous case, this scenario occurs when
one end attempts to create a context that the other end
is trying to recover. The draft states that CT(peer)
must be updated upon the reception of an I1 message,
but this open the possibility of the considered attack.
The solution is again to update CT(peer) upon the
reception of the R2 message.
Proposed change: not updating CT(peer) upon the reception
of I1 in I2bis-SENT, but do it with R2
ok
- 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
ok
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?
What's important is that the old information should be gone once the
I2 is processed.