Re: [Mip6] RR protocol

[Jianying Zhou <[e-mail]>]

Hi, Christian,

Thank you very much for your comments. Our feedback is as follows.

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


===========
It depends on how the attacker is positioned. If the attacker can 
intercept both HoT and CoT in a single RR session, your attack on the 
original RR protocol works. (However, based on the RR design assumption, 
it occurs less likely.) In our attacking scenario, the attacker could 
intercept HoT and CoT in different RR sessions.

Our improvement prevents the attack in both your scenario and our our 
scenario. HoT and CoT are all linked to specific HoA and CoA, and they 
cannot be used to forge valid binding updates with other HoA and CoA. 
(Note CN will use HoA and CoA etc. to re-calculate KTh and KTc.)
=========


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


=========
If an attacker uses CoA_i and CoA_j, or HoA_i and HoA_j, or HoA_i and 
CoA_j (in this order) to generate MACbu,  the attack will fail. As the 
attacker will select them randomly, the probability of success to forge 
a valid binding update is 1/4, that is only using CoA_i and HoA_j. (CN 
will use this ordered information to re-calculate KTc and KTh in binding 
update verification.) With our improvement, the traffic-permutation 
attack could be prevented.
=========


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


=========
If MN has bound CoA in HoT, then even if the attacker is on the path 
between the CN and the MN's HA and intercepts HoT, and further 
intercepts CoT on the path between the CN and CoA path, the attack still 
does not work. The same reason as explained in response to your first 
comment. (Note again, HoT, CoT, HoA, CoA are all linked in our 
improvement, any change of them will invalidate the binding update 
verification process.)
=========


> I might be missing something. If so, don't hesitate to tell me. ;-)
>
> Bye, see you in Washington D.C...


Look forward to seeing you in Washington DC next week.

Cheers.

Jianying


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



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