Subject: RE: [MEXT] re-direction attack on MCoA

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

Hi Julien, 

Replies inline.

=8==8<=8==
> 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.
[Ben] MIPv6 assumes that MN and HA have a trust relationship, hence HA does
not need to check the CoA that MN binds. Furthermore, a single MIPv6 session
only allows MN to bind a single CoA to its HoA at HA, hence further implying
that HA need not check CoA. However in MCoA, MN can now bind many CoAs at
HA. Can we assume the same trust level that the HA gives in MIPv6 applies to
MCoA? The original trust model of MIPv6 holds in MIPv6 operation due to the
specific conditions (e.g. only binding 1 CoA). However, if we change the
condition, we might need use other mechanisms to enhance the original trust
model to ensure that it holds. This is what I call adaptability (which what
most mammals are good at..;p)

> 
> > 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.
> 
> 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?
[Ben] The intention use previously was meant to say the goal of the attacker
is to make it a hassle for the operator in providing service to its
subscribers. If one MCoA MN is denied of service, the attacker can just
'capture' another MCoA MN to do its dirty work Since the operator is
tracing, it is likely that the operator can figure out the root of the issue
(e.g. the use of MCoA) base on the trend of the attack. Hence, the operator
might limited the usage of MCoA until it finds the 'mastermind' behind all
of this attack. I apologize the misuse of words in my last example ('shut
down' might be too harsh).

All in all, what I am trying to say is that tracing only limits the effect
of the attack from escalating further and not preventing it.

Regards,
Benjamin Lim

> 
> > 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?
> 
> See my comments on your two points above.
> 
> Best,
> 
> --julien

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

---

From: Wassim Haddad <[email-masked]>
Date: Wed, 30 Jan 2008 10:32:20 +0200 (EET)

> of the attack from escalating further and not preventing it.

=> which (again) also perfectly applies to a single CoA.

Regards,

Wassim H.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 30 Jan 2008 10:09:59 +0100

I agree with Wassim on both mails.

There's also the situation where the MN/MR might be fooled by the
visited network into believing that the CoA (or its prefix if a network
is attacked as opposed to a host) is on the visited link. DSMIP is also
exposed, in particular with IPv4 CoAs.

There are many scenarios that do not involve high mobility were a 3-way
or a 4-way handshake could be used to verify the CoA. We have proposed
such a test in section 6 of the RRH draft that uses a triggered 2nd BU
flow to verify the CoA in the first one:
http://tools.ietf.org/html/draft-thubert-nemo-reverse-routing-header-07#
section-6 

Pascal

>-----Original Message-----
>From: Wassim Haddad [mailto:[email-masked]] 
>Sent: mercredi 30 janvier 2008 09:32
>To: Benjamin Lim
>Cc: 'Julien Laganier'; [email-masked]
>Subject: RE: [MEXT] re-direction attack on MCoA
>
>> All in all, what I am trying to say is that tracing only limits the 
>> effect of the attack from escalating further and not preventing it.
>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 30 Jan 2008 17:44:58 +0100

Hi Ben,

> Replies inline.

I fail to see why the usage of multiple CoAs change the trust model  
for MIP w.r.t. to its relationship between MN and HA? could you expand  
on that?

> effect

We agree that tracing capabilities does not prevent that attack. The  
point being discussed afaict is whether we think this tracing  
capability is enough deterrent to make this attack not attractive to  
be persued by an attacker.

I mean, that is basically the case of security cameras that are  
recording (i mean those that do not have a person looking at them all  
the time). They do not prevent you from attacking but you know they  
will catch you later if you do something

this seems to be enough deterrent for many attackers, i guess.  
Wouldn't this be the case too?

Regards, marcelo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 30 Jan 2008 17:46:05 +0100

Pascal,

The question at this point is the following one: do you think that  
this threat should be addressed in the MCoA draft itself?

comments?

Regards, marcelo

---

From: Wassim Haddad <[email-masked]>
Date: Wed, 30 Jan 2008 19:19:07 +0200 (EET)

Hi Marcelo,

IMHO, this topic has to be included as a new item in the new charter and
should not be limited to MCoA.

Regards,

Wassim H.

On Wed, 30 Jan 2008, marcelo bagnulo braun wrote:

> Pascal,
>
> The question at this point is the following one: do you think that this 
> threat should be addressed in the MCoA draft itself?
>
> comments?
>
> Regards, marcelo
>
>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 30 Jan 2008 18:46:30 +0100

Fair enough.

I think George has made a very nice suggestion w.r.t. this in a  
previous email

I think that it may be interesting to write first a draft about  
residual threats on MIP from a general perspective, not limited to  
this one and then move to the potential solutions

I think that it would be good to write tis first draft in order to  
understand the potantail impact of those threats and figure out which  
ones need to be addressed.

comments? volunteers?

Regards, marcelo

---

From: Wassim Haddad <[email-masked]>
Date: Wed, 30 Jan 2008 20:16:35 +0200 (EET)

On Wed, 30 Jan 2008, marcelo bagnulo braun wrote:

> I think George has made a very nice suggestion w.r.t. this in a previous 
> email

=> I agree.

> I think that it may be interesting to write first a draft about residual 
> threats on MIP from a general perspective, not limited to this one and then 
> move to the potential solutions
>
> I think that it would be good to write tis first draft in order to understand 
> the potantail impact of those threats and figure out which ones need to be 
> addressed.
>
> comments? volunteers?

=> As there is a clear interest in the redirection attack on the HA side, 
I volunteer to do some work on this one.

Regards,

Wassim H.

---

From: "Benjamin Lim" <[email-masked]>
Date: Thu, 31 Jan 2008 10:28:13 +0800

Hi Marcelo, 

Replies inline.

=8==8<=8==
> I fail to see why the usage of multiple CoAs change the trust 
> model for MIP w.r.t. to its relationship between MN and HA? 
> could you expand on that?
[Ben] This point has been explained on the mailing list (old and new) for a
few times. I snip a summarize version of it here. More details can be found
in  draft (section 2) 
http://tools.ietf.org/wg/mext/draft-lim-mext-multiple-coa-verify-00.txt

=8==8<=8==
[Ben] RFC3775 assumes trust for home registration. More than likely, the CoA
is specified in the source address field of the packet hence ingress
filtering can be assumed to be performed. Even if AltCoA option used, in
RFC3775, at most MN can only specify one AltCoA binding. But in bulk
registration, MN can specify more than one CoA to be bound at HA.
Furthermore, only one of these CoAs is specified in the source address field
of the BU. The rest are specified in the BU itself. Hence, this increases
the risk of not knowing if they are actually valid routing address to MN
that HA has to take when binding these CoAs.
=8==8<=8==

Regards,
Benjamin Lim

> >> 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
> > [Ben] The intention use previously was meant to say the goal of the 
> > attacker is to make it a hassle for the operator in 
> providing service 
> > to its subscribers. If one MCoA MN is denied of service, 
> the attacker 
> > can just 'capture' another MCoA MN to do its dirty work Since the 
> > operator is tracing, it is likely that the operator can 
> figure out the 
> > root of the issue (e.g. the use of MCoA) base on the trend of the 
> > attack. Hence, the operator might limited the usage of MCoA 
> until it 
> > finds the 'mastermind'
> > behind all
> > of this attack. I apologize the misuse of words in my last example 
> > ('shut down' might be too harsh).
> >
> We agree that tracing capabilities does not prevent that 
> attack. The point being discussed afaict is whether we think 
> this tracing capability is enough deterrent to make this 
> attack not attractive to be persued by an attacker.
> 
> I mean, that is basically the case of security cameras that 
> are recording (i mean those that do not have a person looking 
> at them all the time). They do not prevent you from attacking 
> but you know they will catch you later if you do something
>

---

From: "Benjamin Lim" <[email-masked]>
Date: Thu, 31 Jan 2008 10:32:16 +0800

Hi, 

=8==8<=8==
> > I think George has made a very nice suggestion w.r.t. this in a 
[Ben] +1

> => As there is a clear interest in the redirection attack on 
> the HA side, I volunteer to do some work on this one.
[Ben] Since my draft already talks about one issue on the multiple CoA
scenario. I can contribute in that area. Will have an offline chat with
Wassim.

Regards,
Benjamin Lim

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 31 Jan 2008 11:13:19 +0100

El 30/01/2008, a las 19:16, Wassim Haddad escribió:
>
> => As there is a clear interest in the redirection attack on the HA  
> side, I volunteer to do some work on this one.
>

I think the work should be general to all residual threats on MIP as  
George mentioned, i think this would be more interesting since it  
would allow us to put the different threats in perspective and figure  
out which ones we should address.

>>>> The question at this point is the following one: do you think  
>>>> that this threat should be addressed in the MCoA draft itself?
>>>> comments?
>>>> Regards, marcelo

---

From: "Suresh Krishnan" <[email-masked]>
Date: Thu, 31 Jan 2008 05:59:51 -0500

Hi Marcelo,
  I am willing to work on a generic MIPv6 threats document along with the other interested people.

Cheers
Suresh

---

From: "George Tsirtsis" <[email-masked]>
Date: Thu, 31 Jan 2008 11:08:04 +0000

I am of course also interested in this work. I guess we already have
enough people to get the ball rolling on this.

Thanks
George

---

From: "Jean-Michel Combes" <[email-masked]>
Date: Thu, 31 Jan 2008 19:07:34 +0100

Hi,

I second Marcelo's opinion.
This is exactly the trust model which is used today by ISP concerning
P2P: no particular mechanism/protocol/architecture to block P2P flows
used to exchange illegal copies but companies (i.e. music and movies
majors) know IP addresses of people exchanging such type of files and
ask ISP to give to the justice the names behind these addresses.
In the MIPv6 case, the companies are also the ISP.

Best regards.

JMC.

2008/1/30, marcelo bagnulo braun <[email-masked]>:
>  > attacker
>  >>> Hence, base on the above points, wouldn't it be better if the home