Defining and updating CT(peer)

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

Hi,

One of the issues that Shinta brought up in his review is the potential 
attack concerning updating CT(peer) with shim6 control packets.
We have been discussing this point with Erik, and this is an attempt to 
summarize my understanding of the problem so far.
Any comments are welcome

Defining and updating CT(peer)

# Issue description

-- When a shim6 context is established (or in its way to be 
established), the reception of shim6 control packets may result
in defining/updating the CT(peer) associated to the shim6 context.
This may pose some security concerns if this operation is not
properly secured.

# Threat related to this operation:

-- The main threat identified is that this could allow an attacker 
to change the CT(peer) of a context leading to an DoS
attack, since subsequent packets with the new CT won't be
recognized by the receiver

# 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?

# Scope

-- Messages involved
I1, I2, R2 and I2bis contain CT information so they must be
considered in this analysis
R1 does not contain CT information, so no need to consider it
R1bis contain CT(packet) which does not result in updating
CT(peer), so there is no need to consider it neither for this
particular threat.

-- States involved
This concern is clearly raised when the CT(peer) for the
context is defined. So, the following states are
affected:
- ESTABLISHED
- I2bis-SENT

In addition, when a state is being created, the reception
of different messages result in the definition of CT(peer)
for that context. In this case, the situation is somehow
different, since CT(peer) is not defined yet, but the
result of the attack is similar, since CT(peer) may end
up with a fake value. This can occur in the following states:
- I1-SENT
- I2-SENT

# Summary of the proposed approach

The idea is not to update nor define CT(peer) upon the
reception of messages that don't contain information of
prior contact. So, the proposal is to defer the
update/define of the CT(peer) until the reception of:
- R2 messages received in I1-SENT, I2-SENT or I2bis-SENT
  states. The R2 contains an valid Initiator nonce
  that proves prior exchange and has a valid ULID-locator
  relation proven through HBA/CGA information, or
- I2 messages received in ESTABLISHED state. The I2
  contains a valid validator and
  a valid ULID-locator relation proven through HBA/CGA
  information.

In this approach, it is still possible for an attacker to
assign an invalid CT(peer) for an established context, but
in order to do that, the attacker needs to be able to
perform a 4-way handshake from one of the locators securely
bound (through HBA/CGA technique) to the used ULID

Note: next the complete case by case analysis is detailed,
so, if you are not really interested i would suggest stop
reading here...


# 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

-- 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

-- 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

-- 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

- 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?

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

- 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