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

Hi Fan,

couple of responses below.

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

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

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

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

See my comments above.  Alright, take care!

- Christian

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

Fan Zhao wrote:
> Hi, Christian,
> 
> On Wed, 29 Mar 2006, Christian Vogt wrote:
> 
> 
>> 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
> 
> 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.
> 
> 
>> 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 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.
> 
> 
>> 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.
> 
> 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
> 
> 
>> Take care, - Christian
>> 
>> -- Christian Vogt, Institute of Telematics, University of Karlsruhe
>>  www.tm.uka.de/~chvogt/pubkey/
>> 

_______________________________________________
Mobopts mailing list
Mobopts@irtf.org
https://www1.ietf.org/mailman/listinfo/mobopts