Re: [lisp] [Ila] LISP for ILA

Tom Herbert <tom@quantonium.net> Tue, 13 March 2018 23:27 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 15A95126DFB for <lisp@ietfa.amsl.com>; Tue, 13 Mar 2018 16:27:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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 JMSloIouXPBn for <lisp@ietfa.amsl.com>; Tue, 13 Mar 2018 16:27:08 -0700 (PDT)
Received: from mail-wr0-x232.google.com (mail-wr0-x232.google.com [IPv6:2a00:1450:400c:c0c::232]) (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 50ED312D7EC for <lisp@ietf.org>; Tue, 13 Mar 2018 16:27:08 -0700 (PDT)
Received: by mail-wr0-x232.google.com with SMTP id n12so2698709wra.2 for <lisp@ietf.org>; Tue, 13 Mar 2018 16:27:08 -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=0+6MPA7OqcT91bvyIQqywHcyTPEy4O1MyMrfPwcx1qM=; b=OAovYFAwK4A0hmJX7qvf3D/1ETA092O8yk+z4a+BarD4CHOrgeuDlvdOPyfaxmhHV3 4W5qd11IxgJjJxwBO5UGtbHa0TgqBGPKetSxCoM8qo0G7K9PoceCkRyT0tO7NBin5Yhc NHk+2Lz3cfcQOjXYJLn2/S5tXdrJLAEQCXptF8oFQbqOAjvZol8+qExvb/3/pHwShLCR 7ZaQBkTxgShKJcQ4IRXHP6cClU7zqiOYdaudZ7ou9NvQbhw99xxEKZLHUslx6b4oyMOw opH8LXJ5QNQC/qx1d/7JZi5HleOG1tKWgDMjTeOPa9sdiISWwRH5WcLUWTGTVtnUvcG2 Qf0A==
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=0+6MPA7OqcT91bvyIQqywHcyTPEy4O1MyMrfPwcx1qM=; b=T4DigoGYLM519BrMqJ6KcKR9V7QqYZhJyKoNYmJtsvv/O6qn/ZK4SbWg66NyuAQ0tn rcaTv2VUZQ0QxA1EeV9YRHlkMthVLw50EOs1hp4pKb/IEWbNAmRGoBxdBZQOzM+XD/Tz KSSdfGMOP8eVq6EPyho6Qnoevkn5ZCYL0/Eo5hQislOaPGp2rpya14yryniD18+hDIdu lIfzKhD6O3Vv10cV71kBiUML9pCVZ/y/rGWm0MD2Qz0yPQkYfxc09zyWE4bNejr3BbFB lSUVqrngeLEY2PxQgCh4CtFR59EXbbmbBy7ADX+IY9Zb8T4vep0G4ZJgzBL3eVIHtrwc /zJg==
X-Gm-Message-State: AElRT7ExZV6qddI/kSqdKTrCHq3tCX8JrsVWUGcZzSYflHh2nLq57iFI at4H2GpAUzmHY8Ya2t9lxhJx2KepP7HDxVFvN8dYNg==
X-Google-Smtp-Source: AG47ELv7DOJ9IYxL8XZjLRyLq/x4tHyMgYI7j69nFj0Z7P38lvfqGo15Fizv4pcKvyY4O2r/PrJbaUYrw29jS8XHMB4=
X-Received: by 10.223.150.117 with SMTP id c50mr2080810wra.196.1520983626732; Tue, 13 Mar 2018 16:27:06 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.135.74 with HTTP; Tue, 13 Mar 2018 16:27:06 -0700 (PDT)
In-Reply-To: <CF1C238D-FBE9-48BC-A7A6-49E45249E5E2@cisco.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>
From: Tom Herbert <tom@quantonium.net>
Date: Tue, 13 Mar 2018 16:27:06 -0700
Message-ID: <CAPDqMeqL1kE+N9APFOSR4fUaek0TjZuDZMZDzDmJfMvyLO38GA@mail.gmail.com>
To: "Alberto Rodriguez Natal (natal)" <natal@cisco.com>
Cc: "ila@ietf.org" <ila@ietf.org>, "lisp@ietf.org" <lisp@ietf.org>, "Fabio Maino (fmaino)" <fmaino@cisco.com>, Albert Cabellos <acabello@ac.upc.edu>, "Vina Ermagan (vermagan)" <vermagan@cisco.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/ejNHcM_qivh_sT2voRrDO71utgg>
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: Tue, 13 Mar 2018 23:27:10 -0000

On Tue, Mar 13, 2018 at 3:50 PM, Alberto Rodriguez Natal (natal)
<natal@cisco.com> wrote:
>
>
> ´╗┐On 3/13/18, 1:05 PM, "Tom Herbert" <tom@quantonium.net> wrote:
>     >
>     >     This is reflected below in: "While the mapping is being resolved via
>     >     the Map-Request/  Map-Reply process, the ILA-N can send the data
>     >     packets to the underlay using the SIR address."
>     >
>     >     I think it should be assumed in ILA that not queuing packets and not
>     >     dropping packets because of resolution are requirements (too much
>     >     latency hit).
>     >
>     > IMHO, these should not be hard requirements. Leveraging ILA-Rs for mapping resolution has another set of tradeoffs to be considered. An operator should be able to decide which set of tradeoffs makes sense for his/her particular scenario.
>     >
>     This is a hard requirement because caches are explicitly not required
>     for ILA to operate. They are *only* optimizations. If there is a cache
>     hit then packets presumably get optimized path, on a cache miss they
>     might take a subopitimal route-- but packets still flow without being
>     blocked! This means that the worse case DOS attack on the cache might
>     cause suboptimal routing; however, if resolution is required then the
>     worse attack case becomes that packets don't flow and it's a much more
>     effective attack.
>
> Performing the mapping resolution at the ILA-N doesn't mean that you can't send the packets to the ILA-R to avoid the first-packet-drop. Those are two different things. Traditionally in LISP, a possible deployment model is to have a couple of RTRs with all the mappings in the site, so xTRs can use them as default path while they are resolving mappings. In this scenario, all the mapping resolution is done at the xTRs while the RTRs are only forwarding "first-packets". We have seen this model working really well even for large LISP deployments.
>
>     >     In ILAMP, a redirect method is defined. On a chache miss the packet is
>     >     forwarded and no other action is taken. If an ILA-R does
>     >     transformation it may send back a mapping redirect informing the ILA-N
>     >     of a transformation. The redirects must be completely secure (one
>     >     reason I'm partial to TCP) and are only sent to inform an ILA-N about
>     >     a positive response. To a large extent this neutralizes the above
>     >     random address DOS attack. There are other means of attack on the
>     >     cache, but the exposure is narrowed I believe.
>     >
>     > That model is supported in LISP via the use of Map-Notifies. However, moving the mapping resolution to the ILA-R comes at a cost. It's putting more load (in terms of both data and control plane) into an architectural component that it's not easy to scale out, since it requires (for instance) reconfiguring the underlay topology.
>
>     I'm not see how this creates more load (i.e. the need for map request
>     packets are eliminated), but I really don't understand what
>     "reconfiguring the underlay topology" means!
>
> Happy to try to clarify this. I'm talking about the load in the ILA-R. With a "redirect" model, the ILA-R has to (1) serve as the data-plane default path and (2) provide control-plane mapping resolution. This is centralizing the data-plane and control-plane into a single component, the ILA-R. Moreover, this will also require a lot of punts from the fast path to the slow path in the ILA-R which has also implications. With a request/reply model, the control-plane resolution is performed at the edges in a distributed fashion and the ILA-R only serves as data-plane default path to avoid dropping traffic. The latter model alleviates the load in the ILA-Rs, which reduces the need to scale them out.
>
Yes, but you are ignoring the load on the mapping servers which also
needs to scale. Additionally, if ILA-N is both forwarding a packet and
sending a map request then this potentially doubles the packet load on
the network and exacerbates the potential DOS attack where someone
floods an ILA-N with packets having bogus destinations. There might be
mitigations to this DOS attack, like heavy-hitters you mentioned, but
we really need the details to see exactly how this works and how
effective they are. On the surface of it, it looks like
request/response model is susceptible to DOS especially when third
parties are allowed to drive the process.

Tom