Re: [Mip6] RR protocol

[Christian Vogt <[e-mail]>]

Hi folks!

Jianying Zhou wrote:
 >> Does the improvement of RR protocol given in
 >> [...]draft-qiu-mip6-rr-improvement-00.txt
 >> provide better security without additional cost?

Jari Arkko wrote:
 > I don't know about the "better security" part -- I would have to
 > think about this in detail. However, I think I can answer for the
 > "without additional cost" part. [...]

Maybe, I can add a bit on the "better-security" part. Here are a few 
comments on your draft [1]...

My first comment is on movement-halting attacks (section 3.2). I agree 
that an attack like this is possible. Actually, this is what [2] calls a 
"time-shift attack": get a token at one time and use it at another time. 
Note that the movement-halting attack can be even simpler than the one 
you describe in your draft. Since you assume that the MN moves rapidly 
enough such that the previous Care-of Keygen Token is still valid when 
the MN is at its new place, it wouldn't surprise if the previous Home 
Keygen Token is still fresh as well. So, the attacker could even use 
both tokens from the previous RR in order to redirect the MN's packet 
back to the old CoA. Note that this attack is simpler for the attacker 
to accomplish than the attack in your draft: Here, the attacker does not 
need to follow the MN to the new location. In your draft, it needs to.

Second, traffic-permutation attacks. This kind of attack is interesting. 
It's a variation of the attack where the perpetrator redirects a MN's 
(or a stationary node's) packets to a random IP address (section 3.1.5 
of [2]). But note that it is well-known that RR is vulnerable to an 
attacker inside the CN's network (more precisely: somewhere on the 
intersection of all paths between the CN and one of the victims). The 
attacker can impersonate any other node in this position, and it can 
redirect other nodes' packets to any IP address. One way of doing this 
is the method you describe in your draft. (Although I don't quite 
understand why the CN would accept a spoofed Binding Update only with 
probability 1/4. The probability should be 1.0 unless you consider 
things like nonce-lifetime expiration...)

Ok, my last comment is on your improvement proposal. Your argumentation 
is interesting, but I am not sure about the benefit your proposal has. 
Consider that, at some point, an attacker must do something actively. 
There is no passive attack against the RR except dropping messages. And 
we know that RR is vulnerable to an attacker on the path between the CN 
and the MN's HA (section 3.1.1 of [2]). In this position, the attacker 
can send its own HoTI with the victim's HoA (and, if we apply your 
proposed improvement, with a CoA that the attacker chooses). Due to its 
position, the attacker can intercept the HoT. The attacker would then 
send a CoTI, again with the victim's HoA (and, if we follow your 
proposal, the chosen CoA). The attacker must send the CoTI from a place 
where it can intercept the CoT. This attack is possible in the RR as 
defined in RFC 3775, and it is still possible with your approach.

I might be missing something. If so, don't hesitate to tell me. ;-)

Bye, see you in Washington D.C...


- Christian


[1] Improvement of Return Routability Protocol
     draft-qiu-mip6-rr-improvement-00.txt

[2] Mobile IP version 6 Route Optimization Security Design Background
     draft-ietf-mip6-ro-sec-02.txt

-- 
Christian Vogt, Institute of Telematics, University of Karlsruhe
www.tm.uka.de/~chvogt/

"Science knows only one commandment: contribute to science."
(Bertolt Brecht)


Jari Arkko wrote:

> I don't know about the "better security" part -- I would have to
> think about this in detail.
> 
> However, I think I can answer for the "without additional cost"
> part. If the home and care-of addresses are bound to each other
> in the HOTI/COTI signaling, this implies that a HOTI/HOT you did
> 30 seconds ago in your previous attachment point is no longer
> valid in this new attachment point. This implies more latency
> at the new attachment point, if you have to redo HOTI/HOT.
> 
> So it seems that there is additional cost.
> 
> --Jari
> 
> Jianying Zhou wrote:
> 
>> In the RR protocol, any pair of home keygen token and care-of keygen 
>> token can generate a valid binding key as long as the indexes, i and 
>> j, are still valid.
>>
>> Does the improvement of RR protocol given in 
>> http://www.ietf.org/internet-drafts/draft-qiu-mip6-rr-improvement-00.txt 
>> provide better security without additional cost?
>>
>> In that proposal, HoA and CoA are bound together. A mobile node MN sends
>>
>>       HoTI = {HoA, CNA, CoA, CKh}   and       CoTI = {CoA, CNA, HoA, CKc}
>> to a correspondent node CN, which replies with the home keygen token
>>
>>       KTh = HMAC_SHA1(Kcn, (HoA|Nj|CoA|0))   and the care-of keygen token
>>       KTc = HMAC_SHA1(Kcn, (CoA|Ni|HoA|1)).

_______________________________________________
Mip6 mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/mip6