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

From: "Fan Zhao" <[email-masked]>
Date: Fri, 31 Mar 2006 20:27:47 -0800 (PST)

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/mobopts

---

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

> your points clearly. Hope this concludes our discussions.

Alright, Fan, thanks likewise.

- Christian