Re: [lisp] [Ila] LISP for ILA

Tom Herbert <tom@quantonium.net> Fri, 16 March 2018 19:10 UTC

Return-Path: <tom@quantonium.net>
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43322120727 for <lisp@ietfa.amsl.com>; Fri, 16 Mar 2018 12:10:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable 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 9-C9ONzS4i2D for <lisp@ietfa.amsl.com>; Fri, 16 Mar 2018 12:10:43 -0700 (PDT)
Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (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 776231252BA for <lisp@ietf.org>; Fri, 16 Mar 2018 12:10:43 -0700 (PDT)
Received: by mail-wm0-x22e.google.com with SMTP id h21so4991738wmd.1 for <lisp@ietf.org>; Fri, 16 Mar 2018 12:10:43 -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:content-transfer-encoding; bh=8LEhQCfCjE1KMdpaHZoWdPrSpGRJ0Vbake/C9a9rvvI=; b=wO6gHTFF1nk/RCxXrYVmtErhmUfxlfRCATh80XgSiSqEKdHR2gwEZhbODqmF2NdgHu xXrQg1kLmxPjINgI/To6Htp9jFXor3CSSkuScEtQ+aWT3PXbEJalGS/1Z8sMv4d+m4kt v6a0G31xPiOdv0OSFjdohoKjZh/GZOEFChIhnfz4SYeja/1hjGWWaKCU//X4YZJcmlX4 VJIrgPJyGgcMfvFvLXgCWz+erewt5YQ9CwtaoRq/Gu9FyfXN15DeDGXmHR9YarYXGtAT Q3PPXWG7MzkgoJiT0sPRl6NvlUoIeC2ZArbQfn97O8pYtI59Mu8sOKTL/YaFlopYmHw7 TbKg==
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:content-transfer-encoding; bh=8LEhQCfCjE1KMdpaHZoWdPrSpGRJ0Vbake/C9a9rvvI=; b=BbRCQl5pNTRzF1kDL2TduD3htGMNcNQ1QO5rv9ldK+QlTCe4MvfuTJBmoqs0JolDFZ KsvwoeM1EST6raPOSPjuCBzwe7b+IWry8B4ueRWE/gAQNuHbXbSKrvfOA3Rb1sMLEoa9 U9EKMljrlD6axrmrYsWfxRm237yO592E+Ratz0y4KSIaBkfJKKomXsrLVxh52cIE1gDp 56TrWAhWVxuCHfLRk8JSKKD7jlF2RsxRGdD+8SM3I28j5GtQsezPaL+JIFfQy3yEeswv abm+5kGVO4RZ6GTb4W8AqMufQnFZni38VmRy8DLyflJVp1G+cI0CaXmjOdt0ji3O4IYL hjGA==
X-Gm-Message-State: AElRT7E3w7yy0/nIF36AA2oxuP6k63RIH0mhmCGjSPgvld9/brRVAzD0 W5fPzYLz93tCwMfpWGmCxY0XYJppY0h2ePz0qGZjhg==
X-Google-Smtp-Source: AG47ELtYgBrkmDrTnEzkINenlYlYI2EDxfy9TGUqFdo6PWB7FyRdmqcCsGC2livKscTxRecZB4asIVItjvk/aI05q0w=
X-Received: by 10.28.18.2 with SMTP id 2mr2512361wms.108.1521227441893; Fri, 16 Mar 2018 12:10:41 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.135.74 with HTTP; Fri, 16 Mar 2018 12:10:41 -0700 (PDT)
In-Reply-To: <16F3AEC4-EDCF-417B-8165-D22C48A06F3D@gmail.com>
References: <F1093230-C087-4168-9C5F-8DA7AB677677@cisco.com> <CAPDqMer58nxEixtH=JuZh9WgM0xKkEQYEjwZ6zg3wTjD76gOHQ@mail.gmail.com> <F920CAE2-9042-41DF-B013-E8FE6F891596@cisco.com> <CAPDqMeriMzM82-R-JOgx4zuqJTk2YOoBaWV_58no2V8yPas9QA@mail.gmail.com> <CF1C238D-FBE9-48BC-A7A6-49E45249E5E2@cisco.com> <CAPDqMeqL1kE+N9APFOSR4fUaek0TjZuDZMZDzDmJfMvyLO38GA@mail.gmail.com> <DA74C61A-647A-44BA-8FE7-916CF8895C49@gmail.com> <CAPDqMeqkGH0ELN=XmqF3dmsdeAurE-y+_H9+_E8mzhHo9d9nXw@mail.gmail.com> <7793B214-A235-4795-983B-CCC75A0B90BE@gmail.com> <CAPDqMeo2bdmwSEkPk002W9oxPhyxnLrr-k9MYeR5ZXEG_OGH0g@mail.gmail.com> <11EDF4FB-8636-4DF2-B687-1AB4934C4F9D@gmail.com> <CAPDqMeoSLqC=mN_hcgiLe-3Dv0c=uezbrZZ9xHn47Osb7rfLVQ@mail.gmail.com> <16F3AEC4-EDCF-417B-8165-D22C48A06F3D@gmail.com>
From: Tom Herbert <tom@quantonium.net>
Date: Fri, 16 Mar 2018 12:10:41 -0700
Message-ID: <CAPDqMer8m5ySuXBoSbBW0vcMnNTj-DxiHykNW+S6y=ReYnMrjA@mail.gmail.com>
To: Dino Farinacci <farinacci@gmail.com>
Cc: Florin Coras <fcoras.lists@gmail.com>, "Alberto Rodriguez Natal (natal)" <natal@cisco.com>, "ila@ietf.org" <ila@ietf.org>, "lisp@ietf.org" <lisp@ietf.org>, David Meyer <dmm@1-4-5.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/Grut4A3_esRkcbWaXwtb_4t2CTk>
Subject: Re: [lisp] [Ila] LISP for ILA
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol <lisp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lisp>, <mailto:lisp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lisp/>
List-Post: <mailto:lisp@ietf.org>
List-Help: <mailto:lisp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lisp>, <mailto:lisp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 16 Mar 2018 19:10:45 -0000

On Fri, Mar 16, 2018 at 11:41 AM, Dino Farinacci <farinacci@gmail.com> wrote:
>> Detecting that something is under DOS attack is not problem. It’s
>
> I do think it is a problem. Because you can’t tell sometimes if it is a high-rate due to high demand from good actors. From the mapping system’s perspective, you don’t know the traffic patterns so you don’t know that if a source-EID wants to talk to 100 EIDs if that is a good actor or a bad actor. If that source-EID is my phone, then it may be suspect, but if it’s a Google server talking to 100 phones, that is pretty normal.
>
>> pretty obvious when a device is getting flooded which a bunch of
>> spoofed SYNs for example. The problem is trying to find that one SYN
>> packet in a thousand that is not part of the attack and is actually
>
> Right, at cisco, we called that “the needle in the haystack problem”. And it comes up when we talk about topics of “punt path” in routers and DoS attacks.
>
>> legitimate. Again this is not easy because the attacker is purposely
>> trying to prevent this determination. AFAIK this is a generally
>
> Yep, that’s right.
>
>> unsolved problem and probably impossible to fully solve. So if the
>
> Agree. We should look at the honey-pot solutions that DNS has used. But its a different animal though than packet attacks.
>
>> reaction to the attack is to stop all requests and that one legitimate
>> flow is blocked from making progress, then it would seen the DOS
>> attack is successful.
>
> That isn’t what would happen with the frequency-hopping idea. If the map-resolver is aggressive in dropping and it drops the needles, those ITRs have a back-up or parallel plan to get their requests resolved from other map-resolvers in the mapping system. Be them part of an anycast group or not.
>
Dino,

Such complexity is why I am still keen on the redirect model for a
mapping system. An ILA cache is an optional element and the control
plane is never inline with packet forwarding and packets are not
dropped on a cache miss. Neither does the generate request packets for
bogus addresses that can't resolved. These properties bound the worse
case DOS attack to be that legitimate traffic takes an unoptimized
route but is not blocked nor dropped. Conservatively, this does
require provisioning ILA-Rs to handle the full load if necessary to be
robust.

Tom

> Dino
>
>
>
>
>