replay attack issue in locator updates ?

[Sébastien Barré <sebastien.barre@uclouvain.be>]

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.

--
Sébastien Barré
Researcher,
CSE department, UCLouvain, Belgium
http://inl.info.ucl.ac.be/sbarre