Re: [lisp] [Ila] LISP for ILA

Tom Herbert <tom@quantonium.net> Fri, 16 March 2018 15:29 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 D365712D77D for <lisp@ietfa.amsl.com>; Fri, 16 Mar 2018 08:29:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] 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 qjk3DrN2hCaS for <lisp@ietfa.amsl.com>; Fri, 16 Mar 2018 08:29:27 -0700 (PDT)
Received: from mail-wm0-x241.google.com (mail-wm0-x241.google.com [IPv6:2a00:1450:400c:c09::241]) (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 E24DE12706D for <lisp@ietf.org>; Fri, 16 Mar 2018 08:29:26 -0700 (PDT)
Received: by mail-wm0-x241.google.com with SMTP id e194so3745603wmd.3 for <lisp@ietf.org>; Fri, 16 Mar 2018 08:29:26 -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=2WNRe4HzBgKaONaLA2avZzg43kiY71F7c8YwItKprRE=; b=LBsUldRtDEbYGrKCijIsIrtUZjovTqQR+jrrzlcHRuz/j8GKpjEeIW9adKjr/eggSM QiIWwItH/F94VsANgtenMr5cl6mF5QDNRUTw0OYGru8Qa4RMBA7+7NzKAfV/Q//l+M0Y Hx/gRhEO5BMqcjprAFJasTZKvASgAQQRk5V1auEZBiRjuCKFmb3OpEDUnocVZh6cOBHX YICLO7gXJ7+3pyWpcts7ZvOI5vC0vMVGGmIyFpzmDzRQWTA7LRDn2I0POtvWBd09KSeq H4D2e38BTaCiBGXeSsagEiLTuifWoX1XTo5DYhAWVgsR8PZ4sWzTjL+tRhgRrUkLFYa4 Qqag==
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=2WNRe4HzBgKaONaLA2avZzg43kiY71F7c8YwItKprRE=; b=nP+5ThyZLzsnqueym38VIF9OXE1XrXw8DDXlfKYy7UrYkqhOZyd85yYi833UEMCt2+ MSfpLHd/Zn0zBjSAWuubpZPx+O+gmlHeONRv7U1WpmQfluP2zCCgK7gRfQvXq6k/AljX /QgePiGsttrAVudGiVmZZQC/1C4uh6T0/0zw2sRmqbrVwPSBZc3XmJQUDHmnsvPLvjuD Uj/AyF/Vs1RvHw41WLqkWKGowCbc3W7s9jqdpErzMLIFYoBfpOJeond1EJyzXDoc1qV7 oAWyDVsN9JoQHCLALzyWWweN4BT3yNWjOmYbE7jwW1RtPsa2W6yc9F8kNjYUD6gMouZx WzLg==
X-Gm-Message-State: AElRT7HJ8JWukYNuyJPDgL4YQGMd6F3ozPjnyjNCIpdaX24IEA0YvRpV F75K5FxUkzntKN4pKQXG7iZ0UZ98WOm7QWvZCJz1yQ==
X-Google-Smtp-Source: AG47ELtO4hr7cDgQ/3UTAUO64F4Rd4HvdQP4bktPAtlr3YYrKlyBTrB8XRzQZNdSRJJqck2o+3XVza1g5GDM9egPzg4=
X-Received: by 10.28.18.2 with SMTP id 2mr2023295wms.108.1521214165212; Fri, 16 Mar 2018 08:29:25 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.135.74 with HTTP; Fri, 16 Mar 2018 08:29:24 -0700 (PDT)
In-Reply-To: <DA74C61A-647A-44BA-8FE7-916CF8895C49@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>
From: Tom Herbert <tom@quantonium.net>
Date: Fri, 16 Mar 2018 08:29:24 -0700
Message-ID: <CAPDqMeqkGH0ELN=XmqF3dmsdeAurE-y+_H9+_E8mzhHo9d9nXw@mail.gmail.com>
To: Florin Coras <fcoras.lists@gmail.com>
Cc: "Alberto Rodriguez Natal (natal)" <natal@cisco.com>, "ila@ietf.org" <ila@ietf.org>, "lisp@ietf.org" <lisp@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/-dkMxqd8wTLYNA-_mkd2bvO0kVQ>
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 15:29:30 -0000

On Tue, Mar 13, 2018 at 6:37 PM, Florin Coras <fcoras.lists@gmail.com> wrote:
> Not sure about ILA-R but typically when deploying LISP, RTR/Proxy-ITRs have
> enough memory to store most, if not all, of the identity to location
> mappings. Therefore, once in steady state, most of the requests to the
> mapping system are triggered by edge devices ITR/ILA-N.
>
> This then means that just rate limiting ITRs should be enough to avoid
> DOS-ing the control plane and the problem converts into one of trying to
> avoid providing sub-optimal paths to legitimate traffic due to attacker
> pressure. As Alberto mentioned, there are a number of solutions to
> determining both the attackers and the destinations set that should be
> protected against cache evictions. The former can be used to determine the
> set of requests that should not be punted, while the latter ensures that
> mappings for popular destinations cannot be evicted by attacks.
>
Florin,

Attackers don't typically set the evil bit in packets and will
otherwise try to make their packets indistiguishable from legitimate
traffic. Can you provide a reference to a specific solution with an
algorithm that is able separate the bad packets from the good packets
wrt the cache.

Thanks,
Tom

> Florin
>
> On Mar 13, 2018, at 4:27 PM, Tom Herbert <tom@quantonium.net> wrote:
>
> 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
>
> _______________________________________________
> lisp mailing list
> lisp@ietf.org
> https://www.ietf.org/mailman/listinfo/lisp
>
>