Subject: [MEXT] re-direction attack on MCoA

From: RYUJI WAKIKAWA <[email-masked]>
Date: Mon, 28 Jan 2008 12:26:47 +0900

Hi,

At the last IETF meeting, Benjamin presented the security  
vulnerability of MCoA, re-direction attack.
Benjamin's text is merged into the security consideration section.   
Thanks Benjamin.

However, we didn't merge the solution part in the MCoA.
The proposed solution is more like an extension and should be written  
in the separate document.
We believe the issue of re-direction attack should not be often  
happened because
a malicious mobile node is always traceable by an operator (i.e. HA).
A mobile node must take certain risk to do re-direction attack.
For the MCoA document it should be sufficient to just point out this  
threats.

If you have any comments, let us know.
I attach the Benjamin's proposed text.

thanks
ryuji

To mitigate such risk described in Section 9, one approach is for the
care-of address to be secured cryptographically (CGA) [RFC-3972], thus
permitting the home agent to know if the mobile node actually owns that
particular care-of address listed in the binding update message.  
However,
introducing cryptographically generated care-of addresses might  
increase the
complexity of the mechanism to achieve multiple bindings such as how a
message can contain multiple CGA signatures for each of the care-of
addresses, integration between the CGA module and Mobility Support  
module in
a network stack implementation and further increasing the size of the
binding update message. Furthermore, using CGA does not prevent a  
malicious
mobile node to launch a flooding attack against a subnet by generating
multiple non-existent care-of addresses in that subnet using the mobile
node's own public keys.

Another approach to mitigate the risk is to employ some means at a home
agent to limit the amount of information that a home agent can send to a
care-of address that has not be tested for its reachability. This  
reduces
the chances of the home agent from flooding packets to a particular  
untested
care-of address. A possible technique to achieve this is to use credit- 
based
authorization (CBA) [RFC-4866]. In this technique, for the home agent to
fully use the care-of address for packet routing, the home agent would  
need
to receive a packet from the mobile node from the untested care-of  
address.
However, the packets that the home agent receives from these untested
care-of addresses might not be sent by the mobile node. Hence, this
technique and the following few proposed techniques will henceforth  
assumes
that ingress filtering within the network is done. For example, a mobile
node can use the Internet Control Message Protocol (ICMP) described in
[RFC-792] to send a request message via its home address to a untested
victim care-of address, thereby triggering a response from this care-of
address. Also, in situations where an interface of the mobile node has
asymmetrical link characteristics (e.g. General Packet Radio System),  
that
particular interface might have resource constraint on its upload path
making it costly for a mobile node to send a packet to its home agent  
using
that particular interface.

In yet another approach, instead of the home agent waiting for a  
packet to
fully utilize a care-of address for routing, it might be possible for  
the
home agent to send a packet to a untested care-of address to trigger a
response from the mobile node from that care-of address. One technique
described in [ID-RRCOOKIE] uses a cookie to prove to the home agent  
that the
mobile node is reachable at a specified care-of address. Another  
technique
could employ the use of the Binding Refresh Request message to trigger  
the
mobile node to send a binding update message from that care-of address  
to
the mobile node. However, this technique of testing reduces the  
optimization
benefit of sending bulk registration as it would require the mobile  
node to
respond via all these care-of addresses. In this case, the mobile node  
might
as well send the binding update message individually for each care-of
address.

To optimize the previous approach in order to keep the benefits of bulk
registration, the home agent could test the care-of address by asking a
mobile node to reply from a different care-of address as oppose to the
care-of address that was used by the home agent to send the trigger  
message.
This utilizes the concept of multiple care-of addresses whereby the  
mobile
node need not respond back using the same path as the reception of the
request. Such a concept is particularly useful in the event that the  
mobile
node has several unverified care-of addresses that needs to be tested.  
By
asking the mobile node to respond via another care-of address, in one  
round
trip time, the home agent would be able to verify two care-of addresses.

_______________________________________________
MEXT mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mext

---

From: "Benjamin Lim" <[email-masked]>
Date: Mon, 28 Jan 2008 12:17:11 +0800

Hi, 

Some points inline to start of discussion.

> -----Original Message-----
> From: RYUJI WAKIKAWA [mailto:[email-masked]] 
> Sent: Monday, January 28, 2008 11:27 AM
> To: [email-masked]
> Subject: [MEXT] re-direction attack on MCoA
> 
> Hi,
> 
> The proposed solution is more like an extension and should be 
> written in the separate document.
> We believe the issue of re-direction attack should not be 
> often happened because a malicious mobile node is always 
> traceable by an operator (i.e. HA).
[Ben] Such risk taken by the mobile node does factor into the account on
wether the attack will occur. However, I find it hard to justify that such
risk will prevent such attack from happening often. If more and more
attackers are willingly to take such risk (e.g. strong sense of purpose or
even 'big ego') or there exisit better mechnisam that helps mask the
attacker identity in the future, can we say that such attacks will not
happen often?

> For the MCoA document it should be sufficient to just point 
> out this threats.
[Ben] This is my point of view. As this is a standard tracks document for a
protocol, stating a possible miuse of the protocol (aka loop hole) without
providing some soultions or guideline to it seems funny. Its like saying
"hey you can exploit this protocol this way. How to slove/prevent it, crack
your own brains" Hence, my intention of the below proposed text is to serve
as a guide that such exploit can be reduce/prevent with some methods. This I
feel helps implementers as we provide some basic steps to help advert such
misuse.

Would appericate any comments to help in this discussion. Thanks!

Regards,
Benjamin Lim
> To mitigate such risk described in Section 9, one approach is 
> for the care-of address to be secured cryptographically (CGA) 
> [RFC-3972], thus permitting the home agent to know if the 
> mobile node actually owns that particular care-of address 
> listed in the binding update message.  
> However,
> introducing cryptographically generated care-of addresses 
> might increase the complexity of the mechanism to achieve 
> multiple bindings such as how a message can contain multiple 
> CGA signatures for each of the care-of addresses, integration 
> between the CGA module and Mobility Support module in a 
> network stack implementation and further increasing the size 
> of the binding update message. Furthermore, using CGA does 
> not prevent a malicious mobile node to launch a flooding 
> attack against a subnet by generating multiple non-existent 
> care-of addresses in that subnet using the mobile node's own 
> public keys.
> 
> Another approach to mitigate the risk is to employ some means 
> at a home agent to limit the amount of information that a 
> home agent can send to a care-of address that has not be 
> tested for its reachability. This reduces the chances of the 
> home agent from flooding packets to a particular untested 
> care-of address. A possible technique to achieve this is to 
> use credit- based authorization (CBA) [RFC-4866]. In this 
> technique, for the home agent to fully use the care-of 
> address for packet routing, the home agent would need to 
> receive a packet from the mobile node from the untested 
> care-of address.
> However, the packets that the home agent receives from these 
> untested care-of addresses might not be sent by the mobile 
> node. Hence, this technique and the following few proposed 
> techniques will henceforth assumes that ingress filtering 
> within the network is done. For example, a mobile node can 
> use the Internet Control Message Protocol (ICMP) described in 
> [RFC-792] to send a request message via its home address to a 
> untested victim care-of address, thereby triggering a 
> response from this care-of address. Also, in situations where 
> an interface of the mobile node has asymmetrical link 
> characteristics (e.g. General Packet Radio System), that 
> particular interface might have resource constraint on its 
> upload path making it costly for a mobile node to send a 
> packet to its home agent using that particular interface.
> 
> In yet another approach, instead of the home agent waiting 
> for a packet to fully utilize a care-of address for routing, 
> it might be possible for the home agent to send a packet to a 
> untested care-of address to trigger a response from the 
> mobile node from that care-of address. One technique 
> described in [ID-RRCOOKIE] uses a cookie to prove to the home 
> agent that the mobile node is reachable at a specified 
> care-of address. Another technique could employ the use of 
> the Binding Refresh Request message to trigger the mobile 
> node to send a binding update message from that care-of 
> address to the mobile node. However, this technique of 
> testing reduces the optimization benefit of sending bulk 
> registration as it would require the mobile node to respond 
> via all these care-of addresses. In this case, the mobile 
> node might as well send the binding update message 
> individually for each care-of address.
> 
> To optimize the previous approach in order to keep the 
> benefits of bulk registration, the home agent could test the 
> care-of address by asking a mobile node to reply from a 
> different care-of address as oppose to the care-of address 
> that was used by the home agent to send the trigger message.
> This utilizes the concept of multiple care-of addresses 
> whereby the mobile node need not respond back using the same 
> path as the reception of the request. Such a concept is 
> particularly useful in the event that the mobile node has 
> several unverified care-of addresses that needs to be tested.  
> By
> asking the mobile node to respond via another care-of 
> address, in one round trip time, the home agent would be able 
> to verify two care-of addresses.
>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 28 Jan 2008 11:30:17 +0100

El 28/01/2008, a las 5:17, Benjamin Lim escribió:

> your own brains"

not really.
imho we should state that the attacker can be traced since a pre  
existent SA with the HA is needed to launch this attack, so basically  
we say that if you do your SA lightly, you may have this problem and  
you would need to take additional security measures.

Regards, marcelo

> Hence, my intention of the below proposed text is to serve

---

From: RYUJI WAKIKAWA <[email-masked]>
Date: Mon, 28 Jan 2008 21:49:41 +0900

>> attacker identity in the future, can we say that such attacks will  

That future is nobody knows:-)
My question is whether we really need this solution in this base MCoA  
document.
You can always propose this solution in the separate document.

> existent SA with the HA is needed to launch this attack, so  
> basically we say that if you do your SA lightly, you may have this  
> problem and you would need to take additional security measures.

agree, this is what we (authors) think.

regards,
ryuji

---

From: Wassim Haddad <[email-masked]>
Date: Mon, 28 Jan 2008 23:04:57 +0200 (EET)

Hi,

On Mon, 28 Jan 2008, marcelo bagnulo braun wrote:

> imho we should state that the attacker can be traced since a pre existent SA 
> with the HA is needed to launch this attack, so basically we say that if you 
> do your SA lightly, you may have this problem and you would need to take 
> additional security measures.

=> IMHO, this type of defense is a "second line of defense" and not a first one 
which should allow to stop the attack immediately when it occurs. So I also believe
that we do need a real mechanism which would be complemented by the existing one.

Regards,

Wassim H.

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 28 Jan 2008 14:28:01 -0800

Hi Benjamin,

FWIW, for the current draft, I think it is sufficient to point
out the threats in the security considerations section. The
home agent knows which mobile node launched the attch, so that
should be a deterrent. We should not require the CoA to be a
CGA, require CBA or mandate a return routability test for the
CoA for the multiple CoA extension.

I also think we should add an informative reference pointing
to draft-lim-mext-multiple-coa-verify-00 for preventing the
attack.

Vijay

---

From: "Benjamin Lim" <[email-masked]>
Date: Tue, 29 Jan 2008 10:50:17 +0800

Hi, 

Reply inline.

=8==8<=8==
> > [Ben] This is my point of view. As this is a standard 
> tracks document 
> > for a protocol, stating a possible miuse of the protocol (aka loop 
> > hole) without providing some soultions or guideline to it 
> seems funny. 
> > Its like saying "hey you can exploit this protocol this way. How to 
> > slove/prevent it, crack your own brains"
> 
> not really.
> basically  
[Ben] I do not think that the SA between MN and HA would stop such problem.
What you propose only limits the effect of the problem and not prevent it.
Even if the malicious MN and HA has a pre-establish SA, how is the HA going
to know to start tracing to find the root of the problem? Only when victims
complain to the HA, then the HA would begin finding the cause to such
problem correct? So the problem has occurred and now the home agent will try
to limit the effect of the problem from spreading even further. 

Also, the attacker need not be the user of the mobile node. One example is
the bot-net scenario where the attacker controls unwilling legit mobile
nodes to perform such attack. The HA can trace back to these unwilling
mobile nodes and take action (e.g. deny these unwilling mobile nodes
service). Yes, by denying the attacker of its tools, you can prevent the
attack from escalating further. However, shutting down your own network to
prevent such action is tad bit costly to the operator no? Maybe this was the
intention of the attacker in the first place.

Hence, base on the above points, wouldn’t it be better if the home agent can
prevent such problem from happening in the first place?

Regards,
Benjamin Lim

---

From: "Benjamin Lim" <[email-masked]>
Date: Tue, 29 Jan 2008 11:03:01 +0800

Hi Vijay, 

=8==8<=8==
> FWIW, for the current draft, I think it is sufficient to 
> point out the threats in the security considerations section. 
> The home agent knows which mobile node launched the attch, so 
> that should be a deterrent. We should not require the CoA to 
> be a CGA, require CBA or mandate a return routability test 
> for the CoA for the multiple CoA extension.
[Ben] I am not mandating a solution for CoA testing yet. My intention in my
draft was to analyze and discuss the best way to solve the problem. Till
then, I feel it might be better to list the current possible approaches to
the problem in the MCoA draft. These approaches serves as some options that
implementers can take to help advert such problem.

> to draft-lim-mext-multiple-coa-verify-00 for preventing the attack.
[Ben] A standard track document pointing to a draft that may expire for
solutions. I am not sure if this is the correct way to go.

Regards,
Benjamin Lim

> >> happened because a malicious mobile node is always traceable by an 
> >> operator (i.e. HA).
> > [Ben] Such risk taken by the mobile node does factor into 
> the account 
> > on wether the attack will occur. However, I find it hard to justify 
> > that such risk will prevent such attack from happening 
> often. If more 
> > and more attackers are willingly to take such risk (e.g. 
> strong sense 
> > of purpose or even 'big ego') or there exisit better mechnisam that 
> > helps mask the attacker identity in the future, can we say 
> that such 
> > attacks will not happen often?
> > 
> > slove/prevent it, crack your own brains" Hence, my intention of the 
> > below proposed text is to serve as a guide that such exploit can be 
> > reduce/prevent with some methods. This I feel helps 
> implementers as we 
> > provide some basic steps to help advert such misuse.
> > 
> >> care-of address to be secured cryptographically (CGA) [RFC-3972], 
> >> thus permitting the home agent to know if the mobile node actually 
> >> owns that particular care-of address listed in the binding update 
> >> message.
> >> However,
> >> increase the complexity of the mechanism to achieve 
> multiple bindings 
> >> such as how a message can contain multiple CGA signatures 
> for each of 
> >> the care-of addresses, integration between the CGA module and 
> >> Mobility Support module in a network stack implementation 
> and further 
> >> increasing the size of the binding update message. 
> Furthermore, using 
> >> CGA does not prevent a malicious mobile node to launch a flooding 
> >> attack against a subnet by generating multiple 
> non-existent care-of 
> >> addresses in that subnet using the mobile node's own public keys.
> >>
> >> Another approach to mitigate the risk is to employ some means at a 
> >> home agent to limit the amount of information that a home 
> agent can 
> >> send to a care-of address that has not be tested for its 
> >> reachability. This reduces the chances of the home agent from 
> >> flooding packets to a particular untested care-of address. 
> A possible 
> >> technique to achieve this is to use credit- based 
> authorization (CBA) 
> >> [RFC-4866]. In this technique, for the home agent to fully use the 
> >> care-of address for packet routing, the home agent would need to 
> >> receive a packet from the mobile node from the untested care-of 
> >> address.
> >> assumes that ingress filtering within the network is done. For 
> >> example, a mobile node can use the Internet Control 
> Message Protocol 
> >> (ICMP) described in [RFC-792] to send a request message 
> via its home 
> >> address to a untested victim care-of address, thereby triggering a 
> >> response from this care-of address. Also, in situations where an 
> >> interface of the mobile node has asymmetrical link characteristics 
> >> (e.g. General Packet Radio System), that particular 
> interface might 
> >> have resource constraint on its upload path making it costly for a 
> >> mobile node to send a packet to its home agent using that 
> particular 
> >> interface.
> >>
> >> packet to fully utilize a care-of address for routing, it might be 
> >> possible for the home agent to send a packet to a untested care-of 
> >> address to trigger a response from the mobile node from 
> that care-of 
> >> address. One technique described in [ID-RRCOOKIE] uses a cookie to 
> >> prove to the home agent that the mobile node is reachable at a 
> >> specified care-of address. Another technique could employ 
> the use of 
> >> the Binding Refresh Request message to trigger the mobile node to 
> >> send a binding update message from that care-of address to 
> the mobile 
> >> node. However, this technique of testing reduces the optimization 
> >> node to respond via all these care-of addresses. In this case, the 
> >> mobile node might as well send the binding update message 
> >> To optimize the previous approach in order to keep the benefits of 
> >> bulk registration, the home agent could test the care-of 
> address by 
> >> asking a mobile node to reply from a different care-of address as 
> >> oppose to the care-of address that was used by the home 
> agent to send 
> >> the trigger message.
> whereby the 
> >> mobile node need not respond back using the same path as the 
> >> reception of the request. Such a concept is particularly useful in 
> >> the event that the mobile node has several unverified care-of 
> >> addresses that needs to be tested.
> >> By
> address, in one 
> >> round trip time, the home agent would be able to verify 
> two care-of 
> >> addresses.
> >>

---

From: "George Tsirtsis" <[email-masked]>
Date: Tue, 29 Jan 2008 10:58:37 +0000

Hi Ben, et.al.,

While the issue you point out is real (everyone seems to agree with
that) it falls under the category of traceable attacks, as others have
already pointed out. In MIPv6 we never really considered the issue of
a "fake" CoAs as a very important one (Only MIPv4 FA Mode deals with
that). Indeed, several attacks, like the redirection attack you point
out are possible, even without MCoA support. But other attacks are
also possible without MCoA support e.g., an MN associates with two
different HAs and registers the HoA from the first as the CoA for the
second and vice versa, creating a routing loop.

So, I share the sentiment of the group that mitigation techniques
should be defined outside the MCoA spec, and I would suggest we
actually expand the scope of these techniques to cover also other
cases involving CoA based attacks.

In any case the attack you describe for the MCoA case does not become
really interesting unless it is combined with flow filtering which is
out of scope of the MCoA draft. In fact I think the following should
be removed form the MCoA draft.....possibly moved to the flow
filtering draft.:
"   This valid care-of address could then be used by the malicious mobile
   node to set up flow filtering rules at its home agent, thereby
   controlling and/or launching new re-direction attacks."

Regards
George

---

From: Julien Laganier <[email-masked]>
Date: Tue, 29 Jan 2008 18:10:03 +0100

Hello,

<Chair hat off>

> Reply inline.

But MIPv6 trust model presuppose that the MN can trusted by the HA, and
thus they have a SA. Thus I don't see how we can stop any such problems
without changing the MIPv6 trust model, which doesn't look realistic.

> intention of the attacker in the first place.

This point seems moot. If the goal of the attacker is to deny service to
"unwilling legit mobile nodes" that it is in control of, then it doesn't
need any of that re-direction stuff: Since it controls them it can
simply deny them service. Or am I missing something?

> prevent such problem from happening in the first place?

See my comments on your two points above.

Best,

--julien

---

From: Wassim Haddad <[email-masked]>
Date: Tue, 29 Jan 2008 23:53:35 +0200 (EET)

Hi Julien,

On Tue, 29 Jan 2008, Julien Laganier wrote:

>>>> [Ben] This is my point of view. As this is a standard tracks document 
>>>> for a protocol, stating a possible miuse of the protocol (aka loop hole) 
>>>> without providing some soultions or guideline to it seems funny. 
>>>> slove/prevent it, crack your own brains" not really.
>>> imho we should state that the attacker can be traced since a pre  existent 
>>> SA with the HA is needed to launch this attack, so basically  we say that 
>>> if you do your SA lightly, you may have this problem and  you would need 
>>> to take additional security measures.

=> IMHO, it is equally unrealistic to have a trust model which does not 
fully grasp the reality. Or perhaps someone can explain how can we know a 
priori that *any* potential attacker will be deterred for fear of being 
traced!

Regards,

Wassim H.

>> Hence, base on the above points, wouldn?t it be better if the home agent 
>> can

---

From: "Benjamin Lim" <[email-masked]>
Date: Wed, 30 Jan 2008 10:16:50 +0800

Hi George, 

=8==8<=8==
> In any case the attack you describe for the MCoA case does 
> not become really interesting unless it is combined with flow 
> filtering which is out of scope of the MCoA draft. In fact I 
> think the following should be removed form the MCoA 
> draft.....possibly moved to the flow filtering draft.:
[Ben] I was using flow filtering to illustrate the effect of the problem (MN
binding fake CoA) I feel this allow readers to grasp the whole situation
more clearly. Thus, I feel this example should remain in the MCoA draft for
clarity purpose.

Regards,
Benjamin Lim