[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Defining and updating CT(peer)
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 I2-SENT state
This case is similar to the previous one. It affects the
case of almost simultaneous context establishment. The
draft states that CT(peer) is defined upon the reception
of an I1 message in I2-SENT state. This present similar
threats as the previous case, and the proposed solution
is the same. Define CT(peer) upon the reception of R2.
Proposed change: not setting CT(peer) upon the reception
of I1 in I2-SENT, but do it with R2
ok.
What should the host send?
-- 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.
Whether this is implemented as a complete replacement of the existing
state, or by discarding the old state and creating a new context, is an
implementation detail.
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
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))
If this was a normal context establishment there wouldn't be any such
check, since there wouldn't be any context when we receive I2. Hence in
that case it is sufficient to check the validator and the locator set
against HBA/CGA, so one could argue those checks should be sufficient in
any state when we receive an I2 message.
- 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.
>
- Receiving I2 packets in I2-SENT and I2bis-SENT state
I can't find a scenario for this case to make sense,
but the draft states that no change is performed upon
the reception of an I2 message in this state, so i
guess no threats are involved.
(Note that even if we update the context information upon
the reception of an I2 message, this wouldn't present a
threat since I2 contains a validator to check prior contact
and HBA/CGA information to check ULID-locator relation)
- Receiving R2 packets in ESTABLISHED state
No action is performed upon the reception on an R2 packet
with a different CT(peer) in ESTABLISHED state
- Receiving R2 packets in I1-SENT, I2-SENT and I2bis-SENT
The draft states that the host would need to update the
CT(peer) upon the reception of an R2 packet in I1-SENT,
I2-SENT and I2bis-SENT state. this does not presents a
security issue because R2 packet must contain the
Initiator Nonce which was included in previously sent
messages
- Receiving I2bis packets in ESTABLISHED state
No action is performed upon the reception on an I2bis
packet with a different CT(peer). Moreover, this situation
is unlikely to happen, since no R1bis message can be generated
for an existent context, so no proper I2bis validator can be
obtained, in order to generate a I2bis message for an
established context
- Receiving I2bis packets in I1-SENT state state
We are in the simultaneous context establishment situation
and the draft states that no context information is updated,
since this is deferred upon the reception of the R2 message
- Receiving I2bis packets in I2-SENT and I2bis-SENT state
I can't identify which scenario would result in this case,
but in any case, the context information is not updated upon
the reception of an I2bis message in this case, so no threat
is involved
ok
Erik