Subject: [mobile-ip] Future attacks and threats

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 25 Jan 2002 16:32:01 -0800

Hi all,

This is an effort to compile all the "future attacks". there
are just too many mails and many people are not sure what 
exactly "future attacks" are.

there are 4 future attackes as far as I can see (Pekka, please
let me know if there are more).

1. described in
http://www.tml.hut.fi/~pnr/presentations/IETF50-SAAG-AddrOwn-Slides.pdf
(Pekka's slides)

     Solution for this threat:
	There is one way of preventing this attack by having 
	a check at the CN.

	lets assume 

	MN1 has created a binding A (HoA) - B (CoA) at the CN.
	when MN2 tries to create a binding C (HoA) - A (CoA),
	the CN performs a check.

	if (bc_lookup(C) == NULL)
        	a new binding, process it;
	if (bc_lookup(A) != NULL)
	        reject binding;
	
	in the example in the slides

	when the target MN tries to bind 3ff0::1 to its home 
	address, the second check would fail because the Attacker 
	has already bound 3ff0::1 has its home address.  so the 
	scenario in slide 11 is prevented from happening.

2. described in draft-aura-mipv6-bu-attacks-00.txt
	
	For this attack to succeed, it requires an unauthenticated
	binding update. since any BU has to pass the return 
	routability test, this is not a threat IMO.

3. (cut and paste from a Pekka's mail)
   > you can use the future attack technique for bombing too.  
   > You physically go to your target network (or tap to a link
   > in between), plug in your laptop, pretend to be your own HA, 
   > establish a binding at the CN, go away, and later let the 
   > binding to expire. If you have active communications going 
   > on when the binding expires (e.g. a large file transfer), 
   > the packets start bombing to your target, and you can even 
   > keep the TCP transfer to go on for some time by carefully 
   > sending false ACKs.

	I am not sure I understand this threat correctly. if the
	attack is to target a network, it would work. but if you
	want to target a single host, it wont work. to target a
	single host, the attacker has to be on the same link
	as the target node, and it also has to pretend that it
	is HA, and both the CoA and HoA have to be from the same
	prefix (maybe I am missing something very obvious). 

4. cut and paste from Pekka's mail with subject "A threat RR doesn't 
   solve and that doesn't seem to exist in IPv4" 
   > Let us consider an attacker A, a corrensponding node CN, and
   > a pre-selected mobile node MN whose home address is HoA.
   > Now, A has decided to steal all traffic that CN will
   > initiate towards MN.  To do so, it somehow arranges itself
   > _once_ to the path between CN and MN's HA.  It may do this,
   > for example, by visiting the network where CN is located,
   > where MN's HA is located, or any network in between.
   > 
   > While being at the path between CN and MN's HA, the attacker
   > creates a binding (and a corresponding BSA) at CN.  This will
   > succeed, since A knows MN's home address and it can foil the
   > RR test.  As a result, CN believes that MN is currently located
   > at the adddress given by A, and therefor whenever it sends
   > packets to MN, it will send them to the attacker.  Thus, A
   > is able to steal all connections initiated by CN towards MN.
   > Furthermore, if CN does not check the return routability
   > of the MN's home address if there is already an existing BSA,
   > then the attacker can keep up the faulty binding as long as it
   > wishes, simply by renewing the binding and BSA periodically.
   > To renew, it no longer needs to be at the path between the CN
   > and the MN's HA.

   	I agree this is a threat that does not exist in IPv4. but
	this threat is too far fetched - the main reason being
	the attacker has to plug into the path between CN and
	HA. We could live with this threat.

I do agree with the observation that the threats from "future 
attacks" can be minimized by limiting the binding lifetime 
(obtained by Return Routability) to a few minutes. none of 
the above threats are so serious that you need a potentially
expensive (computationally) mechanism like CGA. IMO CGA is
very useful for IPv6. it actually eliminates a few threats 
that exist in IPv6 protocol. proving address ownership is
a big deal IMO. it also takes care of neighbor discovery 
threats identified in draft-kempf-ipng-netaccess-threats-00.txt
to a certain extent. it SHOULD be taken up in the IPv6 WG.

if I am missing something, please let me know.

regards
Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 25 Jan 2002 16:46:14 -0800

hi,

(2) is in sec 2.5 (Bombing CoA with Unwanted Data),
draft-aura-mipv6-bu-attacks-00.txt

Vijay

---

From: Francis Dupont <[email-masked]>
Date: Sat, 26 Jan 2002 16:20:37 +0100

=> this is not a comment about the remainder of this message
but on principles: these "future attacks" should be clearly
documented into the threat model document aka
draft-ietf-mobileip-mipv6-scrty-reqts-xx.txt
of course if they are not yet.
BTW it seems there are more than 4 issues...

Regards

[email-masked]

PS: this is not against you, if this is not done soon
the pressure should be put on authors of security requirements.

---

From: Pekka Nikander <[email-masked]>
Date: Mon, 28 Jan 2002 10:55:51 +0200

Hi Vijay,

> let me know if there are more).

Thanks for compiling this list.  Right now (Monday morning and
I still haven't had my coffee) I can't right away thing about
additional future attacks, but I am pretty sure that there are
others, too.  That is, as far as I know, nobody has tried to
perform a rigorious analysis on the area.

The basic mechanisms is well understood, though.  The basic
idea in all the future attacks is that you create a false
binding, and use it then to launch some kind of attack in the
future.  Depending on the protections involved, creating
the false binding may be easier or harder, and therefore
the risks created by a particular attack scenario depend
on the protections applied.

What makes the future attacks perhaps more devious than the
other attacks is that the attacker can select the _time_
when to establish the false binding.  In other types of
attacks, the attacker usually has to wait for the the
target node or network to talk to a CN, or in other ways
must be able to wait for the right time to launch the attack.
In the future attacks usually not so; the preparations can
be done beforehand, e.g. in the night when the target MN
is likely to be off-line.

> expensive (computationally) mechanism like CGA. 

I tend to agree, at least in the light of my current understanding.
The residual threats left after applying two-way-RR (both towards
the CoA and HoA) and limiting the binding lifetime to a few
minitutes _seem_ to be small enough that we can accept them.

It is important to understand, though, that the lifetime
limitation is a very essential element here.  RR is needed
to limit the _place_ of the attacker; to succeed, the attacker
must somehow get into the vulnerable spots in RR, i.e.
at the MN link, HA link, CN link, or a path between
the MN and CN or CN and HA, depending on the attack.
The lifetime limitation is needed to limit the _time_ when
the attacker can prepare for the attack.  Without this time
limitation, the attacker could prepare hours or even days
before the actual attack.  The lifetime limitation brings
back this to something reasonable, i.e. minutes.

> IMO CGA is

I tend to agree here, too.  However, since the scope of
the problem is fairly limited, MAYBE it would be better
to split off a new WG from IPv6 WG, prepare solutions there,
and then bring them back to the IPv6 WG.  I don't just know.
Could you, Vijay, raise this issue with Bob and Steve?
I know that at least Erik (Nordmark) and James (Kempf)
are very keen on seeing something to happen in that area.

--Pekka

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 28 Jan 2002 14:15:28 +0100 (CET)

> back this to something reasonable, i.e. minutes.

And if the HA-MN part of the communication is protected by something
like a secure tunnel for the BU associated messages then of course the
MN link as the path between the HA and MA can be made not vulnerable to
any such attacks.

> are very keen on seeing something to happen in that area.

So far there's been some discussion in PANA about whether (part of)
this problem belongs there but the correct answer from a management
perspective seems to be NO (need to make sure that PANA can deliver
a more basic authentication first).

I wonder if there is a set of people that would make to drive
a CGA BoF to point out what the addresses can be useful for?
So far I know:
	Authenticate and authorize hosts joining anycast addresses
	(in charter for MAGMA WG really)

	Same for multicast (need to understand how this fits with the multicast
	architecture that anybody can join a group)

	DAD and Address resolution spoofing (part of netacess-threats)

	Binding Updates

So I don't know what the best steps are for this.

  Erik

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 28 Jan 2002 12:41:09 -0800

> are very keen on seeing something to happen in that area.

I think it would be better if Gabriel or Claude (Castelluccia)
take this up.

Vijay

---

From: "James Kempf" <[email-masked]>
Date: Mon, 28 Jan 2002 14:43:57 -0800

Vjay,

Erik and I have a draft on threats to Neighbor Discovery
(draft-kempf-ipng-netaccess-threats-00.txt). I am very interested in
finding some solutions to securing Neighbor Discovery for public access
networks, because it is a problem
that wireless access providers will have when deploying 802.11 public
access networks. The problem came up in
PANA but we were requested to move out of there because it didn't seem
to be in scope, it probably
isn't in scope here either. We've been discussing it privately, perhaps
it's time to set up a mailing list?
Also, maybe Erik can tell us if we should contact Bob and Steve about
whether to keep it in
IPNG or start a separate BOF?

Were there any other threats besides those to Neighbor Discovery that
you had in mind? It might
make sense to handle this as a separate activity if they were bundled
(provided bundling makes sense
technically).

            jak

----- Original Message -----
From: "Vijay Devarapalli" <[email-masked]>
To: "Pekka Nikander" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; "Erik
Nordmark" <[email-masked]>; "James Kempf"
<[email-masked]>
Sent: Monday, January 28, 2002 12:41 PM
Subject: [mobile-ip] Re: Future attacks and threats

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 29 Jan 2002 11:10:31 +0100 (CET)

> IPNG or start a separate BOF?

How about setting up a separate mailing list and check on how many people
are interested in working on solving these types of problems?

It might be that a focused BoF and perhaps WG makes more sense, but it
would require that a number of people are willing to work on the problem.

  Erik