[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Defining and updating CT(peer)
Hello Marcelo,
Thank you for your thorough clarification and sorry that it took
so long for me to reply. Please find my comments inline:
On Sun, 19 Feb 2006 19:27:33 +0100
marcelo bagnulo braun <marcelo@it.uc3m.es> wrote:
> 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?
Yes, I think so.
>
> # 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.
Ok.
>
> 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
Right.
>
> 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
Yes, I agree.
>
> -- 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
I agree.
I also think it's fine to keep the optimization in case of
concurrent context exchange (replying to I1 with 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
Ok.
>
> -- 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
>
> 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?
I think the former choice is fine. (see below)
> 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
I think above is fine. In such case (a responder receives
I2 message from an initiator) in ESTABLISHED state, it
implies that the context was lost (for some reason) at the
peer (initiator). So, it seems that holding the old
context does not make much sense.
>
> - 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 ?
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. Maybe some texts are needed in Section 7.11
with regard to the treatment of CT value to be included in
R2 message.
>
> - 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)
I agree.
>
> - 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
This should be another mysterious case. I agree that there is
no need to process the R2 packet.
>
> - 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
I agree.
>
> - 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
I agree. In such case, I2bis should be discarded.
>
> - 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
Same as the case when receiving I2 packet in I1-SENT.
>
> - 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
Neither can I imagine such case. I agree that I2bis packet
should be discarded in this case.
Regards,
Shinta