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

Tom Herbert <tom@quantonium.net> Tue, 01 May 2018 22:33 UTC

Return-Path: <tom@quantonium.net>
X-Original-To: ila@ietfa.amsl.com
Delivered-To: ila@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2088D12EAE7 for <ila@ietfa.amsl.com>; Tue, 1 May 2018 15:33:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
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=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=quantonium-net.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EGUtLdcpapny for <ila@ietfa.amsl.com>; Tue, 1 May 2018 15:33:00 -0700 (PDT)
Received: from mail-wr0-x229.google.com (mail-wr0-x229.google.com [IPv6:2a00:1450:400c:c0c::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EAE912EAE0 for <ila@ietf.org>; Tue, 1 May 2018 15:33:00 -0700 (PDT)
Received: by mail-wr0-x229.google.com with SMTP id o2-v6so9112901wrj.13 for <ila@ietf.org>; Tue, 01 May 2018 15:33:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quantonium-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=q+e7gUqltNmR1j848sJ8DlS71xXU6GHVvGDsJcs4rtg=; b=nl3g01NgRMvhqGQBea6GyOJ6ZHWRtu9lbNXvOO8W9uJF+wh2PCq0TE3tWwP8KHFdzW cshn2ufHRZ6fwRoeL4S7g+cVaT8srz/okDhCJQIpBghf4TqIp5g5iNnTI8joOeFUNr3p vkjHiGczeGWasTYtqK8tNCS/WM9xiboN3FV6vCWAqPVSkDquRfTj6ZHqAzaZk4ewaFAX YrEagwQpVhcKSvI9XZYdrli1gc+Np4bUXBXsuc00QvOEh6UzMTO92sXsZO0uTbvoab1D BBoHfxrhuQXf50D7mWnpDBmJWuTnm7H4oe8BIgpyifouu0dvBJdIAq77uvmOxw12obNB TEPw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=q+e7gUqltNmR1j848sJ8DlS71xXU6GHVvGDsJcs4rtg=; b=mTEAA7nLkzEh8u7m0TfHoO49wG431TjQRAumPmICusUgr8psBYv64diyg7gWKSUTbq X2Kb875OKrOfa5vrdh+ooiHnl8et4EYAZ+71JuIItR3NcVwfAeWVx3VC+QQzkVU89nXD O0RFEnGH77VqPJJ+ZT3y0QLfnTctmfaViRHxtqpP6+T1pNLZpprS4LrZizlTxo+rcrPU CMwX5bZ7HZ4VHSCQAjMdoIzPohZujiUPc+vFKTYDifZ5rn+srojBuUrGFqEvRy+U677x dN13H0e7KBvWFz4Wd8KaprYXdzbt6OXtBTHTQp8vn8IP1Cyo1OYsfVKHLgBqHKN+JS4k XFGQ==
X-Gm-Message-State: ALQs6tAdPjzzEoQLOWACNve0wTpBNyOeMF4i8yNsPG4guULetXtQdWNh Frb7fvWTKHvhsZcrAPw+ojobksjjeDiz9YR+2MbO0g==
X-Google-Smtp-Source: AB8JxZqRvlccZzao+wbXF/OoVrXkQR/VvElN9JRF9e+PEKkbHVt1jgkrKU2uf7as6NVFx76wTiqyMZUMGf5mcVGPKJE=
X-Received: by 2002:adf:dc0d:: with SMTP id t13-v6mr11552523wri.153.1525213978947; Tue, 01 May 2018 15:32:58 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.128.227 with HTTP; Tue, 1 May 2018 15:32:58 -0700 (PDT)
In-Reply-To: <CA+YHcKF3z+LoVE=18HMgTNTpCN+23dDjkDx8bhZzWPdTeiX-_Q@mail.gmail.com>
References: <CALx6S37_oce-S0pEUgB8CpkWemcHhrb4HoDXUfPHZMGiokCqcA@mail.gmail.com> <253963a3-9e0b-2cb9-e216-745c6b99766c@joelhalpern.com> <CAPDqMeqsdG5FKtMaq9bjcJYDMw69Ow=OkeqMdba8aqRh9ayPrQ@mail.gmail.com> <08110014-adce-3f88-02d1-643871e46dcb@joelhalpern.com> <CALx6S34=Yeu3-hHTiVCOoQUM7KwvXPpGMmu8Ss-ZHeuOU6b7ug@mail.gmail.com> <CA+YHcKF3z+LoVE=18HMgTNTpCN+23dDjkDx8bhZzWPdTeiX-_Q@mail.gmail.com>
From: Tom Herbert <tom@quantonium.net>
Date: Tue, 01 May 2018 15:32:58 -0700
Message-ID: <CAPDqMeqcy-9+_Dk0yp=j7icQkDTvYnkYiwAbvRCq3oJ7UPciQA@mail.gmail.com>
To: Alberto Rodriguez-Natal <rodrigueznatal@gmail.com>
Cc: Tom Herbert <tom@herbertland.com>, "Joel M. Halpern" <jmh@joelhalpern.com>, ila@ietf.org, 5GANGIP <5gangip@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ila/pYKe0g-k_OpIZPW44SLZb1j14f0>
Subject: Re: [Ila] [5gangip] ILA forwaring [Was Re: Problem Statement]
X-BeenThere: ila@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Identifier Locator Addressing <ila.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ila>, <mailto:ila-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ila/>
List-Post: <mailto:ila@ietf.org>
List-Help: <mailto:ila-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ila>, <mailto:ila-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 01 May 2018 22:33:03 -0000

On Tue, May 1, 2018 at 2:59 PM, Alberto Rodriguez-Natal
<rodrigueznatal@gmail.com> wrote:
> On Tue, May 1, 2018 at 10:16 AM, Tom Herbert <tom@herbertland.com> 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