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

Tom Herbert <> Tue, 01 May 2018 23:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3AE0B126DFB for <>; Tue, 1 May 2018 16:20:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id S7ae9zVFiZwf for <>; Tue, 1 May 2018 16:20:14 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c0c::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5DE09126BF6 for <>; Tue, 1 May 2018 16:20:14 -0700 (PDT)
Received: by with SMTP id 94-v6so10755112wrf.5 for <>; Tue, 01 May 2018 16:20:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=n5sHZPS/Lo4D6GMmwF0iika0UsrD+oBcZwbG73cuPKg=; b=k2JeWSXxav8rZJDNrsxj8jQwO+W9oLtz+CS/Jbs9ICJlhfbJMxf1LHisA6XyxM+mMS ICWF+PSLNYcgTLm6iEoJedSwV0DWYeJl65frmxAJLVFHx+0fmdFHYoOPXkPcPDhqBIcV /x+uEFjRpNyreWN4Lbnm+RWVeukCBPEAkrVo3fW2ObPEgRFzQYFt/v1Zffc4XMOUgRW+ HLr2ukuWXKl7lZcN7gXEQ9Mr2owEIyzkB/caPtq3ipbKdlIEH/pUXZ8QsekcMkySuLE9 F/8nZyHpEW74RRi59/UErZVeA3EWZKUDxnOCdsMvFiWWGMw+WBsSCG7MgL7x2ATR1BcF E5Zg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=n5sHZPS/Lo4D6GMmwF0iika0UsrD+oBcZwbG73cuPKg=; b=inH0cYHkHK6cJTvpiy1bbOX7cYEISFNlgecn+iXrkBrakLSseiouJaNRr8OygERSGC Nw/aAIVVRn+tXIk029YYSePWJG0SNzMGvLOJv+tu/fwY7oD7ORtN2CGyNrpwB0T7poeU 6OXJbhNlHuYXzC1Swc/PZcwzmOvb6t44HYTmqU0CSiDSYYDBaZoSnHmwFZP7Xkk2Nh0J BA7bfEbATeg9e51CzVvLbTNb+EU/tjYFnIOB66u46+Rgg5f1zkdCFqU3SJrD2+PEaM7P HNsnk01updeeBgZR5Ojhky/F5SCLTYR9QIr72F1ceDn+aFF4REn+e8SioE2A9ubSIqCd ay3Q==
X-Gm-Message-State: ALQs6tAFGJ7cSEMsBOO9Wmb2gie/gWvwODmfPKnTg4DEE4u+hC3oVSI/ SIy70EI7O0t4DVySYcbNan+HOXLllP4o/MvwNwICtQ==
X-Google-Smtp-Source: AB8JxZrjP2Vn9Gqi7mSmhTd9tKVvcWyYdPr5HX6cp55bnMiCxcaNYmDG3kPivZDHkE5aJmPra4NBnt3XY97oJTly9fE=
X-Received: by 2002:adf:9162:: with SMTP id j89-v6mr12821092wrj.196.1525216812725; Tue, 01 May 2018 16:20:12 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Tue, 1 May 2018 16:20:12 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <>
From: Tom Herbert <>
Date: Tue, 01 May 2018 16:20:12 -0700
Message-ID: <>
To: "Joel M. Halpern" <>
Cc: Alberto Rodriguez-Natal <>, Tom Herbert <>,, 5GANGIP <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Subject: Re: [Ila] [5gangip] ILA forwaring [Was Re: Problem Statement]
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Identifier Locator Addressing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 01 May 2018 23:20:23 -0000

On Tue, May 1, 2018 at 3:49 PM, Joel M. Halpern <> 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.


> Yours,
> Joel
> On 5/1/18 6:32 PM, Tom Herbert wrote:
>> On Tue, May 1, 2018 at 2:59 PM, Alberto Rodriguez-Natal
>> <> wrote:
>>> On Tue, May 1, 2018 at 10:16 AM, Tom Herbert <> 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