Subject: [Mobopts] Comments on Early Binding Updates

From: Erik Nordmark <[email-masked]>
Date: Tue, 2 Mar 2004 22:04:37 -0800 (PST)

Since we ran out of mike time I have two points:

I think basing the "credits" on amount of data sent by the MN instead
of supposedly received by the MN makes sense for two reasons:
 - avoid needing crypto-strength proof that the MN has indeed received
   the packets it acknowledges
 - handle assymetric access link bandwidth

Today the amount of flooding a node can cause is limited by
the bandwidth it can transmit. Thus if you have ADSL you might be
able to receive 1.5Mbps you can send much less.
Unless this assymetry is a very temporary technological glitch
we shouldn't ignore it.

---

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?
(Perhaps there are orchestration issues here - could the MN use this to 
orchestrate multiple CNs for a DDoS?)

  Erik

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

---

From: "James Kempf" <[email-masked]>
Date: Tue, 2 Mar 2004 22:55:24 -0800

> orchestrate multiple CNs for a DDoS?)

How could one enforce this in a deployment/implementation where the MN's
stack could be hacked to get around the limitation?

            jak

---

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

> Unless this assymetry is a very temporary technological glitch

Right.

> orchestrate multiple CNs for a DDoS?)

Bandwidth limiting may be fine as well, at least if the "effort" needed
to "show" that you can do 64 kbps is bigger than the effort needed to
send IP packets with a spoofed source address at 64 kbps (which the mobile
node can do in any case). The reason why we want to have this limit on
the effort is to ensure that we don't introduce easier attacks than
we already have in the Internet.

Perhaps the real question, however, is which one is easier, packet
counting or bandwidith limiting?

In any case, these methods belong to the class of asymmetric cost schemes.
The general idea is that attacker's cost increases faster than defense
cost, damage cost, or like in this case, the cost of another attack.

--Jari

---

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

James Kempf wrote:

>>could one restrict the CN to send at 64 kbps until the CoA has been
> 
> confirmed?
> 

It does not matter what the MN's stack does. We have to assume it can be
compromised, or even evil to begin with.

But the point is that the MN has to provide some assurance to the
CN that it has spent a lot of effort in past communication with the
CN. Under this condition, the CN can send some packets to the claimed
care-of address even before its verification. Why? Because an evil
MN can already send spoofed TCP SYN packets or ICMP Echo Requests,
and get a 1-1 flooding at the victim site. With the condition that
we will set, the flooding is less than 1-1, i.e., you will have to
do more work to get one packet to the victim.

--Jari

P.S. There might be an effect to what denial-of-service tracing mechanisms
do for this. But the last time I checked, at least the IETF (maybe even
the world) had given up on such tracing schemes.

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 2 Mar 2004 23:51:12 -0800 (PST)

> stack could be hacked to get around the limitation?

Logic lives on the CN.
The MN's input to this piece of logic is only the number/rate that it sends
to the CN. It can't "fake" this since it is limited by the outgoing bandwidth
from the MN.

  Erik

---

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

> Not quite sure I follow. If the MN is responsible for sending a number/rate,
> what's to prevent it from lying?

Sorry for being unclear.

The MN is sending data packets - nothing else.

The CN can measure the number of packets/bytes sent by the MN over time
and apply the logic (whichever one folks come up with) to come up
with the limit it will use to for the number of packets/bytes (or rate?)
that it will send to the new CoA until the CoA has been verified.

  Erik

---

From: Francis Dupont <[email-masked]>
Date: Wed, 03 Mar 2004 09:33:26 +0100

Is the "Early Binding Updates" document for mobopts (an IRTF WG) or
for mip6 (an IETF WG)? I ask because the "credit" idea is fine for
a scientific conference or meeting but *not* for an engineering
forum... Why to try to defend againstsuch a complex reflection attack
when it is so simple to use a large number of reflectors (e.g., there
should be ~1 million Web servers which can blindly bomb you if my
stupid ISP doesn't use ingress filtering)?

Regards

[email-masked]

PS: BTW my ISP uses ingress filtering, not because it is not stupid, but
because it doesn't want to get "hidden customers" using my connection (:-).
PPS: even if the IETF network is protected by ingress filtering I can
easily spoof your address (we are on the same network) and even send
fake TCP_ACKs (:-).

---

From: Jari Arkko <[email-masked]>
Date: Wed, 03 Mar 2004 10:06:26 +0200

> what's to prevent it from lying?

The MN is not responsible for that. Even that part of the logic must reside
on the CN, i.e., it would measure the rate or number.

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

Copying an answer for the mobile ip list... I said this: "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. "

--Jari

---

From: "James Kempf" <[email-masked]>
Date: Tue, 2 Mar 2004 23:59:37 -0800

jak