<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>Hi Cedric,</p>
<br>
<div class="moz-cite-prefix">On 09/28/2016 01:43 PM, Cedric Westphal
wrote:<br>
</div>
<blockquote cite="mid:etPan.57ec1d49.7a74db3e.171c@localhost"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<div>Hi,<br>
<br>
regarding 3), it's probably too late once your under attack.
Note that in this case, it's Akamai that was attacked, and even
though they have more capacity to spread out the attack, the
server still went down.<br>
<br>
regarding 2), many people have made this content that NDN
requires flow balance and that measuring flow imbalance tells
you about attack. There is information in the unsatisfied
interests. That is true, but that information is noisy and more
importantly, relying on it means it becomes a new vector of
attacks. <br>
<br>
Consider a few nodes spraying interests for non existing
objects. The router will see a flow imbalance, and will shut
down traffic, but it can't discriminate between valid traffic
and attack. Attack succeeds. This is different from flooding the
PIT, since it only attacks the monitoring of the flow imbalance
and the router stops forwarding not under PIT exhaustion but
from its observation of unsatisfied interests.<br>
</div>
</blockquote>
<br>
I am not sure why the single router failure scenario keeps coming
up, but I will try this one last time. The attack *will* succeed (at
least the type of attacks we have been discussing here) to bring
down one or more routers. NDN, however, enables you to manage
communication failure. In one example, we may allow routers in
networks with many attackers to overload and fail by controlling the
PIT size. That would have the policy effect of higher collateral
damage in networks with high infection rate. No single policy will
work for all cases, so other policies are also possible.<br>
<br>
There is noting magical about NDN that will thwart all DDoS attacks
(as much as I like unicorns). You can have crappy designs in NDN,
just like any other architecture. As with any other system there are
tradeoffs and compromises. The fundamental question, IMHO, is which
architecture allows you to make the best tradeoffs. I put my money
on the one that provides better feedback.<br>
<br>
Christos.<br>
<br>
<blockquote cite="mid:etPan.57ec1d49.7a74db3e.171c@localhost"
type="cite">
<div>
<br>
New features enabled by PIT are also new risks.<br>
<br>
C.<br>
<br>
Sent from HUAWEI AnyOffice<br>
</div>
<div name="AnyOffice-Background-Image" style="border-top:1px solid
#B5C4DF; font-size:14px; line-height:20px; padding:8px">
<div style="word-break:break-all"><b>From:</b>Paul Bellamy</div>
<div style="word-break:break-all"><b>To:</b><a class="moz-txt-link-abbreviated" href="mailto:ndn-interest@lists.cs.ucla.edu">ndn-interest@lists.cs.ucla.edu</a>,</div>
<div style="word-break:break-all"><b>Date:</b>2016-09-28
01:57:52</div>
<div style="word-break:break-all"><b>Subject:</b>Re:
[Ndn-interest] Largest DDoS attack ever delivered by botnet of
hijacked IoT devices</div>
<div><br>
</div>
</div>
<div>
<div dir="ltr">One the invariants of a DoS is that there are a
lot of packets depleting the resources of a single target
physical machine. Which means we can prevent it in two ways.
Given that, there are several potential solutions which jump
to my mind:
<div><br>
1) Reject bad-actors sending lots of packets. Would work
against a DoS, but not a DDos, as each individual actor is
sending a reasonable amount of packets.</div>
<div><br>
<div>2) Stop too many packets reaching the single target.
During resource-exhaustion we could purge PIT entries with
similar prefixes. The nature of the flooded interests
means they should all have a similar prefix. We could
limit the number of outstanding interests for a given
prefix.</div>
<div><br>
</div>
<div>3) Scale up the target. IMO, one of the big advantages
of NDN for service-operators is that (unlike IP) interests
don't have to be answered by any specific physical
machine. If you've designed your application well, you can
easily add more capacity. This is "good enough", until you
run into cost-constraints.</div>
<div><br>
</div>
<div>Of those, a combination of 2 and 3 seem the most
practical.</div>
<div><br>
</div>
<div>Regards,</div>
<div>Paul</div>
</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Ndn-interest mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Ndn-interest@lists.cs.ucla.edu">Ndn-interest@lists.cs.ucla.edu</a>
<a class="moz-txt-link-freetext" href="http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest">http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest</a>
</pre>
</blockquote>
<br>
</body>
</html>