Re: replay attack issue in locator updates ?

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

Hi Seb,

from the security considerations section of the shim6 proto spec

  o  Every control message of the Shim6 protocol, past the context
     establishment, carry the context tag assigned to the particular
     context.  This implies that an attacker needs to discover that
     context tag before being able to spoof any Shim6 control message
     as described in section 4.4 of [15].  Such discovery probably
     requires to be along the path in order to be sniff the context tag
     value.  The result is that through this technique, the Shim6
     protocol is protected against off-path attackers.


So, i agree with you, an on path attacker can launch such attack, but 
this has been a design tradeoff
The protocol is not designed to provide protection against on path 
attackers for this case

Regards, marcelo


Sébastien Barré escribió:
> Hi,
>
> While reading rfc4218, I realized that I'm not sure that locator 
> update messages in the Shim6 protocol are protected against replay 
> attacks (section 4.1.4 of rfc 4218).
> What I observed is that a nonce mechanism is used (successfully) to 
> protect session initiation messages. Next, the same kind of mechanism 
> is used to protect locator updates, but it seems to me that it cannot 
> work in that case.
>
> The principle used in the Shim6 protocol regarding the use of nonce, 
> in a request/response scheme, is that the requester picks a random 
> number that is copied back by the responder inside the answer. This 
> protects the answer against replay attacks, not the request. And it is 
> completely right so (usually), since the answer is the one that 
> contains critical information.
>
> Here comes the difference between initiation messages and locator 
> updates. During initiation locators are sent as responses (with a 
> copied nonce). But during locator updates, locators are sent during 
> the request, which opens the following attack scenario IMO :
>
> * A starts a Shim6 exchange with B
> * Some time later it sends a locator update to B. This works well, 
> except that the update is simply remembered by X, an attacker.
> * even later, a second update is sent from A to B, which invalidates 
> all previous locators, and announces others. This also works well.
> * Now X decides to replay its remembered locator update. B has no 
> reason to reject that packet, thus it will update it's locator set 
> back to the invalid locator set. It can thus not talk to A anymore.
> Because the packet was accepted by B, B will send back an ack to A, 
> but A will either not receive it, or receive it and ignore it, because 
> the ack *is* protected by the nonce, and the nonce is not longer valid.
>
> Now, looking further at the mechanisms, I found that there is some 
> possible protection available without modifying the protocol, and that 
> is due to a good side effect of locator list generation number. This 
> one is incrementally updated for each new list, and it is part of the 
> CGA signature. Thus if the receiver of an update request (B above) 
> simply checks that the received generation number is greater than it's 
> previous one (and within some reasonable window), it will be able to 
> drop replayed messages.
>
> Note that this does not work if HBA is used. In that case, no 
> signature is present and the attacker simply needs to replace the 
> generation number before to send it. But this does not seem a too big 
> concern, since the user has the option between more efficiency (hba) 
> or more security(cga).
>
> Thus, maybe I missed something, but if i didn't it may be worth adding 
> some paragraph in the draft (section 10.4 - receiving update request 
> messages) telling that in case the request holds a locator list, the 
> generation number MUST be checked to be greater than the previously 
> stored one and within some window (size of which to be thought about). 
> If the provided generation number does not fall into that window, then 
> it is probably a replay and the packet MUST be silently dropped (or an 
> error message sent ?).
>
> Can anybody here (still up and following the list :-) ) give some 
> opinion about this ?
>
> thanks,
>
> Sébastien.