From nobody Tue Oct 4 16:02:44 2016 Return-Path: X-Original-To: ideas@ietfa.amsl.com Delivered-To: ideas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B2671294C9 for ; Tue, 4 Oct 2016 16:02:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 U4eiwBoFfueQ for ; Tue, 4 Oct 2016 16:02:41 -0700 (PDT) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (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 3AA271294F6 for ; Tue, 4 Oct 2016 16:02:41 -0700 (PDT) Received: by mail-io0-x229.google.com with SMTP id q192so3900968iod.0 for ; Tue, 04 Oct 2016 16:02:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=2QgqAOWBgBg/EZ3f/n91YBnmJtatSnN8K/4KzFSc69Y=; b=vFN+qilPMM7h4Dw8N1RmyZDHra+b9vd2mb9GCpAMMyL8ToXGLS4gDebwHNlbwusBiA HFdRVLIQ+rHdQcFnyVmrdP8A2g22au9S3/8m+BpIA831kaTnLddIi7+EJbdnUYKTvMCI URoYHThoZHe74L9FDeC/5nadh8zSWn5m3wUpZDOd8U5puY83R6zitTXwh5eTHUPzE330 3olFL9aOzcblK6w3elnSP0uiMcT6rlkZOZjNtVMhqrerho0ZkVAA0+z9pc7aeq2jLOmw RkMies61tgRDsxTlSZKgb92T5De40f5GFAOWXs2zbVVV2Guik+jl9dfGrjpTV3qzQaUs yhpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=2QgqAOWBgBg/EZ3f/n91YBnmJtatSnN8K/4KzFSc69Y=; b=dgQM/GtHez5Q2xckAFJ029CIr/G+FMKn3gdy4f8e66LOcp/9RuReTBVuOUiasutQ6m bONI+Mos+X7P15hJTuGRa1tF0/yjLi3u7Mh4G2Fxy87ZuTXmgPhgRCRj3y9KVAIMqXAU InEjg2+BPWq9pQt7+erb2/LTGkH8xEl0SkL4hcJAx/wxqS8QYmbymbzaEl56FAqG6Egg ddeDF4mWqNsaRWFYv81/YUhi2kE2KKrmcgq6hdBHzpLhqCRmtyEK/Jr8BfeZCqd2GSn9 vt1NayiJQZEdfeq21HgC9lJwjueNg84IBDkTZ4zJg2HZeMCaQxKIOFwMInmAZMBZzooa xrcQ== X-Gm-Message-State: AA6/9Rk0+8uwKveghv2ZiaT3I/QhGnY6Clwb20xrQZIHYE6EFpSrpRqWbNaLNeU0IRw/jR+hHRSj+vNxmMZI7g== X-Received: by 10.107.39.76 with SMTP id n73mr7817743ion.180.1475622160346; Tue, 04 Oct 2016 16:02:40 -0700 (PDT) MIME-Version: 1.0 From: Kiran Makhijani Date: Tue, 04 Oct 2016 23:02:30 +0000 Message-ID: To: ideas@ietf.org Content-Type: multipart/alternative; boundary=001a11404962b0b45a053e120e30 Archived-At: Subject: [Ideas] Mobility usecase draft-padma-ideas-problem-statement-00.txt X-BeenThere: ideas@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussions relating to the development, clarification, and implementation of control-plane infrastructures and functionalities in ID enabled networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2016 23:02:42 -0000 --001a11404962b0b45a053e120e30 Content-Type: text/plain; charset=UTF-8 Hello authors, +1 on the problem statement. I think a uniform approach to mapping system framework is very much needed. But if it is ID specific there are many more functionalities related to Identity in the networks than just the mapping systems. Is the scope only limited to mapping function aspects? I also have some questions in the mobility section. - In 7.1.1, "we assume that ID functionality is handled within the network and is transparent to the UEs or hosts." What kind of ID functionality is being assumed here? - Figure in 7.1.1 assumes that MGW is only required for mobile networks. Are you saying that Host1 and Host2 are not ID enabled and IDs are only mappable in mobile networks. So, if UE does not need mobility, it need not go through MGW? - Can I assume that functional block "Mapping System" is missing from figure? OR is it not same as the MGW? 1. The new carrier provides the full locator (mapping to Base_station2) and the MGW sends directly to that locator - Not sure what you said in this part and the lines that followed in 7.1.2. Could you explain what is full locator (vs just locator) and only significant in inter-provider case? a UE can move from one base station to other in single provider network too. Why wont you need 'full locator' there? Thanks Kiran -- Kiran --001a11404962b0b45a053e120e30 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello authors,=C2=A0
+1 on the problem statement. I th= ink a uniform approach to mapping system framework is very much needed.=C2= =A0
But =C2=A0if it is ID specific there are many more functional= ities related to Identity in the networks than just the mapping systems. Is= the scope only limited to mapping function aspects?

I a= lso have some questions in the mobility section.
- In 7.1.1= , "we=C2=A0=C2=A0assume that ID functionality is handled within th= e network and is transparent to the UEs or hosts."
What kind of ID functionality is being as= sumed here?=C2=A0
- F<= /span>igure in 7.1.1 assumes that MGW is only required for mobile networks.= Are you saying that Host1 and Host2 are not ID enabled and IDs are only ma= ppable in mobile networks. So, if UE does not need mobility, it need not go= through MGW?
- Can I assume that functional block "Mapping = System" is missing from figure? OR is it not same as the MGW?

1.  The new carrier pro=
vides the full locator (mapping to
       Base_station2) and the MGW sends directly to that locator
- Not sure what you said in this part and the lines that followed in = 7.1.2. Could you explain what is full locator (vs just locator) and only si= gnificant in inter-provider case? a UE can move from one base station to ot= her in single provider network too. Why wont you need 'full locator'= ; there?

Thanks
Kiran


--
Kiran
--001a11404962b0b45a053e120e30-- From nobody Fri Oct 28 16:26:53 2016 Return-Path: X-Original-To: ideas@ietfa.amsl.com Delivered-To: ideas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6070F129435 for ; Fri, 28 Oct 2016 16:26:52 -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=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.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 VfrNxj5Wquw5 for ; Fri, 28 Oct 2016 16:26:50 -0700 (PDT) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (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 659631295F7 for ; Fri, 28 Oct 2016 16:26:50 -0700 (PDT) Received: by mail-qk0-x230.google.com with SMTP id v138so14363100qka.0 for ; Fri, 28 Oct 2016 16:26:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=Z0BteAuVP20fkNlqv8m8OvHmLEyIeI5+Hbdukala8QU=; b=bhcobW5M+4kvJsuImLoycFKTASElCsaRq8CFPqfkmNTTF/yPnxmMc3Q5uHoHFZPb49 rWxHhBgu0JZ161V0qGbMh6sEw+YkyljG4tFenX+E9KxABYLpv9HqffoWN5sD+hBOa9rr kt6L7nG4p9oAMNikScOdIlq6CcCubMLAMoMn/xGEz3vmyFoUsoVOlyxp9RmNF4p5CY++ FgYhildm+rPjlyfKobK+SbFRJOpl6j8BYR6M7LBLcycb00g/2IzvVyWL54ssMz2LkUs6 QxDQCcQFa5TV5lLqCGma/1GUpyO2zozHMDEqrEncb/phD3XchNpRLtw97vzaq0AZnGAI Zi7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=Z0BteAuVP20fkNlqv8m8OvHmLEyIeI5+Hbdukala8QU=; b=c4jh3NPvaY58D3RLcaSZwtLHax/WbaGv+r9VxBSAbt9GubWIZq/cWEWa8uKIdgT6iM y7Kzp1vuzeoC6MR+i9JvGev1hGgsE6hLnPDkNo4A9wuj8+D/iSPjQbyOXskAxm1OoYLu zIAe4Uydjqnp5IMIl0QB8sWevxcyqI1VMyBvItSvOYXw4sfhoJ9kAxI9uSLuouFgB6q9 E8SKh+pkGB+HT/ze474cSzaB2tnwmAfm6tuge5QXDWSx0NjjvIZ86rie4vYAjVmepd4s oyfdN65QJHlNWKZTwbhwPR4KXU6mu694AX6yK/HDI/V7AtN9ogyN3ebxEjRbTdNy1mtH XoJw== X-Gm-Message-State: ABUngveQXL3r/W0VzM45EuPNDPu217MTWM5aPSEPWDOVPUuxGgIgbTjicKBa0FmrpLWixhw7z2E/H0CfnSSzwA== X-Received: by 10.55.41.39 with SMTP id p39mr13081895qkh.245.1477697209316; Fri, 28 Oct 2016 16:26:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.44.71 with HTTP; Fri, 28 Oct 2016 16:26:48 -0700 (PDT) In-Reply-To: References: <147760701595.24654.9061600670227862705.idtracker@ietfa.amsl.com> From: Tom Herbert Date: Fri, 28 Oct 2016 16:26:48 -0700 Message-ID: To: ideas@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [Ideas] Fwd: New Version Notification for draft-herbert-nvo3-ila-03.txt X-BeenThere: ideas@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussions relating to the development, clarification, and implementation of control-plane infrastructures and functionalities in ID enabled networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2016 23:26:52 -0000 Hello, I've posted an update to the ILA draft. I would like to request that this draft be taken up as a WG item in inet-area. In Berlin we chatted with the int-area ADs and the conclusion for ILA (this draft) seemed to be that it should be worked in int-area WG. There will be a routing or control plane component that may be appropriate for routing area. Changes from previous version: - Restructured to make the draft more normative. - Addressed several comments from Pierre Pfister and others - Tried to make the description more generic and less datacenter virtualization specific (eliminated references to nvo3 specific terms) - Supporting material has been moving to - Added more detail in addressing diagrams and description We are also updating the ILA mobility draft for that effort. Comments on this draft are greatly appreciated. Thanks, Tom ---------- Forwarded message ---------- From: Date: Thu, Oct 27, 2016 at 3:23 PM Subject: New Version Notification for draft-herbert-nvo3-ila-03.txt To: Tom Herbert A new version of I-D, draft-herbert-nvo3-ila-03.txt has been successfully submitted by Tom Herbert and posted to the IETF repository. Name: draft-herbert-nvo3-ila Revision: 03 Title: Identifier-locator addressing for IPv6 Document date: 2016-10-27 Group: Individual Submission Pages: 38 URL: https://www.ietf.org/internet-drafts/draft-herbert-nvo3-ila-03.txt Status: https://datatracker.ietf.org/doc/draft-herbert-nvo3-ila/ Htmlized: https://tools.ietf.org/html/draft-herbert-nvo3-ila-03 Diff: https://www.ietf.org/rfcdiff?url2=draft-herbert-nvo3-ila-03 Abstract: This specification describes identifier-locator addressing (ILA) for IPv6. Identifier-locator addressing differentiates between location and identity of a network node. Part of an address expresses the immutable identity of the node, and another part indicates the location of the node which can be dynamic. Identifier-locator addressing can be used to efficiently implement overlay networks for network virtualization as well as solutions for use cases in mobility. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Fri Oct 28 16:40:12 2016 Return-Path: X-Original-To: ideas@ietfa.amsl.com Delivered-To: ideas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02E9C129638; Fri, 28 Oct 2016 16:40:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.652 X-Spam-Level: X-Spam-Status: No, score=-4.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] 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 M3xDk55AsZmx; Fri, 28 Oct 2016 16:40:07 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65924129429; Fri, 28 Oct 2016 16:40:06 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CZG08931; Fri, 28 Oct 2016 23:40:04 +0000 (GMT) Received: from DFWEML701-CAH.china.huawei.com (10.193.5.175) by lhreml703-cah.china.huawei.com (10.201.5.104) with Microsoft SMTP Server (TLS) id 14.3.235.1; Sat, 29 Oct 2016 00:40:03 +0100 Received: from DFWEML501-MBB.china.huawei.com ([10.193.5.179]) by dfweml701-cah.china.huawei.com ([10.193.5.175]) with mapi id 14.03.0235.001; Fri, 28 Oct 2016 16:39:53 -0700 From: Padmadevi Pillay Esnault To: "ideas@ietf.org" Thread-Topic: Technical plenary: Attacks against the architecture - implications for the Network Mapping System Thread-Index: AQHSMTdVE6o3cYrLi025ADZM5w7QIaC+f2AA Date: Fri, 28 Oct 2016 23:39:52 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.213.48.218] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090206.5813E1D4.011B, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: a923a50355e87759d9a3cbaa3b166bd1 Archived-At: Cc: Padmadevi Pillay Esnault , "lisp@ietf.org" Subject: [Ideas] FW: Technical plenary: Attacks against the architecture - implications for the Network Mapping System X-BeenThere: ideas@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussions relating to the development, clarification, and implementation of control-plane infrastructures and functionalities in ID enabled networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2016 23:40:09 -0000 VGhlIHJlY2VudCBEZW5pYWwtb2Ytc2VydmljZSBhdHRhY2tzIGlzIGEgc2NlbmFyaW8gd2Ugc2hv dWxkIGhhdmUgaW4gbWluZCB3aGVuIGJ1aWxkaW5nIHJvYnVzdG5lc3MgaW4gdGhlIG5ldHdvcmsg bWFwcGluZyBzeXN0ZW0uDQpJbiBkcmFmdC1wYWRtYS1pZGVhcy1wcm9ibGVtLXN0YXRlbWVudC0w MC50eHQsIHRoZXJlIGlzIGEgc2VjdGlvbiBvbiBtYXBwaW5nIHN5c3RlbSBzZWN1cml0eSByZXF1 aXJlbWVudHMgdGhhdCBzcGVjaWZpY2FsbHkgY292ZXIgDQp0aGlzIGNhc2UuDQoNCk9uZSBvZiB0 aGUgcXVlc3Rpb25zIHRoYXQgY29tZXMgdG8gbWluZCBpcyB3aGV0aGVyIHRoZSByb2J1c3RuZXNz IG9mIHN1Y2ggYSBtYXBwaW5nIHN5c3RlbSBzaG91bGQgZHJvcC90aHJvdHRsZSByZXNwb25zZXMg d2hlbiBpdCBpcyANCk92ZXJsb2FkZWQgb3Igc2hvdWxkIHdlIGV4cGVjdCBpdCBhbHdheXMgdG8g aGFuZGxlIHRoZSBsb2FkIG5vIG1hdHRlciB3aGF0Pw0KV2hpbGUgd2UgZG8gcHJvcG9zZSB0byBy YXRlLWxpbWl0IHRoZSBtZXNzYWdlcyBpbiB0aGUgcHJvYmxlbSBzdGF0ZW1lbnQsIGlzbid0IHRo aXMgcGxheWluZyBpbnRvIHRoZSBoYW5kcyBvZiB0aGUgYXR0YWNrZXJzPw0KDQpSZXF1ZXN0aW5n IGZlZWRiYWNrIGZyb20gdGhlIGxpc3QgYW5kIGNjaW5nIHdnIHdpdGggZXhwZXJ0aXNlIGluIHRo ZSBhcmVhIG9yIGludGVyZXN0IGluIG1hcHBpbmcgc3lzdGVtIHRlY2hub2xvZ3kuDQoNClRoYW5r cyBpbiBhZHZhbmNlDQpQYWRtYQ0KDQpCZWxvdyBhbiBleGNlcnB0IGZyb20gdGhlIGRyYWZ0DQo2 LjQuICBNYXBwaW5nIFN5c3RlbSBTZWN1cml0eQ0KDQogICBUaGUgc2VjdXJlIG1hcHBpbmcgc3lz dGVtIG11c3QgaGF2ZSB0aGUgZm9sbG93aW5nIHJlcXVpcmVtZW50czoNCg0KICAgMS4gIFRoZSBj b21wb25lbnRzIG9mIHRoZSBtYXBwaW5nIHN5c3RlbSBuZWVkIHRvIGJlIHJvYnVzdCBhZ2FpbnN0 DQogICAgICAgZGlyZWN0IGFuZCBpbmRpcmVjdCBhdHRhY2tzLiAgSWYgYW55IGNvbXBvbmVudCBp cyBhdHRhY2tlZCwgdGhlDQogICAgICAgcmVzdCBvZiB0aGUgc3lzdGVtIHNob3VsZCBhY3Qgd2l0 aCBpbnRlZ3JpdHkgYW5kIHNjYWxlIGFuZCBvbmx5DQogICAgICAgdGhlIGluZm9ybWF0aW9uIGFz c29jaWF0ZWQgd2l0aCB0aGUgY29tcHJvbWlzZWQgY29tcG9uZW50IGlzIG1hZGUNCiAgICAgICB1 bmF2YWlsYWJsZS4NCg0KICAgMi4gIFRoZSBhZGRpdGlvbiBhbmQgcmVtb3ZhbCBvZiBjb21wb25l bnRzIG9mIHRoZSBtYXBwaW5nIHN5c3RlbSBtdXN0DQogICAgICAgYmUgcGVyZm9ybWVkIGluIGEg c2VjdXJlIG1hdHRlciBzbyBhcyB0byBub3QgdmlvbGF0ZSB0aGUNCiAgICAgICBpbnRlZ3JpdHkg YW5kIG9wZXJhdGlvbiBvZiB0aGUgc3lzdGVtIGFuZCBzZXJ2aWNlIGl0IHByb3ZpZGVzLg0KDQog ICAzLiAgVGhlIGluZm9ybWF0aW9uIHJldHVybmVkIGJ5IGNvbXBvbmVudHMgb2YgdGhlIG1hcHBp bmcgc3lzdGVtDQogICAgICAgbmVlZHMgdG8gYmUgYXV0aGVudGljYXRlZCBhcyB0byBkZXRlY3Qg c3Bvb2ZpbmcgZnJvbQ0KICAgICAgIG1hc3F1ZXJhZGVycy4NCg0KICAgNC4gIEluZm9ybWF0aW9u IHJlZ2lzdGVyZWQgKGJ5IHB1Ymxpc2hlcnMpIHRvIHRoZSBtYXBwaW5nIHN5c3RlbSBtdXN0DQog ICAgICAgYmUgYXV0aGVudGljYXRlZCBzbyB0aGUgcmVnaXN0ZXJpbmcgZW50aXR5IG9yIHRoZSBp bmZvcm1hdGlvbiBpcw0KICAgICAgIG5vdCBzcG9vZmVkLg0KDQogICA1LiAgVGhlIG1hcHBpbmcg c3lzdGVtIG11c3QgYWxsb3cgcmVxdWVzdCBhY2Nlc3MgKGZvciBzdWJzY3JpYmVycykgdG8NCiAg ICAgICBiZSBvcGVuIGFuZCBwdWJsaWMuICBIb3dldmVyLCBpdCBpcyBvcHRpb25hbCB0byBwcm92 aWRlDQogICAgICAgY29uZmlkZW50aWFsaXR5IGFuZCBhdXRoZW50aWNhdGlvbiBvZiB0aGUgcmVx dWVzdGVycyBhbmQgdGhlDQogICAgICAgaW5mb3JtYXRpb24gdGhleSBhcmUgcmVxdWVzdGluZy4N Cg0KICAgNi4gIEFueSBpbmZvcm1hdGlvbiBwcm92aWRlZCBieSBjb21wb25lbnRzIG9mIHRoZSBt YXBwaW5nIHN5c3RlbSBtdXN0DQogICAgICAgYmUgY3J5cHRvZ3JhcGhpY2FsbHkgc2lnbmVkIGJ5 IHRoZSBwcm92aWRlciBhbmQgdmVyaWZpZWQgYnkgdGhlDQogICAgICAgY29uc3VtZXIuDQoNCiAg IDcuICBNZXNzYWdlIHJhdGUtbGltaXRpbmcgYW5kIG90aGVyIGhldXJpc3RpY3MgbXVzdCBiZSBw YXJ0IG9mIHRoZQ0KICAgICAgIGZvdW5kYXRpb25hbCBzdXBwb3J0IG9mIHRoZSBtYXBwaW5nIHN5 c3RlbSB0byBwcm90ZWN0IHRoZSBzeXN0ZW0NCiAgICAgICBmcm9tIGludmFsaWQgb3ZlcmxvYWRl ZCBjb25kaXRpb25zLg0KDQogICA4LiAgVGhlIG1hcHBpbmcgc3lzdGVtIHNob3VsZCBzdXBwb3J0 IHNvbWUgZm9ybSBvZiBwcm92aXNpb25lZA0KICAgICAgIHBvbGljeS4gIEVpdGhlciBpbnRlcm5h bCB0byB0aGUgc3lzdGVtIG9yIHZpYSBtZWNoYW5pc21zIGZvcg0KICAgICAgIHVzZXJzIG9mIHRo ZSBzeXN0ZW0gdG8gZGVzY3JpYmUgcG9saWN5IHJ1bGVzLiAgQWNjZXNzIGNvbnRyb2wNCiAgICAg ICBzaG91bGQgbm90IHVzZSB0cmFkaXRpb25hbCBncmFudWxhci1iYXNlZCBhY2Nlc3MgbGlzdHMg c2luY2UgdGhleQ0KICAgICAgIGRvIG5vdCBzY2FsZSBhbmQgYXJlIGhhcmQgdG8gbWFuYWdlLiAg QnkgdGhlIHVzZSBvZiB0b2tlbi0gb3INCiAgICAgICBrZXktIGJhc2VkIGF1dGhlbnRpY2F0aW9u IG1ldGhvZHMgYXMgd2VsbCBhcyBkZXBsb3lpbmcgbXVsdGlwbGUNCiAgICAgICBpbnN0YW5jZXMg b2YgdGhlIG1hcHBpbmcgc3lzdGVtIHdpbGwgYWxsb3cgYWNjZXB0YWJsZSBwb2xpY3kNCiAgICAg ICBwcm9maWxlcy4gIE1hY2hpbmUgbGVhcm5pbmcgdGVjaG5pcXVlcyBjb3VsZCBhdXRvbWF0ZSB0 aGVzZQ0KICAgICAgIG1lY2hhbmlzbXMuDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N CkZyb206IElFVEYtQW5ub3VuY2UgW21haWx0bzppZXRmLWFubm91bmNlLWJvdW5jZXNAaWV0Zi5v cmddIE9uIEJlaGFsZiBPZiBJRVRGIENoYWlyDQpTZW50OiBGcmlkYXksIE9jdG9iZXIgMjgsIDIw MTYgOToyMSBBTQ0KVG86IElFVEYgQW5ub3VuY2VtZW50IExpc3QNCkNjOiBpZXRmQGlldGYub3Jn DQpTdWJqZWN0OiBUZWNobmljYWwgcGxlbmFyeTogQXR0YWNrcyBhZ2FpbnN0IHRoZSBhcmNoaXRl Y3R1cmUNCg0KVGhlIHRlY2huaWNhbCBwbGVuYXJ5IGluIFNlb3VsIHdpbGwgYmUgYWJvdXQgdGhl IHJlY2VudCBEZW5pYWwtb2YtU2VydmljZQ0KYXR0YWNrcyBpbnZvbHZpbmcgdGhlIHVzZSBvZiBj b21wcm9taXNlZCBvciBtaXNjb25maWd1cmVkIG5vZGVzIG9yIA0K4oCcdGhpbmdz4oCdLCBhbmQg dGhlIGFyY2hpdGVjdHVyYWwgaXNzdWVzIGFzc29jaWF0ZWQgd2l0aCB0aGUgbmV0d29yaw0KYmVp bmcgdnVsbmVyYWJsZSB0byB0aGVzZSBhdHRhY2tzLg0KDQpTZWUNCg0KICBodHRwczovL3d3dy5p ZXRmLm9yZy9ibG9nLzIwMTYvMTAvYXR0YWNrLWFnYWluc3QtdGhlLWFyY2hpdGVjdHVyZS8NCg0K YW5kIGpvaW4gdXMgZm9yIHRoZSBkaXNjdXNzaW9uIG9uIFdlZG5lc2RheSAxNjo0MC0xOToxMCwg Tm92ZW1iZXIgMTYsDQoyMDE2IGVpdGhlciBpbiBwZXJzb24gb3IgcmVtb3RlbHkuIFlvdSBjYW4g cmVnaXN0ZXIgZm9yIHRoZSBtZWV0aW5nIGhlcmU6IA0KDQogIGh0dHBzOi8vd3d3LmlldGYub3Jn L21lZXRpbmcvOTcvaW5kZXguaHRtbA0KDQpKYXJpIEFya2tvLCBJRVRGIENoYWlyDQoNCg== From nobody Fri Oct 28 16:53:25 2016 Return-Path: X-Original-To: ideas@ietfa.amsl.com Delivered-To: ideas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 951D71296D8 for ; Fri, 28 Oct 2016 16:53:23 -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=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.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 AJ4Zgj95zX_g for ; Fri, 28 Oct 2016 16:53:21 -0700 (PDT) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (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 960E11296D7 for ; Fri, 28 Oct 2016 16:53:21 -0700 (PDT) Received: by mail-qk0-x22c.google.com with SMTP id v138so14832980qka.0 for ; Fri, 28 Oct 2016 16:53:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=htptznJ1CRmmdIHNI5iRD/Xl1WWLuMhEW9QHVH4vBe8=; b=BtlKpZ1N/iBp1W3NPe47KrJIj+wWuN5pN89cL46T/WpeD/cWGPuhUghS7Lny6F1Jx1 j/KVOPsgSr3zZMe7qyRRAirUV26sKYe011Lr6yRb/Y5ccN5a4mi8Nn7wDIMIPn4i6SFM 7xS8R0i1qYKhgWQxg0hWfnO4kZU12gch8ALHVceFeqmvsCf7q+9Pmq/oXa2c6vEp6Gju dX0l5qAz0I4GV3wdUpxq9qu4ajXNGAer5AAVN0IJlgJx9q14p60q45Krl1wKMj4pBV9k un+f5dwDnxqAMZ6g85pwD0n23BNCj7l1qiJuKuFfA/mzApD0mjplGb75NcTDhbSPeRSb Jm3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=htptznJ1CRmmdIHNI5iRD/Xl1WWLuMhEW9QHVH4vBe8=; b=B1PfRfoE23NTsRwYWbdeB+CudZ7+qebp9LtnomSrOyDjdRJ0HJ3Vp9rqTU0kkoMmOf Gm27DxmH12s50ynAF9MuCPP6JcTJ5p4qju6TkqkFQTPuyF2JBzaMP5VOBJ32CeKbPRJd 74YR7CqpJCPNT9y1jzMN3y/TMidLkkB91qQe02Hb8AZ+8aXbd3m1w7i8/R28/eJNjCql 429WMv75Bw5G3c19/zDvXn2HzyR1voxqpuOfnnjoSkYWYJoEu3pj+4+pM8EQMZZRUefR sn+pEcAA+Kyo5NOs6BPqJGnxZFJ0ALV2iC+jwVZ3fB48N0EaCKhOi2aneQVqBJYmq817 IoKw== X-Gm-Message-State: ABUngvdROdk+meXpkvJN26K431hX9KiLb6bazIEp11awJKqlQY49KbfkfWQ7/THYd/5FTNyjBomq6TBSBsTFlQ== X-Received: by 10.55.41.39 with SMTP id p39mr13148039qkh.245.1477698800577; Fri, 28 Oct 2016 16:53:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.44.71 with HTTP; Fri, 28 Oct 2016 16:53:20 -0700 (PDT) In-Reply-To: References: From: Tom Herbert Date: Fri, 28 Oct 2016 16:53:20 -0700 Message-ID: To: Kiran Makhijani Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: ideas@ietf.org Subject: Re: [Ideas] Mobility usecase draft-padma-ideas-problem-statement-00.txt X-BeenThere: ideas@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussions relating to the development, clarification, and implementation of control-plane infrastructures and functionalities in ID enabled networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2016 23:53:23 -0000 On Tue, Oct 4, 2016 at 4:02 PM, Kiran Makhijani wrote: > Hello authors, > +1 on the problem statement. I think a uniform approach to mapping system > framework is very much needed. > But if it is ID specific there are many more functionalities related to > Identity in the networks than just the mapping systems. Is the scope only > limited to mapping function aspects? > For the purposes of this I would say that the scope is limited to mapping function aspects. But, even with that scope it is going to be hard to produce a mapping system without having some discussion as to how IDs are generated and managed in the first place (like how do we ensure uniqueness, ID namespaces, etc.). So in the end the scope actually will be pretty broad it we're trying for a general solution. > I also have some questions in the mobility section. > - In 7.1.1, "we assume that ID functionality is handled within the network > and is transparent to the UEs or hosts." > What kind of ID functionality is being assumed here? I'd say this refers to the mapping of location to identifiers. A UE might know its identity and give that do the network, but the mapping, mobility related functions are more likely handled by the network. This pragmatic in that we can't change all UEs (e.g. smart phones) to participate in a new mobility protocol. > - Figure in 7.1.1 assumes that MGW is only required for mobile networks. Are > you saying that Host1 and Host2 are not ID enabled and IDs are only mappable > in mobile networks. So, if UE does not need mobility, it need not go through > MGW? I thinks that's true based on the scalability problem I mentioned above about UEs participating in mobility. Most likely they will live behind a MGW (ILA router in ILA nomenclature) that does mapping and forwarding for mobile nodes. If a MGW doesn't need mobility then it's packets (directed to it) wouldn't need to go through MGW-- it just looks like a non-mobile host at that point. > - Can I assume that functional block "Mapping System" is missing from > figure? OR is it not same as the MGW? > MGW uses mapping system. The mapping system wouldn't be a discrete node in the network. Although there might be devices that just provide resolutions and mapping without implementing gateway functionality (may like an NVA in nvo3 parlance). > 1. The new carrier provides the full locator (mapping to > Base_station2) and the MGW sends directly to that locator > > - Not sure what you said in this part and the lines that followed in 7.1.2. > Could you explain what is full locator (vs just locator) and only > significant in inter-provider case? a UE can move from one base station to > other in single provider network too. Why wont you need 'full locator' > there? > I think we're making a subtle distinction that should probably be spelled out. Consider that after migration UE.A wants to speak to UE.B in a different carrier network. We need an MGW to resolve the address. There's are two possibilities reference here: 1) Two mappings: UE.A sends packet to a local MGW. MGW maps destination to an address of a MGW in the other provider. Packet forwarded to that provider. Received by the MGW at that provider and then a second mapping occurs to get packet to UE.B within that provider. 2) One mapping: UE.A sends packet to a local MGW. The local MGW knows the exact mapping for the address of UE.B in other provider (this is what we meant by full locator). The packet is mapped and forwarded direct to where UE.B without any further mapping. The advantage of #1 is that providers don't need to share as much information. For instance, if UE.B is moving around in the new providers network, UE.A's network doesn't need to know about that. The downside is that it results in more hops and triangular rouitng. Tom > Thanks > Kiran > > > > -- > Kiran > > _______________________________________________ > Ideas mailing list > Ideas@ietf.org > https://www.ietf.org/mailman/listinfo/ideas > From nobody Fri Oct 28 19:08:25 2016 Return-Path: X-Original-To: ideas@ietfa.amsl.com Delivered-To: ideas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C058B129457 for ; Fri, 28 Oct 2016 19:08:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 v7Y2j7w2whoZ for ; Fri, 28 Oct 2016 19:08:22 -0700 (PDT) Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::236]) (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 E81BB12956D for ; Fri, 28 Oct 2016 19:08:21 -0700 (PDT) Received: by mail-pf0-x236.google.com with SMTP id n85so46114406pfi.1 for ; Fri, 28 Oct 2016 19:08:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=jDZ+VJQif2QQVqmATwnfshNDcmYv5nsZJ7t3BGFVuXo=; b=uuWuktvXmwyLvdV2yywcdZy4Ap2EEnOJLeRU/S6JSkZXxqsaYLcESxAge6zPRA46v6 7xCTMPf4vgFWtZAD1gXb01hWXuE4St4hCp/TYOuXuC3g3pGk/PQ9fCTHC5WH+A3Llpog N4fRWSHVOOyQUbMPHzZBfzL2ilausW7wTiE+erE0lAiRALvujfihfFEcE0/kNRNjewA6 ynJAju/t1FUynqHAyT4Wj0ddIe/U8myDW5nPB2y/dDpa6f4I7Ilr5XA+v0NrF7IO4tpk NTPNgIAXsMja4EBFaNPWc2C2LsqWYYD4huBs3WnDMb9oYzb2WuA7IDCUY5VxTWK8QNgJ /oLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=jDZ+VJQif2QQVqmATwnfshNDcmYv5nsZJ7t3BGFVuXo=; b=WCuVAbhqg8/Xwk20FMiPoikHZcbbMcZEHYJcG/RUnMw33J3L0Gc25cE3M/wlFxBLZp lstX9NzHhZT0j2XJMRBFIJ5UDnSUK910zlCTxwwla+78qyAauEvqG0FmouasLgLZpdGw Mgoo5uYNr/dNI+MCfiS+WeGofiQYA/b4oBZvio+nj6HgmtEknqOzTna959ujYxL053WX Tqi1/Em73IVnIOzUqLhTfOJ9j2QwiLSshtaLqfA/8izjuw5cFtwoyKCT4j2rPAKrtTTa 9q+eG5fjIJY5fRLF7eVuuBE363Q8c4opJdBJKXIZF6bZb1MTqeVicVigRm2qwxFJSRmA 6oPg== X-Gm-Message-State: ABUngvcZS6BeJV5h56/l+XygghksLvbMqpa46B+60jwsVfCe4ZsMwmezHDcTm1W0+kddUA== X-Received: by 10.99.221.85 with SMTP id g21mr24627873pgj.121.1477706901544; Fri, 28 Oct 2016 19:08:21 -0700 (PDT) Received: from ?IPv6:2603:3024:151c:55f0:2d14:7dfb:c4db:bbdb? ([2603:3024:151c:55f0:2d14:7dfb:c4db:bbdb]) by smtp.gmail.com with ESMTPSA id e90sm21644660pfd.5.2016.10.28.19.08.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 28 Oct 2016 19:08:21 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Dino Farinacci X-Mailer: iPhone Mail (14B72c) In-Reply-To: Date: Fri, 28 Oct 2016 19:08:20 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Tom Herbert Archived-At: Cc: Kiran Makhijani , ideas@ietf.org Subject: Re: [Ideas] Mobility usecase draft-padma-ideas-problem-statement-00.txt X-BeenThere: ideas@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussions relating to the development, clarification, and implementation of control-plane infrastructures and functionalities in ID enabled networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Oct 2016 02:08:24 -0000 > The advantage of #1 is that providers don't need to share as much > information. For instance, if UE.B is moving around in the new > providers network, UE.A's network doesn't need to know about that. The > downside is that it results in more hops and triangular rouitng. Tom, LISP supports both models but #1 is more popular due to NATs are in the= data path.=20 Dino= From nobody Fri Oct 28 20:15:07 2016 Return-Path: X-Original-To: ideas@ietfa.amsl.com Delivered-To: ideas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 149DD129482; Fri, 28 Oct 2016 20:15:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 yxXB5D4m4eBO; Fri, 28 Oct 2016 20:15:04 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 BBC2B129424; Fri, 28 Oct 2016 20:15:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id ABE0F240F6F; Fri, 28 Oct 2016 20:15:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1477710903; bh=oxlNDvudICIglGfbR/oc+0SsXKYFkKIQ/JbU9EBxnuo=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=YamAHn3j4zXvno7HCQCbr6blqrZMmjb06F3o4rMJX+W8uAkK7hvPlMV6plJinKOVM y1WzkopghOhcKWHcDTG4oW7Z8S+ntd3NRcgHVgy9w02g/g3WBXASA4YsisZeacr2c+ DWcq2varePWEB6LM2jB4hU7N6NOxajlHz1Jrjb9Q= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 1A900240828; Fri, 28 Oct 2016 20:15:03 -0700 (PDT) To: Padmadevi Pillay Esnault , "ideas@ietf.org" References: From: "Joel M. Halpern" Message-ID: <85dd645c-37ca-0839-a175-2fb05539fbf2@joelhalpern.com> Date: Fri, 28 Oct 2016 23:15:28 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "lisp@ietf.org" Subject: Re: [Ideas] [lisp] FW: Technical plenary: Attacks against the architecture - implications for the Network Mapping System X-BeenThere: ideas@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussions relating to the development, clarification, and implementation of control-plane infrastructures and functionalities in ID enabled networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Oct 2016 03:15:06 -0000 There are some preliminary thoughts on overload issues in the security considerations of draft-ietf-lisp-introduction. I will also be curious to see what the presentations at the technical plenary in Seoul have to suggest on the issue, if anything. There probably is more with considering. Yours, Joel On 10/28/16 7:39 PM, Padmadevi Pillay Esnault wrote: > The recent Denial-of-service attacks is a scenario we should have in mind when building robustness in the network mapping system. > In draft-padma-ideas-problem-statement-00.txt, there is a section on mapping system security requirements that specifically cover > this case. > > One of the questions that comes to mind is whether the robustness of such a mapping system should drop/throttle responses when it is > Overloaded or should we expect it always to handle the load no matter what? > While we do propose to rate-limit the messages in the problem statement, isn't this playing into the hands of the attackers? > > Requesting feedback from the list and ccing wg with expertise in the area or interest in mapping system technology. > > Thanks in advance > Padma > > Below an excerpt from the draft > 6.4. Mapping System Security > > The secure mapping system must have the following requirements: > > 1. The components of the mapping system need to be robust against > direct and indirect attacks. If any component is attacked, the > rest of the system should act with integrity and scale and only > the information associated with the compromised component is made > unavailable. > > 2. The addition and removal of components of the mapping system must > be performed in a secure matter so as to not violate the > integrity and operation of the system and service it provides. > > 3. The information returned by components of the mapping system > needs to be authenticated as to detect spoofing from > masqueraders. > > 4. Information registered (by publishers) to the mapping system must > be authenticated so the registering entity or the information is > not spoofed. > > 5. The mapping system must allow request access (for subscribers) to > be open and public. However, it is optional to provide > confidentiality and authentication of the requesters and the > information they are requesting. > > 6. Any information provided by components of the mapping system must > be cryptographically signed by the provider and verified by the > consumer. > > 7. Message rate-limiting and other heuristics must be part of the > foundational support of the mapping system to protect the system > from invalid overloaded conditions. > > 8. The mapping system should support some form of provisioned > policy. Either internal to the system or via mechanisms for > users of the system to describe policy rules. Access control > should not use traditional granular-based access lists since they > do not scale and are hard to manage. By the use of token- or > key- based authentication methods as well as deploying multiple > instances of the mapping system will allow acceptable policy > profiles. Machine learning techniques could automate these > mechanisms. > > > -----Original Message----- > From: IETF-Announce [mailto:ietf-announce-bounces@ietf.org] On Behalf Of IETF Chair > Sent: Friday, October 28, 2016 9:21 AM > To: IETF Announcement List > Cc: ietf@ietf.org > Subject: Technical plenary: Attacks against the architecture > > The technical plenary in Seoul will be about the recent Denial-of-Service > attacks involving the use of compromised or misconfigured nodes or > “things”, and the architectural issues associated with the network > being vulnerable to these attacks. > > See > > https://www.ietf.org/blog/2016/10/attack-against-the-architecture/ > > and join us for the discussion on Wednesday 16:40-19:10, November 16, > 2016 either in person or remotely. You can register for the meeting here: > > https://www.ietf.org/meeting/97/index.html > > Jari Arkko, IETF Chair > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > From nobody Sat Oct 29 08:40:44 2016 Return-Path: X-Original-To: ideas@ietfa.amsl.com Delivered-To: ideas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58DF31293D9; Sat, 29 Oct 2016 08:40:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 HZT1fv0yVvDm; Sat, 29 Oct 2016 08:40:37 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (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 893FD1293EE; Sat, 29 Oct 2016 08:40:37 -0700 (PDT) Received: by mail-qk0-x22d.google.com with SMTP id o68so119844428qkf.3; Sat, 29 Oct 2016 08:40:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qn2qR/N/SoaLCLcUFzo5tt+QT3j+GsYK9/vq7zri1mw=; b=If34HL2ALt+1z6ulgG8bnUNm4UernphmJsiW0xX915Mv8d9SDGShl+ZmjFMHQdfqfM dbuBtJFCeVkDDIX16fL5wENLi+jxWrsYB8qfd2S1q4+Y+YaRpyZoT0+0YyIj/EaQ6aiG fWAHakEzP8tLz+12saadpU6TDS+6G/HdXqn37zjDluxCQt1v2Ojbj5F9R7OXDhKTpAC6 KPwl2yKe1ktYDTOK4HV9MImKD+kKyvy0AwevnmMuqIMEnP9oUqH5SMl+BcJPTq0byG85 ZQL/t2A4PsJq48G2kyj4To+5PNykpP3NfPCcWPjrQ7ZNJhE7wlW0FDrwqjaNWhWxiBtS tTyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=qn2qR/N/SoaLCLcUFzo5tt+QT3j+GsYK9/vq7zri1mw=; b=YCvGiMk/y0uoyeHDYxaoIGVKzDXu0SJWk8iMvJtVs4nHLnuPqhe1c6ZvRheuIySV1n 807bOOuxAAdjf6ciW7SfIX27Jq8sAljrH3eB+YGe6zblcXntmANKDOQuc3K0Q+QIJ/1u HHhLFE5kRFa7J76Iwjkwd5VkawkMnQ+1uTM+4DcP+NJ/ZJ7jUKPJUQcRviKs2xmn5Emj PhSL1jzXPJ+X9NXYhM3vp6ZbZ8xjiWZu4aDpo5WN0qnWrVI9tqfaK+7oifDVmJ9ekbse A9pXtvMX2zRzDs0UpvNIoYsJVGNT8OYy5M/rIfitgd9rGMMy18fmpB1X+ox5egZaoF+n mskQ== X-Gm-Message-State: ABUngveIksmkMYa2IfYu8lAQlFlWD+xcsSw0+8c594n9R+/7IxHVdL2Op/HlgRMugxsRkHYR9hLjbg/zzGNyiA== X-Received: by 10.55.188.193 with SMTP id m184mr15517791qkf.129.1477755636530; Sat, 29 Oct 2016 08:40:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.38.15 with HTTP; Sat, 29 Oct 2016 08:40:36 -0700 (PDT) In-Reply-To: <85dd645c-37ca-0839-a175-2fb05539fbf2@joelhalpern.com> References: <85dd645c-37ca-0839-a175-2fb05539fbf2@joelhalpern.com> From: Padma Pillay-Esnault Date: Sat, 29 Oct 2016 08:40:36 -0700 Message-ID: To: "Joel M. Halpern" Content-Type: multipart/alternative; boundary=94eb2c0430a6c7c167054002cb6d Archived-At: Cc: "ideas@ietf.org" , Padmadevi Pillay Esnault , "lisp@ietf.org" Subject: Re: [Ideas] [lisp] FW: Technical plenary: Attacks against the architecture - implications for the Network Mapping System X-BeenThere: ideas@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussions relating to the development, clarification, and implementation of control-plane infrastructures and functionalities in ID enabled networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Oct 2016 15:40:40 -0000 --94eb2c0430a6c7c167054002cb6d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Joel The security section has the following recommendations for overload issues 1. Rate limit the sending of messages to the mapping system. 2.To improve resiliency and reduce the overall number of messages exchanged, LISP offers the possibility to leak information, such as reachab= ilty of locators, directly into data plane packets 3. Using trustable Map-Servers that strictly respect [RFC6833] and the lightweight authentication mechanism proposed byLISP-Sec [I-D.ietf-lisp-sec] reduces the risk of attacks Here are the potential problems I see with these 1. Rate limiting messages has the same result the DDOS attack was aiming at= . 2. Leaking the information may have consequences for the privacy unless we are using ephemeral EIDs 3. We can trick the system to legitimately make a lot of updates. For example a large number of IDs distributed that keep on registering that they have changed locations frequently and an equally large number of devices trying to access them. There has been a lot of digital ink about IoT devices being vulnerable to be compromised and that the sheer number of devices (several billions) to be the easy target for bonnets. Discussions about use of rfc2728 or how ISP could handle these attacks. It is a difficult problem to solve and in the end we are pushing the responsibility to other entities to do the right thing ... In section 5 of draft-padma-ideas-problem-statement, there is a section in the table which specifically discuss about the structure of IDs and whether we should used them for specific classes or as the Network Mapping system is proposing to attach metadata to ID. I am inclined to think if we can give ID some inherent class which can restrict what these devices can do. Why would a fridge ever try to access a bank account unless something is seriously wrong? In the case of IoT, it would have been possible to drop request from a camera or sensor requesting to map netflix or twitter. With IP addresses, it is difficult to differentiate who is what. Structured IDs allocations or metadata in the NMS may be an opportunity to simplify some of this operational complexity. Thoughts? Padma On Fri, Oct 28, 2016 at 8:15 PM, Joel M. Halpern wrote: > There are some preliminary thoughts on overload issues in the security > considerations of draft-ietf-lisp-introduction. > > I will also be curious to see what the presentations at the technical > plenary in Seoul have to suggest on the issue, if anything. > > There probably is more with considering. > > Yours, > Joel > > > On 10/28/16 7:39 PM, Padmadevi Pillay Esnault wrote: > >> The recent Denial-of-service attacks is a scenario we should have in min= d >> when building robustness in the network mapping system. >> In draft-padma-ideas-problem-statement-00.txt, there is a section on >> mapping system security requirements that specifically cover >> this case. >> >> One of the questions that comes to mind is whether the robustness of suc= h >> a mapping system should drop/throttle responses when it is >> Overloaded or should we expect it always to handle the load no matter >> what? >> While we do propose to rate-limit the messages in the problem statement, >> isn't this playing into the hands of the attackers? >> >> Requesting feedback from the list and ccing wg with expertise in the are= a >> or interest in mapping system technology. >> >> Thanks in advance >> Padma >> >> Below an excerpt from the draft >> 6.4. Mapping System Security >> >> The secure mapping system must have the following requirements: >> >> 1. The components of the mapping system need to be robust against >> direct and indirect attacks. If any component is attacked, the >> rest of the system should act with integrity and scale and only >> the information associated with the compromised component is made >> unavailable. >> >> 2. The addition and removal of components of the mapping system must >> be performed in a secure matter so as to not violate the >> integrity and operation of the system and service it provides. >> >> 3. The information returned by components of the mapping system >> needs to be authenticated as to detect spoofing from >> masqueraders. >> >> 4. Information registered (by publishers) to the mapping system must >> be authenticated so the registering entity or the information is >> not spoofed. >> >> 5. The mapping system must allow request access (for subscribers) to >> be open and public. However, it is optional to provide >> confidentiality and authentication of the requesters and the >> information they are requesting. >> >> 6. Any information provided by components of the mapping system must >> be cryptographically signed by the provider and verified by the >> consumer. >> >> 7. Message rate-limiting and other heuristics must be part of the >> foundational support of the mapping system to protect the system >> from invalid overloaded conditions. >> >> 8. The mapping system should support some form of provisioned >> policy. Either internal to the system or via mechanisms for >> users of the system to describe policy rules. Access control >> should not use traditional granular-based access lists since they >> do not scale and are hard to manage. By the use of token- or >> key- based authentication methods as well as deploying multiple >> instances of the mapping system will allow acceptable policy >> profiles. Machine learning techniques could automate these >> mechanisms. >> >> >> -----Original Message----- >> From: IETF-Announce [mailto:ietf-announce-bounces@ietf.org] On Behalf Of >> IETF Chair >> Sent: Friday, October 28, 2016 9:21 AM >> To: IETF Announcement List >> Cc: ietf@ietf.org >> Subject: Technical plenary: Attacks against the architecture >> >> The technical plenary in Seoul will be about the recent Denial-of-Servic= e >> attacks involving the use of compromised or misconfigured nodes or >> =E2=80=9Cthings=E2=80=9D, and the architectural issues associated with t= he network >> being vulnerable to these attacks. >> >> See >> >> https://www.ietf.org/blog/2016/10/attack-against-the-architecture/ >> >> and join us for the discussion on Wednesday 16:40-19:10, November 16, >> 2016 either in person or remotely. You can register for the meeting here= : >> >> https://www.ietf.org/meeting/97/index.html >> >> Jari Arkko, IETF Chair >> >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp >> >> > _______________________________________________ > Ideas mailing list > Ideas@ietf.org > https://www.ietf.org/mailman/listinfo/ideas > --94eb2c0430a6c7c167054002cb6d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Joel

The security section has the fo= llowing recommendations for overload issues
1. Rate limit the sending of messages to the mapping sys= tem.
2.To improve = resiliency and reduce the overall number of messages exchanged, LISP offers the possibili= ty to leak information, such as reachabilty of locators, directly into data plane packets=
3. = Using trustabl= e Map-Servers that strictly respect [RFC6833] and the lightweight authentication mechanis= m proposed byL= ISP-Sec [I-D.ietf-lisp-sec] reduces the risk of attacks
H= ere are the potential problems I see with these
1. Rate limiting = messages has the same result the DDOS attack was aiming at.
2. Le= aking the information may have consequences for the privacy unless we are u= sing ephemeral EIDs
3. We can trick the system to legitimately ma= ke a lot of updates. For example a large number of IDs distributed that kee= p on registering that they have changed locations frequently and an equally= large number of devices trying to access them.
There has been a lot of digital ink about IoT devices being vul= nerable to be compromised and that the sheer number of devices (several bil= lions) to be the easy target for bonnets.=C2=A0 Discussions about use of rf= c2728 or how ISP could handle these attacks. It is a difficult problem to s= olve and in the end we are pushing the responsibility to other entities to = do the right thing ... =C2=A0

In section 5 of draft-padma-ideas-pr= oblem-statement, there is a section in the table which specifically discuss= about the structure of IDs and whether we should used them for specific cl= asses or as the Network Mapping system is proposing to attach metadata to I= D.

I am inclined to think if we can g= ive ID some inherent class which can restrict what these devices can do. Wh= y would a fridge ever try to access a bank account unless something is seri= ously wrong? In the case of IoT, it would have been possible to drop reques= t from a camera or sensor requesting to map netflix or twitter.=C2=A0
=

With IP addresses, it is difficult to differentiate who= is what.
Structured IDs allocations or metadata in the NMS may b= e an opportunity to simplify some of this operational complexity.

Thoughts?
Padma



On Fri, O= ct 28, 2016 at 8:15 PM, Joel M. Halpern <jmh@joelhalpern.com> wrote:
There are some preliminary tho= ughts on overload issues in the security considerations of draft-ietf-lisp-= introduction.

I will also be curious to see what the presentations at the technical plena= ry in Seoul have to suggest on the issue, if anything.

There probably is more with considering.

Yours,
Joel


On 10/28/16 7:39 PM, Padmadevi Pillay Esnault wrote:
The recent Denial-of-service attacks is a scenario we should have in mind w= hen building robustness in the network mapping system.
In draft-padma-ideas-problem-statement-00.txt, there is a section on m= apping system security requirements that specifically cover
this case.

One of the questions that comes to mind is whether the robustness of such a= mapping system should drop/throttle responses when it is
Overloaded or should we expect it always to handle the load no matter what?=
While we do propose to rate-limit the messages in the problem statement, is= n't this playing into the hands of the attackers?

Requesting feedback from the list and ccing wg with expertise in the area o= r interest in mapping system technology.

Thanks in advance
Padma

Below an excerpt from the draft
6.4.=C2=A0 Mapping System Security

=C2=A0 =C2=A0The secure mapping system must have the following requirements= :

=C2=A0 =C2=A01.=C2=A0 The components of the mapping system need to be robus= t against
=C2=A0 =C2=A0 =C2=A0 =C2=A0direct and indirect attacks.=C2=A0 If any compon= ent is attacked, the
=C2=A0 =C2=A0 =C2=A0 =C2=A0rest of the system should act with integrity and= scale and only
=C2=A0 =C2=A0 =C2=A0 =C2=A0the information associated with the compromised = component is made
=C2=A0 =C2=A0 =C2=A0 =C2=A0unavailable.

=C2=A0 =C2=A02.=C2=A0 The addition and removal of components of the mapping= system must
=C2=A0 =C2=A0 =C2=A0 =C2=A0be performed in a secure matter so as to not vio= late the
=C2=A0 =C2=A0 =C2=A0 =C2=A0integrity and operation of the system and servic= e it provides.

=C2=A0 =C2=A03.=C2=A0 The information returned by components of the mapping= system
=C2=A0 =C2=A0 =C2=A0 =C2=A0needs to be authenticated as to detect spoofing = from
=C2=A0 =C2=A0 =C2=A0 =C2=A0masqueraders.

=C2=A0 =C2=A04.=C2=A0 Information registered (by publishers) to the mapping= system must
=C2=A0 =C2=A0 =C2=A0 =C2=A0be authenticated so the registering entity or th= e information is
=C2=A0 =C2=A0 =C2=A0 =C2=A0not spoofed.

=C2=A0 =C2=A05.=C2=A0 The mapping system must allow request access (for sub= scribers) to
=C2=A0 =C2=A0 =C2=A0 =C2=A0be open and public.=C2=A0 However, it is optiona= l to provide
=C2=A0 =C2=A0 =C2=A0 =C2=A0confidentiality and authentication of the reques= ters and the
=C2=A0 =C2=A0 =C2=A0 =C2=A0information they are requesting.

=C2=A0 =C2=A06.=C2=A0 Any information provided by components of the mapping= system must
=C2=A0 =C2=A0 =C2=A0 =C2=A0be cryptographically signed by the provider and = verified by the
=C2=A0 =C2=A0 =C2=A0 =C2=A0consumer.

=C2=A0 =C2=A07.=C2=A0 Message rate-limiting and other heuristics must be pa= rt of the
=C2=A0 =C2=A0 =C2=A0 =C2=A0foundational support of the mapping system to pr= otect the system
=C2=A0 =C2=A0 =C2=A0 =C2=A0from invalid overloaded conditions.

=C2=A0 =C2=A08.=C2=A0 The mapping system should support some form of provis= ioned
=C2=A0 =C2=A0 =C2=A0 =C2=A0policy.=C2=A0 Either internal to the system or v= ia mechanisms for
=C2=A0 =C2=A0 =C2=A0 =C2=A0users of the system to describe policy rules.=C2= =A0 Access control
=C2=A0 =C2=A0 =C2=A0 =C2=A0should not use traditional granular-based access= lists since they
=C2=A0 =C2=A0 =C2=A0 =C2=A0do not scale and are hard to manage.=C2=A0 By th= e use of token- or
=C2=A0 =C2=A0 =C2=A0 =C2=A0key- based authentication methods as well as dep= loying multiple
=C2=A0 =C2=A0 =C2=A0 =C2=A0instances of the mapping system will allow accep= table policy
=C2=A0 =C2=A0 =C2=A0 =C2=A0profiles.=C2=A0 Machine learning techniques coul= d automate these
=C2=A0 =C2=A0 =C2=A0 =C2=A0mechanisms.


-----Original Message-----
From: IETF-Announce [mailto:ietf-announce-bounces@ietf.org] On Behalf Of = IETF Chair
Sent: Friday, October 28, 2016 9:21 AM
To: IETF Announcement List
Cc: ietf@ietf.org Subject: Technical plenary: Attacks against the architecture

The technical plenary in Seoul will be about the recent Denial-of-Service attacks involving the use of compromised or misconfigured nodes or
=E2=80=9Cthings=E2=80=9D, and the architectural issues associated with the = network
being vulnerable to these attacks.

See

=C2=A0 https://www.ietf.org/blog/2= 016/10/attack-against-the-architecture/

and join us for the discussion on Wednesday 16:40-19:10, November 16,
2016 either in person or remotely. You can register for the meeting here:
=C2=A0 https://www.ietf.org/meeting/97/index.html=

Jari Arkko, IETF Chair

_______________________________________________
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp


_______________________________________________
Ideas mailing list
Ideas@ietf.org
https://www.ietf.org/mailman/listinfo/ideas

--94eb2c0430a6c7c167054002cb6d-- From nobody Sat Oct 29 09:02:49 2016 Return-Path: X-Original-To: ideas@ietfa.amsl.com Delivered-To: ideas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C62541295C5; Sat, 29 Oct 2016 09:02:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 nIVOySnB4gsS; Sat, 29 Oct 2016 09:02:42 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 C69B6129536; Sat, 29 Oct 2016 09:02:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id AE3A624261A; Sat, 29 Oct 2016 09:02:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1477756962; bh=xuv/Z1tRrNCqH3or3+O3L+Tzou5w021N7XJEdRNXiRU=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=HBiOwE77BquAN9RoYDlXKnI8ryhMMyfJ1tVtWWgyAQ54ExXZzu9ki3BrJgT+VrQi7 BDWFYIsptcI10cO8Jfy+SaprQbtIWADjqI5vA4hmH/L7E0+oAHz0wbBG0rj/9TcvhE 3CobZvPOODCZp8hE+ynrtLswJ7Wl3LzN6jSf65fY= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id ECE92241298; Sat, 29 Oct 2016 09:02:41 -0700 (PDT) To: Padma Pillay-Esnault References: <85dd645c-37ca-0839-a175-2fb05539fbf2@joelhalpern.com> From: "Joel M. Halpern" Message-ID: <9147701f-8395-7b2e-d370-111200ce2656@joelhalpern.com> Date: Sat, 29 Oct 2016 12:03:13 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "ideas@ietf.org" , Padmadevi Pillay Esnault , "lisp@ietf.org" Subject: Re: [Ideas] [lisp] FW: Technical plenary: Attacks against the architecture - implications for the Network Mapping System X-BeenThere: ideas@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussions relating to the development, clarification, and implementation of control-plane infrastructures and functionalities in ID enabled networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Oct 2016 16:02:45 -0000 Remember that with LISP, the mapping system is somewhat insulated due to the fact that queries are only accepted from MR, not directly from anything claiming to be an ITR. And it is normally expected that the association between mapping system internals and MR/MS is authenticated (otherwise there are lots of other issues.) This does not provide complete protection, as there are many situations where the MR does not have an authentication relationship with the querying ITR. Having said that, it can be noted that in many cases there is such a relationship. Such a relationship prevents a random outside attack. Even when there is no such relationship, and even if the MR does not rate limit, an effective DoS attack would have to target multiple MR to cause significant difficulty. Also, it seems to me that if all you want to do is break a single MR, then rate limiting is irrelevant. In the absence of limits on who can query a specific MR, you can bombard it with more queries than it can handle and you will take it out of service. So a rate limit helps the system while harming the MR capability only slightly. Trying to infer whether an entity is allowed to undertake specific operations without authentication, using information such as the IP address, seems fraught with failure. Trying to classify all entities into types (onotology?) seems unlikely to produce correct results, as classes are not cleanly defined. As I said, I look forward to the technical presentation at the IETF meeting to see if they have any ideas that can help. Yes, there is work to be done. Putting authorization into the identity seems to be asking for trouble. Yours, Joel On 10/29/16 11:40 AM, Padma Pillay-Esnault wrote: > Hi Joel > > The security section has the following recommendations for overload issues > 1. Rate limit the sending of messages to the mapping system. > 2.To improve resiliency and reduce the overall number of > messagesexchanged, LISP offers the possibility to leak information, such > as reachabilty of locators, directly into data plane packets > 3. Using trustable Map-Servers that strictly respect [RFC6833] and the > lightweight authentication mechanism proposed byLISP-Sec > [I-D.ietf-lisp-sec] reduces the risk of attacks > > Here are the potential problems I see with these > 1. Rate limiting messages has the same result the DDOS attack was aiming at. > 2. Leaking the information may have consequences for the privacy unless > we are using ephemeral EIDs > 3. We can trick the system to legitimately make a lot of updates. For > example a large number of IDs distributed that keep on registering that > they have changed locations frequently and an equally large number of > devices trying to access them. > > There has been a lot of digital ink about IoT devices being vulnerable > to be compromised and that the sheer number of devices (several > billions) to be the easy target for bonnets. Discussions about use of > rfc2728 or how ISP could handle these attacks. It is a difficult problem > to solve and in the end we are pushing the responsibility to other > entities to do the right thing ... > > In section 5 of draft-padma-ideas-problem-statement, there is a section > in the table which specifically discuss about the structure of IDs and > whether we should used them for specific classes or as the Network > Mapping system is proposing to attach metadata to ID. > > I am inclined to think if we can give ID some inherent class which can > restrict what these devices can do. Why would a fridge ever try to > access a bank account unless something is seriously wrong? In the case > of IoT, it would have been possible to drop request from a camera or > sensor requesting to map netflix or twitter. > > With IP addresses, it is difficult to differentiate who is what. > Structured IDs allocations or metadata in the NMS may be an opportunity > to simplify some of this operational complexity. > > Thoughts? > Padma > > > > On Fri, Oct 28, 2016 at 8:15 PM, Joel M. Halpern > wrote: > > There are some preliminary thoughts on overload issues in the > security considerations of draft-ietf-lisp-introduction. > > I will also be curious to see what the presentations at the > technical plenary in Seoul have to suggest on the issue, if anything. > > There probably is more with considering. > > Yours, > Joel > > > On 10/28/16 7:39 PM, Padmadevi Pillay Esnault wrote: > > The recent Denial-of-service attacks is a scenario we should > have in mind when building robustness in the network mapping system. > In draft-padma-ideas-problem-statement-00.txt, there is a > section on mapping system security requirements that > specifically cover > this case. > > One of the questions that comes to mind is whether the > robustness of such a mapping system should drop/throttle > responses when it is > Overloaded or should we expect it always to handle the load no > matter what? > While we do propose to rate-limit the messages in the problem > statement, isn't this playing into the hands of the attackers? > > Requesting feedback from the list and ccing wg with expertise in > the area or interest in mapping system technology. > > Thanks in advance > Padma > > Below an excerpt from the draft > 6.4. Mapping System Security > > The secure mapping system must have the following requirements: > > 1. The components of the mapping system need to be robust > against > direct and indirect attacks. If any component is > attacked, the > rest of the system should act with integrity and scale > and only > the information associated with the compromised component > is made > unavailable. > > 2. The addition and removal of components of the mapping > system must > be performed in a secure matter so as to not violate the > integrity and operation of the system and service it > provides. > > 3. The information returned by components of the mapping system > needs to be authenticated as to detect spoofing from > masqueraders. > > 4. Information registered (by publishers) to the mapping > system must > be authenticated so the registering entity or the > information is > not spoofed. > > 5. The mapping system must allow request access (for > subscribers) to > be open and public. However, it is optional to provide > confidentiality and authentication of the requesters and the > information they are requesting. > > 6. Any information provided by components of the mapping > system must > be cryptographically signed by the provider and verified > by the > consumer. > > 7. Message rate-limiting and other heuristics must be part > of the > foundational support of the mapping system to protect the > system > from invalid overloaded conditions. > > 8. The mapping system should support some form of provisioned > policy. Either internal to the system or via mechanisms for > users of the system to describe policy rules. Access control > should not use traditional granular-based access lists > since they > do not scale and are hard to manage. By the use of token- or > key- based authentication methods as well as deploying > multiple > instances of the mapping system will allow acceptable policy > profiles. Machine learning techniques could automate these > mechanisms. > > > -----Original Message----- > From: IETF-Announce [mailto:ietf-announce-bounces@ietf.org > ] On Behalf Of IETF Chair > Sent: Friday, October 28, 2016 9:21 AM > To: IETF Announcement List > Cc: ietf@ietf.org > Subject: Technical plenary: Attacks against the architecture > > The technical plenary in Seoul will be about the recent > Denial-of-Service > attacks involving the use of compromised or misconfigured nodes or > “things”, and the architectural issues associated with the network > being vulnerable to these attacks. > > See > > > https://www.ietf.org/blog/2016/10/attack-against-the-architecture/ > > > and join us for the discussion on Wednesday 16:40-19:10, > November 16, > 2016 either in person or remotely. You can register for the > meeting here: > > https://www.ietf.org/meeting/97/index.html > > > Jari Arkko, IETF Chair > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > > > > _______________________________________________ > Ideas mailing list > Ideas@ietf.org > https://www.ietf.org/mailman/listinfo/ideas > > > From nobody Sat Oct 29 10:20:21 2016 Return-Path: X-Original-To: ideas@ietfa.amsl.com Delivered-To: ideas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B196312953A; Sat, 29 Oct 2016 10:20:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 JW4xoJwkNic3; Sat, 29 Oct 2016 10:20:15 -0700 (PDT) Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::22a]) (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 972921293E1; Sat, 29 Oct 2016 10:20:15 -0700 (PDT) Received: by mail-pf0-x22a.google.com with SMTP id 197so54078165pfu.0; Sat, 29 Oct 2016 10:20:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=wwX3VhLDoyjL6lddO7keAUr6+n13WPK7PeIM7jXrL4c=; b=Tgw3ogzIY0LLcSTRspDnMPCGH/LtRysjprNyIdonPCl+W81tFqSKzoqwijpNmy52hO 1XwDhjEJGvjhuysVAyQuJvnvajmUzQcVyEnpFJv0qaoZUgYNdEROI+k8qcQvv/Gmd7xu C6eTm+QAIdV3LyhA7+LBysxtExSBbsIruDcPli+lkEzi4HFZ/uxFdGii5HKxnZaGRjqC B5weEkPkiyWBPha39o3hKuOomAdGJPup4HSKUeO4vity8ZT425WL8pYl2n+juMdrNHo+ alUgR+d+gffgP/eL9tF2bmPBQlNZgr7snEKfavELyC6tiR8IGXOxOyHiB6FtXHK4LGn3 IJ4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=wwX3VhLDoyjL6lddO7keAUr6+n13WPK7PeIM7jXrL4c=; b=a1yR1CKb3TgEDn0w+bxRzGSe6KLkX/JP0CJB8WzwpKqUnVQVYO6KkxtV0XZYkEfhuE dz1o2HcY+QMKB6B9yLC9Sp0WTSh/X+Vr07rglP0KpNt1tLdwZ6YhOImJGbebgp/WOLZX GMed5DOwm5wG7j78AzDw8pfaR3JFq4EMBzb+sBFvWu7EDOltFv//fw2FEgeiYoDNtmqC bc4oRfKlkzrgMtnBo8pjrQeqPXbBLSNoikpl849L7bfJs0nnqNtwAM77rGN6m5OwGf8F S6KfL2jncMT4kaegTUMC+Fsav0PDvViytZrDxy5JWdmlSdDlaEAwcb/8pyrhQmZrdCl7 Su3Q== X-Gm-Message-State: ABUngvczgfxnwo6MYutd7fhkNsfjQPWz3bayNPnxZjNL2ADUeOsu69asoy5TFErV4lkPRQ== X-Received: by 10.98.43.136 with SMTP id r130mr34841607pfr.171.1477761615239; Sat, 29 Oct 2016 10:20:15 -0700 (PDT) Received: from [10.197.31.157] (173-11-119-245-SFBA.hfc.comcastbusiness.net. [173.11.119.245]) by smtp.gmail.com with ESMTPSA id u17sm26271289pfa.83.2016.10.29.10.20.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 29 Oct 2016 10:20:14 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) From: Dino Farinacci In-Reply-To: Date: Sat, 29 Oct 2016 10:20:10 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <09534746-0A8F-4CAB-9778-5032F90604F0@gmail.com> References: <85dd645c-37ca-0839-a175-2fb05539fbf2@joelhalpern.com> To: Padma Pillay-Esnault X-Mailer: Apple Mail (2.3226) Archived-At: Cc: "ideas@ietf.org" , "Joel M. Halpern" , "lisp@ietf.org" Subject: Re: [Ideas] [lisp] FW: Technical plenary: Attacks against the architecture - implications for the Network Mapping System X-BeenThere: ideas@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussions relating to the development, clarification, and implementation of control-plane infrastructures and functionalities in ID enabled networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Oct 2016 17:20:17 -0000 > In section 5 of draft-padma-ideas-problem-statement, there is a = section in the table which specifically discuss about the structure of = IDs and whether we should used them for specific classes or as the = Network Mapping system is proposing to attach metadata to ID. Maybe we can experiment with the EID-prefix block 2001:5::/32 from RFC = 7954/7955 to allocate sub-blocks from large regions of the world. Yes, = geographical allocations without the issue of the past, since EIDs are = not injected into the underlay routing and are not based on Internet = topology. Do this first and then decide which, say continent block is registered = to a regional mapping system. And if an ID needs to register to multiple = mapping systems. The mapping systems should considered to be relatively = local in scope and may overlap. This could help mitigate DoS attacks to a smaller (but still scalable) = part of the infrastructure. Dino From nobody Sat Oct 29 10:28:01 2016 Return-Path: X-Original-To: ideas@ietfa.amsl.com Delivered-To: ideas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 358951294F3; Sat, 29 Oct 2016 10:27:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 TXSPjIfR-CW2; Sat, 29 Oct 2016 10:27:54 -0700 (PDT) Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com [IPv6:2607:f8b0:400e:c00::233]) (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 09608129421; Sat, 29 Oct 2016 10:27:54 -0700 (PDT) Received: by mail-pf0-x233.google.com with SMTP id s8so53850215pfj.2; Sat, 29 Oct 2016 10:27:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=iEoGu2hJ5HqOBkFV+MXCD2x/hmfQdTOgZ57wH8ctYJg=; b=bvDc/irTnAMFZLgOYnewKhUCSi1pB5E67yTJBfLTqMjDZ7A/bqSj1VF0oOCzzPEBVZ M+LK9soksrP9X78e+kJOytMbNIanq6RbYsutg9Yo9yZ7YeztG+xRYv8YVxbytJO6IeAF Rolax+q2ajDXm5QvqGIIgbeQM9kHKm+0ZqDPP8DLbqZ1gpUj+uPZdz/cS6wzRmmClQXU 614ytXG/Gl5v3qAH6eUY0D25UsvcpfvoLMcOxQ7kymyv5RdIEuVhHjtJ1XBgqs4ociBk Wz2Dj185Yein3chvCvJYRFkz1d28r1gMX3WZ5Sea96fBB1qSZxQOjmHzGAkQ0zZGszww cpPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=iEoGu2hJ5HqOBkFV+MXCD2x/hmfQdTOgZ57wH8ctYJg=; b=eNJwWvSZPz1vg3p0lHMpy9ttxsj3dBVj682m4CsErDl3Bc2H6XfEIsmxcuiM0sTc7v IP0f34yx8xcihuZKOQjAXSTZVqz6qZVJ9P+BC8Hr4tR0sdTnMJdLEDaYVJo1lUSjvrJc Q8CVoB9ISr+31jS3oUTgwIZ9567wwVz9SGAQq7CZPHUYL+c9PYSLw5Tc7VoWwdcxXT6Q 8dIkCZFp397fVL5fD4WQQMvM4s/TawunQrlZxTheFlKYNG6MsoUYXfzmve4n2l774I5/ Vi6HFRnULJRVc2p4i5WQrh2nO7LrAox11VZ4OyEktwZMKks/sWH7+d0YyW4HLr/qqE3h JpxA== X-Gm-Message-State: ABUngvehxWvfENfFyRb+DsajhlQYLwgzvah26A2QK7G0AQMTbySAX/yjGw7OaHJqQwMa7Q== X-Received: by 10.99.55.66 with SMTP id g2mr28703074pgn.65.1477762073594; Sat, 29 Oct 2016 10:27:53 -0700 (PDT) Received: from [10.197.31.157] (173-11-119-245-SFBA.hfc.comcastbusiness.net. [173.11.119.245]) by smtp.gmail.com with ESMTPSA id ak3sm26412641pad.19.2016.10.29.10.27.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 29 Oct 2016 10:27:52 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) From: Dino Farinacci In-Reply-To: <9147701f-8395-7b2e-d370-111200ce2656@joelhalpern.com> Date: Sat, 29 Oct 2016 10:27:48 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <85dd645c-37ca-0839-a175-2fb05539fbf2@joelhalpern.com> <9147701f-8395-7b2e-d370-111200ce2656@joelhalpern.com> To: "Joel M. Halpern" X-Mailer: Apple Mail (2.3226) Archived-At: Cc: Padma Pillay-Esnault , "ideas@ietf.org" , "lisp@ietf.org" Subject: Re: [Ideas] [lisp] FW: Technical plenary: Attacks against the architecture - implications for the Network Mapping System X-BeenThere: ideas@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussions relating to the development, clarification, and implementation of control-plane infrastructures and functionalities in ID enabled networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Oct 2016 17:27:55 -0000 > Also, it seems to me that if all you want to do is break a single MR, = then rate limiting is irrelevant. In the absence of limits on who can = query a specific MR, you can bombard it with more queries than it can = handle and you will take it out of service. So a rate limit helps the = system while harming the MR capability only slightly. This is why it is important to anycast most of the MRs that will be = deployed. So the attack sources are naturally sending, in spread out = fashion, to a very large cluster-set of MRs. Only with a concentration = of sources in the relatively same topoglical area with lots of bandwidth = can be successful at a many-to-1 attack. > Trying to infer whether an entity is allowed to undertake specific = operations without authentication, using information such as the IP = address, seems fraught with failure. Trying to classify all entities = into types (onotology?) seems unlikely to produce correct results, as = classes are not cleanly defined. And remember by doing signature verification or decryption, the problem = gets worse for the MR. Because it has to use more resources when most of = the packets are from unauthorized sources. And white-listing 1 billion users to provide a public service minus the = 1,000,000 attackers is a white-list management nightmare/challenge. > As I said, I look forward to the technical presentation at the IETF = meeting to see if they have any ideas that can help. Yes, there is work = to be done. Putting authorization into the identity seems to be asking = for trouble. Definitely. Dino From nobody Sat Oct 29 10:38:43 2016 Return-Path: X-Original-To: ideas@ietfa.amsl.com Delivered-To: ideas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9431A12950B; Sat, 29 Oct 2016 10:38:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 PlVQJWYGvtjZ; Sat, 29 Oct 2016 10:38:36 -0700 (PDT) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (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 CFC71129407; Sat, 29 Oct 2016 10:38:35 -0700 (PDT) Received: by mail-qt0-x22c.google.com with SMTP id c47so6631904qtc.2; Sat, 29 Oct 2016 10:38:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/Ut+0lmGwTKn9tqgszZBLSAZeyPJM2sxQjevgWmbb/c=; b=Us+tFRkD6A7ftC+LFbxTqn0RJJdWVpCGbmvuop4hfd2ubFQG93njkAdSqIeZ9JUbOt AEGVSMYGnq8Nabx5aoQXVrUWsAjQrvPKF5UC9AZPX5rq+TBDveFvm/GgFhGLTzmgAAUc C5l9VHQZTTpwdpzsFrYr07YuxGWPxAWCGYhqOdvhB2BDEw6ZSx0FmskvUTKAdrFrWcol NgdKlfae4R4hqLGaRHKE4NSt0RxtOXE3UHHASwl5A9fsCskcGCgRR80qOkp+Cl34AgE1 4aF6YkZWojvV9pqOyqoSmKE+l2IZZHEvvFFZbKL1yDT2gE6R5ZnkNs3uR1jjK0MFei7s 9pPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/Ut+0lmGwTKn9tqgszZBLSAZeyPJM2sxQjevgWmbb/c=; b=VgGk5bHWlplzUiqYmIKCnExtTQK92DF1oM//ylKrELvOPSco/7huhDUifMsTy5cnkx 2js4N1rZVeJd44wIDf6GlqhBl0Wx3H/3QPi9zjmWqR8W9OnIBE4sAMNeGADBq1k/ExG8 lXqnKYxKV8ROdNS+ZIwW+uhhe6+NUBCKep6DgKGJZAws1I9/Q6qFbeBAJ3ONCb0Hb8md L7tskvupUnpFDYYi0aPF3PgvRygsq2hyi4VB+0amdNfy9/Zg1ldNoxhDUQOJPJboie1N bM3rjtIbSbkf3ouXJfVs3vZSOQtazDCwH5iFXLuEtTRv79LGyuPmT6ukdyDsKs1KUP3t Bdhw== X-Gm-Message-State: ABUngvdZSipKSjAcUUWh1Atf2YrqEylCSgA27FmFtPduvrIPE52cON5ND3+sInqrVaPXi+jW4Ey7zd0cWVzgnw== X-Received: by 10.200.51.251 with SMTP id d56mr3214646qtb.89.1477762714897; Sat, 29 Oct 2016 10:38:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.38.15 with HTTP; Sat, 29 Oct 2016 10:38:34 -0700 (PDT) In-Reply-To: <09534746-0A8F-4CAB-9778-5032F90604F0@gmail.com> References: <85dd645c-37ca-0839-a175-2fb05539fbf2@joelhalpern.com> <09534746-0A8F-4CAB-9778-5032F90604F0@gmail.com> From: Padma Pillay-Esnault Date: Sat, 29 Oct 2016 10:38:34 -0700 Message-ID: To: Dino Farinacci Content-Type: multipart/alternative; boundary=001a1134f2ecaf1b070540047151 Archived-At: Cc: "ideas@ietf.org" , "Joel M. Halpern" , "lisp@ietf.org" Subject: Re: [Ideas] [lisp] FW: Technical plenary: Attacks against the architecture - implications for the Network Mapping System X-BeenThere: ideas@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussions relating to the development, clarification, and implementation of control-plane infrastructures and functionalities in ID enabled networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Oct 2016 17:38:37 -0000 --001a1134f2ecaf1b070540047151 Content-Type: text/plain; charset=UTF-8 On Sat, Oct 29, 2016 at 10:20 AM, Dino Farinacci wrote: > > In section 5 of draft-padma-ideas-problem-statement, there is a section > in the table which specifically discuss about the structure of IDs and > whether we should used them for specific classes or as the Network Mapping > system is proposing to attach metadata to ID. > > Maybe we can experiment with the EID-prefix block 2001:5::/32 from RFC > 7954/7955 to allocate sub-blocks from large regions of the world. Yes, > geographical allocations without the issue of the past, since EIDs are not > injected into the underlay routing and are not based on Internet topology. > > Do this first and then decide which, say continent block is registered to > a regional mapping system. And if an ID needs to register to multiple > mapping systems. The mapping systems should considered to be relatively > local in scope and may overlap. > > This could help mitigate DoS attacks to a smaller (but still scalable) > part of the infrastructure. > Agree. Thanks Padma > > Dino > > --001a1134f2ecaf1b070540047151 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sat, Oct 29, 2016 at 10:20 AM, Dino Farinacci <= farinacci@gmail.co= m> wrote:
> In = section 5 of draft-padma-ideas-problem-statement, there is a section i= n the table which specifically discuss about the structure of IDs and wheth= er we should used them for specific classes or as the Network Mapping syste= m is proposing to attach metadata to ID.

Maybe we can experiment with the EID-prefix block 2001:5::/32 from R= FC 7954/7955 to allocate sub-blocks from large regions of the world. Yes, g= eographical allocations without the issue of the past, since EIDs are not i= njected into the underlay routing and are not based on Internet topology.
=C2=A0
Do this first and then decide which, say continent block is registered to a= regional mapping system. And if an ID needs to register to multiple mappin= g systems. The mapping systems should considered to be relatively local in = scope and may overlap.

This could help mitigate DoS attacks to a smaller (but still scalable) part= of the infrastructure.

=C2=A0<Padma= > Agree.

Thanks
Padma

Dino


--001a1134f2ecaf1b070540047151-- From nobody Mon Oct 31 09:31:23 2016 Return-Path: X-Original-To: ideas@ietfa.amsl.com Delivered-To: ideas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00393128B44; Mon, 31 Oct 2016 09:31:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 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] 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 amJXxWZqLdN9; Mon, 31 Oct 2016 09:31:16 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (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 4E7A91298B9; Mon, 31 Oct 2016 09:31:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id u9VGVFKB048562; Mon, 31 Oct 2016 09:31:15 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (xch15-06-11.nw.nos.boeing.com [137.136.239.220]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u9VGVB53048540 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Mon, 31 Oct 2016 09:31:11 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (137.136.238.222) by XCH15-06-11.nw.nos.boeing.com (137.136.239.220) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 31 Oct 2016 09:31:10 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1178.000; Mon, 31 Oct 2016 09:31:10 -0700 From: "Templin, Fred L" To: Padma Pillay-Esnault , Dino Farinacci Thread-Topic: [lisp] [Ideas] FW: Technical plenary: Attacks against the architecture - implications for the Network Mapping System Thread-Index: AQHSMfrdtNRXbsmgRk6cjS2L0R6v+aDAIsoAgAAFJACAApt/8A== Date: Mon, 31 Oct 2016 16:31:10 +0000 Message-ID: <1fb6fb630dd345cf8bed1d8164b04dd2@XCH15-06-08.nw.nos.boeing.com> References: <85dd645c-37ca-0839-a175-2fb05539fbf2@joelhalpern.com> <09534746-0A8F-4CAB-9778-5032F90604F0@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: multipart/alternative; boundary="_000_1fb6fb630dd345cf8bed1d8164b04dd2XCH150608nwnosboeingcom_" MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Cc: "ideas@ietf.org" , "lisp@ietf.org" Subject: Re: [Ideas] [lisp] FW: Technical plenary: Attacks against the architecture - implications for the Network Mapping System X-BeenThere: ideas@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussions relating to the development, clarification, and implementation of control-plane infrastructures and functionalities in ID enabled networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2016 16:31:18 -0000 --_000_1fb6fb630dd345cf8bed1d8164b04dd2XCH150608nwnosboeingcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksIG9uZSBvYnNlcnZhdGlvbiBhbmQgb25lIHF1ZXN0aW9uLiBUaGUgb2JzZXJ2YXRpb24gaXMg dGhhdCBhbnl0aGluZyBvbiB0aGUgb3Blbg0KSW50ZXJuZXQgdGhhdCBwcm92aWRlcyBhIHNlcnZp Y2UgY2FuIGJlIHN1YmplY3QgdG8gRGVuaWFsIG9mIFNlcnZpY2Ug4oCTIGFuZCwgSSBhbSBub3QN Cmp1c3QgdGFsa2luZyBhYm91dCB0aGUgTElTUCBtYXBwaW5nIHN5c3RlbS4gVGhlIHF1ZXN0aW9u IGlzIGhvdyBpcyBpdCB0aGF0IHdlIGhhdmUNCm5vdCB5ZXQgc2VlbiBEb1MgYXR0YWNrcyB0YWtl IGRvd24gY3JpdGljYWwgSW50ZXJuZXQgc2VydmljZXMgc3VjaCBhcyBvbmxpbmUgYmFua2luZzsN CmhhdmUgd2UganVzdCBiZWVuIGx1Y2t5IHVwIHRvIG5vdz8NCg0KVGhhbmtzIC0gRnJlZA0KDQpG cm9tOiBsaXNwIFttYWlsdG86bGlzcC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUGFk bWEgUGlsbGF5LUVzbmF1bHQNClNlbnQ6IFNhdHVyZGF5LCBPY3RvYmVyIDI5LCAyMDE2IDEwOjM5 IEFNDQpUbzogRGlubyBGYXJpbmFjY2kgPGZhcmluYWNjaUBnbWFpbC5jb20+DQpDYzogaWRlYXNA aWV0Zi5vcmc7IGxpc3BAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbbGlzcF0gW0lkZWFzXSBGVzog VGVjaG5pY2FsIHBsZW5hcnk6IEF0dGFja3MgYWdhaW5zdCB0aGUgYXJjaGl0ZWN0dXJlIC0gaW1w bGljYXRpb25zIGZvciB0aGUgTmV0d29yayBNYXBwaW5nIFN5c3RlbQ0KDQoNCg0KT24gU2F0LCBP Y3QgMjksIDIwMTYgYXQgMTA6MjAgQU0sIERpbm8gRmFyaW5hY2NpIDxmYXJpbmFjY2lAZ21haWwu Y29tPG1haWx0bzpmYXJpbmFjY2lAZ21haWwuY29tPj4gd3JvdGU6DQo+IEluIHNlY3Rpb24gNSBv ZiBkcmFmdC1wYWRtYS1pZGVhcy1wcm9ibGVtLXN0YXRlbWVudCwgdGhlcmUgaXMgYSBzZWN0aW9u IGluIHRoZSB0YWJsZSB3aGljaCBzcGVjaWZpY2FsbHkgZGlzY3VzcyBhYm91dCB0aGUgc3RydWN0 dXJlIG9mIElEcyBhbmQgd2hldGhlciB3ZSBzaG91bGQgdXNlZCB0aGVtIGZvciBzcGVjaWZpYyBj bGFzc2VzIG9yIGFzIHRoZSBOZXR3b3JrIE1hcHBpbmcgc3lzdGVtIGlzIHByb3Bvc2luZyB0byBh dHRhY2ggbWV0YWRhdGEgdG8gSUQuDQoNCk1heWJlIHdlIGNhbiBleHBlcmltZW50IHdpdGggdGhl IEVJRC1wcmVmaXggYmxvY2sgMjAwMTo1OjovMzIgZnJvbSBSRkMgNzk1NC83OTU1IHRvIGFsbG9j YXRlIHN1Yi1ibG9ja3MgZnJvbSBsYXJnZSByZWdpb25zIG9mIHRoZSB3b3JsZC4gWWVzLCBnZW9n cmFwaGljYWwgYWxsb2NhdGlvbnMgd2l0aG91dCB0aGUgaXNzdWUgb2YgdGhlIHBhc3QsIHNpbmNl IEVJRHMgYXJlIG5vdCBpbmplY3RlZCBpbnRvIHRoZSB1bmRlcmxheSByb3V0aW5nIGFuZCBhcmUg bm90IGJhc2VkIG9uIEludGVybmV0IHRvcG9sb2d5Lg0KDQpEbyB0aGlzIGZpcnN0IGFuZCB0aGVu IGRlY2lkZSB3aGljaCwgc2F5IGNvbnRpbmVudCBibG9jayBpcyByZWdpc3RlcmVkIHRvIGEgcmVn aW9uYWwgbWFwcGluZyBzeXN0ZW0uIEFuZCBpZiBhbiBJRCBuZWVkcyB0byByZWdpc3RlciB0byBt dWx0aXBsZSBtYXBwaW5nIHN5c3RlbXMuIFRoZSBtYXBwaW5nIHN5c3RlbXMgc2hvdWxkIGNvbnNp ZGVyZWQgdG8gYmUgcmVsYXRpdmVseSBsb2NhbCBpbiBzY29wZSBhbmQgbWF5IG92ZXJsYXAuDQoN ClRoaXMgY291bGQgaGVscCBtaXRpZ2F0ZSBEb1MgYXR0YWNrcyB0byBhIHNtYWxsZXIgKGJ1dCBz dGlsbCBzY2FsYWJsZSkgcGFydCBvZiB0aGUgaW5mcmFzdHJ1Y3R1cmUuDQoNCiA8UGFkbWE+IEFn cmVlLg0KDQpUaGFua3MNClBhZG1hDQoNCkRpbm8NCg0K --_000_1fb6fb630dd345cf8bed1d8164b04dd2XCH150608nwnosboeingcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLmdtYWlsLQ0KCXttc28t c3R5bGUtbmFtZTpnbWFpbC07fQ0Kc3Bhbi5nbWFpbC1ob2VuemINCgl7bXNvLXN0eWxlLW5hbWU6 Z21haWwtaG9lbnpiO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMx RjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ e3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4 PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0i MSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5 IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9Ildv cmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+SGksIG9uZSBvYnNlcnZhdGlvbiBhbmQgb25lIHF1ZXN0aW9uLiBUaGUgb2JzZXJ2 YXRpb24gaXMgdGhhdCBhbnl0aGluZyBvbiB0aGUgb3BlbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JbnRl cm5ldCB0aGF0IHByb3ZpZGVzIGEgc2VydmljZSBjYW4gYmUgc3ViamVjdCB0byBEZW5pYWwgb2Yg U2VydmljZSDigJMgYW5kLCBJIGFtIG5vdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5qdXN0IHRhbGtpbmcg YWJvdXQgdGhlIExJU1AgbWFwcGluZyBzeXN0ZW0uIFRoZSBxdWVzdGlvbiBpcyBob3cgaXMgaXQg dGhhdCB3ZSBoYXZlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPm5vdCB5ZXQgc2VlbiBEb1MgYXR0YWNrcyB0 YWtlIGRvd24gY3JpdGljYWwgSW50ZXJuZXQgc2VydmljZXMgc3VjaCBhcyBvbmxpbmUgYmFua2lu Zzs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+aGF2ZSB3ZSBqdXN0IGJlZW4gbHVja3kgdXAgdG8gbm93Pzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhhbmtzIC0gRnJlZDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBp biAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6 c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+IGxpc3AgW21haWx0bzpsaXNwLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhh bGYgT2YgPC9iPlBhZG1hIFBpbGxheS1Fc25hdWx0PGJyPg0KPGI+U2VudDo8L2I+IFNhdHVyZGF5 LCBPY3RvYmVyIDI5LCAyMDE2IDEwOjM5IEFNPGJyPg0KPGI+VG86PC9iPiBEaW5vIEZhcmluYWNj aSAmbHQ7ZmFyaW5hY2NpQGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IGlkZWFzQGlldGYu b3JnOyBsaXNwQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbbGlzcF0gW0lkZWFz XSBGVzogVGVjaG5pY2FsIHBsZW5hcnk6IEF0dGFja3MgYWdhaW5zdCB0aGUgYXJjaGl0ZWN0dXJl IC0gaW1wbGljYXRpb25zIGZvciB0aGUgTmV0d29yayBNYXBwaW5nIFN5c3RlbTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBTYXQsIE9jdCAyOSwgMjAxNiBhdCAx MDoyMCBBTSwgRGlubyBGYXJpbmFjY2kgJmx0OzxhIGhyZWY9Im1haWx0bzpmYXJpbmFjY2lAZ21h aWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+ZmFyaW5hY2NpQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3Rl OjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4t bGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGNsYXNzPSJnbWFpbC0iPiZndDsgSW4gc2VjdGlvbiA1IG9mIGRyYWZ0LXBhZG1hLWlkZWFzLXBy b2JsZW0tc3RhdGVtZW50LCB0aGVyZSBpcyBhIHNlY3Rpb24gaW4gdGhlIHRhYmxlIHdoaWNoIHNw ZWNpZmljYWxseSBkaXNjdXNzIGFib3V0IHRoZSBzdHJ1Y3R1cmUgb2YgSURzIGFuZCB3aGV0aGVy IHdlIHNob3VsZCB1c2VkIHRoZW0gZm9yIHNwZWNpZmljIGNsYXNzZXMgb3IgYXMgdGhlIE5ldHdv cmsgTWFwcGluZw0KIHN5c3RlbSBpcyBwcm9wb3NpbmcgdG8gYXR0YWNoIG1ldGFkYXRhIHRvIElE Ljwvc3Bhbj48YnI+DQo8YnI+DQpNYXliZSB3ZSBjYW4gZXhwZXJpbWVudCB3aXRoIHRoZSBFSUQt cHJlZml4IGJsb2NrIDIwMDE6NTo6LzMyIGZyb20gUkZDIDc5NTQvNzk1NSB0byBhbGxvY2F0ZSBz dWItYmxvY2tzIGZyb20gbGFyZ2UgcmVnaW9ucyBvZiB0aGUgd29ybGQuIFllcywgZ2VvZ3JhcGhp Y2FsIGFsbG9jYXRpb25zIHdpdGhvdXQgdGhlIGlzc3VlIG9mIHRoZSBwYXN0LCBzaW5jZSBFSURz IGFyZSBub3QgaW5qZWN0ZWQgaW50byB0aGUgdW5kZXJsYXkgcm91dGluZyBhbmQgYXJlDQogbm90 IGJhc2VkIG9uIEludGVybmV0IHRvcG9sb2d5LjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3Rl Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0ND Q0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21h cmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RG8gdGhpcyBmaXJzdCBhbmQg dGhlbiBkZWNpZGUgd2hpY2gsIHNheSBjb250aW5lbnQgYmxvY2sgaXMgcmVnaXN0ZXJlZCB0byBh IHJlZ2lvbmFsIG1hcHBpbmcgc3lzdGVtLiBBbmQgaWYgYW4gSUQgbmVlZHMgdG8gcmVnaXN0ZXIg dG8gbXVsdGlwbGUgbWFwcGluZyBzeXN0ZW1zLiBUaGUgbWFwcGluZyBzeXN0ZW1zIHNob3VsZCBj b25zaWRlcmVkIHRvIGJlIHJlbGF0aXZlbHkgbG9jYWwgaW4gc2NvcGUgYW5kIG1heQ0KIG92ZXJs YXAuPGJyPg0KPGJyPg0KVGhpcyBjb3VsZCBoZWxwIG1pdGlnYXRlIERvUyBhdHRhY2tzIHRvIGEg c21hbGxlciAoYnV0IHN0aWxsIHNjYWxhYmxlKSBwYXJ0IG9mIHRoZSBpbmZyYXN0cnVjdHVyZS48 bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOyZsdDtQYWRtYSZndDsgQWdyZWUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UGFkbWE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0ND Q0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJn aW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9t OjEyLjBwdCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPjxicj4NCjxzcGFuIGNsYXNzPSJn bWFpbC1ob2VuemIiPkRpbm88L3NwYW4+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1 b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_1fb6fb630dd345cf8bed1d8164b04dd2XCH150608nwnosboeingcom_-- From nobody Mon Oct 31 10:27:53 2016 Return-Path: X-Original-To: ideas@ietfa.amsl.com Delivered-To: ideas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D8AD12958B; Mon, 31 Oct 2016 10:27:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 K-vItdVpkIgi; Mon, 31 Oct 2016 10:27:51 -0700 (PDT) Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com [IPv6:2607:f8b0:400e:c00::233]) (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 28D97129969; Mon, 31 Oct 2016 10:27:51 -0700 (PDT) Received: by mail-pf0-x233.google.com with SMTP id d2so4790398pfd.0; Mon, 31 Oct 2016 10:27:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=IBH8M5usExNxonKy//RQEir0SHCqpYOTuxe9xknt16E=; b=X4msh9FMW+/sCNW9V/IjiVtj2+CHrPIyT6bNxGj09IHqpc2ExwwD0wxfWSBEoOypW2 /MqcsLWdUzPj+KO51aCmk9yEUD8NEFjp7zkPIaSeRLIQwQ41OFwxpFUlVBgENbHVoSkF wTB2zDT/NjI6m3xgI4D51EmF6kHI8NowOT85MFqcDwnhKIp7VnOB66JzCgW/rj1nxCo6 c4xp6dzNna94kZjqDoF9HhBG1VlKVUNyVFr+dCWJ/hpvCmCKWUTKlfm4fgSI7piZAFBz +DEUX9QrZLgkIBHmm+6d/4PZ5UcAi4WvAQaCCU/cv7xwKKIHt/GbNfD5i7pTp9dv6T/p xVtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=IBH8M5usExNxonKy//RQEir0SHCqpYOTuxe9xknt16E=; b=XyONpgpmersmWxcyP2JosvoC4Ea0H9Hc5Lm5IfsteLEIRSwPP00x5WCRDGteLaZq+R r2yxxtXI9urYRo5WC0+x2X+XOKdl2HsBYZWk1fwa2fluZi8P6N6tkU/89A4YmHLp1C0m qqhPg0GrrvHC+PkiYsVR57Ny+1mDyrwLHXsRMkV9/K6cseYRdG3orGFTK/xyRPvMfBnI FkjYylNYm67t3JvzpIEEpFQea5oKq2RQNyA8qALRzZcBXRCIIZe+RNOGh9OxPeJ8mxSn y9HPxd2ntPX9H3xSqlwQq9hWGYmaR2dpLNviamXaaLMq2P1tSg89162esA3lOYY4QZ2U eGJg== X-Gm-Message-State: ABUngvc2sfXADFszVncL83D5FttOnpzx5WC09HQu3TTtNyJ3i1BCWo7Uv3MgwgNoU9gu/Q== X-Received: by 10.99.242.5 with SMTP id v5mr42424296pgh.137.1477934870808; Mon, 31 Oct 2016 10:27:50 -0700 (PDT) Received: from [10.197.31.157] (173-11-119-245-SFBA.hfc.comcastbusiness.net. [173.11.119.245]) by smtp.gmail.com with ESMTPSA id v6sm8238324pab.14.2016.10.31.10.27.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 31 Oct 2016 10:27:50 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) From: Dino Farinacci In-Reply-To: <1fb6fb630dd345cf8bed1d8164b04dd2@XCH15-06-08.nw.nos.boeing.com> Date: Mon, 31 Oct 2016 10:02:57 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <85dd645c-37ca-0839-a175-2fb05539fbf2@joelhalpern.com> <09534746-0A8F-4CAB-9778-5032F90604F0@gmail.com> <1fb6fb630dd345cf8bed1d8164b04dd2@XCH15-06-08.nw.nos.boeing.com> To: "Templin, Fred L" X-Mailer: Apple Mail (2.3226) Archived-At: Cc: Padma Pillay-Esnault , "ideas@ietf.org" , "lisp@ietf.org" Subject: Re: [Ideas] [lisp] FW: Technical plenary: Attacks against the architecture - implications for the Network Mapping System X-BeenThere: ideas@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussions relating to the development, clarification, and implementation of control-plane infrastructures and functionalities in ID enabled networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2016 17:27:52 -0000 > Hi, one observation and one question. The observation is that anything = on the open > Internet that provides a service can be subject to Denial of Service = =E2=80=93 and, I am not > just talking about the LISP mapping system. The question is how is it = that we have > not yet seen DoS attacks take down critical Internet services such as = online banking; > have we just been lucky up to now? Fred, it has happened. Just hidden to avoid headlines and fear. Dino From nobody Mon Oct 31 11:48:51 2016 Return-Path: X-Original-To: ideas@ietfa.amsl.com Delivered-To: ideas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 692361299D3; Mon, 31 Oct 2016 11:48:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.718 X-Spam-Level: X-Spam-Status: No, score=-5.718 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] 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 h_fLGN6O-rWg; Mon, 31 Oct 2016 11:48:46 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC1141299A8; Mon, 31 Oct 2016 11:48:45 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CZK87733; Mon, 31 Oct 2016 18:48:43 +0000 (GMT) Received: from DFWEML702-CAH.china.huawei.com (10.193.5.176) by lhreml707-cah.china.huawei.com (10.201.5.199) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 31 Oct 2016 18:48:40 +0000 Received: from DFWEML501-MBB.china.huawei.com ([10.193.5.179]) by dfweml702-cah.china.huawei.com ([10.193.5.176]) with mapi id 14.03.0235.001; Mon, 31 Oct 2016 11:48:31 -0700 From: Padmadevi Pillay Esnault To: "Templin, Fred L" Thread-Topic: [Ideas] [lisp] FW: Technical plenary: Attacks against the architecture - implications for the Network Mapping System Thread-Index: AQHSM5Q+tB8Wu9GAmk+kxUM29tK5Q6DDP3GA//+hTHA= Date: Mon, 31 Oct 2016 18:48:31 +0000 Message-ID: References: <85dd645c-37ca-0839-a175-2fb05539fbf2@joelhalpern.com> <09534746-0A8F-4CAB-9778-5032F90604F0@gmail.com> <1fb6fb630dd345cf8bed1d8164b04dd2@XCH15-06-08.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.213.48.228] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090202.5817920B.027A, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: b55a82351c1e69ef9caa1780a4478e68 Archived-At: Cc: Padma Pillay-Esnault , "ideas@ietf.org" , Dino Farinacci , "lisp@ietf.org" Subject: Re: [Ideas] [lisp] FW: Technical plenary: Attacks against the architecture - implications for the Network Mapping System X-BeenThere: ideas@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussions relating to the development, clarification, and implementation of control-plane infrastructures and functionalities in ID enabled networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2016 18:48:48 -0000 SGkgRnJlZA0KDQpUaGFua3MgZm9yIHJhaXNpbmcgdGhpcyBpbnRlcmVzdGluZyBxdWVzdGlvbi4N Cg0KWWVzIGl0IGhhcyBoYXBwZW5lZCBhbmQgd2lsbCBjb250aW51ZSB0byBkbyBzby4gSXQgd2ls bCBhIHZlcnkgc2Vuc2l0aXZlIHRvcGljIHRoYXQgbm9uZSBvZiB0aGUgZW50aXRpZXMgYXR0YWNr IHdvdWxkIHdhbnQgdG8gYmUgcHVibGljaXplZCBhdCBhbGwgY29zdC4NClRoYXQgc2FpZCwgaXQg aXMgbXVjaCBlYXNpZXIgZm9yIGEgcHJpdmF0ZSBpbnN0aXR1dGlvbiB0byBrZWVwIGl0IHVuZGVy IHRoZSB3cmFwcy4NCg0KQXJlIHRoZXkgdGFraW5nIG1lYXN1cmVzPyBBYnNvbHV0ZWx5IQ0KSXQg aXMgcHJldHR5IHJlY2VudCB0aGF0IHdlIG5vdyBoYXZlIGF1dGhlbnRpY2F0aW9uIGJhc2VkIG9u IHdoaWNoIGNvbXB1dGVyIGlzIHVzZWQgdG8gbG9naW4gdXNpbmcgMiBzdGVwIHZlcmlmaWNhdGlv bi4gVGhlIHR3bw0KU3RlcCB2ZXJpZmljYXRpb24gaW52b2x2aW5nIGNvbmZpcm1hdGlvbiBvZiBj b2RlIHNlbnQgdG8gbW9iaWxlIGNhbiBiZSBjb25zaWRlcmVkIGEgdGVsbCB0YWxlIHNpZ24uDQoN CkkgdGhpbmsgdGhlIGRpZmZlcmVuY2Ugd2l0aCB0aGUgbGF0ZXN0IGF0dGFjayBpcyB0aGF0IA0K LSBpdCBpbnZvbHZlZCB0aGUgRE5TIHN5c3RlbSBvciBvdGhlciBzZXJ2aWNlcyB0aGF0IGNhbm5v dCByZWx5IG9uIHRoZSB0d28gc3RlcCB2ZXJpZmljYXRpb24gZm9yIGluc3RhbmNlIHdoaWNoIGNv dWxkIHBvdGVudGlhbGx5IGlkZW50aWZ5IGl0IHRoZSByZXF1ZXN0cyBhcmUgZnJvbSBib3RuZXRz LiANClRoZSBsYXJnZXIgYW5kIGluZGlzY3JpbWluYXRlIHlvdSBhcmUgYWJvdXQgdXNlcnMgdG8g eW91ciBzZXJ2aWNlLCB0aGUgaGlnaGVyIHRoZSByaXNrIG9mIGEgRERPUyBhdHRhY2sgd2FpdGlu ZyB0byBoYXBwZW4uDQotIEl0IGlzIGhhcmRlciB0byBrZWVwIGl0IHVuZGVyIHRoZSB3cmFwcyB3 aGVuIHlvdSBoYXZlIG11bHRpcGxlIHBhcnRpZXMgaW52b2x2ZWQuDQoNCkNvbWluZyBiYWNrIHRv IHRoZSBtYXBwaW5nIHN5c3RlbXMsIHdoaWxlIGl0IG1heSBiZSB2dWxuZXJhYmxlIGp1c3QgYXMg bWFueSBvdGhlciBjb21wb25lbnRzIG9mIHRoZSBpbnRlcm5ldCwgbm93IGlzIHRpbWUgZm9yIHJl dGhpbmtpbmcuIA0KSSBhbSByZWFsbHkgbG9va2luZyBmb3J3YXJkIHRvIHRoZSB0ZWNobmljYWwg cGxlbmFyeS4gVGhlIGxhdGVzdCBhdHRhY2sgaGlnaGxpZ2h0cyB0aGUgdXJnZW5jeSB0byBnZXQg c3RhcnRlZCBvbiB3b3JraW5nIG9uIGl0LiANClRoZSBtb3RpdmF0aW9uIGZvciB0aGUgSURFQVMg cHJvYmxlbSBzdGF0ZW1lbnQgaXMgdG8gaWRlbnRpZnkgdGhlc2UgY3JpdGljYWwgaXNzdWVzIGFu ZCBwcm92aWRlIGEgZnJhbWV3b3JrIGxldmVyYWdpbmcgcHJvcGVydGllcyBpbiBJRCBlbmFibGVk IG5ldHdvcmtzLg0KSU1ITywgaXQgaXMgYmVzdCB0byBoYXZlIGEgZnJhbWV3b3JrIGZvciBhbGwg SUQgZW5hYmxlZCBuZXR3b3JrcyByYXRoZXIgdGhhbiBnb2luZyBhYm91dCBpdCBpbiBwaWVjZW1l YWwsIGFuZCB0aGlzIGlzIHRoZSBnb2FsIGZvciBJREVBUywgb3IgYXQgbGVhc3QgaXQgaXMgYSBz dGFydGluZyBwb2ludC4NCg0KUGFkbWENCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZy b206IElkZWFzIFttYWlsdG86aWRlYXMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIERp bm8gRmFyaW5hY2NpDQpTZW50OiBNb25kYXksIE9jdG9iZXIgMzEsIDIwMTYgMTA6MDMgQU0NClRv OiBUZW1wbGluLCBGcmVkIEwNCkNjOiBQYWRtYSBQaWxsYXktRXNuYXVsdDsgaWRlYXNAaWV0Zi5v cmc7IGxpc3BAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbSWRlYXNdIFtsaXNwXSBGVzogVGVjaG5p Y2FsIHBsZW5hcnk6IEF0dGFja3MgYWdhaW5zdCB0aGUgYXJjaGl0ZWN0dXJlIC0gaW1wbGljYXRp b25zIGZvciB0aGUgTmV0d29yayBNYXBwaW5nIFN5c3RlbQ0KDQo+IEhpLCBvbmUgb2JzZXJ2YXRp b24gYW5kIG9uZSBxdWVzdGlvbi4gVGhlIG9ic2VydmF0aW9uIGlzIHRoYXQgYW55dGhpbmcgb24g dGhlIG9wZW4NCj4gSW50ZXJuZXQgdGhhdCBwcm92aWRlcyBhIHNlcnZpY2UgY2FuIGJlIHN1Ympl Y3QgdG8gRGVuaWFsIG9mIFNlcnZpY2Ug4oCTIGFuZCwgSSBhbSBub3QNCj4ganVzdCB0YWxraW5n IGFib3V0IHRoZSBMSVNQIG1hcHBpbmcgc3lzdGVtLiBUaGUgcXVlc3Rpb24gaXMgaG93IGlzIGl0 IHRoYXQgd2UgaGF2ZQ0KPiBub3QgeWV0IHNlZW4gRG9TIGF0dGFja3MgdGFrZSBkb3duIGNyaXRp Y2FsIEludGVybmV0IHNlcnZpY2VzIHN1Y2ggYXMgb25saW5lIGJhbmtpbmc7DQo+IGhhdmUgd2Ug anVzdCBiZWVuIGx1Y2t5IHVwIHRvIG5vdz8NCg0KRnJlZCwgaXQgaGFzIGhhcHBlbmVkLiBKdXN0 IGhpZGRlbiB0byBhdm9pZCBoZWFkbGluZXMgYW5kIGZlYXIuDQoNCkRpbm8NCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCklkZWFzIG1haWxpbmcgbGlz dA0KSWRlYXNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v aWRlYXMNCg==