Subject: [Mobopts] review of <draft-irtf-mobopts-ro-enhancements-06.txt>

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 27 Mar 2006 17:10:42 +0200

Hi,

I have reviewed <draft-irtf-mobopts-ro-enhancements-06.txt> and I
believe this document is basically ready for publication. It contains
a nice survey of MIPv6 optimizations which I consider useful. Note
that I am not an MIPv6 expert - I understand its basic principles, but
my expertise clearly lies in other areas.

Given my background, I would have loved to see also some discussion of
operational issues of the various approaches (kind of management
considerations), that is, how difficult will it be to debug problems,
what needs to be configured where, when and by whom, what needs to be
monitored to detect abuse or ongoing attacks, etc. On the operational
side, simplicity usually wins and hence understanding the management
impact of the various proposals is IMHO an important criterium for the
evaluation.

I have a more general observation I like to raise: I counted 29
citations of Internet Drafts out of 62 citations in total, which means
almost 47% of all citations are "work in progress". I checked up to
reference 22 and it seems that 5 out of the 17 cited IDs among the
first 22 references have already expired. How much should we be
concerned about publishing an RFC which points to quite a bit of
documents not really archived (in the sense that there is not a
defined entity in charge of maintaining access to the cited
documents)? This issue clearly has a wider scope and may require some
discussion or a policy within the IRTF as a whole. I did not go back
to the document to check what the purpose of those citations are, that
is, whether the main optimization idea is sufficiently summarized in
the mobopts draft under review so that the reference more serves as a
way to give credits. In such cases, I would not see a problem. If,
however, a reference is really needed to fully grasp a proposal, then
having dangling pointers is kind of problematic.

Next to these quite general comments, I do have a few concrete
comments and editorial suggestions:

a) I suggest to move the first paragraph of section 1 to the end of
   section one. I find it a bit strange to start an introduction by
   explaining who has reviewed the document.

   After moving the paragraph, the first sentence in the now first
   paragraph should be reworded so that it does start a bit more
   reader friendly and not just "RFC 3775 [42] specifies".

b) Section 1.1 page 4 last line: Do you really mean "not reluctant"?

c) Section 1.1 page 5 last bullet: s/in the certifications/in certificates

d) Section 1.2 page 6: introduce acronym BU the first time you use it

e) Section 2 surprises me. The usual convention is to acknowledge
   contributors and reviewers at the end of an RFC but not in the
   middle. I suggest to move this section to the very end. Note that
   this also requires changes in the introduction.

f) Section 4.7 talks about the credit-based authorization approach
   while 4.8 talks about heuristics. I am wondering whether
   credit-based authorization is no just another heuristic approach.

g) Section 5.2: I would like to know whether there are "standard"
   scenarios people use in the community to compare the various
   approaches. Ideally, such "standard" scenarios would be derived
   from real-world measurements. If such "standard" scenarios exist,
   it might be useful to point to them so that researchers can easily
   publish comparable results. If such "standard" scenarios do not
   exist, you might want to raise the construction of such things in
   order to produce comparable results as a potential future work
   item.

h) idnits complains that the document does not distinguish between
   normative and informative references. I guess all references are
   informative and I have no idea how strict today's rules are.

i) Reference [48] says "to be presented" and the date is November
   2004 - perhaps this actually got meanwhile presented?

j) Given my background, I would have loved to see also some discussion
   of operational issues of the various approaches (kind of management
   considerations), that is, how difficult will it be to debug
   problems, what needs to be configured where, when and by whom, what
   needs to be monitored to detect abuse or ongoing attacks, etc.

k) Reference [45] seems to be a bit screwed up.

l) How useful is it to cite mailing list messages (I am referring to
   references [59] and [60])? Are there no other suitable references
   for the "optimistic" approach?

m) Where was [8] published?

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

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

---

From: Fan Zhao <[email-masked]>
Date: Mon, 27 Mar 2006 16:50:45 -0800 (PST)

Hi Christian,

I have some questions about EBU/CBA:
1. The way that EBU works assumes that MN knows
what next network it will associate with during handover.
However this information may not be available to MN always.
2. What is the incentive for CN to implement the CBA as there
is no penalty if CN is involved into this kind of reflective
DoS attack and also the fact is that the server (CN) in the
current Internet does not care about its processing overhead
unless itself is under DoS attack. I also have concerns that
some application preformance may be hurt by CBA, which might
again reduce the incentive to support CBA.

It will be great that these issues can be addressed in the
next versions of your drafts.

Sincerely,
fan

---

From: Christian Vogt <[email-masked]>
Date: Mon, 27 Mar 2006 19:48:15 -0600

Hi Fan,

thanks for your comments.  My responses are in-line.

> However this information may not be available to MN always.

For proactive use of EBU, yes.  In this case, the MN must use, e.g.,
Media-Independent Information Services to find out about potential
target links and acquire the prefixes in use on those links.  The MN can
then send a proactive EBU message prior to handoff and switch to the new
link once an EBA message is received on the old link.

For reactive use of EBU, the MN does not need to know about its future
point of attachment.

> again reduce the incentive to support CBA.

Well, as a content provider, wouldn't you get upset if someone misused
resources of your servers for a flooding attack?

And besides resource consumption, packets that your servers would send
to the node under attack would originate from a source address that
belongs to your domain.

Having said that, and given that CBA is a rather simple mechanism, I'm
positive that implementing CBA is worthwhile from the CN's perspective.

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

Hope this helps.

- Christian

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

---

From: Jari Arkko <[email-masked]>
Date: Mon, 27 Mar 2006 20:14:23 -0800

>>again reduce the incentive to support CBA.

Good question! If something is entirely up to a party
that does not get a direct benefit from supporting
that something, then this is often proven to lead to
problems. However, there are certain things that
we can do:

o  Setting the proper standards requirements (e.g. MUST
    implement and use). In many cases this is sufficient,
    unless the implementation is really expensive and
    complicated.

o  Defining our protocols in such a way that they
    simply do not work without that implementation
    in the other end.

o  Avoiding complex designs that would be burdensome
    to implement.

--Jari

---

From: Fan Zhao <[email-masked]>
Date: Tue, 28 Mar 2006 19:09:00 -0800 (PST)

Hi Christian,

let me reply in seperate emails.

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

2) If the target of the attacker is other entity that is not in the
same domain of CN (If the victim is in the same domain as CN, it is similar
with flooding CN as the link to this domain is affected.), from the
perspective of economics, CN should consider whether it is worth
sacrificing the performance experienced by (many) good MNs for
the protection of other entity that CN in fact does not care about.

> to the node under attack would originate from a source address that
Then what? The reality is that there is no penalty for CN to become
a reflector: 1) You cannot block CN because it is in a different domain;
2) The service of CN is needed by other MNs, thus it cannot be shut down.

So the one motivated is MN itself. The history that MN communicates with
CN can be one kind of "credit", which is represented by hash chain
in draft-zhao-mip6-rr-ext-01 and is used to distinuguish the good from
the bad.

> positive that implementing CBA is worthwhile from the CN's perspective.
There is a scalability issue for CN: even though CBA for each flow
is light-weight, it could become a burden given many
flows. There are always costs for security.

> always at least as good as standard Mobile IPv6.
Can you please elaborate?

> Second, CBA works fine
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.

Sincerely,
fan

---

From: Fan Zhao <[email-masked]>
Date: Tue, 28 Mar 2006 19:25:32 -0800 (PST)

Hi Jari,

I think it works if like that. The reasons I brought
out my questions are just because 1) In the protocol design
sometimes the assumption that a communicating peer is
compliant may not be true. 2) Incentive needs to be considered
in the protocol design, especially security mechanisms
always come with costs.

Sincerely,
fan

---

From: Fan Zhao <[email-masked]>
Date: Tue, 28 Mar 2006 19:41:51 -0800 (PST)

Hi Christian,

I am wondering if there are better terms
rather than reactive registration and proactive registration
because in reactive registration HoT is
proactively elicited.

Sincerely,
fan

---

From: Christian Vogt <[email-masked]>
Date: Tue, 28 Mar 2006 23:34:25 -0600

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?
>
> 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.
>
> 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),
but rather an attack against a third party that the CN becomed involved
in.  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.

But the resources consumed by CBA are minor, too--- especially in the
case where the CN is strong.  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.

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.

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

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

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.

Hope this helps.

- Christian

---

From: Christian Vogt <[email-masked]>
Date: Tue, 28 Mar 2006 23:38:28 -0600

Fan,

the "registration" does not include the RR according to RFC3775
terminology.

Regards,
- Christian

---

From: Fan Zhao <[email-masked]>
Date: Wed, 29 Mar 2006 16:34:31 -0800 (PST)

Hi Christian,

I saw you skipped many of my comments. Does it mean
you agree on them?

Please see my reply below.

> I wasn't concerned about an attack on the CN (i.e., content provider),
I knew. Just include it for the completeness.

> in.
Yes. I did mention it in the original post.

> Such an attack binds resources of the CN, which the CN could
This is not all I mean. But I understand CBA is not for that
purpose.

> 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
My main concern is whether CBA is the best choice.

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

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

---

From: Fan Zhao <[email-masked]>
Date: Wed, 29 Mar 2006 16:36:33 -0800 (PST)

Hi Christian,

I knew that. What I mean is that in reactive registration
there is proactive HoTi/HoT, which may cause confustion.
But it is not a big deal.

Sincerely,
fan

---

From: Christian Vogt <[email-masked]>
Date: Wed, 29 Mar 2006 21:20:10 -0600

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.

>> But the resources consumed by CBA are minor, too--- especially in
>> the case where the CN is strong.
> 

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.

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

> results in. I do not know which performance is better definitely in this

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

> application. For example, RTT in wireless network may vary

So you think 500ms for a CoTI-CoT exchange may not be sufficient?

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.

- Christian

Fan Zhao wrote:
> Hi Christian,
> 
> I saw you skipped many of my comments. Does it mean you agree on
> them?
> 
>>> 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.
>> 
>> but rather an attack against a third party that the CN becomed
>> involved in.
> 
>> 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.
> 
>> 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.
> 
>> 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.
> 
>>>> applications, there are two things to consider:  First, Mobile
>>>> IPv6 with EBU/CBA is always at least as good as standard Mobile
>>>> IPv6.
>>> 
>>  standard Mobile IPv6 provided that it has sufficient credit.  If
>> it has sufficient credit, EBU/CBA obviously performs better than
>> standard Mobile IPv6.
>> 
>> (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.
>> 
>> directly.  In this case, the performance of EBU/CBA is the same as
>> that of standard Mobile IPv6 for packets that the CN sends.
> 
>  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.
>>>> 
>>>>  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
>>> 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)
>> 
>> 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. 
> 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

---

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

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

---

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

Hi Christian,

Sorry I do not have enough time to reply on this email.
I will do that tomorrow. Good day.

Sincerely,
fan

On Wed, 29 Mar 2006, Christian Vogt wrote:

> With EBU/CBA, the CN learns about the CoA earlier, namelyopts>,
	<mailto:[email-masked]?subject=unsubscribe>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mobopts>,
	<mailto:[email-masked]?subject=subscribe>
Errors-To: [email-masked]

Hi Christian,

Sorry I do not have enough time to reply on this email.
I will do that tomorrow. Good day.

Sincerely,
fan

On Wed, 29 Mar 2006, Christian Vogt wrote:

> >>> is invented; but CBA cannot distinguish betw, when it
> >>>>  Wheteen the good and the

her or not this happens depends on how much the asymmetry