Subject: [Mip6] Re: Comments on Early Binding Updates

From: Christian Vogt <[email-masked]>
Date: Wed, 3 Mar 2004 20:04:09 +0100

Hi Francis, Jari, Erik, and James!

Below are a few comments on your emails which you have sent to the MIP6
and MOBOPTS mailing lists following (or immediately preceding) my
presentation on Early Binding Updates
(http://www.ietf.org/internet-drafts/draft-vogt-mip6-early-binding-updates-00.txt)
at the MOBOPTS session.

Best regards

- Christian

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

Francis Dupont wrote on misuse of Early Binding Updates
for flooding attacks:

> > 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".

Francis, you propose that a mobile node be required to do a standard
binding update within each two successive Early Binding Updates. This
would be a simple and easy-to-implement mechanism. Unfortunately
however, an attacker could easily trick this mechanism: It would direct
a large data stream towards the attacked victim node for a time
slightly shorter than an unconfirmed care-of address's (CoA's)
lifetime. When the unconfirmed CoA is about to expire, the attacker
would direct the data stream to itself by means of a standard Binding
Update message, and it would immediately re-direct the data stream, by
means of an Early Binding Update message, to the attacked victim node.
The attacker could repeat this procedure indefinitely. 

There is another disadvantage of the hold-down mechanism: Suppose a
mobile node sends to the correspondent node an Early Binding Update
message. Then, all of a sudden, the handover fails, and the mobile node
falls back to the original sub-network. In this situation, the mobile
node would want to send to the correspondent node another Early Binding
Update message, re-updating the correspondent node to the old CoA. With
the hold-down mechanism, however, this second Early Binding Update
message would be rejected, because there has been no standard binding
update between this and the first Early Binding Update message.

Jari Arkko commented on Credit-Based Authorization:

> 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.)

This is very true. If this threat is considered serious, one should
refrain from using downlink packets as a criteria for credit
collection. (A solution to use downlink packets nonetheless might be to
have the correspondent node send to the mobile node, at random times,
Challenge messages to which the mobile node must respond. Such
Challenge messages would be dropped at the router with the same
probability as any other data packet. The correspondent node would
record for how many Challenge messages it receives a response. The
mobile node's CREDIT counter would increase more or less fast depending
on the percentage of responded-to Challenge messages. This "solution",
however, is probably too complex and therefore unapplicable.)

Francis Dupont commented on Credit-Based Authorization:

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

James Kempf wrote on the same issue:

> Jari's point - that the rate be constructed based on the 
> previous rate - might be more doable, but there might be
> an issue with an MN that was on a broadband link, since
> it could concievably bomb a node on a lower bandwidth
> link (a point which has already been mentioned).

IMO, there are two reason why an attacker may want to use reflection for
a flooding attack. First, the attacker may want to reveal its identity.
Second, the attacker may want to make use of an amplification which
comes along with the reflection.

Revealing one's identity is not possible with Mobile IPv6, because the
correspondent node tags all outgoing data packets with the intended
recipient's (i.e., the attacker's) home address. The home address, in
turn, cannot be spoofed, because Early Binding Updates require the
mobile node (or attacker) to do a home-address test before an Early
Binding Update message can be sent.

Amplification is also not possible with Early Binding Updates if
Credit-Based Authorization is applied. This is because the data volume
sent to an attacked victim node is limited by the data volume that the
attacker must send itself. Francis and James, you argue that the
attacker might be willing to spend this effort if it sits on a fast
link. But if this is the case, there are other, more efficient attacks,
which are already possible without Mobile IPv6. Jari Arkko elaborates
on this:

> 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. 

Erik Nordmark wrote:

> It might be worth-while to think about bandwidth and rate 
> limiting as an alternative to byte/packet counting. While 
> it is hard to determine the actual rate at which the MN can 
> send, I think it would be interesting to understand this
> part. For instance, if the MN can only send at 64 kbps 
> could one restrict the CN to send at 64 kbps until the CoA 
> has been confirmed?

Using the uplink (mobile-node-to-correspondent-node) data rate as a
limit on how much data the correspondent node can send to an
unconfirmed CoA makes sense, because the uplink data rate is what
determines the data rate with which an attacker can wage a flooding
attack *without* Mobile IPv6. Thus, if a mobile node's (or attacker's)
credit was based on the uplink data rate, misusing Early Binding
Updates for flooding attacks would probably become inattractive.

The disadvantage of using the uplink data rate as a limit on how much
data the correspondent node can send to an unconfirmed CoA gets obvious
if the former is much less than the latter. This is, e.g., the case
with asymmetric applications like video streaming. If the correspondent
node reduced the downlink data rate to the recently observed uplink
data rate, it would not be able to send all packets that it receives
from the application. The correspondent node would thus have to either
buffer or drop those packets that do not fit within the limited
downlink data rate. 

Buffering data packets is probably infeasible, as it significantly
increases the required resources at the correspondent node. Moreover, a
buffer may eventually overflow anyway. Throwing away packets is not a
solution either, since it may seriously impact ongoing connections
which are sensitive to data loss. TCP connections are one example. One
might therefore restrict Early Binding Updates to loss-*in*sensitive
applications only (which would include most delay-sensitive
applications). Yet, making Early Binding Updates (an L3 protocol)
applicable to only a certain set of applications is not a wise idea
IMO.

Francis Dupont wrote:

> 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.

Yes, Francis, this is true if ingress filtering was universally applied.
Until now, however, this is not the case. The correspondent node should
therefore have a different means - e.g., the CoA test - to determine
whether or not the mobile node is reachable. Mobile IPv6 goes the most
secure way and requires a CoA test *before* CoA registration. If the
CoA-test requirement is to be more relaxed, like with Early Binding
Updates, the correspondent node needs more intelligence to prevent
flooding attacks. One mechanism to provide this intelligence is
Credit-Based Authentication.

I agree that an attacker could bypass ingress filtering, if applied, by
using an Alternate CoA option. In other words, the Alternate CoA option
could render ingress filtering useless. As you say, Francis, the
Alternate CoA option should therefore not be used with Early Binding
Updates. I have previously mentioned this on the MIP6 mailing list
(February 10, 2004).

Francis Dupont wrote:

> Is the "Early Binding Updates" document for mobopts
> (an IRTF WG) or for mip6 (an IETF WG)? 

When submitting the Internet-Draft on Early Binding Updates, we assumed
that it may best fit into the MIP6 WG. This is why the Internet-Draft
has the "mip6" infix in its name. Of course, if the MIP6 community
finds that there is a better place for Early Binding Updates, we would
not hesitate to move the Internet-Draft.

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

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

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 3 Mar 2004 19:10:18 -0500 (EST)

Hi Christian,
  I had just one comment.

On Wed, 3 Mar 2004, Christian Vogt wrote:
...
>Revealing one's identity is not possible with Mobile IPv6, because the

In fact it is the exact opposite. The attacking node's identity WILL 
ALWAYS be revealed in mobile ipv6. Did you mean hide instead of reveal?

Regards
Suresh

This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.

---

From: "James Kempf" <[email-masked]>
Date: Wed, 3 Mar 2004 17:25:47 -0800

Christian,

> Credit-Based Authentication.

Ingress filtering won't work if the MN is trying to bomb someone on its old
link. The MN could send off the early BU, then move to a new subnet, leaving
the victim on the old subnet subject to the attack. With standard RR, the MN
could do the same trick for nodes on its link, but there the MN has some
incentive not to, since the impact of a DoS attack on the MN's own traffic
may be negative.

Also, I've got a little concern about fixed time limits on the traffic
restriction, in addition to the other issues you've mentioned here. If the
layer 2 handover latency has considerable variability, it may be difficult
to gauge the traffic restriction timeout such that a sufficient percentage
of mobile nodes get adequate handover performance to maintain user
satisfaction. As an example, according to Bill Arbaugh's work, the handover
latency for 802.11 ranges anywhere from about 70 to 200 ms. Unless the time
limit is outside 99.999% of the variability for the layer 2 handover
technology in all kinds of deployments, it might lead to undesirable packet
drops.

            jak

---

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

> > Revealing one's identity is not possible with
> > Mobile IPv6...
> 
> In fact it is the exact opposite. The attacking
> node's identity WILL ALWAYS be revealed in mobile
> ipv6. Did you mean hide instead of reveal?

Oh my God, thanks Suresh. Yes, I meant to say "conceal" or "hide one's
identity". I guess it was late when I wrote that email...

Thanks for pointing to this.

- Christian

|
| Christian Vogt

---

From: Francis Dupont <[email-masked]>
Date: Thu, 04 Mar 2004 06:40:52 +0100

In your previous mail you wrote:

   
   Francis, you propose that a mobile node be required to do a standard
   binding update within each two successive Early Binding Updates.

=> no, what I suggested is to wait 3 seconds from the first EBU and
not to reset this timer to 3 seconds (i.e., let it run down to 0)
when other EBUs is received. So a tentative CoA registration can't
be refreshed continually for more than 3 seconds.

   Unfortunately
   lifetime.

=> if ingress filtering is used and is effective, it can't. If ingress
filtering is not used or is not effective, you are already dead and
relaxed/delayed CoA check won't change this.

   When the unconfirmed CoA is about to expire, the attacker
   
=> this doesn't matter.

=> this could be a problem with a real hold-down mechanism, but
not for my simpler proposal: re-updates are not dropped, they just
don't reset the timeout. Note that to remove a binding is not a problem
(RO is an optimization), the thing to avoid is to keep an old binding.
BTW the draft 24 takes care of this, for instance Kbm is different
for deleting bindings...

=> I am not interested to waste time about ineffective defense
against inexistent attacks..

=> you mean hide? I can't see why the attacker may want to reveal
its identity...

=> unfortunately the attacker doesn't need any bounded amplification...

   But if this is the case, there are other, more efficient attacks,
   which are already possible without Mobile IPv6.

=> I buy this argument!

   

=> I know it is not universally applied and more I know exactly why...
But my point is that when ingress filtering is not applied or is
ineffective, you are a setting duck and nasty things can happen
even if there is no moblte IPv6 capable correspondent node somewhere.

   Until now, however, this is not the case. The correspondent node should
   therefore have a different means - e.g., the CoA test - to determine
   whether or not the mobile node is reachable. Mobile IPv6 goes the most
   secure way and requires a CoA test *before* CoA registration.

=>note this is true *only* for a common correspondent, not a home agent.

   If the
   flooding attacks.

=> I strongly disagree about this need.

=> this is the only really need!
   
Regards

[email-masked]

---

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

link.

=> yes some ingress filtering mechanisms are ineffective when the
attacker moves after the launch of its attack but this has nothing
to do with using mobile IPv6 for the attack...

   The MN could send off the early BU, then move to a new subnet, leaving
   the victim on the old subnet subject to the attack. With standard RR, the MN
   could do the same trick for nodes on its link, but there the MN has some
   incentive not to, since the impact of a DoS attack on the MN's own traffic
   may be negative.
   
=> attacks from someone on the same link are a real issue and
one way to solve it, SEND, gives near nothing...

Regards

---

From: "James Kempf" <[email-masked]>
Date: Wed, 3 Mar 2004 23:07:46 -0800

> one way to solve it, SEND, gives near nothing...

Sure. It wasn't intended to. It's only intended to secure the IP address/L2
address resolution, and router discovery, not third party DoS attacks.

            jak

---

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

=> (likely to be ou of the scope :-) The point I tried to raise is that
some smart devices can detect attackers which are stealing your address
but without what SEND had promised they can't know which are real owners
so either are limited to detection or can be misued for DoS (e.g. when
they "locked" to the first seen)...

Regards

---

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

> relaxed/delayed CoA check won't change this.

Ah, I think I can see our difference now better. Thanks
for the explanation.

My view is that there's different levels of being "dead".
What I want to prevent is an amplification attack where
bad guys can cause a lot more packets to the victims than
what they have to send.

My current view is that even with no ingress filtering,
there is no such clear attack in plain IP which would enable
significant amplification. But I may have missed something.
I think we can agree that if vulnerability X makes the
ingress filtering-less situation much worse ("more dead")
than it already is, this would be a problem.

Alternatively, your opinion is that the situation is already
so bad without ingress filtering that its hopeless, and some
increase in vulnerabilities does not matter any more.
OTOH, there seems to be a nasty issue with the victims not
getting protection from their OWN ingress filter but from
the attacker's ingress, if any.

--Jari

---

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

=> I object: what you call an amplification attack causes a
number of packets of the same order. Packets are larger (MTU size
in place of ACKs) but they don't come for free and are limited
to a sending window per correspondent. This for the theory
but unfortunately we know what happens in the real world:
DDoS attackers use zombies which both give unbound amplification
and hide the real origin of the attacks. They don't seem to
use reflection even when reflection disperses traffic between
sources and the victim.

   My current view is that even with no ingress filtering,
   there is no such clear attack in plain IP which would enable
   significant amplification.

=> do you ever read the news?

=> it doesn't matter: using mobile IPv6 has a very bad property
for attackers: it makes them easier to track because of the HoA.

=> this is a bad thing which has nothing to do with Mobile IPv6...

Regards