Re: CBA Re: [Mobopts] questions about EBU/CBA

> Thanks for your time for discussions. At least I can say I understand
> your points clearly. Hope this concludes our discussions.

Alright, Fan, thanks likewise.

- Christian

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

Fan Zhao wrote:
> Hi Christian,
> 
> 
>>Fan -
>>
>>
>>>I saw you skipped many of my comments. Does it mean you agree on
>>>them?
>>
>>Some of your later comments were already attended to by an earlier
>>in-line comment from my side.  I think I did not skip anything but your
>>reference to your draft.  That I would like to re-read first before I
>>make a statement.
> 
> OK.
> 
> 
>>>>But the resources consumed by CBA are minor, too--- especially in
>>>>the case where the CN is strong.
>>>
>>>I am not just looking at the resources consumed by CBA, but also the 
>>>impacts on the performances of good MNs, which you did not address
>>>here.
>>
>>Sure, I did.  See my later explanation on what happens in case a MN has
>>insufficient credit during handoff.  This is exactly the situation were
>>CBA might have a performance impact.  Performance is still better than
>>with standard Mobile IPv6.  But at the cost of security, which I
>>consider inacceptable, you may be able to increase performance if you
>>deactivated CBA.
> 
> IMO, address verification is still the best compromise 
> among security, performance and costs so far. It is very difficult to
> make changes as the equilibrium of these factors will be broken
> unless there is a killer application so that the people want to
> use it even with the risk/costs. 
> 
> 
>>>>Things are actually a bit similar with TCP's congestion-avoidance
>>>>mechanism.  Congestion avoidance ensures fair share of network
>>
>>resources
>>
>>>>between concurrent connections.  Like CBA, congestion avoidance is a
>>>>sender-based mechanism.  Non-compliance typically leads to better
>>>>throughput results for a single connection at the cost of other
>>>>connections.  But most CNs are nevertheless TCP-friendly.
>>>>
>>>>While this comparison is not 100% correct, it does show that there is
>>
>>a
>>
>>>>willingness to support mechanisms even if the benefits of doing so
>>>>cannot be directly reaped.
>>>
>>>I understand your points. However many cases already show TCP behaves
>>>badly with non-compliant sender/receiver. A standard should not be
>>>just working but the best from all available.
>>
>>My point is that there is wide acceptance of mechanisms which may imply
>>minor disadvantages for a single connection, but are to the advantage of
>>the Internet as a whole.  TCP congestion avoidance is one example, CBA
>>is another.  Sure there will always be nodes that don't comply.  But the
>>majority of nodes does and will.
> 
> OK, point taken. It might be because of the history reasons. TCP is 
> already 
> established for so many years that even very good changes, such as
> syn cookie, are not widely used. 
>  
> Security depends on the weakest link. If the Internet is originally 
> secure, we should do everything we can to keep it perfectly
> secure. But now it is not and probably will never be.
> Different vulnerabilities has different levels of severity.
> The severe vulnerability may make the whole Internet
> in trouble, thus each node still has incentives to prevent it with
> the inevitable costs. The efforts to completely prevent any threats
> may be in vain in a imperfect world.
> 
> 
>>>>With EBU/CBA, the MN can send and receive packets earlier than with
>>>>standard Mobile IPv6 provided that it has sufficient credit.  If it
>>
>>has
>>
>>>>sufficient credit, EBU/CBA obviously performs better than standard
>>>>Mobile IPv6.
>>>>
>>>>If the MN does not have sufficient credit, there are two options:
>>>>
>>>>(a)  The CN directs the packets to the MN's HoA.  Then, communications
>>>>can at least continue, albeit via a sub-optimal path.  This may be an
>>>>advantage over standard Mobile IPv6.
>>>>
>>>>(b)  The CN drops the packets that it cannot send to the MN CoA
>>>>directly.  In this case, the performance of EBU/CBA is the same as
>>
>>that
>>
>>>>of standard Mobile IPv6 for packets that the CN sends.
>>>
>>>Why? In MIP6, CN always sends the packets whenever requested, right?
>>>But here CN has to drop it. But you may count the advantages that EBU
>>>results in. I do not know which performance is better definitely in
>>
>>this
>>
>>>case.
>>
>>Consider a handoff scenario.  With standard Mobile IPv6, the CN
>>continues to send packets to the MN's old CoA until it receives the
>>Binding Update message.  These packets won't be received by the MN any
>>more, so the CN could just as well have dropped the packets in the first
>>place.
>>
>>Also, until the CN receives the Binding Update message, it will drop all
>>received packets that the MN sends to it from the new CoA due to a
>>binding-cache mismatch.
>>
>>With EBU/CBA, the CN learns about the CoA earlier, namely, when it
>>receives the Early Binding Update message.  It will already accept
>>packets that the MN sends from the new CoA as of then.  This is one
>>advantage that EBU/CBA has over standard Mobile IPv6.
>>
>>Furthermore, if the MN has sufficient credit, the CN can also send
>>route-optimized packets to the MN's new CoA.  This is a second advantage
>>of EBU/CBA in case credit is available.
>>
>>[If the MN does not have sufficient credit, the CN may opt to send
>>packets for the MN to the HoA.  This may be another advantage, provided
>>the path through the home agent is not too long.]
> 
> OK. However with a unidirectional UDP communication between CN and MN,
> there is no credit but costs generated. Overall CBA/EBU yields 
> benefits more or less but I am not sure if it is 
> signaficant considering the cost. 
> 
> 
>>>My feeling is CreditAgingFactor and CreditAgingInterval can only
>>>be derived empirically, which cannot guarantee to work optimally in any
>>>situation (even we do not what is optimal.). Thus these
>>>parameters should be different with different network and
>>>application. For example, RTT in wireless network may vary
>>>dramatically.
>>
>>So you think 500ms for a CoTI-CoT exchange may not be sufficient?
> 
> No, I am just thinking that the amount of credits should
> be _just_ enough for the communication before the new CoA verification 
> is done, thus different applications/network communications may need
> different credits. In some situations this amount of credits is
> even less than the credits collected via CBA. Along the line of 
> your thinking, in order to keep the flooding attack unattractive 
> to attackers, you want to associate the credits with the efforts of 
> packet sending before, which may cause the insufficient credits.
> 
> 
>>Note that, if the MN-CN RTT is that high, *reactive* end-to-end mobility
>>optimizations may not be strong enough anyway.  After all, it would take
>>the same MN-CN RTT until the MN has updated the CN with the new CoA and
>>the first data packet from the CN has propagated to the new CoA.
>>
>>But you can do *proactive* handoffs with EBU/CBA, too, as described in
>>draft-vogt-mobopts-simple-ebu-00.txt.  In such a case, the MN's credit
>>must cover the L2-handoff delay in addition to the latency of the
>>CoTI-CoT exchange.
>>
>>So yes, there will be situations where the MN may have less credit than
>>it would want to have.  As you say, this is the cost of security.  But
>>there are two important observations that one should make:
>>
>>- This is not an all-or-nothing game.  Even if credit is insufficient to
>>cover the entire handoff period, the CN will still send part of the
>>packets to the MN in a route-optimization way until all credit is gone.
>> Hence, lack of credit is unlikely to have an impact throughout the
>>*entire* handoff period, but it may have an impact later during the
>>handoff period.
>>
>>- Applications that benefit most from EBU/CBA are real-time applications
>>with direct user interaction such as VoIP.  Such applications are
>>typically symmetric in terms of the data rates from the MN to the CN and
>>vice versa.  This is where CBA won't have a performance impact at all,
>>all the more since the MN earns new credit for sending packets while it
>>consumes existing credit for receiving packets.
>>
>>Referring to your proposal to make credit aging adaptive to different
>>application and network scenarios:  Unfortunately, this is infeasible
>>from a security standpoint.  Credit aging prevents an attacker with
>>low-bandwidth Internet attachment from acquiring inappropriate volumes
>>of credit over a long time.  Such an attacker could misuse its credit
>>for a burst of flooding packets which does not compare to what the
>>attacker itself would be capable to send.
>>
>>Given that the type of application can be selected by the MN (or an
>>attacker), and given that it is by far untrivial for the CN to securely
>>acquire information about the MN's Internet attachment, credit aging
>>ought to be kept static and should be designed to work well in a
>>majority of cases with the types of applications that benefit most.
> 
> 
> Thanks for your time for discussions. At least I can say I understand
> your points clearly. Hope this concludes our discussions.
> 
> Sincerely,
> fan
>  
> 
>>- Christian
>>
>>-- 
>>Christian Vogt, Institute of Telematics, University of Karlsruhe
>>www.tm.uka.de/~chvogt/pubkey/
>>
>>
>>
>>Fan Zhao wrote:
>>
>>>Hi Christian,
>>>
>>>I saw you skipped many of my comments. Does it mean you agree on
>>>them?
>>>
>>>Please see my reply below.
>>>
>>>On Tue, 28 Mar 2006, Christian Vogt wrote:
>>>
>>>
>>>
>>>>Hello Fan!
>>>>
>>>>Some comments in-line:
>>>>
>>>>
>>>>
>>>>>>Well, as a content provider, wouldn't you get upset if someone 
>>>>>>misused resources of your servers for a flooding attack?
>>>>>
>>>>>The redirection attack should be addressed by address
>>>>>verification. Due to the lack of address verification in EBU, CBA
>>>>>is invented; but CBA cannot distinguish between the good and the
>>>>>bad, thus it is a double-sided sword.
>>>>>
>>>>>1) If the target of the attacker is the content provider itself
>>>>>(CN in this context), it is similar with supporting many MNs. CBA
>>>>>is not the solution to help CN because both good and bad MN (the
>>>>>attacker) receives the same treatment. Also there are many other
>>>>>ways to flood CN.
>>>>
>>>>I wasn't concerned about an attack on the CN (i.e., content
>>>>provider),
>>>
>>>I knew. Just include it for the completeness.
>>>
>>>
>>>
>>>>but rather an attack against a third party that the CN becomed
>>>>involved in.
>>>
>>>Yes. I did mention it in the original post.
>>>
>>>
>>>
>>>>Such an attack binds resources of the CN, which the CN could 
>>>>otherwise be spent on useful traffic.
>>>>
>>>>Still, you are right in saying that the resources bound for the
>>>>attack may not have a noticable impact if the CN is
>>>>well-provisioned.
>>>
>>>This is not all I mean. But I understand CBA is not for that purpose.
>>>
>>>
>>>
>>>
>>>>But the resources consumed by CBA are minor, too--- especially in
>>>>the case where the CN is strong.
>>>
>>>I am not just looking at the resources consumed by CBA, but also the 
>>>impacts on the performances of good MNs, which you did not address
>>>here.
>>>
>>>
>>>
>>>>If this is not incentive enough, it is up to the protocol
>>>>specification to make either preemtive reachability verification,
>>>>or concurrent reachability verification plus CBA a "MUST" to
>>>>safeguard the Internet as a whole.
>>>
>>>My main concern is whether CBA is the best choice.
>>>
>>>
>>>
>>>>Things are actually a bit similar with TCP's congestion-avoidance 
>>>>mechanism.  Congestion avoidance ensures fair share of network
>>>>resources between concurrent connections.  Like CBA, congestion
>>>>avoidance is a sender-based mechanism.  Non-compliance typically
>>>>leads to better throughput results for a single connection at the
>>>>cost of other connections.  But most CNs are nevertheless
>>>>TCP-friendly.
>>>>
>>>>While this comparison is not 100% correct, it does show that there
>>>>is a willingness to support mechanisms even if the benefits of
>>>>doing so cannot be directly reaped.
>>>
>>>I understand your points. However many cases already show TCP behaves
>>> badly with non-compliant sender/receiver. A standard should not be 
>>>just working but the best from all available.
>>>
>>>
>>>
>>>>>>Referring to your concern about the performance impact on 
>>>>>>applications, there are two things to consider:  First, Mobile
>>>>>>IPv6 with EBU/CBA is always at least as good as standard Mobile
>>>>>>IPv6.
>>>>>
>>>>>Can you please elaborate?
>>>>
>>>>With EBU/CBA, the MN can send and receive packets earlier than with
>>>> standard Mobile IPv6 provided that it has sufficient credit.  If
>>>>it has sufficient credit, EBU/CBA obviously performs better than
>>>>standard Mobile IPv6.
>>>>
>>>>If the MN does not have sufficient credit, there are two options:
>>>>
>>>>(a)  The CN directs the packets to the MN's HoA.  Then,
>>>>communications can at least continue, albeit via a sub-optimal
>>>>path.  This may be an advantage over standard Mobile IPv6.
>>>>
>>>>(b)  The CN drops the packets that it cannot send to the MN CoA 
>>>>directly.  In this case, the performance of EBU/CBA is the same as
>>>>that of standard Mobile IPv6 for packets that the CN sends.
>>>
>>>Why? In MIP6, CN always sends the packets whenever requested, right? 
>>>But here CN has to drop it. But you may count the advantages that EBU
>>> results in. I do not know which performance is better definitely in
>>>this case.
>>>
>>>
>>>
>>>>The MN can still send packets from an unverified CoA, however.
>>>>
>>>>
>>>>
>>>>>>Second, CBA works fine for all applications where the data sent
>>>>>>by the MN and data sent by the CN are roughly balanced.
>>>>>>
>>>>>>CBA may run out of credit--- and hence preclude further 
>>>>>>route-optimized traffic until reachability verification 
>>>>>>completes--- if the CN sends at a much higher rate than the MN.
>>>>>> Whether or not this happens depends on how much the asymmetry
>>>>>>in data rates is, as well as on the speed of credit aging. 
>>>>>>Fortunately, credit aging is designed to work well for
>>>>>>applications as asymmetric as a TCP download from the CN to the
>>>>>>MN.
>>>>>
>>>>>I am also wondering how the parameters, CreditAgingFactor and 
>>>>>CreditAgingInterval, are set up? It should be
>>>>>application-specific rather than static. So a procedure to derive
>>>>>those parameters dynamically might need to be added in the next
>>>>>version.
>>>>
>>>>CreditAgingFactor and CreditAgingInterval are static parameters.
>>>>They are chosen in a way that a MN downloading data from a CN can
>>>>earn sufficient credit even though the MN sends much less than the
>>>>CN.
>>>>
>>>>Assume a PMTU of 1500 bytes.  Say, the CN sends full-sized TCP
>>>>segments, and the MN sends a TCP ACK without any TCP options for
>>>>every second segment.  This is the worst asymmetry that can happen
>>>>with TCP (given PMTU = 1500 bytes).  Further assume, that the nodes
>>>>need 500ms for the concurrent CoA test.
>>>>
>>>>Given and consumed credit equals the size of packets (in bytes)
>>>>received and sent by the CN, respectively.
>>>>
>>>>The question is how long the MN needs to collect credit before
>>>>simple CBA allows it to do an optimized handoff.  So, what's the
>>>>ratio between the size of packets that the CN sends and the size of
>>>>packets that the MN sends?
>>>>
>>>>The CN sends two full-sized TCP segments.  This is 3000 bytes or
>>>>3000 credits.
>>>>
>>>>The MN sends a TCP ACK upon reception of the second TCP segment.
>>>>This ACK is composed as follows:
>>>>
>>>>IPv6 header (40 bytes) Destination Options Extension Header (24
>>>>bytes) HoA Option Padding TCP ACK (20 bytes)
>>>>
>>>>Hence, the entire packet is 84 bytes big, and worth 84 credits.
>>>>
>>>>The asymmetry ratio between the CN-to-MN flow and the MN-to-CN flow
>>>>is thus 3000 bytes / 84 bytes = 35.7.  The MN therefore needs at
>>>>least 500ms * 35.7 = 17.9 seconds between two successive handoffs
>>>>for acquiring sufficient credit for a 500-ms concurrent CoA test.
>>>>
>>>>The aging interval should be no shorter than 2 * 17.9 = 35.7
>>>>seconds, however, if the credit is cut in half after each such
>>>>interval. (Folks were talking about 30-seconds to 1-minute aging
>>>>intervals anyway.)
>>>>
>>>>Note that the assumed RTT of 500ms just for a concurrent CoA test
>>>>is quite long.  In many realistic scenarios will the RTT be lower. 
>>>>Moreover, the MN may have more to say than just ACK's.  And it gets
>>>> credit for duplicate ACK's, too.
>>>
>>>My feeling is CreditAgingFactor and CreditAgingInterval can only be
>>>derived empirically, which cannot guarantee to work optimally in any 
>>>situation (even we do not what is optimal.). Thus these parameters
>>>should be different with different network and application. For
>>>example, RTT in wireless network may vary dramatically.
>>>
>>>Sincerely, fan
>>>
>>>
>>>
>>>>Hope this helps.
>>>>
>>>>- 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