Re: [Ila] LISP for ILA
Tom Herbert <tom@quantonium.net> Tue, 13 March 2018 20:05 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 B4E47120047 for <ila@ietfa.amsl.com>; Tue, 13 Mar 2018 13:05:52 -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=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 i88xiqqmwIeZ for <ila@ietfa.amsl.com>; Tue, 13 Mar 2018 13:05:50 -0700 (PDT)
Received: from mail-wr0-x244.google.com (mail-wr0-x244.google.com [IPv6:2a00:1450:400c:c0c::244]) (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 A4A79126CD6 for <ila@ietf.org>; Tue, 13 Mar 2018 13:05:49 -0700 (PDT)
Received: by mail-wr0-x244.google.com with SMTP id l8so2197362wrg.5 for <ila@ietf.org>; Tue, 13 Mar 2018 13:05:49 -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=iJPVTVHcJ9t1hROJTbxFkiNRPzb2gmzHLAfK4LgW6oc=; b=kwntPVvgi/mnmTvJmqiKKUK+fXeOLh0JghoIKvP1Njv6ZUlmFHjoD7Q5biczQ33cZZ rwypfXDtha4vZU52r8TZBS8l2OHUfscbO8vST+Ql+MxBGeAIs3vhA3FNCY/4xAFl2sH9 cDeuAH4BsCoFXtY7wURKEy7jRiMuwJO/MiZV1WCxLjd0aKwgPmFf8LgHk70NUHJGz/SN 9L0qsLvccoRLGVkC7koECDMtd/+nRHuXvBNUsxStY2Yv8+12nUQKLw8M0e79jxKhjBkX 4E2dd+mKAbE90K9JCz+RrLCw374PfMqBZRSLUBOSMgj31iJYN+UUhcM6KW15z7piSja9 OSAg==
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=iJPVTVHcJ9t1hROJTbxFkiNRPzb2gmzHLAfK4LgW6oc=; b=TJwH9OLTn854lBcSfp5phAwC5IX+q9afXohPbI7LiHRXGTkY4XNFHD8Zt/p65CWWTl oy+n3FaOvYfdi2BNfPcEHfO9SEQOxVmzC5nlXUFtl/CpqL4Y2P6qi63J92SZzEk8U6A6 bdFnQuDAF7C27fYWQdBtBi/yFIVOUEukN+1Eh+f4/5HF+hyE3oGeqlSuL3nv0J5ohTud v+yGGAriaOJsfhtZa0Jm8M7d7C/QgIFkn5DT2OtQ4fFZsLUNfQVLuZq1pUW0waaDY7To DjLEqnwICltDwPqLWmB6an0QTIN8DMWN7+wC59HsESxIPH1hKVjidopWgaUy4qL2oGlx HHgQ==
X-Gm-Message-State: AElRT7HPS6Rg3KKYJxGOKtofWfS9xUYtqN2UF0mulS8k44A0cE9VjNjA nKweBG3ctpj2ck7SsZXa5x66Hf6iBAKmMhjEBH1PKw==
X-Google-Smtp-Source: AG47ELuJSQmnq9dc1kC9i0vVfVoGuryQwWwhagGtGC1S5k7b2vg9EQrnBmGNvjDG21wZAooMclM4x8A0flafIHUV/z8=
X-Received: by 10.223.146.230 with SMTP id 93mr1595816wrn.241.1520971547675; Tue, 13 Mar 2018 13:05:47 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.135.74 with HTTP; Tue, 13 Mar 2018 13:05:47 -0700 (PDT)
In-Reply-To: <F920CAE2-9042-41DF-B013-E8FE6F891596@cisco.com>
References: <F1093230-C087-4168-9C5F-8DA7AB677677@cisco.com> <CAPDqMer58nxEixtH=JuZh9WgM0xKkEQYEjwZ6zg3wTjD76gOHQ@mail.gmail.com> <F920CAE2-9042-41DF-B013-E8FE6F891596@cisco.com>
From: Tom Herbert <tom@quantonium.net>
Date: Tue, 13 Mar 2018 13:05:47 -0700
Message-ID: <CAPDqMeriMzM82-R-JOgx4zuqJTk2YOoBaWV_58no2V8yPas9QA@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/ila/z95IueCWuWlNYjOq30saan4fYjg>
Subject: Re: [Ila] LISP for ILA
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, 13 Mar 2018 20:05:53 -0000
On Tue, Mar 13, 2018 at 12:28 PM, Alberto Rodriguez Natal (natal) <natal@cisco.com> wrote: > Hi Tom, > > Apologies for the delayed response. Thanks for your time reading the draft and for the feedback. See some comments inline. > > On 3/5/18, 4:42 PM, "Tom Herbert" <tom@quantonium.net> wrote: > > Thanks for posting the draft! > > Overall, I think the approach straightforward, and it's very nice that > there is no change required to the ILA architecture. > > I have some concerns about the LISP control plane in terms of > DOSability and scalability. Btw, LISP is not in Linux kernel because > of concerns about DOSability, so there was some prior discussion on > this topic in related mailing lists, > > From the draft: "When an ILA-N has to send traffic towards a remote > Identifier for which it does not have the associated Locator, it has > to obtain it first from a MS." > > This is not actually true. The forwarding cache in the ILA-N is a > routing optimization, if there is no entry on the cache then the > packet is forwarded. If it needs to be transformed then that will be > done by an ILA-R in the path. Until the cache is populated the routing > might be sub-optimal but packets still flow. > > As you point below, we're not saying otherwise in the draft. Sending the traffic to an ILA-R while the mapping is being retrieved is certainly an option. We'll update the text to be clearer on this. > > 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. > If the map request is sent and the packet is forwarded, that means > that a packet received at the ILA-N can generate two packets to be > forwarded in the network. An obvious DOS attack is for a host to send > random to destinations in the network to try to generate cache misses. > Section 8.2 discusses this, but the solution to implement heavy > hitters counters is not detailed. It would be nice to see more detail > how this would work and how it will mitigate the DOS attack. > > Heavy hitters counters are a well-known technique to mitigate DOS attacks in the data-plane (used not only in LISP). There are several papers on that in the literature, see [1] for a recent example. Regarding LISP in particular, you can find some research on the modeling of the LISP map-cache in [2][3]. Following that work, we did some designs on how to apply heavy hitters counters to the LISP map-cache back in the day. We'll try to make that research also available. As they say, the devil is in the details... :-) > > 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! Tom > > "LISP as defined in [I-D.ietf-lisp-rfc6833bis] runs over a UDP > transport, however the exact same signaling can be used over a TCP > transport without affecting the protocol operation." > > What is the status of TCP support? I believe the trend in datacenter > control protocols is towards TCP and even RPC. Integrated security, > congestion control, authentication, and tooling are strong points in > favor of TCP. Is it reasonable to say that TCP is the preferred > protocol? Can the LISP message easily be converted to RPC (REST, > Thrift, GRPC, ...? > > LISP can run as it is over TCP. It can also be extended with the mechanisms described in [4] when a reliable transport is in place. If TCP makes more sense for your particular scenario, then you can make it your preferred transport. In general, which transport to use will depend on the characteristics of each individual deployment. On you last point, please note that OpenDaylight already supports LISP over REST [5]. > > Looking at the map-reply message format, I am concerned about its > size. By my count, it's 40 bytes to provide one record with one > locator where record and locator are 8 bytes. If we need to scale a > system to billions of nodes this overhead could be an issue even if > it's the control plane. Is there any plan to have a compressed version > of this. For instance ,if there is only one RLOC returned wouldn't the > priorities and weights be useless? > > One thing that we can (and should) discuss is the best way to encode ILA Identifier/Locators into LISP messages. Regarding removing fields from the Map-Reply, I'm unsure that the cost of reducing protocol functionality, increasing signaling machinery and adding parsing complexity is worth saving a few bits. Specially if you are planning to later use an RPC version of the protocol. > > Thanks again for your comments Tom. This is an interesting discussion :) > > Best, > Alberto > > [1] https://arxiv.org/pdf/1611.04825.pdf > [2] https://arxiv.org/pdf/1312.1378.pdf > [3] http://personals.ac.upc.edu/fcoras/publications/2015-fcoras-scalability.pdf > [4] https://tools.ietf.org/html/draft-kouvelas-lisp-map-server-reliable-transport-04 > [5] https://wiki.opendaylight.org/view/OpenDaylight_Lisp_Flow_Mapping:Architecture > >
- [Ila] LISP for ILA Alberto Rodriguez Natal (natal)
- Re: [Ila] LISP for ILA Tom Herbert
- Re: [Ila] LISP for ILA Dino Farinacci
- Re: [Ila] LISP for ILA Tom Herbert
- Re: [Ila] LISP for ILA Dino Farinacci
- Re: [Ila] LISP for ILA Templin, Fred L
- Re: [Ila] LISP for ILA Alberto Rodriguez Natal (natal)
- Re: [Ila] LISP for ILA Alberto Rodriguez Natal (natal)
- Re: [Ila] LISP for ILA Dino Farinacci
- Re: [Ila] LISP for ILA Tom Herbert
- Re: [Ila] LISP for ILA Alberto Rodriguez Natal (natal)
- Re: [Ila] LISP for ILA Alberto Rodriguez Natal (natal)
- Re: [Ila] LISP for ILA Tom Herbert
- Re: [Ila] LISP for ILA Alberto Rodriguez Natal (natal)
- Re: [Ila] [lisp] LISP for ILA Florin Coras
- Re: [Ila] [lisp] LISP for ILA Tom Herbert
- Re: [Ila] [lisp] LISP for ILA Richard Li
- Re: [Ila] [lisp] LISP for ILA Tom Herbert
- Re: [Ila] [lisp] LISP for ILA Tom Herbert
- Re: [Ila] [lisp] LISP for ILA Dino Farinacci
- Re: [Ila] [lisp] LISP for ILA Tom Herbert
- Re: [Ila] [lisp] LISP for ILA Dino Farinacci
- Re: [Ila] [lisp] LISP for ILA Tom Herbert
- Re: [Ila] [lisp] LISP for ILA Dino Farinacci
- Re: [Ila] [lisp] LISP for ILA Paul Vinciguerra
- Re: [Ila] [lisp] LISP for ILA Tom Herbert
- Re: [Ila] [lisp] LISP for ILA Dino Farinacci
- Re: [Ila] [lisp] LISP for ILA Dino Farinacci
- Re: [Ila] [lisp] LISP for ILA Uma Chunduri
- Re: [Ila] [lisp] LISP for ILA Tom Herbert
- Re: [Ila] [lisp] LISP for ILA Dino Farinacci
- Re: [Ila] [lisp] LISP for ILA Dino Farinacci
- Re: [Ila] [lisp] LISP for ILA Uma Chunduri
- Re: [Ila] [lisp] LISP for ILA Tom Herbert
- Re: [Ila] [lisp] LISP for ILA Uma Chunduri
- Re: [Ila] [lisp] LISP for ILA - scaling Joel M. Halpern
- Re: [Ila] [lisp] LISP for ILA - scaling Alberto Rodriguez-Natal
- Re: [Ila] [lisp] LISP for ILA - scaling Dino Farinacci
- Re: [Ila] [lisp] LISP for ILA - scaling jmh.direct