Subject: Re: [Mip6] comments on draft-vogt-mip6-early-binding-updates-00

From: Christian Vogt <[email-masked]>
Date: Tue, 2 Mar 2004 16:00:55 +0100

Hi Jari!

> I already sent some comments earlier, but I reread this draft
> prior to the meeting. Here are some additional comments. Overall
> I find your draft quite promising. There's probably a need to
> change the approach to byte counts rather than fixed time
> limits, as dicussed earlier.

You are referring to the following question: How can a correspondent
node (CN) know how much data it may sent to a "good" mobile node's
(MN's) new care-of address (CoA), while that CoA is being verified
by a concurrent CoA test, without allowing a malicious node to misuse
the concurrent CoA test for a flooding attack. And yes, the 3-seconds
time limit on the concurrent CoA test, which we proposed in version
-00 of the [2], does not solve the problem for two reasons.

The first reason is the one you mentioned in an earlier email: The
amount of data a CN may send within three seconds can be arbitrarily
high. It is only limited by the pipe between the CN and the target IP
address. A second reason is that a 3-seconds time limit alone does not
prevent a malicious node from continually refreshing a tentative
CoA registration.

It might seem to be an obvious approach to replace the 3-seconds time
limit by a constant byte (or packet) limit. A constant byte limit would
bound the data volume that a CN may send to a yet-to-be-verified
CoA. But a constant byte limit has a similar shortfall than the
constant time time limit proposed in [2], namely: Whatever limit is
chosen, it might still allow for a flooding attack against a node at a
narrow link.

This observation led us to the idea of balancing the data volume that a
CN can send to an "unconfirmed" CoA of a MN with the data volume
that the CN has earlier sent to a "confirmed" CoA of the same MN. With
"unconfirmed" CoA I mean a CoA for which a concurrent CoA test is still
ongoing. With "confirmed" CoA I mean a CoA for which the CN has
obtained assurance, through a CoA test, that the MN is indeed reachable
at that CoA. We called this approach "Credit-Based Authorization",
meaning that a MN must collect some "credit" (in terms of data volume)
before it can do a concurrent CoA test.

In an email, you suggest using the data volume originated *by the MN*,
and sent to the CN, as the counter-balance to what the CN may sent to a
yet-to-be-verified CoA of the MN. Yes, this is a good idea. As
discussed during our conversation after yesterday's MIP6 session,
one should probably use both types of traffic, which would also allow
for applications with asymmetric data flows. 

> However, if as suggested you would change the approach to
> specifically take this into account, this would no longer be a
> problem. Basically, a CN would agree to send out at most X bytes
> of traffic while in the tentative state, where X is, say, 10 % of
> the bytes sent by the MN during the last few minutes. This would
> result in the attacker (mobile node) having to send at least 100
> bytes to get just 10 bytes to the attacker, clearly less than the
> 1-1 reflection simply using TCP SYNs. Still, the 10% is more than
> enough to transfer the data needed until the care-of test answer
> arrives: if you have a constant data rate, 10% of data sent during
> three minutes gives you 18 s to complete the care-of address test.
> 
> If you exceed X, you move the stream back to the home address.

We are currently working on version -01 of [2] in which we specify
Credit-Based Authorization, but we did not finish the new version
in time for this IETF meeting. I do have a slide on Credit-Based
Authorization, which I will show during my presentation of Early
Binding Updates at the MOBOPTS session on Wednesday afternoon, 
provided there is sufficient time. (It is only a 10-minutes
presentation.)

> If this draft goes further, it might make sense to separate
> the home address and care-of address optimizations. That is,
> you could have one draft that explains how the home address
> tests can be initiated before handover takes place. Or would
> this be considered too simple for a draft?... I don't know.

One argument that might be against separating Early Binding Update I-D
is that, in Mobile IPv6, a MN may already do a home-address (HoA) test
whenever it whishes. Though the MIPv6 specification suggest to do the
HoA test after a handover, a MN may also do it before the handover
without violating the protocol specification. In fact, a HoA test can
be done at any time as long as the Home Keygen Token retrieved from it
is not expired when eventually used for Binding Update message
authentication. Nonetheless, I think that splitting the I-D is an
excellent idea, because both the early HoA test as well as the
concurrent CoA test require additional commentary. As far as the HoA
test goes, I may just cite your previous email:

> Perhaps the separate draft that I suggested makes sense, because
> you would also have to describe the exception that you talk about
> in the above [...]

...namely having the MN do a HoA test even when it is at home. As far
as the CoA test goes, there is this credit-based authorization method
which will be specified in version -01 of [2]. Certainly, splitting
the I-D into two separate I-Ds would make both of them easier to read.

> Maybe the byte count scheme could be called the "Adaptive
> Amplification Attack Prevention" (AAAP) or "Attack Cost
> War for Amplification" (ACWA).

We called it "Credit-Based Authorization" for now. It does not sound
too spectacular, I admit. "Counter-Balance-Based Egress Monitoring
could be another alternative.

> Hmm... I wonder if this has been described anywhere else.
> Seems like a rather general scheme. But maybe not, as it
> only makes sense in movements. Write a paper somewhere on this,
> interested?

Credit-Based Authorization is definitely an important topic per se
and needs dedicated consideration. And yes, we intend to elaborate
further on this topic. Writing a paper is an excellent idea!

The following comments are not related to Credit-Based Authorization.

> Maybe with some simulation data should be included, and rules
> to tell when it makes sense: delay at movement vs. potentially
> unnecessary messaging if we didn't move after all.

You are right. Simulation analyses are still on our to-do list.

> Presumably you could do an EBU as soon as you receive the Home Test
> message. I think this would simplify your state machine.

I agree. This is true. When writing this I-D, we thought from an
implementor's perspective: An Early-Binding-Update-enabled MN would
probably implement standard binding updates as well, and that code
could just be re-used here. But, you are right: The state machine gets
simpler if Early Binding Updates are used in all situations.

Jari, I appreciate your detailed comments on Early Binding Updates.

Best regards,

- Christian

[1]
http://www.arkko.com/publications/draft-aura-mipv6-bu-attacks-01.txt
[2]
http://www.ietf.org/internet-drafts/draft-vogt-mip6-early-binding-updates-00.txt

|
| Christian Vogt
| Institute of Telematics, University of Karlsruhe
| www.tm.uka.de/~chvogt/
|

Quoting Jari Arkko <[email-masked]>:

> I already sent some comments earlier, but I reread this draft
> prior to the meeting. Here are some additional comments. Overall
> I find your draft quite promising. There's probably a need to
> change the approach to byte counts rather than fixed time
> limits, as dicussed earlier.
> 
> > We propose a modified binding-update procedure that
> > evades the latency of both address tests.
> 
> If this draft goes further, it might make sense to separate
> the home address and care-of address optimizations. That is,
> you could have one draft that explains how the home address
> tests can be initiated before handover takes place. Or would
> this be considered too simple for a draft?... I don't know.
> Maybe with some simulation data should be included, and rules
> to tell when it makes sense: delay at movement vs. potentially
> unnecessary messaging if we didn't move after all. Anyway,
> this part of the optimization would work well with any other
> optimization scheme as well, not just the care-of-test-less
> early binding updates. Or without any other optimization.
> 
> > before changing its point of network attachment. At home, the
> > mobile node does not use Mobile IPv6. It hence does not run a
> > home-address test, and it does not acquire a Home Keygen 
> > Token, before it moves to a foreign link. Also, when the 
> > mobile node powers on at a foreign
> 
> I don't see a reason why the predictive home test strategy
> wouldn't work even in this case. In either case, you have to have
> some ability to "guess" that you will be moving soon, or otherwise
> you'll just be doing some extra signaling.
> 
> > One may consider letting the mobile node perform a home-address
> > test even while being at home. This could accelerate handovers
> > from the home link to a foreign link. The Home Test Init and 
> > Home Test messages would continue to obey to the rules defined
> > in sections 9.4 and 11.6 of [1], except that they would not have
> > to be tunneled between the mobile node and its home agent.
> 
> This is true. But if you are going to adopt predictive home tests,
> I would apply them even to the home case.
> 
> Perhaps the separate draft that I suggested makes sense, because
> you would also have to describe the exception that you talk about
> in the above.
> 
> > These observations lead to the following exception: When a mobile
> > node wants to register a new care-of address with a correspondent
> > node, and the mobile node does not yet know a valid Home Keygen
> > Token, the mobile node runs a standard binding update instead of
> > an Early Binding Update. When the standard binding update is
> > complete, the mobile node can communicate through its new care-of
> > address. The
> 
> Presumably you could do an EBU as soon as you receive the Home
> Test message. I think this would simplify your state machine.
> 
> > test. We claim that testing the mobile node's reachability at
> > its new care-of address may also be done at (3). Data trans-
> > mission to and from the new care-of address may wait or, as
> > with Early Binding Updates, start with appropriate restrictions
> > until the mobile node has provided proof to the correspondent
> > node that it is reachable at its new care-of address.
> 
> This is the issue we discussed earlier. As has been stated by
> Francis and others, in the Internet we already (unfortunately,
> since ingress filtering is not ubiquitous) have the possibility
> to spoof source addresses, leading to 1-1 reflection attacks on
> e.g. TCP SYN packets. So 1-1 reflection is not necessarily
> something we need to prevent in Mobile IPv6. Base RR attempts,
> however, to prevent 1-N reflection attacks where you send one
> (or some) packets and get many more packets to the victim's
> network. The basic scenario is tricking someone into opening a
> stream, and moving the stream towards the victim and letting
> the "someone" pump data towards the victim for a while.
> 
> Your -00 draft with the 3 second time limit still has this issue,
> as a CN which supports EBUs could pump 3 seconds of data stream
> to the victim. How serious is this? It depends on the interface
> speed and effort needed to open the particular stream. Lets say
> 10 packets to open the stream and get over the slow start (maybe
> someone can help me with the actual numbers...). If the CN is a
> mobile on a congested GPRS link, there may not be many packets
> sent during the 3 seconds. But if the CN is an idle web server on
> an OC-3 link there could be a lot of packets, particularly since
> the attacker can send some spoofed TCP ACKs, having learned the
> sequence numbers while opening the stream.
> 
> However, if as suggested you would change the approach to
> specifically take this into account, this would no longer be a
> problem. Basically, a CN would agree to send out at most X bytes
> of traffic while in the tentative state, where X is, say, 10 % of
> the bytes sent by the MN during the last few minutes. This would
> result in the attacker (mobile node) having to send at least 100
> bytes to get just 10 bytes to the attacker, clearly less than the
> 1-1 reflection simply using TCP SYNs. Still, the 10% is more than
> enough to transfer the data needed until the care-of test answer
> arrives: if you have a constant data rate, 10% of data sent during
> three minutes gives you 18 s to complete the care-of address test.
> 
> If you exceed X, you move the stream back to the home address.
> 
> The drawback of this scheme is that on the first binding you may
> be unable to do this, even if you had ongoing data transfer with
> the mobile while it was at home. This is because the IP stack would
> not be counting the received bytes.
> The Home Keygen Token and
> 
> > the Care-of Keygen Token are likely to arrive at the mobile node
> > via disjoint paths: The former passes through the mobile node's
> > home agent, the latter does not. An attacker will thus have a
> > hard time to capture both tokens.
> 
> Strictly speaking, this is not the main worry. As documented in [1],
> the attacker is free to choose the care-of path. So I would worry
> more about attackers posing as mobile nodes and doing the RR test
> than attackers being able to eavesdrop on an RR test performed
> by a legitimate node. In order to pose as a mobile node, you need
> to be on the path to the home agent, and your draft does not change
> that so I think you are ok. (Also, if you are on the path to the
> home agent you can do all sorts of other nasty stuff.)
> 
> (You say all this later in the text, but I just wanted to say
> that two paths are not a protection in RR, your method, or other
> methods.)
> 
> > Another way to mitigate the threat of flooding attacks is to
> > grant Early Binding Updates to trusted nodes only. Recall that
> > the
> 
> I wouldn't put too much emphasis on this. However, if we had some
> stronger home test mechanisms (e.g. CGA), you could combine EBUs
> with them, getting more security.
> 
> --Jari

-------------------------------------------------------------
This message was sent through ATIS: http://atiswww.ira.uka.de 

_______________________________________________
Mip6 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mip6

---

From: Jari Arkko <[email-masked]>
Date: Tue, 02 Mar 2004 17:50:05 +0200

What you say looks reasonable. I'm just responding to one
issue that probably needs more care than we originally thought

> for applications with asymmetric data flows. 

This would indeed be desireable. However, you can't really count on
the packets that the CN sends actually being delivered to the MN.
For instance, the MN might be on a slow link, sending fake TCP ACKs
towards the the CN. The CN would be sending data at a high rate, but
most of the packets would be dropped by a router on the path. (This
observation was made by Erik Nordmark.)

But this isn't necessarily a serious limitation, as the long
credit collecting period vs. short care-of test RTT gives you
some maneuvering room. And if you happen to run out of "credit",
the world will not end, it will just work a bit slower...

--Jari

---

From: Francis Dupont <[email-masked]>
Date: Wed, 03 Mar 2004 06:15:06 +0100

In your previous mail you wrote:

   A second reason is that a 3-seconds time limit alone does not
   prevent a malicious node from continually refreshing a tentative
   CoA registration.
   
=> this can be easily solve by some kind of hold-down mechanism...
In this case IMHO the best is just not to reset the timer on "refresh".

=> I agree: as the line speed can be between some kbits/s to a hundred
Mbits/s (wireless) or some Gbits/s (wired) you either kill performance
or victims behind a narrow link.

=> this is very complex and does nothing for a victim behind a narrow
link and an attacker behind a fast link.
   
Regards

[email-masked]

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 3 Mar 2004 00:06:45 -0800 (PST)

> Btw, there is some discussion about this in the mobopts list too.

Sorry for starting things on that list; I hadn't seen the discussion on
this list yet.

> Re: victim behind a narrow link and attacker behind a
> fast link. You are right that this doesn't do anything
> for this case. But isn't this already the case today?
> I mean an attacker behind a fast link can send a zillion
> spoofed TCP SYNs to www.cnn.com and have the responses
> go my GPRS link, which would be hosed. The effort required
> for this would be a sending a zillion packets. To do this
> via early binding updates, you'd need more than a zillion
> packets.

Or alternatively directly flood the victim.
In the case of the BU with a victim as the CoA the victim can
actually tell the attacker's IP address - it is contained in the
Home Address option. 
Thus the direct flood and the BU using the victim as the CoA 
have similar properties:
 - victim can tell the address of the attacker
 - ingress filtering can't prevent the attack since the source address is not
   spoofed

The difference is the limit on bandwidth.

  Erik

---

From: Francis Dupont <[email-masked]>
Date: Wed, 03 Mar 2004 11:42:30 +0100

In your previous mail you wrote:

   >    ... We called this approach "Credit-Based Authorization",
   
   Lets explore this a little bit.
   
=> just ask implementors... IMHO they don't be happy with this:
a defense against a not-existant attack when ingress filtering is used
(when ingress filtering is not used/effective attackers have simpler and
more efficient ways to bomb you).

   Francis, I presume the credit based scheme must also ensure
   that Alt-CoA is not used, right?

=> any mechanism which does not perform or does delay a care-of address
check has to refuse fake alternate care-of addresses. I argue this is
the only needed care.

   Because if we don't ensure
   that, an attacker that is under ingress filtering could do
   attacks that he previously couldn't. This is because the
   care-of test would have to be done for the claimed address,
   but the care-of test is not needed in the tentative stage.
   
=> we already know that.

=> so the credit stuff is not useful?

   I mean an attacker behind a fast link can send a zillion
   spoofed TCP SYNs to www.cnn.com and have the responses
   go my GPRS link, which would be hosed.

=> a zillion to www.cnn.com won't work. A zillion to a different
www.<something>.com will work pretty well.

   The effort required
   for this would be a sending a zillion packets.

=> the attacker only needs enough zombies to make the load per zombie
acceptable for zombie connections.

   To do this
   
=> this is not a problem at all today and the reason attackers won't
misuse Mobile IPv6 is they can use plain IPv6 with less effort.

Regards

---

From: Francis Dupont <[email-masked]>
Date: Wed, 03 Mar 2004 12:05:45 +0100

- ingress filtering can't prevent the attack since the source
      address is not spoofed
   
=> I disagree for the second: this is a property of the direct flood,
not of the reflection flood using or not Mobile IPv6.
BTW the standard reflection flood has not the first property
(i.e., victim cannot tell the address of the attacker).

=> which is not effective as the limit is per correspondent and
is relative to the bandwidth of attacker(s).

Regards

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 3 Mar 2004 03:37:50 -0800 (PST)

> (i.e., victim cannot tell the address of the attacker).

I agree it isn't the property of the reflection flood (but I didn't talk
about that case.)

With mobile IPv6 with a relaxed/delayed test of the Care-of address
you do have the property that the attackers address is disclosed
to the victim.

With X as attacker, A the victim, B the "server":

X starts a session with B to get B to send a high-bandwith stream
of packets to X.

X then sends a HoTI/HoT to B (no need for CoTI/CoT since the
CoA test is delayed in this case).

X sends a BU to B specifying that the CoA is A.
B starts the CoA test with A, and starts sending the high-bandwidth
stream to A.
	These packets are CN->MN packets thus per the mobile IPv6 specification
	they contain the Home Address option with the value X.

(And X continues to send predicted "acks" to B to ensure that the
high-bandwidth stream continues to flow to A.)

   Erik

---

From: Francis Dupont <[email-masked]>
Date: Wed, 03 Mar 2004 13:47:34 +0100

=> perhaps I have abusively translate "the BU using the victim as
the CoA" as the reflection flood using Mobile IPv6.

=> this is the first property, the second is to be immune to
the ingress filtering (the CoA is the source address and is the
address of the victim so the ingress filtering is the proper defense).

=> this is blocked by the ingress filtering (*).

=> a full sending window.

=> I agree and this is not a nice property for the attacker.

=> A sends "resets" to B too...

(*) the important thing is the reflection flood using IPv6 or
Mobile IPv6 with relaxed/delayed CoA test, and the direct flood
using fake source address are *blocked* by the ingress filtering.
So we are loosing our time to discuss about mitigating against
a second order attack when a first order one is available and
shared the same defense. This is RIDICULOUS!

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 3 Mar 2004 20:39:36 -0800 (PST)

> address of the victim so the ingress filtering is the proper defense).

Are you saying that the source address of the BU must be the (new) CoA?

Hmm - maybe that is sufficient in the MIPv6 case (I have multi6 in the back
of my head as well, which has a variant of the same issues.)

Perhaps the draft discusses this, but when you handle an early binding update,
when is "HoA check" in the binding cache updated?
In basic MIPv6 this happens when the BU is processed i.e. after that
the MN can no longer send packets with the old CoA as the source since
the Home Address option check will drop such packets.
If the same thing applies in the early binding update case it means
that the attacker can not send any "ack" packets to the CN since they
would contain the "old" CoA - oops - they would not carry a home address
option thus they would not be subject to "the HOA and IP src must match
the binding cache" check.
Hmm...

  Erik

---

From: Francis Dupont <[email-masked]>
Date: Thu, 04 Mar 2004 07:55:01 +0100

=> yes!

=> I don't know a case where a real alternate CoA is needed or even
useful with a common correspondent in Mobile IPv6. If such a case
exists for multi-homing, it should be written down to:
 - analyze possible security issues
 - avoid that someone proposes to zap this feature to make
   correspondent code simpler!

   Perhaps the draft discusses this...

=> this is for Christian.

Regards

---

From: Jari Arkko <[email-masked]>
Date: Thu, 04 Mar 2004 09:23:54 +0200

> of my head as well, which has a variant of the same issues.)

Its a necessary but imho insufficient condition that the new care-of
address is the source of EBUs. The HAO and the home tests ensure that
the victim will always know where the stuff is coming from. Its the same
also if I send to him the packets directly. But what we in my opinion
should prevent is the amplification, not pure reflection.

> the Home Address option check will drop such packets.

That's right.

> If the same thing applies in the early binding update case it means

I think it should.

> the binding cache" check.

Well, isn't the sending of the acks already prevented by ingress
filtering? I mean if you have ingress filtering, you might not even
be able to send the EBU to begin with, let alone spoofed ACKs.

However, we are in part trying to build these things so that the
lack of ingress filtering doesn't open up the situation for many
new attacks. Remember that the victim can have ingress filtering
but the attacker not.

--Jari

---

From: Jari Arkko <[email-masked]>
Date: Thu, 04 Mar 2004 10:16:21 +0200

Francis Dupont wrote:
>    But what we in my opinion
> => this is the detail we disagree: if we prevent pure reflection,
> we prevent this attack and all others using the same hole but
> which are *reality*, not speculations.

I can understand that. But isn't there still a difference? I mean you
and I have no power whatsoever to get the service providers to
use ingress filtering. But we do have a choice of protocol designs,
and there we can have an effect. I agree that if we could make the
world ingress filtered, we wouldn't need any of this. But while this
is not yet the case, I wouldn't like to let the 5% of the Internet
that is not ingress filtered cause even more serious attacks to the
rest than they already can do.

> => it doesn't matter to get new attacks, it does matter to get no new
> attacks which have a definitive advantage over current attacks, e.g.
> which defeat ingress filtering by hiding the source address...

Agreed.

--Jari

---

From: Francis Dupont <[email-masked]>
Date: Thu, 04 Mar 2004 11:53:22 +0100

use ingress filtering.

=> IMHO you should talk with some ISP people.. The reason ingress
filtering is not universlly deployed is not the one you seems to
believe...

   But we do have a choice of protocol designs,
   and there we can have an effect. I agree that if we could make the
   world ingress filtered, we wouldn't need any of this.

=> we have to make the world ingress filtered because the current
attacks are already enough deadly.

   But while this
   
=> they already can do more than enough. As I said, we should mainly
care to avoid new attacks which cannot be handled by ingress filtering
<period>

Regards

PS: If I apply your proposed criterion we should kill Mobile IPv6 ASAP:
imagine that a bad guy gets control over a home agent, just because it
runs our favorite junk OS, and to seem more secure whole HA-MN tunnels
are protected by ESP. With a very small number of BUs and IKE DPD the
attacker can remotely divert all the traffic destinated to MNs to where
he'd like and as this traffic is ESP victim knows only the HA address
and can't send TCP RST for instance.
PPS: here "control" is control over the AAA system of the HA: it is
enough and should be easier and more discrete than full control.

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Thu, 4 Mar 2004 18:13:59 -0800

Francis,

I am trying to understand your argument better..

>    I mean if you have ingress filtering,
> 
> => this is the only case which makes sense.
> 
>    you might not even
>    new attacks.
I can see your point. Your point is about why would anyone use MIPv6 when
one can use plain IPv6 to launch the reflection attack. Using MIPv6 also has
a dis-advantage that it exposes the home address of the attacker. But 
does it mean that we can design protocols with this vulnerability expecting
that ingress filtering will get deployed in the future which will automatically
solve this problem ? Then why do we have to CoTI/CoT messages at all in
the base protocol ? Assume we ban the alternate care-of-address option,
and also that ingress filtering will get deployed in the future, does that
mean CoT/CoTI is not needed at all ? I don't think that the reason that
EBU just limits the attack to a very small amount of time is good
enough as the attacker just have to send a lot more EBUs for it to
increase the magnitude.

-mohan

---

From: "Christian Vogt" <[email-masked]>
Date: Sun, 7 Mar 2004 18:43:52 +0100

PiBJIGRvbid0IHRoaW5rIHRoYXQgdGhlIHJlYXNvbiB0aGF0IEVCVSBqdXN0IGxpbWl0cyANCj4gdGhlIGF0dGFjayB0byBhIHZlcnkgc21hbGwgYW1vdW50IG9mIHRpbWUgaXMgZ29vZA0KPiBlbm91Z2ggYXMgdGhlIGF0dGFja2VyIGp1c3QgaGF2ZSB0byBzZW5kIGEgbG90IG1vcmUgDQo+IEVCVXMgZm9yIGl0IHRvIGluY3JlYXNlIHRoZSBtYWduaXR1ZGUuDQoNCg0KSGkgTW9oYW4sDQoNCkkgYWdyZWUgdGhhdCBzb2xlbHkgbGltaXRpbmcgdGhlIHRpbWUgZHVyaW5nIHdoaWNoIGRhdGEgcGFja2V0cyBjYW4gYmUgc2VudCB0byBhbiB1bnZlcmlmaWVkIGNhcmUtb2YgYWRkcmVzcyAtIGkuZS4sIGEgY2FyZS1vZiBhZGRyZXNzIGZvciB3aGljaCBhIGNhcmUtb2YtYWRkcmVzcyB0ZXN0IGhhcyBub3QgeWV0IGJlZW4gYWNjb21wbGlzaGVkIC0gaXMgaW5zdWZmaWNpZW50IHRvIHByZXZlbnQgZmxvb2RpbmcgYXR0YWNrcy4gRm9yIHRoaXMgcmVhc29uLCBFYXJseSBCaW5kaW5nIFVwZGF0ZXMgYXBwbHkgYSBtZWNoYW5pc20sIENyZWRpdC1CYXNlZCBBdXRob3JpemF0aW9uLCB0byBlbnN1cmUgdGhhdCB0aGUgZGF0YSB2b2x1bWUgc2VudCB0byBhIG1vYmlsZSBub2RlIGF0IGFuIHVudmVyaWZpZWQgY2FyZS1vZiBhZGRyZXNzIGlzIGxpbWl0ZWQgYnkgdGhlIGVmZm9ydCB3aGljaCB0aGUgbW9iaWxlIG5vZGUgaGFzIHJlY2VudGx5IHNwZW50IHdoaWxlIGl0cyBjYXJlLW9mIGFkZHJlc3Mgd2FzIHZlcmlmaWVkLg0KDQpJIGdhdmUgYSBwcmVzZW50YXRpb24gb2YgQ3JlZGl0LUJhc2VkIEF1dGhvcml6YXRpb24gZHVyaW5nIHRoZSBNT0JPUFRTLVNlc3Npb24gb2YgdGhlIDU5dGggSUVURiBtZWV0aW5nLiBUaGUgbWVjaGFuaXNtIHdpbGwgYmUgZGV0YWlsZWQgaW4gdGhlIG5leHQgdmVyc2lvbiBvZiB0aGUgSW50ZXJuZXQtRHJhZnQgb24gRWFybHkgQmluZGluZyBVcGRhdGVzLg0KDQpLaW5kIHJlZ2FyZHMsDQoNCg0KLSBDaHJpc3RpYW4NCg0KDQp8DQp8IENocmlzdGlhbiBWb2d0DQp8IEluc3RpdHV0ZSBvZiBUZWxlbWF0aWNzLCBVbml2ZXJzaXR5IG9mIEthcmxzcnVoZSAoVEgpDQp8IHd3dy50bS51a2EuZGUvfmNodm9ndC8NCnwNCg0KDQpNb2hhbiBQYXJ0aGFzYXJhdGh5IHdyb3RlOg0KPiBGcmFuY2lzLA0KPiANCj4gSSBhbSB0cnlpbmcgdG8gdW5kZXJzdGFuZCB5b3VyIGFyZ3VtZW50IGJldHRlci4uDQo+IA0KPj4gSW4geW91ciBwcmV2aW91cyBtYWlsIHlvdSB3cm90ZToNCj4+IA0KPj4gICAgQnV0IHdoYXQgd2UgaW4gbXkgb3Bpbmlvbg0KPj4gICAgc2hvdWxkIHByZXZlbnQgaXMgdGhlIGFtcGxpZmljYXRpb24sIG5vdCBwdXJlIHJlZmxlY3Rpb24uDQo+PiANCj4+ID0+IHRoaXMgaXMgdGhlIGRldGFpbCB3ZSBkaXNhZ3JlZTogaWYgd2UgcHJldmVudCBwdXJlIHJlZmxlY3Rpb24sDQo+PiB3ZSBwcmV2ZW50IHRoaXMgYXR0YWNrIGFuZCBhbGwgb3RoZXJzIHVzaW5nIHRoZSBzYW1lIGhvbGUgYnV0DQo+PiB3aGljaCBhcmUgKnJlYWxpdHkqLCBub3Qgc3BlY3VsYXRpb25zLg0KPj4gDQo+PiAgICBJIG1lYW4gaWYgeW91IGhhdmUgaW5ncmVzcyBmaWx0ZXJpbmcsDQo+PiANCj4+ID0+IHRoaXMgaXMgdGhlIG9ubHkgY2FzZSB3aGljaCBtYWtlcyBzZW5zZS4NCj4+IA0KPj4gICAgeW91IG1pZ2h0IG5vdCBldmVuDQo+PiAgICBiZSBhYmxlIHRvIHNlbmQgdGhlIEVCVSB0byBiZWdpbiB3aXRoLCBsZXQgYWxvbmUgc3Bvb2ZlZCBBQ0tzLg0KPj4gDQo+PiAgICBIb3dldmVyLCB3ZSBhcmUgaW4gcGFydCB0cnlpbmcgdG8gYnVpbGQgdGhlc2UgdGhpbmdzIHNvIHRoYXQgdGhlDQo+PiAgICBsYWNrIG9mIGluZ3Jlc3MgZmlsdGVyaW5nIGRvZXNuJ3Qgb3BlbiB1cCB0aGUgc2l0dWF0aW9uIGZvciBtYW55DQo+PiAgICBuZXcgYXR0YWNrcy4NCj4+IA0KPj4gPT4gaXQgZG9lc24ndCBtYXR0ZXIgdG8gZ2V0IG5ldyBhdHRhY2tzLCBpdCBkb2VzIG1hdHRlciB0byBnZXQgbm8gbmV3DQo+PiBhdHRhY2tzIHdoaWNoIGhhdmUgYSBkZWZpbml0aXZlIGFkdmFudGFnZSBvdmVyIGN1cnJlbnQgYXR0YWNrcywgZS5nLg0KPj4gd2hpY2ggZGVmZWF0IGluZ3Jlc3MgZmlsdGVyaW5nIGJ5IGhpZGluZyB0aGUgc291cmNlIGFkZHJlc3MuLi4NCj4+IA0KPiBJIGNhbiBzZWUgeW91ciBwb2ludC4gWW91ciBwb2ludCBpcyBhYm91dCB3aHkgd291bGQgYW55b25lIHVzZSBNSVB2Ng0KPiB3aGVuIA0KPiBvbmUgY2FuIHVzZSBwbGFpbiBJUHY2IHRvIGxhdW5jaCB0aGUgcmVmbGVjdGlvbiBhdHRhY2suIFVzaW5nIE1JUHY2DQo+IGFsc28gaGFzIA0KPiBhIGRpcy1hZHZhbnRhZ2UgdGhhdCBpdCBleHBvc2VzIHRoZSBob21lIGFkZHJlc3Mgb2YgdGhlIGF0dGFja2VyLiBCdXQNCj4gZG9lcyBpdCBtZWFuIHRoYXQgd2UgY2FuIGRlc2lnbiBwcm90b2NvbHMgd2l0aCB0aGlzIHZ1bG5lcmFiaWxpdHkNCj4gZXhwZWN0aW5nIHRoYXQgaW5ncmVzcyBmaWx0ZXJpbmcgd2lsbCBnZXQgZGVwbG95ZWQgaW4gdGhlIGZ1dHVyZQ0KPiB3aGljaCB3aWxsIGF1dG9tYXRpY2FsbHkgc29sdmUgdGhpcyBwcm9ibGVtID8gVGhlbiB3aHkgZG8gd2UgaGF2ZSB0bw0KPiBDb1RJL0NvVCBtZXNzYWdlcyBhdCBhbGwgaW4gDQo+IHRoZSBiYXNlIHByb3RvY29sID8gQXNzdW1lIHdlIGJhbiB0aGUgYWx0ZXJuYXRlIGNhcmUtb2YtYWRkcmVzcw0KPiBvcHRpb24sIA0KPiBhbmQgYWxzbyB0aGF0IGluZ3Jlc3MgZmlsdGVyaW5nIHdpbGwgZ2V0IGRlcGxveWVkIGluIHRoZSBmdXR1cmUsIGRvZXMNCj4gdGhhdCBtZWFuIENvVC9Db1RJIGlzIG5vdCBuZWVkZWQgYXQgYWxsID8gSSBkb24ndCB0aGluayB0aGF0IHRoZQ0KPiByZWFzb24gdGhhdCANCj4gRUJVIGp1c3QgbGltaXRzIHRoZSBhdHRhY2sgdG8gYSB2ZXJ5IHNtYWxsIGFtb3VudCBvZiB0aW1lIGlzIGdvb2QNCj4gZW5vdWdoIGFzIHRoZSBhdHRhY2tlciBqdXN0IGhhdmUgdG8gc2VuZCBhIGxvdCBtb3JlIEVCVXMgZm9yIGl0IHRvDQo+IGluY3JlYXNlIHRoZSBtYWduaXR1ZGUuDQo+IA0KPiAtbW9oYW4NCg0K_______________________________________________Mip6 mailing [email-masked]://www.ietf.org/mailman/listinfo/mip6

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Mon, 8 Mar 2004 09:59:59 -0800

> > I don't think that the reason that EBU just limits
> > the attack to a very small amount of time is good
> > enough as the attacker just have to send a lot more
> > EBUs for it to increase the magnitude.
>
>
> Hi Mohan,
>
> I agree that solely limiting the time during which data packets can be sent to an unverified care-of address - i.e., a care-of
address for which a care-of-address test has not yet been accomplished - is insufficient to prevent flooding attacks. For this
reason, Early Binding Updates apply a mechanism, Credit-Based Authorization, to ensure that the data volume sent to a mobile node at
an unverified care-of address is limited by the effort which the mobile node has recently spent while its care-of address was
verified.
>
> I gave a presentation of Credit-Based Authorization during the MOBOPTS-Session of the 59th IETF meeting. The mechanism will be
detailed in the next version of the Internet-Draft on Early Binding Updates.
Ok. By limiting the amount of data sent during the "unverified care-of-address" window, you
still want it to be useful for applications that wanted to use EBU. Not knowing the details, i will
wait for your next version of the draft.

-mohan

> Kind regards,
>
>
> - Christian
>
>
> |
> | Christian Vogt
> | Institute of Telematics, University of Karlsruhe (TH)
> | www.tm.uka.de/~chvogt/
> |
>
>
> Mohan Parthasarathy wrote:
> > Francis,
> >
> > does it mean that we can design protocols with this vulnerability
> > expecting that ingress filtering will get deployed in the future
> > which will automatically solve this problem ? Then why do we have to
> > CoTI/CoT messages at all in
> > and also that ingress filtering will get deployed in the future, does
> > that mean CoT/CoTI is not needed at all ? I don't think that the
> > reason that
> 2*zT¨¥Sx%SËLSz¢z×è®m¶>?ÿ 0?ë_¢¸?T¨¥T©ÿ-+-Swèþh©

---

From: Christian Vogt <[email-masked]>
Date: Thu, 4 Mar 2004 09:23:52 +0100

> Perhaps the draft discusses this, but when you handle an
> early binding update, when is "HoA check" in the binding
> cache updated?

Hi Erik,

you are right: An Early Binding Update message is authenticated by a key
which was produced with a Home Keygen Token. The correspondent node
must verify this authentication. (I think this is what you refer to as
a "HoA check [update]".) So here again, if ingress filtering was
employed at the mobile node's (i.e., the attacker's) access network,
the mobile node (attacker) would not be able to fake the IP source
address of the Early Binding Update message as well as of any data
packet.

As an aside: An Early Binding Update message is authenticated in the
same way as a standard Mobile IPv6 Binding Update message when used by
a mobile node which returns to its home network and wishes to delete an
existing binding.

When the correspondent node receives an Early Binding Update message, it
updates the associated binding-cache entry, which then becomes
tentative. The updated, tentative binding-cache entry is equivalent to
a standard Mobile IPv6 binding-cache entry, except that its lifetime is
shorter.

Best regards

- Christian

|
| Christian Vogt

Quoting Erik Nordmark <[email-masked]>:

> > => this is the first property, the second is to be
> > immune to the ingress filtering (the CoA is the source 
> > address and is the address of the victim so the 
> > ingress filtering is the proper defense).
> 
> Hmm - maybe that is sufficient in the MIPv6 case (I have 
> multi6 in the back of my head as well, which has a 
> variant of the same issues.)
> 
> Perhaps the draft discusses this, but when you handle an
> early binding update, when is "HoA check" in the binding
> cache updated?
>
> In basic MIPv6 this happens when the BU is processed 
> i.e. after that the MN can no longer send packets with 
> the old CoA as the source since the Home Address option
> check will drop such packets. If the same thing applies
> in the early binding update case it means that the
> attacker can not send any "ack" packets to the CN since
> they would contain the "old" CoA - oops - they would not
> carry a home address option thus they would not be
> subject to "the HOA and IP src must match the binding 
> cache" check. Hmm...
> 
>   Erik

---

From: Jari Arkko <[email-masked]>
Date: Thu, 04 Mar 2004 10:01:39 +0200

Francis Dupont wrote:

> useful with a common correspondent in Mobile IPv6.

I also don't know of a practical case where this would
be needed.

(I may still disagree on whether skipping alt-coa
is a defense.)

--Jari

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 4 Mar 2004 00:30:15 -0800 (PST)

> be able to send the EBU to begin with, let alone spoofed ACKs.

You can't send the EBU, but you can send the ACKs if you don't
need the HAO to send them i.e. if the attacker is "at home".

This seems a bit assymetric; when the MN is sending while away from home 
the CoA/HoA need to match the binding cache entry at the CN. But when sending
while at home there is no check that there isn't a binding cache entry at the
CN.

Agreed.

   Erik

---

From: Francis Dupont <[email-masked]>
Date: Thu, 04 Mar 2004 09:04:54 +0100

you might not even

Regards

---

From: Jari Arkko <[email-masked]>
Date: Wed, 03 Mar 2004 09:30:05 +0200

> or victims behind a narrow link.

Right.

As Christian's draft contains the fixed 3 sec limit, presumably his
implementation does as well, so we don't have practical experience about
the complexity. But what would we have to do? I think the algorithm
is here:

  - Upon creating a BCE, set a counter to zero.

  - Upon receiving a packet from the MN with a HAO, check if the
    BCE is in final (non-tentative) state. If yes, increment
    a counter in the BCE with the size of the packet.

  - In order to avoid collecting a lot of credit for a long time,
    the credit must be aged somehow. There's fancy ways of doing
    this, but a simple scheme might be to divide the current credit
    by two every 30 seconds.

  - When sending a packet to the mobile node when the BCE is
    in the tentative stage, decrement the counter with the
    size of the packet. If you reach zero, delete the BCE or
    move it back to its previous location.

Is this all, or is something else also needed?

that Alt-CoA is not used, right? Because if we don't ensure

--Jari