Re: [lisp] [Ila] LISP for ILA
Richard Li <renwei.li@huawei.com> Wed, 14 March 2018 05:46 UTC
Return-Path: <renwei.li@huawei.com>
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 E58EF126BF3; Tue, 13 Mar 2018 22:46:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.23
X-Spam-Level:
X-Spam-Status: No, score=-4.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
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 Bprrgjnwc6Qf; Tue, 13 Mar 2018 22:46:35 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 735811243F6; Tue, 13 Mar 2018 22:46:35 -0700 (PDT)
Received: from lhreml702-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 52564E00B5CAA; Wed, 14 Mar 2018 05:46:31 +0000 (GMT)
Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.382.0; Wed, 14 Mar 2018 05:46:32 +0000
Received: from SJCEML521-MBB.china.huawei.com ([169.254.6.91]) by SJCEML701-CHM.china.huawei.com ([169.254.3.93]) with mapi id 14.03.0382.000; Tue, 13 Mar 2018 22:46:29 -0700
From: Richard Li <renwei.li@huawei.com>
To: "fcoras.lists@gmail.com" <fcoras.lists@gmail.com>, "tom@quantonium.net" <tom@quantonium.net>
CC: "ila@ietf.org" <ila@ietf.org>, "lisp@ietf.org" <lisp@ietf.org>
Thread-Topic: [lisp] [Ila] LISP for ILA
Thread-Index: AQHTu1fMV+3J8CSW3UidZrOQcw/s/g==
Date: Wed, 14 Mar 2018 05:46:29 +0000
Message-ID: <etPan.5aa8b735.78abe9cc.989@RENWEIs-iPad>
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>, <CAPDqMepL9-ms8P-zEX2FDe6zWCDkEZrHU4u90Kc7sEQDqi0=bg@mail.gmail.com>
In-Reply-To: <CAPDqMepL9-ms8P-zEX2FDe6zWCDkEZrHU4u90Kc7sEQDqi0=bg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: multipart/alternative; boundary="_000_etPan5aa8b73578abe9cc989RENWEIsiPad_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/7Z5mhbBAQgy93ahxWtITVl7bGyQ>
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: Wed, 14 Mar 2018 05:46:38 -0000
》 enlightening or convincing. I am really hoping we can get something 》more concrete for dealing with DOS threats in a control plane for ILA. Isn’t DOS a data plane problem? Richard From: Tom Herbert To: Florin Coras; Cc: ila@ietf.org; lisp@ietf.org; Subject: Re: [lisp] [Ila] LISP for ILA Time: 2018-03-13 22:25:44 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. > ILA-Rs contain the all the mappings for the shard the service. If they don't have a mapping for a packet, then the packet is dropped. > 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. > Okay, but I still don't know where the details and analysis of these solutions are. It's not enough to simply say that rate limiting is the solution to the DOS threat. I looked at RFC7835, for instance, which gives a nice analysis of the threat, but the suggested mitigations are "careful deployment and configuration" and "Systematically applying filters and rate limitation"-- that guidance is not particularly enlightening or convincing. I am really hoping we can get something more concrete for dealing with DOS threats in a control plane for ILA. 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 > > _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
- [lisp] LISP for ILA Alberto Rodriguez Natal (natal)
- Re: [lisp] [Ila] LISP for ILA Tom Herbert
- Re: [lisp] [Ila] LISP for ILA Dino Farinacci
- Re: [lisp] [Ila] LISP for ILA Tom Herbert
- Re: [lisp] [Ila] LISP for ILA Dino Farinacci
- Re: [lisp] LISP for ILA Templin, Fred L
- Re: [lisp] [Ila] LISP for ILA Alberto Rodriguez Natal (natal)
- Re: [lisp] [Ila] LISP for ILA Alberto Rodriguez Natal (natal)
- Re: [lisp] [Ila] LISP for ILA Dino Farinacci
- Re: [lisp] [Ila] LISP for ILA Tom Herbert
- Re: [lisp] [Ila] LISP for ILA Alberto Rodriguez Natal (natal)
- Re: [lisp] [Ila] LISP for ILA Alberto Rodriguez Natal (natal)
- Re: [lisp] [Ila] LISP for ILA Tom Herbert
- Re: [lisp] [Ila] LISP for ILA Alberto Rodriguez Natal (natal)
- Re: [lisp] [Ila] LISP for ILA Florin Coras
- Re: [lisp] [Ila] LISP for ILA Tom Herbert
- Re: [lisp] [Ila] LISP for ILA Richard Li
- Re: [lisp] [Ila] LISP for ILA Tom Herbert
- Re: [lisp] [Ila] LISP for ILA Tom Herbert
- Re: [lisp] [Ila] LISP for ILA Dino Farinacci
- Re: [lisp] [Ila] LISP for ILA Tom Herbert
- Re: [lisp] [Ila] LISP for ILA Dino Farinacci
- Re: [lisp] [Ila] LISP for ILA Tom Herbert
- Re: [lisp] [Ila] LISP for ILA Dino Farinacci
- Re: [lisp] [Ila] LISP for ILA Paul Vinciguerra
- Re: [lisp] [Ila] LISP for ILA Tom Herbert
- Re: [lisp] [Ila] LISP for ILA Dino Farinacci
- Re: [lisp] [Ila] LISP for ILA Dino Farinacci
- Re: [lisp] [Ila] LISP for ILA Uma Chunduri
- Re: [lisp] [Ila] LISP for ILA Tom Herbert
- Re: [lisp] [Ila] LISP for ILA Dino Farinacci
- Re: [lisp] [Ila] LISP for ILA Dino Farinacci
- Re: [lisp] [Ila] LISP for ILA Uma Chunduri
- Re: [lisp] [Ila] LISP for ILA Tom Herbert
- Re: [lisp] [Ila] LISP for ILA Uma Chunduri
- Re: [lisp] [Ila] LISP for ILA - scaling Joel M. Halpern
- Re: [lisp] [Ila] LISP for ILA - scaling Alberto Rodriguez-Natal
- Re: [lisp] [Ila] LISP for ILA - scaling Dino Farinacci
- Re: [lisp] [Ila] LISP for ILA - scaling jmh.direct