Re: [Ila] [5gangip] ILA forwaring [Was Re: Problem Statement]

[Tom Herbert <[e-mail]>]

On Thu, May 3, 2018 at 9:23 AM,  <[e-mail]> wrote:
> Hi Tom,
> I understand you correctly that DDOS attacks can never be completely prevented whatever protocol you use.
> It will however always remain related to known IP addresses and the more versatile these are handled a mitigation strategy could be designed.

Dirk,

I disagree. IP addresses can too easily be spoofed, it's easy to hide
identity behind a NAT (see discussion about CGNAT and law enforcement
on int-area list), and trying to turn off individual addresses doesn't
work if it's a DDOS. This is nothing new. For instance, content
providers have long accepted the fact that they can't prevent SYN
attacks and there's little point to trying to go back to source IP
address (they are always spoofed in a SYN attack). The better strategy
is to absorb the attack and minimize the negative effects so that the
attack is not worth the effort.

> As you may have seen we mention improved handling of mapping systems and subsequently of DDOS protection also in the current version of our PS document https://github.com/bsarikaya/atic/blob/master/atick_problemstatement.3.txt which Behcet has announced recently.
> May I ask you to please comment on the ideas outlined there?

I don't see much difference in the latest version. For a problem
statement, I still think there is too much focus on the solutions and
not nearly enough description of what the actual problems are to be
solved.

Tom

> Thanks!

> Best Regards
> Dirk
>
> -----Original Message-----
> From: 5gangip [mailto:[e-mail]] On Behalf Of Tom Herbert
> Sent: Mittwoch, 2. Mai 2018 01:20
> To: Joel M. Halpern <[e-mail]>
> Cc: Tom Herbert <[e-mail]>; [e-mail]; Alberto Rodriguez-Natal <[e-mail]>; 5GANGIP <[e-mail]>
> Subject: Re: [5gangip] [Ila] ILA forwaring [Was Re: Problem Statement]
>
> On Tue, May 1, 2018 at 3:49 PM, Joel M. Halpern <[e-mail]> wrote:
>> You seem to be saying that even though not all DDOS attacks are
>> structurally the same, and even though if ILA were widely adopted not
>> all ILA networks would be structurally the same, there should
>> nonetheless be one required qay of handling DDOS?
>
> Yes, at least as core default in the protocol. It's precisely _because_ not all DDOS attacks are structurally the same. An attacker is not going to conform to to our expectations of what they should be doing, so if we enable LISP option N to mitigate one form of attack, they will just use another attack that isn't mitigated. For example, if the mitigation is to identify attackers by address when requests from the address exceed a threshold then this works as long as the attacker strikes from one machine, but it falls apart if the attacker launches a DDOS attack from several hosts where requests from none of the hosts exceed the threshold.
>
> The ILA model works because it assumes there is no absolute way to prevent the the worst case attack on a cache which is to completely kill it (i.e. drive it to 0% hit rate). In this state the behavior sub-optimal routing, which is much better than loss of service. This is not dependent on the structure of the attack, network topology, or the network operator getting the configuration just right-- it is inherent in the protocol.
>
> Tom
>
>>
>> Yours,
>> Joel
>>
>>
>> On 5/1/18 6:32 PM, Tom Herbert wrote:
>>>
>>> On Tue, May 1, 2018 at 2:59 PM, Alberto Rodriguez-Natal
>>> <[e-mail]> wrote:
>>>>
>>>> On Tue, May 1, 2018 at 10:16 AM, Tom Herbert <[e-mail]> wrote:
>>>>>
>>>>>
>>>>> I think you've misunderstood my position. Caches are _very_
>>>>> important to eliminate the cost triangular routing (latency, average path load).
>>>>> This reduces latency and reduces average load on ILA-Rs. But, and
>>>>> this is the critical part, caches are only an _optimization_ in
>>>>> ILA. That means if the cache is rendered ineffective (like by a
>>>>> well crafted DOS
>>>>> attack) then the only effect is that the optimization is loss (i.e.
>>>>> greater latency due to triangular router)-- this is quantitively
>>>>> the worst effect of the attack on an ILA cache. This can be
>>>>> contrasted that to LISP where the worst case effects of a DOS
>>>>> attack on the cache is loss of service for users (infinite latency
>>>>> since packets can be dropped or indefinitely blocked on a cache miss).
>>>>
>>>>
>>>>
>>>> This can be misleading. This is not comparing LISP vs ILA, this is
>>>> comparing the models of Request/Reply at the edge vs Notifications
>>>> (aka Redirects) at the core. Both LISP-CP and ILAMP support these
>>>> two models.
>>>>
>>>> Besides, this is assuming an scenario where the only feasible DOS
>>>> mitigation is absorbing the attack. There are other scenarios where
>>>> other countermeasures are possible. For instance, if you have a
>>>> deployment where you can prevent address spoofing, counting and
>>>> blocking misbehaving nodes offers similar DOS protection and
>>>> requires way less infrastructure resources.
>>>>
>>> Alberto,
>>>
>>> The answer to my question of how does LISP address DOS attacks seems
>>> to be "there are many options". Some of the options are to assume
>>> that DOS does not exist in the network, some assume external
>>> configuration like address spoofing is enabled, some assume that
>>> attacks can be identified and can be stopped at the source, some
>>> might assume that everything is okay because there's never been a DOS
>>> attack before. I have yet to see the effects of any of these
>>> quantified, and none of these state how the LISP _protocol_ itself
>>> addresses DOS. It may seem counter-intuitive, but offering a bunch of
>>> options really is not necessarily a good thing-- sometime less is
>>> more. To put this another way LISP has been rejected from Linux
>>> precisely because of its susceptibility to DOS. If you were to try
>>> again and the best answer to the DOS question is that it's up to the
>>> operator to figure out the right options to use, then I believe it
>>> would be soundly rejected again. That approach does not work at scale.
>>>
>>> Tom
>>>
>>> _______________________________________________
>>> ila mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/ila
>>>
>>
>
> _______________________________________________
> 5gangip mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/5gangip