Subject: [Mobopts] CBA vs. draft-zhao-mip6-rr-ext-01.txt

From: Christian Vogt <[email-masked]>
Date: Wed, 29 Mar 2006 23:39:19 -0600

Hi Fan,

in a previous email, you suggested that the hash-chain mechanism
described in [1] could be an alternative for Credit-Based Authorization.
 I don't agree with that perception.

[1] draft-zhao-mip6-rr-ext-01.txt

In [1], a MN can prove through a chain of hashes that it has
successfully gone through the past i correspondent registrations, where
i is an integer value between 0 and N, and N is initially selected by
the MN.

Like the similar strategy described in [2], your approach can be used to
extend the lifetime of the MN's binding at the CN.

[2] draft-arkko-mipv6-binding-lifetime-extension-00.txt

But a hash chain does not provide any evidence to the CN that a new
care-of address, chosen by the MN, is correct.  An attacker could easily
re-register with the same CN several times, using valid care-of
addresses, in order to increase the length of its hash chain.  If the CN
took this as an indication that the MN's next care-of address can be
trusted, it would be wrong.

The point is that an attacker (alias the MN) does not have to send a
single data packet until its hash chain is long.  But when its hash
chain is long enough to make the CN trustful, the attacker could
register a false care-of address and initate a redirection-based
flooding attack.

Such an attack can have significant amplification given that the
attacker did not send data packets prior to the attack.

Credit-Based Authorization does not have this vulnerability because it
limits the data volume a CN can send to a MN's unverified care-of
address to the data volume that the CN has recently received from that MN.

Take care,
- Christian

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

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

---

From: Fan Zhao <[email-masked]>
Date: Thu, 30 Mar 2006 23:21:02 -0800 (PST)

Hi, Christian,

> [2] draft-arkko-mipv6-binding-lifetime-extension-00.txt
The idea in my mind is actually very similar with [2], i.e.
using the history of communication for a future prediction
but with an additional reaction.

> trusted, it would be wrong.
The idea is the following:
CN may start to establish the trust with a previously unknown MN
given the ongoing communication. At certain point when MN
starts the handover, CN can still continue to send the traffic to
the unverified CoA. If MN is not malicious, this maximizes the
benefits of EBU because Mn can receive the traffic from CN
seamlessly. If MN is the attacker to attack another victim,
the victim is able to send back a message to CN to request to
stop forwarding the traffic. With an additional message exchange
like the address verification procedure, CN can verify that this
request is indeed from the address that it currently forwards the
traffic to (More precisely, the request can be from any node
on the path anyway.), and then CN would stop forwarding and
give the negative feedback to this malicious MN.

It is very similar with the real world, for example, the relationship
between humans.

>From the incentive point of view,
CN is likely to support this option because 1) it can serve
the good MN better. 2) it can stop forwarding the traffic to
the wrong place as it wastes its resources.

MN is likely to support this option if the handover delay is
really important as it can receive the traffic quickly during
handover.

Any other node would appreciate the option that helps stop receiving
the wrong traffic from CN. Otherwise, when it is under the attack, it
can not do anything about it except dropping the offending
traffic at the last hop. It will be very happy to provide
the negative feedback to CN once the attack starts.

> address to the data volume that the CN has recently received from that MN.
So my point is that CBA could limit the attack effects.
However, it does not maximize the benefits of EBU. The optimal case
is that the good MN should always receive the traffic without
limitation and the bad attacker should not succeed. But CBA treats
them the same way.

My proposal sacrifices the victims for the best service for good MNs
because the reality is CN would not have to hold guilty if involved in
reflective DDoS attack and the victim would use that option to help
themselves anyway.

What do you think?

Sincerely,
fan

---

From: Fan Zhao <[email-masked]>
Date: Thu, 30 Mar 2006 23:49:31 -0800 (PST)

Hi Christian,

One sidenote: CN may not extend the lifetime
of binding for each successful binding.

Sincerely,
fan

On Thu, 30 Mar 2006, Fan Zhao wrote:

> traffic to (More precisely, the request can be from anFrom [email-masked] Fri Mar 31 03:06:09 2006
Date: Thu, 30 Mar 2006 23:49:31 -0800 (PST)
From: Fan Zhao <[email-masked]>
To: Fan Zhao <[email-masked]>
Cc: Christian Vogt <[email-masked]>, Jari Arkko <[email-masked]>,
	Mobopts <[email-masked]>
Subject: [Mobopts] Re: CBA vs. draft-zhao-mip6-rr-ext-01.txt

Hi Christian,

One sidenote: CN may not extend the lifetime
of binding for each successful binding.

Sincerely,
fan

---

From: Christian Vogt <[email-masked]>
Date: Fri, 31 Mar 2006 22:44:44 -0600

Hi Fan,

couple of responses below.

>> described in [1] could be an alternative for Credit-Based
>> Authorization. I don't agree with that perception.
>> 
>> successfully gone through the past i correspondent registrations,
>> where i is an integer value between 0 and N, and N is initially
>> selected by the MN.
>> 
>> Like the similar strategy described in [2], your approach can be
>> used to extend the lifetime of the MN's binding at the CN.
>> 
> The idea in my mind is actually very similar with [2], i.e. using the
> history of communication for a future prediction but with an
> additional reaction.
> 
>>  care-of address, chosen by the MN, is correct.  An attacker could
>> easily re-register with the same CN several times, using valid
>> care-of addresses, in order to increase the length of its hash
>> chain.  If the CN took this as an indication that the MN's next
>> care-of address can be trusted, it would be wrong.
> 
> The idea is the following: CN may start to establish the trust with a
> previously unknown MN given the ongoing communication. At certain
> point when MN starts the handover, CN can still continue to send the
> traffic to the unverified CoA. If MN is not malicious, this maximizes
> the benefits of EBU because Mn can receive the traffic from CN 
> seamlessly. If MN is the attacker to attack another victim, the
> victim is able to send back a message to CN to request to stop
> forwarding the traffic. With an additional message exchange like the
> address verification procedure, CN can verify that this request is
> indeed from the address that it currently forwards the traffic to
> (More precisely, the request can be from any node on the path
> anyway.), and then CN would stop forwarding and give the negative
> feedback to this malicious MN.

I don't like the idea of allowing an attacker to do what it wants and
requiring other nodes to protect themselves in case of an attack.  E.g.,
how would you realize the additional message exchange that you are
describing when the victim is a legacy node that does not support your
mobility protocol?

> It is very similar with the real world, for example, the relationship

Human behavior may not always be a good measure. ;-)

> From the incentive point of view, CN is likely to support this option
> because 1) it can serve the good MN better. 2) it can stop forwarding
> the traffic to the wrong place as it wastes its resources.

See my comment above.

> MN is likely to support this option if the handover delay is really
> important as it can receive the traffic quickly during handover.
> 
>  can not do anything about it except dropping the offending traffic
> at the last hop. It will be very happy to provide the negative
> feedback to CN once the attack starts.

Again, see above.

>> The point is that an attacker (alias the MN) does not have to send
>> a single data packet until its hash chain is long.  But when its
>> hash chain is long enough to make the CN trustful, the attacker
>> could register a false care-of address and initate a
>> redirection-based flooding attack.
>> 
>> Credit-Based Authorization does not have this vulnerability because
>> it limits the data volume a CN can send to a MN's unverified
>> care-of address to the data volume that the CN has recently
>> received from that MN.
> 
> So my point is that CBA could limit the attack effects. However, it
> does not maximize the benefits of EBU. The optimal case is that the
> good MN should always receive the traffic without limitation and the
> bad attacker should not succeed. But CBA treats them the same way.

In simple CBA (where the MN gets credit for packets that the CN has
received from it), the MN will always have enough credit if it sends
approximately at the same rate as the CN does.  This is the case for
interactive real-time applications such as VoIP, i.e., the type of
application for which the need for optimization is probably most urgent.

But even for applications like TCP downloads, where most data goes from
the CN to the MN, the MN is very likely to gather sufficient credit with
most mobility patterns given the chosen parameters for credit aging.

BTW, with advanced CBA (where the MN gets credit for packets received
from the CN), you don't have a problem with any type of application.
See draft-vogt-mobopts-credit-based-authorization-00.txt.

> because the reality is CN would not have to hold guilty if involved
> in reflective DDoS attack and the victim would use that option to
> help themselves anyway.
> 
> What do you think?

See my comments above.  Alright, take care!

- Christian

Fan Zhao wrote:
>> described in [1] could be an alternative for Credit-Based
>> Authorization. I don't agree with that perception.
>> 
>> successfully gone through the past i correspondent registrations,
>> where i is an integer value between 0 and N, and N is initially
>> selected by the MN.
>> 
>> Like the similar strategy described in [2], your approach can be
>> used to extend the lifetime of the MN's binding at the CN.
>> 
> The idea in my mind is actually very similar with [2], i.e. using the
> history of communication for a future prediction but with an
> additional reaction.
> 
> 
>>  care-of address, chosen by the MN, is correct.  An attacker could
>> easily re-register with the same CN several times, using valid
>> care-of addresses, in order to increase the length of its hash
>> chain.  If the CN took this as an indication that the MN's next
>> care-of address can be trusted, it would be wrong.
> 
> The idea is the following: CN may start to establish the trust with a
> previously unknown MN given the ongoing communication. At certain
> point when MN starts the handover, CN can still continue to send the
> traffic to the unverified CoA. If MN is not malicious, this maximizes
> the benefits of EBU because Mn can receive the traffic from CN 
> seamlessly. If MN is the attacker to attack another victim, the
> victim is able to send back a message to CN to request to stop
> forwarding the traffic. With an additional message exchange like the
> address verification procedure, CN can verify that this request is
> indeed from the address that it currently forwards the traffic to
> (More precisely, the request can be from any node on the path
> anyway.), and then CN would stop forwarding and give the negative
> feedback to this malicious MN.
> 
> From the incentive point of view, CN is likely to support this option
> because 1) it can serve the good MN better. 2) it can stop forwarding
> the traffic to the wrong place as it wastes its resources.
> 
> MN is likely to support this option if the handover delay is really
> important as it can receive the traffic quickly during handover.
> 
>  can not do anything about it except dropping the offending traffic
> at the last hop. It will be very happy to provide the negative
> feedback to CN once the attack starts.
> 
> 
>> The point is that an attacker (alias the MN) does not have to send
>> a single data packet until its hash chain is long.  But when its
>> hash chain is long enough to make the CN trustful, the attacker
>> could register a false care-of address and initate a
>> redirection-based flooding attack.
>> 
>> Credit-Based Authorization does not have this vulnerability because
>> it limits the data volume a CN can send to a MN's unverified
>> care-of address to the data volume that the CN has recently
>> received from that MN.
> 
> So my point is that CBA could limit the attack effects. However, it
> does not maximize the benefits of EBU. The optimal case is that the
> good MN should always receive the traffic without limitation and the
> bad attacker should not succeed. But CBA treats them the same way.
> 
> because the reality is CN would not have to hold guilty if involved
> in reflective DDoS attack and the victim would use that option to
> help themselves anyway.
> 
> What do you think?
> 
> Sincerely, fan
> 
> 
>> Take care, - Christian
>> 
>> -- Christian Vogt, Institute of Telematics, University of Karlsruhe