Subject: [mobile-ip] Risks of not verifying the care-of address <draft-roe-mobileip-updateauth-01>

From: Erik Nordmark <[email-masked]>
Date: Sun, 9 Dec 2001 00:47:45 +0100 (CET)

Section 7.3 of <draft-roe-mobileip-updateauth-01> says
   The BAKE/2 and CAM-DH protocols described in this memo verify that
   that packets sent to a mobile node's claimed care-of address reach an
   entity that is willing to participate in the protocol.  If this check
   was not performed, a malicious mobile node could perform a denial of
   service attack by asking a correspondent node to send it a high
   volume stream of data, and then sending the correspondent a binding
   update that redirects the stream of data to the victim of the denial
   of service attack.  

But there seems to be a tradeoffs between this type of protection and
"3rd party reflection".
By this term I mean X sending a packet to A (with X as the source address)
which tells A to send packets to B.
("Normal reflection" is based on spoofing the source address to cause
reply packets to go back to the wrong place.)

BTW: bu3way has problem as well - the BUR sent from the CoA causes a BUC
to be sent to the Home Address.

If sending a packet from a CoA (or HoA) to the CN causes packets to be
sent to the address that was not in the source field, then this is
"3rd party reflection".

Such protocol mechanisms can be used to cause DoS attacks against low bandwidth
nodes as well.

For instance, assume X and A have 100 Mbps bandwidth between then and B
only has 100 kbps bandwidth.

Then X can send 100 Mbps of BU related packets (the first packet in
an exchange) to A. For DoS reasons A can't create state associated with
that first packet. If A sends the "response" packet to an IP address
other than the source address of the "request" then B might see on the order
of 100 MBps of packets coming towards it.

And ingress filtering can't prevent this, ITRACE can't trace it back from B,
etc.

So I think the conservative thing to do if there is a need to check with the
CoA as well as the HoA during BUs is to send more packets.
For instance, the MN could send packet1 both with CoA as the source
(causing a "response" to be sent to the CoA) and with HoA as the source
(reverse-tunneled through the HA).
Then when the has the information from both "responses" it can do the
actual BU.

But it still isn't obvious to me that preventing packet flooding
attacks against a unwilling CoA is a requirement. Seems like there are other
means to flood a low-bandwidth node.

  Erik

---

From: Jari Arkko <[email-masked]>
Date: Sun, 09 Dec 2001 03:10:40 +0200

> sent to the address that was not in the source field, then this is

Ah, I see. So the problem in BAKE/2 and CAM-DH is more the message to the
Home Address, than the CoA routability test.

Interestingly, the problem you describe is exactly the same one as we
have been discussing around the HAO and regular traffic! Obviously,
when sending the first packet of BAKE/2 we do not have a BCE ready yet -
so to use the HAO at this time would be illegal according to rules
laid out before.

I believe also Classic Bake, Busec, and SUCV have a similar issue.

> Then when the has the information from both "responses" it can do the

This is an interesting approach. We have to think about it some more.
A few issues come to mind:

- Using a similar technique as we are using now, the additional message does
   not have to add more delay, if both messages can be sent simultaneously
- In order to keep the CN stateless, the processing of the two legs must
   be kept independent and two response messages generated also. Have to
   look at the math to make sure this is doable...

> means to flood a low-bandwidth node.

I believe what we do with the CoA test can, if omitted, cause really serious
damage. It's not just the low bandwidth nodes, the attack outlined in draft-aura
(open tcp to yourself, take a look at the sequence numbers, then move the stream
towards victim, possibly send a few TCP ACKs now and then to keep the stream going)
appears to be able to easily flood larger nodes or whole networks due
to the high amplification factor. It appears more serious than HOA reflection,
where there's no amplification. However, the success of the attack depends on (a)
ingress filtering being off in the attacker's network (irrelevant if it is on
in the victim network). And, (b) you have to be on the path HA-CN in order to
fool the CN's weak authentication procedure*. Ok, so you could say that it is
an unlikely place to be in. However, in this case the attacker has complete
freedom to choose both HA and CN nodes in a way that places him between them.
This is because he is not attacking HA and CN, he is attacking someone at another
location, the CoA.

I can't immediately see how you could do with current stationary
IPv4. Since we assumed there's no ingress filtering, the attacker could
indeed try to open a session towards a spoofed source address. Attacks like
that exist, and typically depend on the knowledge the attacker has on how
the OS allocates TCP sequence numbers etc. But there's an important
additional advantage that MIPv6 gives for the attacker: he can
temporarily direct the flow to himself to learn TCP sequence numbers
or any basic DoS protection built to the particular protocol.

Jari

*) Trivial for BAKE/2 and relatives. For CAM-DH and relatives, you could invent
your own public key and address.

---

From: Erik Nordmark <[email-masked]>
Date: Sun, 9 Dec 2001 22:02:00 +0100 (CET)

> Home Address, than the CoA routability test.

OK - you mean I swapped things around.
The first packet is sourced from the CoA and this causes a packet to
be sent to the HoA.

>    not have to add more delay, if both messages can be sent simultaneously

agreed.

>    look at the math to make sure this is doable...

I the context bu3way you could get a separate cookie on each path and
be required to present both cookies in the actual BU message.
In this case the CN would be stateless.

> damage. It's not just the low bandwidth nodes, the attack outlined in
> draft-aura (open tcp to yourself, take a look at the sequence numbers, then
> move the stream towards victim, possibly send a few TCP ACKs now and then to
> keep the stream going) appears to be able to easily flood larger nodes or
> whole networks due to the high amplification factor. It appears more serious
> than HOA reflection, where there's no amplification. However, the success of
> the attack depends on (a) ingress filtering being off in the attacker's
> network (irrelevant if it is on in the victim network). 

Why does ingress filtering need to be off?

The attacker has the home address for the connection.
Thus it can send ACK packets from its home address while the
data packet are route optimized to go directly to the CoA (victim).

Of course, in this case the victim sees the HoA in the packets which points
at the attacker. Spoofing allows the attacker to hide.

  Erik

> And, (b) you have to
> be on the path HA-CN in order to fool the CN's weak authentication
> procedure*. Ok, so you could say that it is an unlikely place to be in.
> However, in this case the attacker has complete freedom to choose both HA
> and CN nodes in a way that places him between them. This is because he is
> not attacking HA and CN, he is attacking someone at another location, the
> CoA.
> 
> *) Trivial for BAKE/2 and relatives. For CAM-DH and relatives, you could
> invent your own public key and address.
> 
>

---

From: Claude Castelluccia <[email-masked]>
Date: Mon, 10 Dec 2001 09:55:24 +0100

> I believe also Classic Bake, Busec, and SUCV have a similar issue.

Hello,

no, SUCV does not have a similar issue..
With SUCV, the packets are exchanged directly between the MN and the CN.
This was motivated by 2 things:
-we wanted to avoid the problem mentioned above
-we wanted to support homeless MN.

regards,
Claude.

--

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/

---

From: Jari Arkko <[email-masked]>
Date: Mon, 10 Dec 2001 13:42:07 +0200

> -we wanted to support homeless MN.

I guess I have to believe what you say, though the -01 version of your
draft seems to say under SUCVp2 that "this message is sent to the MN's
Home Address and forwarded by the Home Agent to the Mobile current
CoA". (Perhaps this has changed in -02 which I hear is around somewhere,
can you btw send a link, I didn't seem to get it from the I-D directories.)

But let's not argue what the protocols do and don't do. I think we
can make a few observations based on the discussion:

- If we believe the HOA reflection is an issue, we should avoid
   HOA reflection even in the weak authentication protocol. This
   is apparently doable in the way that we discussed with Erik previously,
   or with the way that you indicate above.

- The only way to support homeless MN is to employ the public key
   hash techniques, HoA return routability isn't applicable. (Or?)

- In order to prevent trivial DoS attacks against the public
   key hash techniques, CAM-DH uses return routability at the
   bottom and SUCV uses puzzles.

Jari

---

From: Claude Castelluccia <[email-masked]>
Date: Mon, 10 Dec 2001 13:00:21 +0100

Hello,

> can you btw send a link, I didn't seem to get it from the I-D directories.)

yes, we have missed the ID submission deadline that why the -02 version is not

on the i-D directories. The 02 version can be retrieved on my Web page at:
http://www.inrialpes.fr/planete/people/ccastel/draft-montenegro-sucv-02.txt

>    bottom and SUCV uses puzzles.

Privacy might also be a reason why you don't want to use return routability.
There
is a section in the SUCV draft v2 that tries to tackle this issue...

regards,
Claude.

--

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 10 Dec 2001 16:15:18 +0100 (CET)

> -we wanted to support homeless MN.

Just a note that as far as I know "homeless MN" isn't a requirement 
the IETF work, at
least I've never seen a discussion whether or not it should be a requirement.

  Erik

---

From: Alexandru Petrescu <[email-masked]>
Date: 10 Dec 2001 14:15:38 +0100

Erik Nordmark <[email-masked]> writes:
> So I think the conservative thing to do if there is a need to check
> with the CoA as well as the HoA during BUs is to send more packets.
> (causing a "response" to be sent to the CoA) and with HoA as the
> source (reverse-tunneled through the HA).  Then when the has the
> information from both "responses" it can do the actual BU.

Something like the two simultaneous messages below?

MN  --------> CN --------> HA
                           |
  <------------------------|

MN            CN <-------- HA
|                           
|-------------------------->

Alex

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 10 Dec 2001 18:13:41 +0100 (CET)

> MN  --------> CN --------> HA

No - the symmetry is different.

One exchange would be
	MN(CoA) ->	CN
	MN(CoA) <-	CN
and the other would be

	MN(HoA) -> HA -> CN	(reverse-tunneled through HA)
	MN(HoA) <- HA <- CN

  Erik

---

From: Alexandru Petrescu <[email-masked]>
Date: 10 Dec 2001 17:58:03 +0100

> 	MN(HoA) -> HA -> CN	(reverse-tunneled through HA)

What would stop a malicious HA to flood CN with MN(HoA)->HA->CN
messages having the HoA of an attacked HA?

I would prefer simpler schemes with a lesser number of messages, this
being presumably easier to secure.  I liked a lot HACOOKIES where the
exchange was only:

MN -> CN -> HA
      CN <- HA

Alex

---

From: Jari Arkko <[email-masked]>
Date: Mon, 10 Dec 2001 19:52:28 +0200

Claude,

We discussed earlier about why there's return routability or not
at the bottom of these public key hash techniques. Then I said

>   bottom and SUCV uses puzzles.

It seems that I missed an important point though. What CAM and
SUCV are able to do is to conclusively prove that the sending
node really came up with the particular IPv6 address in question.
However, it is still possible for attackers to pick a network X,
generate their own key and address, and claim to be mobile nodes
from X. This could potentially be used for something bad, such
as initiating a session from a CoA and then deleting the BCE and
bombing X with traffic that continues to flow from the CN to the
MN.

The prevention of this attack is another reason why CAM-DH runs BAKE/2
at the bottom: the return routability tests ensure that the attackers
can't claim to be from X if they really aren't from there (or on
the path to it).

Jari

---

From: Jari Arkko <[email-masked]>
Date: Mon, 10 Dec 2001 23:02:11 +0200

> messages having the HoA of an attacked HA?

I'm not sure I understand your attack, I think we pretty much
have to trust the HA. And of course, anyone can spoof messages
towards the CN so the CN must be prepared to deal with that
in any case. Several proposals do that, in various ways.

> being presumably easier to secure.  I liked a lot HACOOKIES where the

Simpler is better of course. However, we do need to fulfil reasonable
security requirements, and not introduce new attacks. Right now,
there's a couple of attacks where we haven't decided yet if they
are serious enough to require protection. These are:

* HOA reflection attack from draft-savola
* As a special case of the above, Erik discovered that you can
   do the reflection attack with some of the current weak authentication
   protocols. This is an example of a security scheme bringing along
   with itself new security problems.
* 3rd party bombing attack from draft-aura

For the first and third attacks we have some proposals that can
prevent them. The protection of the second attack is being discussed
in this thread.

As far as I can see, HACOOKIES could potentially be vulnerable to
the second attack. It seems to be vulnerable to the third attack
as well, but only for attackers on the HA-CN path because the
attacker would have to know the ha-mn cookie, at least if the
CN public key is attached to the BUQR.

Jari

---

From: Jari Arkko <[email-masked]>
Date: Mon, 10 Dec 2001 23:07:03 +0200

> at the attacker. Spoofing allows the attacker to hide.

Spoofing is necessary for the attacker to send the Weak Auth / Binding Update
messages. These must appear as if they came from the CoA, otherwise the CN
should immediately throw the messages away.

Jari

---

From: Michael Thomas <[email-masked]>
Date: Mon, 10 Dec 2001 13:41:13 -0800 (PST)

> in any case. Several proposals do that, in various ways.

   Ignore if this is noise. What happens if the HA and MN
   are in collusion? 

 > > being presumably easier to secure.  I liked a lot HACOOKIES where the

   Note that in COOKIES, the HA intervention was an
   optimization. Because of collusion, the security
   properties were really those of the MN and CN 
   (ie, you can't make any assumptions about the
   trustworthiness of the HA).

		      Mike

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 10 Dec 2001 22:40:46 +0100 (CET)

> messages having the HoA of an attacked HA?

Nothing, just like there isn't anything preventing the HA to
send TCP SYN packets with HA as the source. In both cases the
reply packet goes back to/through the HA.

But I seem to have failed to communicate the problem here.

A sending a packet to B which causes B to reply to A is
not different than most protocols - TCP SYN, ICMP echo, DNS lookups, etc.

A sending a packet to B which causes B to send a packet to C
is quite different. That is my concern.

  Erik

---

From: Michael Thomas <[email-masked]>
Date: Mon, 10 Dec 2001 13:55:01 -0800 (PST)

> is quite different. That is my concern.

   Indeed, however, is this possibly solvable
   by requiring CN to rate limit verifications?
   That is, when a CN sees a new HAO for which 
   it doesn't have a cache entry, the only traffic
   it will send via tha HA is something that will
   verify that the MN is, in fact, reachable that
   way, and that that traffic is rate limited?
   
   I haven't managed to grok the amplification
   attack so I have no idea whether this would be
   generally helpful.

	     Mike

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 11 Dec 2001 00:17:38 +0100 (CET)

>    way, and that that traffic is rate limited?

In theory yes, but I have no idea what is a reasonable rate to
plug into an implementation that runs on everything from my laptop
to a 64+ processor server.

Defense against TCP SYN attacks can detect when something unusual
is going on (connections in SYN-RCVD timing out) and apply limits
in that case.
But since we don't want to create state (to avoid DoS) on the first
packet I don't see how an implementation can determine when something
unusual is going on.
This leaves picking a magic "number of new BUs per second" rate out
of a hat.

>    attack so I have no idea whether this would be

It isn't an amplification - one packet results in one packet.
But the issue is that the victim sees a packet from B and has no
way (other that getting B to collect packet traces) to find out
that the packets are in fact generated because of A sending things to B.

  Erik

---

From: Michael Thomas <[email-masked]>
Date: Mon, 10 Dec 2001 17:11:15 -0800 (PST)

> This leaves picking a magic "number of new BUs per second" rate out

   Hmm. It seems to me that the only that is
   necessary is to make the input effort (BU's)
   from the attacker be greater than the output
   effort (verifies). That is, if the attacker doesn't
   get leverage through his reflectors, the attacker
   would either find some other leverage mechanism
   (oh say, IIS zombies), or just direct a spoofed
   flooding attack directly. 

   I would think that rate limiting would make that
   true. Yes, you may end up with a state DoS attack
   on the refelector, but couldn't its effects be
   mitigated by separate accounting? This is, after
   all, supposed to be a cache.

		 Mike

---

From: Erik Anderlind <[email-masked]>
Date: Mon, 10 Dec 2001 21:49:14 -0500

Hi,
It seems another way a mobile node could deal with this
reflection DoS is to change its COA through use of its
favorite IPv6 address assignment method. Unless 
the attacker is explicitly notified about the change
in mobile address, it seems it could not know what the 
new address is, and thus the duration of the attack 
is bounded. 

The proposal has the nice property 
of making it desireable to implement mechanisms 
for the mobile to generate "privacy" addresses 
(with random suffix), as 
otherwise it might be possible for attacker to 
guess the new address.
Routers will eventually return "ICMP Unreachable" to CN and 
the later will redirect the stream back via the HA to 
the attacker!!!
If the CN sees this happens many times, it could possibly 
blacklist the HA collaborating with the malicious node.

...Erik (a different Erik)

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 11 Dec 2001 04:01:46 +0100 (CET)

>    flooding attack directly. 

The way reflectors is used during DDoS attacks (Vern Paxon has paper
on this) doesn't assume any packet amplication.
The reflectors are just used to hide the IP addresses of the slaves.

>    all, supposed to be a cache.

You continue to assert that rate limiting works so I'll continue
to assert that I don't know whether 1 BU per second or 1 million BUs per
second is too high.

   Erik

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 11 Dec 2001 04:16:05 +0100 (CET)

> new address is, and thus the duration of the attack 

The reflection attack doesn't necessarily attack small mobile nodes -
it might be public web servers as in the DDoS attacks that was in
the news two years ago.

Those nodes don't want to change their IP address.

  Erik

---

From: Jari Arkko <[email-masked]>
Date: Tue, 11 Dec 2001 05:28:47 +0200

>    way, and that that traffic is rate limited?

Unfortunately, each CN could be seeing just a single
packet, while a large number of CNs could be used
by the attacker to send individual packets to a
single victim.

But even so, I'm not exactly sure how serious these
attacks are.

Jari

---

From: Michael Thomas <[email-masked]>
Date: Mon, 10 Dec 2001 20:03:24 -0800 (PST)

> by the attacker to send individual packets to a

   If a CN rate limited its BU processing (which may
   be good idea anyway just to protect against
   broken MN's), that means that an attacker
   would only get a fraction of output of each
   CN it contacts. Yes, it's still a reflector
   attack, but it wouldn't even be break even
   for the attacker's effort. This doesn't seem
   like a very fertile ground; you can do the same
   thing source spoofing SYN's probably with higher
   efficiency. It's only if the attacker gets
   amplification that we should worry. 

		Mike

---

From: Michael Thomas <[email-masked]>
Date: Mon, 10 Dec 2001 20:17:36 -0800 (PST)

> The reflectors are just used to hide the IP addresses of the slaves.

   Yes, this is a legitimate concern, but you can
   do the same thing by source spoofing SYN's. It's
   amplification that makes these attacks attractive
   though.
 
 > to assert that I don't know whether 1 BU per second or 1 million BUs per
 
   "Works" is too strong a word. "Makes less attractive"
   is more like it. At some level, that's what DoS avoidance
   is all about. 

	  Mike

---

From: Claude Castelluccia <[email-masked]>
Date: Tue, 11 Dec 2001 09:58:28 +0100

Hello Jari,

> can't claim to be from X if they really aren't from there (or on

In SUCV, the 4 SUCVp messages are exchanged between the CN and the
MN (the CoA).
So the MN has to be in the X network (or on the path to it) for the SUCV
exchange to succeed...

The only weakness (i think) is that this exchange might succeed even if
the attacker is on the path to X but
return routability does not solve this problem. In fact what prevents, in
this case, an attacker to choose
a HomeAddress that is also on the path from the CN to X???

I think that return routability might only be useful against an attacker
trying to redirect a "legitimate" HomeAddress...
but SUCV/CAM also solves this issue...

Am i missing something here?

Claude.

--

---

From: Jari Arkko <[email-masked]>
Date: Tue, 11 Dec 2001 18:34:43 +0200

> So the MN has to be in the X network (or on the path to it) for the SUCV 

Ah yes, but in my attack above X was the prefix of the home network and
it was assumed to be different from Y, the prefix of the CoA network.

> return routability does not solve this problem. In fact what prevents, 
> in this case, an attacker to choose

Here's the attack:

1. Invent a new SUCV-address (you can do it) of the form X:<HoA>

2. Go to network Y and get an address Y:<CoA>

3. Run SUCV against any CN. This will succeed, because the
    attacker generated the address by himself.
4. Start some session with the CN, using Route Optimization
5. Send a BU to the CN with lifetime 0. This will kill the BCE.
6. CN continues to send a number of packets towards X:<HoA>
    on the open session (e.g. RTP videostream).
7. The packets arrive at network X, and do not hit any
    specific node because in step 1 we obviously can't
    pick any existing address. However, the network will
    be full of packets, and X's Internet pipe may be full.

This attack has a relatively high amplification factor.

Jari

---

From: Claude Castelluccia <[email-masked]>
Date: Wed, 12 Dec 2001 11:48:49 +0100

> This attack has a relatively high amplification factor.

Ok that should work but
steps 1, 2 and 3 is SUCV...5,6,7 is IPSec....
IPSec (i.e. BU authentication part) seems to be the problem here ;-)

but anyway you can do much better than that ;-)
Most of the proposed schemes, except BU3WAY, (correct me if i am wrong)
propose a solution to establish a SA between the MN and the CN...then
BU are securized using the generated SKEY....

So what someone could do is:
1- establish a SA with a CN using SUCV/CAM, Bake....
2- Start some session with the CN using route optimization
3- register X  (the network or host target) as your CoA...
..packets will be sent to X!!

I believe that most of the schemes will fail against this attack...(note that
in SUCV you won't
be able to attack a host address but a network).

If we really want to solve these problems, the requirements are then:
1- How to avoid the initial messages to go through the HA before the MN is
authenticated
to avoid "3rd party reflection" (that was the start of this thread)?
2- How to avoid someone generating a fake Home Address and redirect msg to it
(this is the
attack you've described)?
3- How to avoid someone registering someone'else address as CoA (this is the
attack that i've
described above)....
4-+ the initial requirements (i.e. How to avoid MiTM + how to avoid HoA
redirection....)

One solution would be:
1- establish the SA between the MN and CN using something like SUCV (i.e.
without going through
the HA).
2 - secure BU using a protocol combining  BU3WAY and the previously establish
SA. For example,
we could have the following mesg exchange each time the MN moves:
  a- MN-> CN : BUR authenticated with SKEY
  b- CN-> HA: BUC authenticated with SKEY
  c- HA->MN: BUC authenticated with SKEY
  d- MN->CN:  BU authenticated  with SKEY..

Comments?
thanks.

Claude.

--

---

From: Jari Arkko <[email-masked]>
Date: Thu, 20 Dec 2001 16:42:47 +0200

> ..packets will be sent to X!!

You are right. We seem to be in a need to prevent not
just bombing attacks against the first CoA but also
all future ones. As you point out, a combination of CGA
and RR techniques could do the job, with RR being repeated
for each new CoA. (It seems unnecessary to repeat HoA and
CGA tests as you move around, though we might do that as
well in order to simplify the protocol.)

Jari