Subject: RE: About RRH security (was Re: [nemo] RE: RO between MR and CN

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Tue, 19 Oct 2004 10:02:03 +0200

> -----Original Message-----
> From: marcelo bagnulo braun [mailto:[email-masked]]
> Sent: lundi 18 octobre 2004 19:52
> To: Pascal Thubert (pthubert)
> Cc: nemo WG; María Calderón; Carlos Jesús Bernardos Cano
> Subject: About RRH security (was Re: [nemo] RE: RO between MR and CN
> 
> Hi all,
> 
> This is part of the security analysis that we have performed about the
> RRH.
> 
> I guess that we could summarize it as follows:
> - The RRH security issues that we identified are more related to lack
> of specification rather than fundamental ones. Meaning that IMHO, the
> current draft doesn't take into account some issues, in particular
> time-shifted attacks, when performing the RRH.
> - The identified issues can be solved through proper host behaviour.
> 
> The main security problem of RRH imho is related with the fact that the
> signaling channel between the MR and the HA is protected through a
> IPSec SA that may be manually configured, for instance. This means that
> the resulting level of trust may be relatively high. However, the
> information contained in the RRH, is not protected with this SA, and
> its protection relies on that the presence of the attacker along the
> path, so the information obtained through RRH has a different level of
> trust than the information obtained through a BU sent from the MR to
> the HA. However, both informations are stored in the same BCE, with the
> same parameters, in particular with the same lifetime. This is a
> security problem since the lifetime of the BCE is closely related with
> the level of trust of the information within the BCE, in particular,
> the BCE lifetime defines the level of protection against the time
> shifted attacks.
> Now, the information protected with IPSec SA between the MR and the HA
> is not vulnerable against time shifted attacks, while the information
> contained in the RRH may be vulnerable to time shifted attacks, as
> presented next.
> 
> The key elements when preventing time shifting attacks, imho, are:
> - the BCE lifetime
> - the frequency of the RRH
> 
> Now let me put an example of how a time shifted attack would be imho:
> - suppose that the MR is configured to send a RRH only with a
> relatively low frequency once that the first RRH is sent i.e. it
> doesn't sends RRH in all data packets, only in one in a time T (suppose
> time T long for efficiency). I guess this makes a lot of sense since we
> don't want to introduce the RRH overhead in all packets.
> This means, that upon the reception of the RRH, the information
> contained in the RRH will be stored in the HA BCE for the BCE lifetime
> (which may be very long) and will not be refreshed for a period T.
> Now suppose that an attacker, that is on the path, modifies the content
> of the RRH, including its own address on the RRH.
> This means that for the time T, the HA will be sending packet to the
> attacker.

If I understand your point, the problem is the time shifting attack has consequences even when the attacker is gone, at least till the next RRH. The draft does not mention how often RRH are sent and what triggers them. 

Note that in this case, and as opposed to MIP RO, the L4 ACKs are still protected because there is an SA. So redirecting packets like this would be equivalent to destroying them, and then the flows tarish. But you can not make that a bombing attack. Since the guy in on the path, it's easier for him to just destroy the packets. And once he's gone, he can not reuse any token he got while he was in to maintain the attack.

Our implementation has a number of heuristics to decide when to roam and when to send RRH. And I guess there could be many more that could make a difference on the marketplace while still maintaining interoperability. MIP does not tell you when to roam. The RRH draft does not tell you when to send RH4's as opposed to RH3's. But as you suggest, explaining that issue and giving directions could be very useful.

The lack of traffic back might be a trigger, to, like, send RRH first, and if it's still no good, move to another AR. The bandwidth you get (back and forth) is more often then not the key to movement. When you have IPSEC, an unknown access with a lot of bandwidth might be a better choice then a safe access that's very benevolent and very slow ... like a modem.

> 
> Now MIPv6 prevents this type of attacks by limiting BCE lifetime to 7
> minutes. The problem here is that the BCE lifetime may be higher
> because the BU that has created it was protected with an IPSec SA.
> 
> The result of this attack is that an attacker may be on the path for
> just a moment and launch an attack that last for a period T (which may
> be very long)
> 
> AFAICT the draft does not consider this explicitely, in particular it
> doesn't defines values for T.
> Please note that sending the RRH in every packet doesn't really
> protects against this attacks, since for instance unidirectional flows
> comming from the HA to the MR would still be susceptible to this type
> of attacks.

Again, the lack of incoming traffic can trigger a RRH. A BU can be used to convey it in the absence of traffic. The question is when you have a malevolent guy on your path, he can easily kill your traffic by just scrambling the radio waves of dropping packets. The problem you raise, as I understand it, is to avoid lasting effects when the bad guy is gone. Again, this is not MIP RO where the bad guy is an intruder close to the CN that attacks and goes. Here, the "bad guy" might stay there. You might even be visiting him. It's not only a question of adding a RRH but also a question of detecting a situation and moving away.

> My suggestion would be to limit the lifetime of the information
> obtained from the RRH to 7 minutes, the same that the BCE information
> obtained through the RR procedure.
> 
> 
> Comments?
Thanks a lot for you point. I'll try some text and submit it to you, unless you wish to propose something?

In our implementation, RRH is sent much more often then every 7mn and it's configurable by the user. We also have an exponential backoff.
And like I said, there's more to it. Maybe we should start a reflection on roaming heuristics when you're in un-trusted territories, what happens if there's r rogue on the way, how MR/MNs react to fluctuating bandwidth (back and forth) etc... Obviously this is beyond the RRH draft...

Pascal

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 19 Oct 2004 19:08:51 +0200

Hi Pascal,

El 19/10/2004, a las 10:02, Pascal Thubert (pthubert) escribió:

>
>
> If I understand your point, the problem is the time shifting attack 
> has consequences even when the attacker is gone, at least till the 
> next RRH. The draft does not mention how often RRH are sent and what 
> triggers them.
>

Perfect summary, indeed

> Note that in this case, and as opposed to MIP RO, the L4 ACKs are 
> still protected because there is an SA.

But data packets only MAY be protected by IPSec, it is not a MUST, 
right?

So perhaps data packets will flow in clear text, in which case the 
attacker can see al the traffic

am i missing your point?

>  So redirecting packets like this would be equivalent to destroying 
> them, and then the flows tarish. But you can not make that a bombing 
> attack. Since the guy in on the path, it's easier for him to just 
> destroy the packets. And once he's gone, he can not reuse any token he 
> got while he was in to maintain the attack.
>
> Our implementation has a number of heuristics to decide when to roam 
> and when to send RRH. And I guess there could be many more that could 
> make a difference on the marketplace while still maintaining 
> interoperability.

agree

>  MIP does not tell you when to roam. The RRH draft does not tell you 
> when to send RH4's as opposed to RH3's. But as you suggest, explaining 
> that issue and giving directions could be very useful.
>

But the point here is that if the RRH refresh is not done soon enough, 
there may be security implications. I mean, those heuristics not only 
have performance concequences but security implications

> The lack of traffic back might be a trigger, to, like, send RRH first, 
> and if it's still no good, move to another AR. The bandwidth you get 
> (back and forth) is more often then not the key to movement. When you 
> have IPSEC, an unknown access with a lot of bandwidth might be a 
> better choice then a safe access that's very benevolent and very slow 
> ... like a modem.
>
>>
> Again, the lack of incoming traffic can trigger a RRH.

Yes, my point is that you probably want to do it more often in some 
cases to prevent time shifted attacks, (even if you are not moving)

>  A BU can be used to convey it in the absence of traffic. The question 
> is when you have a malevolent guy on your path, he can easily kill 
> your traffic by just scrambling the radio waves of dropping packets. 
> The problem you raise, as I understand it, is to avoid lasting effects 
> when the bad guy is gone.

yes

>  Again, this is not MIP RO where the bad guy is an intruder close to 
> the CN that attacks and goes. Here, the "bad guy" might stay there. 
> You might even be visiting him. It's not only a question of adding a 
> RRH but also a question of detecting a situation and moving away.
>

well, perhaps this is more ambicious...
I guess that an initial approach would be to avoid time shifting 
attacks.
I mean, if our security goal is simply to be as good as fixed IPv6, 
this is good enough imho

> unless you wish to propose something?

I don't feel that i understand all the elements involved in the 
heuristics to write something, but i would be glad to provide feedback 
on the text

> In our implementation, RRH is sent much more often then every 7mn

good, but probably some lower bound for the frequency should be defined 
i guess.

Regards, marcelo

>  and it's configurable by the user. We also have an exponential 
> backoff.
> And like I said, there's more to it. Maybe we should start a 
> reflection on roaming heuristics when you're in un-trusted 
> territories, what happens if there's r rogue on the way, how MR/MNs 
> react to fluctuating bandwidth (back and forth) etc... Obviously this 
> is beyond the RRH draft...
>
> Pascal
>
>
>
>
>
>
>
>
------------------------------------------
Please note that my former email address
[email-masked] is no longer in use
Please send mail to:
marcelo at it dot uc3m dot es
------------------------------------------