From nobody Tue Jun 3 12:04:46 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1F6B1A025B for ; Tue, 3 Jun 2014 12:04:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.601 X-Spam-Level: X-Spam-Status: No, score=-102.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 xAaLHTjLG4XB for ; Tue, 3 Jun 2014 12:04:41 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0205.outbound.protection.outlook.com [207.46.163.205]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D173C1A0249 for ; Tue, 3 Jun 2014 12:04:40 -0700 (PDT) Received: from CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) by CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) with Microsoft SMTP Server (TLS) id 15.0.949.11; Tue, 3 Jun 2014 19:04:33 +0000 Received: from CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.68]) by CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.68]) with mapi id 15.00.0949.001; Tue, 3 Jun 2014 19:04:33 +0000 From: Ronald Bonica To: Dino Farinacci Thread-Topic: [lisp] Restarting last call on LISP threats Thread-Index: AQHPa58LSm48HWl6Wky1MR3KNHiENZs9MyiAgAD04oCAAJ/u8IAAAtXQgADypICAAlhbEIABfmkAgAefyVCAAITngIABbBJggAETbwCABC0O0IAAtqUAgAABTnCAADykgIABvzTggAATfICAAA/EoIAAEAYAgAlC09A= Date: Tue, 3 Jun 2014 19:04:31 +0000 Message-ID: <4a60f797eebc467aa4095ad56a3491e2@CO1PR05MB442.namprd05.prod.outlook.com> References: <536CFA13.4010102@joelhalpern.com> <4e6c0aaac8fb4aba87ab137cc49b51dc@CO2PR05MB636.namprd05.prod.outlook.com> <1a200c5f5de041fbaf88edd1a5c3159c@CO1PR05MB442.namprd05.prod.outlook.com> <860b7987207345afb282a82862ff42c0@CO1PR05MB442.namprd05.prod.outlook.com> <2CF699DA-2BAA-4A76-BFF1-64625E001184@gmail.com> <09d3b0d276004c88b6de1a59cf863062@CO1PR05MB442.namprd05.prod.outlook.com> <3269BEE4-C3E5-4D76-A1C0-0B70B6928A12@gmail.com> <538361DA.10808@joelhalpern.com> <029e0f8bc7ba433ba4d3ee70b8431f9f@CO1PR05MB442.namprd05.prod.outlook.com> <3519A6AD5B18C44EB0291EC6C880A906012FD3@NYDC-EXCH01.vinci-consulting-corp.local> <936e209eb2fb49288f3a776aaa4b71cb@CO1PR05MB442.namprd05.prod.outlook.com> <7E76C55E-CCD0-4A52-A481-5BA9BF6A6689@gmail.com> <9091dab3083e460abb2080f1e9315aba@CO1PR05MB442.namprd05.prod.outlook.com> <4B057F83-72DF-44B8-A6D5-2DF6829C8948@gmail.com> In-Reply-To: <4B057F83-72DF-44B8-A6D5-2DF6829C8948@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.13] x-microsoft-antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: x-forefront-prvs: 02318D10FB x-forefront-antispam-report: SFV:NSPM; SFS:(979002)(6009001)(428001)(13464003)(51704005)(24454002)(199002)(189002)(377454003)(92566001)(74316001)(50986999)(19580405001)(81542001)(81342001)(86362001)(19580395003)(99396002)(74662001)(83322001)(2656002)(80022001)(46102001)(101416001)(85852003)(66066001)(20776003)(33646001)(64706001)(77982001)(54356999)(21056001)(74502001)(83072002)(87936001)(79102001)(99286001)(31966008)(76176999)(1411001)(4396001)(76576001)(76482001)(24736002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB442; H:CO1PR05MB442.namprd05.prod.outlook.com; FPR:; MLV:ovrnspm; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (: juniper.net does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=rbonica@juniper.net; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/IsUKwIxj7opofNKnmzuQCrH0UDA Cc: Roger Jorgensen , LISP mailing list list Subject: Re: [lisp] Restarting last call on LISP threats X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 19:04:44 -0000 Dino, I think statements are true. That is: 1) The attack stream is crafted to maximize the ratio of attack packets to = map-requests. 2) Traffic originating from a real PiTR probably won't maximize the ratio o= f attack packets to map-requests because "packets encapsulated by PITRs ori= ginate from non-LISP sources. Thereby the ITR at the LISP site will nativel= y-forward to those random places. And those native-forward map-cache entrie= s are very coarse since the mapping system returns the least specific prefi= x that covers all non-LISP sites." In either case, if we are going to deploy LISP on the global Internet, we n= eed to deal with the attack in the threats document. Ron > -----Original Message----- > From: Dino Farinacci [mailto:farinacci@gmail.com] > Sent: Tuesday, May 27, 2014 9:12 PM > To: Ronald Bonica > Cc: Paul Vinciguerra; Joel M. Halpern; Damien Saucez; Roger Jorgensen; LI= SP > mailing list list > Subject: Re: [lisp] Restarting last call on LISP threats >=20 >=20 >=20 > > On May 27, 2014, at 5:18 PM, Ronald Bonica wrote: > > > > RPB] > > Exactly. Source EIDs are chosen to maximize the ratio of attack packets= to > map-requests sent by the victim XTR. > > > > This is what make the attack stream so different from a stream that a P= iTR > is likely to send during normal operation. >=20 > It is not different for that reason. It is different because packets > encapsulated by PITRs originate from non-LISP sources. Thereby the ITR at > the LISP site will natively-forward to those random places. And those nat= ive- > forward map-cache entries are very coarse since the mapping system return= s > the least specific prefix that covers all non-LISP sites. >=20 > I believe Paul is still right IMO. >=20 > Dino From nobody Tue Jun 10 08:09:09 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABDBA1B27FF for ; Tue, 10 Jun 2014 08:09:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 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, HELO_EQ_FR=0.35, SPF_PASS=-0.001] autolearn=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 g5vkjSDE7PMc for ; Tue, 10 Jun 2014 08:09:07 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 925091B27F8 for ; Tue, 10 Jun 2014 08:09:06 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id cc10so1839952wib.1 for ; Tue, 10 Jun 2014 08:09:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version; bh=cBA2ietwudnDYw8cLzCSs2hDrVbDf5EDvj32ldPU4Oo=; b=Q4vShmSO+dds9naSb6vVSltmxfu8dJiUiDxgyFJqeOsEQtusuVh4ACEuqTJNeEPSSX AM6BAsyNCJCY6DgcVGU+DQouP8PGLztpiqqi6NuwuHuMxpANYPr0N/zmTLfm0lFXkKKB HR1A8llaYA+CAd9MPTfjxfOqMpIbPRnNzFJzib2QB5oEMReEu5NYLGKRXZgh/igbo1dv lzywBjytDoIDea6Ql6bMI7c5HAvpyxXf+eLP/S/xeQ8xmGhHi5PteysQ2hautuTQ4sKf B2CXHeeuDDeHgacfDFgLdgcUD6wL9EiAsTyIZSlbIznHdsYIBkFot25PWOHFLJlSwHgS RMQQ== X-Received: by 10.194.110.71 with SMTP id hy7mr42598988wjb.23.1402412945041; Tue, 10 Jun 2014 08:09:05 -0700 (PDT) Received: from faucon.inria.fr (faucon.inria.fr. [138.96.201.73]) by mx.google.com with ESMTPSA id hi6sm29994291wjc.32.2014.06.10.08.09.04 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 10 Jun 2014 08:09:04 -0700 (PDT) From: Damien Saucez Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: Date: Tue, 10 Jun 2014 17:09:03 +0200 To: draft-ietf-lisp-eid-block@tools.ietf.org, LISP mailing list list Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/xIuiCy3t6GPtJtL7erotDGJ3cV0 Subject: [lisp] LISP EID Block - IPR disclosures X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 15:09:07 -0000 Dear all, I am the document shepherd for draft-ietf-lisp-eid-block-08. In order for me to complete the shepherd writeup, I would like first to ask the authors and the WG if any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. Best regards, Damien Saucez From nobody Tue Jun 10 08:13:00 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15B221A01A5 for ; Tue, 10 Jun 2014 08:12:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 MEgiSDXtMdDB for ; Tue, 10 Jun 2014 08:12:58 -0700 (PDT) Received: from mail-pb0-x22e.google.com (mail-pb0-x22e.google.com [IPv6:2607:f8b0:400e:c01::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 045B01B27BC for ; Tue, 10 Jun 2014 08:12:57 -0700 (PDT) Received: by mail-pb0-f46.google.com with SMTP id rq2so6279130pbb.5 for ; Tue, 10 Jun 2014 08:12:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=A/m1GOie4FDg1hNpgDKFIZ8UUcPIkv6mRJe+cz7Ia7U=; b=e2ubH05qxTKhL8aNq8hvHpCWCx0ENMiRUZ2njLt/wg86N7FBjZ7vz+bgCB/MoplTg/ HPF2Yvnoo1QQZ/R+PgPF/EXdRhUdtG02ZhawA/4Mi3Y5R2fLRPZjKBoN9N2xYwu4OSif 3NHb3GT6J8Uk/xz/KQrea6j59o8UjpwteCFhtFGc13jAvQjTh43BExgwNQmyEkABtEqa nGNnriZEOgkn1XzGSRbAFonQTuvwrwFgnNwg3z6FtHvDtdhsFm2qlkLmTUiEjH1CLvC/ KyIMsJSFRCmqj8DOyNbzRgc5PxcE1olD4YnDfzljDmep/cF2VDwo9Gd0NlSowKMs1TKu HlOw== X-Received: by 10.66.232.68 with SMTP id tm4mr6199743pac.114.1402413177713; Tue, 10 Jun 2014 08:12:57 -0700 (PDT) Received: from dino-macbook.wp.comcast.net (173-8-188-29-SFBA.hfc.comcastbusiness.net. [173.8.188.29]) by mx.google.com with ESMTPSA id ao4sm70031936pbc.51.2014.06.10.08.12.55 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 10 Jun 2014 08:12:55 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Dino Farinacci In-Reply-To: Date: Tue, 10 Jun 2014 08:12:54 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: To: Damien Saucez X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/voLbI8JNRUOUXYTGxoGvkTgtB0U Cc: draft-ietf-lisp-eid-block@tools.ietf.org, LISP mailing list list Subject: Re: [lisp] LISP EID Block - IPR disclosures X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 15:12:59 -0000 I am not aware of any IPR pertaining to this draft. Dino On Jun 10, 2014, at 8:09 AM, Damien Saucez wrote: > Dear all, > > I am the document shepherd for draft-ietf-lisp-eid-block-08. In order > for me to complete the shepherd writeup, I would like first to ask the > authors and the WG if any and all appropriate IPR disclosures required > for full conformance with the provisions of BCP 78 and BCP 79 have > already been filed. > > Best regards, > > Damien Saucez > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From nobody Tue Jun 10 08:40:39 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C02B1A01E1 for ; Tue, 10 Jun 2014 08:40:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, SPF_PASS=-0.001] autolearn=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 4jQsfTSGfjX4 for ; Tue, 10 Jun 2014 08:40:37 -0700 (PDT) Received: from zproxy110.enst.fr (zproxy110.enst.fr [137.194.52.33]) by ietfa.amsl.com (Postfix) with ESMTP id 0C23D1A01A7 for ; Tue, 10 Jun 2014 08:40:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zproxy110.enst.fr (Postfix) with ESMTP id 58EDA10126D; Tue, 10 Jun 2014 17:40:35 +0200 (CEST) Received: from zproxy110.enst.fr ([127.0.0.1]) by localhost (zproxy110.enst.fr [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id QnmewEQZVgs9; Tue, 10 Jun 2014 17:40:25 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zproxy110.enst.fr (Postfix) with ESMTP id 624C6101265; Tue, 10 Jun 2014 17:40:25 +0200 (CEST) X-Virus-Scanned: amavisd-new at zproxy110.enst.fr Received: from zproxy110.enst.fr ([127.0.0.1]) by localhost (zproxy110.enst.fr [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id E1KXYXNdTBAY; Tue, 10 Jun 2014 17:40:25 +0200 (CEST) Received: from dhcp164-99.enst.fr (dhcp164-99.enst.fr [137.194.165.99]) by zproxy110.enst.fr (Postfix) with ESMTPSA id 008A5101257; Tue, 10 Jun 2014 17:40:24 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Luigi Iannone In-Reply-To: Date: Tue, 10 Jun 2014 17:40:25 +0200 Content-Transfer-Encoding: 7bit Message-Id: <3985DB9C-C3D7-4A40-BC4A-3D1C87E1CC65@telecom-paristech.fr> References: To: Damien Saucez X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/VXsSmSkvWK8Uz8Sq0B0dd2fRsVA Cc: draft-ietf-lisp-eid-block@tools.ietf.org, LISP mailing list list Subject: Re: [lisp] LISP EID Block - IPR disclosures X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 15:40:38 -0000 Not aware of any IPR concerning this document. Luigi On 10 Jun 2014, at 17:09, Damien Saucez wrote: > Dear all, > > I am the document shepherd for draft-ietf-lisp-eid-block-08. In order > for me to complete the shepherd writeup, I would like first to ask the > authors and the WG if any and all appropriate IPR disclosures required > for full conformance with the provisions of BCP 78 and BCP 79 have > already been filed. > > Best regards, > > Damien Saucez From nobody Tue Jun 10 09:57:57 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 349BF1A0202 for ; Tue, 10 Jun 2014 09:57:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.902 X-Spam-Level: X-Spam-Status: No, score=-101.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 i8azWmETienL for ; Tue, 10 Jun 2014 09:57:55 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0140.outbound.protection.outlook.com [207.46.163.140]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBDEB1A0096 for ; Tue, 10 Jun 2014 09:57:54 -0700 (PDT) Received: from CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) by CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) with Microsoft SMTP Server (TLS) id 15.0.949.11; Tue, 10 Jun 2014 16:57:52 +0000 Received: from CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.68]) by CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.92]) with mapi id 15.00.0949.001; Tue, 10 Jun 2014 16:57:52 +0000 From: Ronald Bonica To: LISP mailing list list Thread-Topic: Re: [lisp] Restarting last call on LISP threats Thread-Index: Ac+Eyeoh9i5jvyNETwW6IzG0gJ4tsw== Date: Tue, 10 Jun 2014 16:57:50 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.11] x-microsoft-antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: x-forefront-prvs: 0238AEEDB0 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(428001)(51444003)(199002)(189002)(76576001)(74502001)(74662001)(31966008)(4396001)(81542001)(21056001)(46102001)(77982001)(76482001)(33646001)(81342001)(83072002)(85852003)(20776003)(2656002)(99396002)(101416001)(74316001)(66066001)(64706001)(54356999)(86362001)(79102001)(92566001)(80022001)(50986999)(83322001)(87936001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB442; H:CO1PR05MB442.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (: juniper.net does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=rbonica@juniper.net; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/6iXTlcZJuaecPtfluzieEsKY2yA Subject: Re: [lisp] Restarting last call on LISP threats X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 16:57:56 -0000 Folks, Earlier in this thread, we agreed that when LISP is deployed on the global = Internet, mapping information cannot be gleaned safely from incoming LISP d= ata packets. Following that train of thought, when LISP is deployed on the = global Internet, is it safe to glean routing locator reachability informati= on from incoming LISP data packets as described in RFC 6830, Section 6.3, b= ullet 1. If not, I think that we need to mention this in the threats docume= nt. Given that ICMP packets are easily spoofed, when LISP is deployed on the gl= obal Internet, is it safe to glean routing locator reachability information= from incoming ICMP packets as described in RFC 6830, Section 6.3, bullet 2= and bullet 4. If not, I think that we need to mention this in the threats = document. Ron Bonica From nobody Tue Jun 10 10:04:12 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C208A1A022F for ; Tue, 10 Jun 2014 10:04:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 FSJdF4XtTjG3 for ; Tue, 10 Jun 2014 10:04:00 -0700 (PDT) Received: from mail-pb0-x22a.google.com (mail-pb0-x22a.google.com [IPv6:2607:f8b0:400e:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55D4A1A0040 for ; Tue, 10 Jun 2014 10:04:00 -0700 (PDT) Received: by mail-pb0-f42.google.com with SMTP id md12so6483430pbc.1 for ; Tue, 10 Jun 2014 10:04:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=BVhQNDQvYHA3TJ15CpFR/SaVlkl3IbINzb/R0huvRDc=; b=Mpc6N+Fd3YTtUuvlvTORMopZrctKIdJjBreG/+WmPXpU7F9PeCAxf2m3DNzRJArvHI k+RFZsh+ETINa/lcc1BYRk1qIwjWIJXTY4oAZqvFeSzOajZoQuulaWouGd5rEyCHwoQk cJWDLATjriFpMgmgo3oIjun7M0c2zb8xQhGjKwovXiWWqC74CJrDpc5zJiAVZXZFDm9K Ut9n76na2m6OYV5E13rDvN6etd7abmrtybNT2bNINLV88rnhNrMaC1joOxaO6yg3Shl+ VZpVOLg7DnY7OOvWyVyFz33rFJy93h4Xn2sSffdDcTnUB8/bqUBCdm7jWCI87vo88NqO +ROw== X-Received: by 10.67.12.171 with SMTP id er11mr6805414pad.132.1402419840084; Tue, 10 Jun 2014 10:04:00 -0700 (PDT) Received: from [192.168.1.174] ([207.145.253.66]) by mx.google.com with ESMTPSA id gw8sm70481685pbc.28.2014.06.10.10.03.52 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 10 Jun 2014 10:03:59 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Dino Farinacci In-Reply-To: Date: Tue, 10 Jun 2014 10:03:51 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Ronald Bonica X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/AwklAUBjsGiDUoFqXH04DX9_HP8 Cc: LISP mailing list list Subject: Re: [lisp] Restarting last call on LISP threats X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 17:04:04 -0000 On Jun 10, 2014, at 9:57 AM, Ronald Bonica wrote: > Earlier in this thread, we agreed that when LISP is deployed on the = global Internet, mapping information cannot be gleaned safely from = incoming LISP data packets. Following that train of thought, when LISP = is deployed on the global Internet, is it safe to glean routing locator = reachability information from incoming LISP data packets as described in = RFC 6830, Section 6.3, bullet 1. If not, I think that we need to mention = this in the threats document. What you can glean is that the source RLOC is up, but you cannot glean = your path to it is reachable. > Given that ICMP packets are easily spoofed, when LISP is deployed on = the global Internet, is it safe to glean routing locator reachability = information from incoming ICMP packets as described in RFC 6830, Section = 6.3, bullet 2 and bullet 4. If not, I think that we need to mention this = in the threats document. What you can glean is that the source RLOC is up, but you cannot glean = your path to it is reachable. Dino From nobody Tue Jun 10 10:06:49 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F5D91A0239 for ; Tue, 10 Jun 2014 10:06:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.601 X-Spam-Level: X-Spam-Status: No, score=-102.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 FzG0oEiXOVu9 for ; Tue, 10 Jun 2014 10:06:46 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0208.outbound.protection.outlook.com [207.46.163.208]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0B231A019B for ; Tue, 10 Jun 2014 10:06:45 -0700 (PDT) Received: from CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) by CO1PR05MB444.namprd05.prod.outlook.com (10.141.73.140) with Microsoft SMTP Server (TLS) id 15.0.949.11; Tue, 10 Jun 2014 17:06:43 +0000 Received: from CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.68]) by CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.92]) with mapi id 15.00.0949.001; Tue, 10 Jun 2014 17:06:43 +0000 From: Ronald Bonica To: Dino Farinacci Thread-Topic: [lisp] Restarting last call on LISP threats Thread-Index: AQHPhM36v1z5qcx3GU+Mb5TT+ra0YZtqkpgA Date: Tue, 10 Jun 2014 17:06:42 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.11] x-microsoft-antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: x-forefront-prvs: 0238AEEDB0 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(428001)(24454002)(13464003)(377454003)(51704005)(51444003)(189002)(199002)(79102001)(2656002)(83072002)(77982001)(80022001)(66066001)(85852003)(99396002)(76482001)(4396001)(46102001)(86362001)(76576001)(20776003)(19580395003)(64706001)(21056001)(1411001)(19580405001)(33646001)(81542001)(76176999)(74316001)(74662001)(101416001)(54356999)(87936001)(74502001)(50986999)(31966008)(83322001)(92566001)(81342001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB444; H:CO1PR05MB442.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: juniper.net does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=rbonica@juniper.net; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/Rll-JwMSMsfuW7C1rYrJ3qYkBm0 Cc: LISP mailing list list Subject: Re: [lisp] Restarting last call on LISP threats X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 17:06:47 -0000 Hi Dino, Given that the LISP data packet or ICMP packet may be from an attacker, is = it even safe to glean that? I think not. = Ron > -----Original Message----- > From: Dino Farinacci [mailto:farinacci@gmail.com] > Sent: Tuesday, June 10, 2014 1:04 PM > To: Ronald Bonica > Cc: LISP mailing list list > Subject: Re: [lisp] Restarting last call on LISP threats >=20 >=20 > On Jun 10, 2014, at 9:57 AM, Ronald Bonica wrote: >=20 > > Earlier in this thread, we agreed that when LISP is deployed on the glo= bal > Internet, mapping information cannot be gleaned safely from incoming LISP > data packets. Following that train of thought, when LISP is deployed on t= he > global Internet, is it safe to glean routing locator reachability informa= tion > from incoming LISP data packets as described in RFC 6830, Section 6.3, bu= llet > 1. If not, I think that we need to mention this in the threats document. >=20 > What you can glean is that the source RLOC is up, but you cannot glean yo= ur > path to it is reachable. >=20 > > Given that ICMP packets are easily spoofed, when LISP is deployed on th= e > global Internet, is it safe to glean routing locator reachability informa= tion > from incoming ICMP packets as described in RFC 6830, Section 6.3, bullet = 2 > and bullet 4. If not, I think that we need to mention this in the threats > document. >=20 > What you can glean is that the source RLOC is up, but you cannot glean yo= ur > path to it is reachable. >=20 > Dino >=20 From nobody Tue Jun 10 10:17:58 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43DFD1A0238 for ; Tue, 10 Jun 2014 10:17:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 dduWWfcLkGOX for ; Tue, 10 Jun 2014 10:17:33 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98EA11A0040 for ; Tue, 10 Jun 2014 10:17:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 675082407A7; Tue, 10 Jun 2014 10:17:31 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-135-218.clppva.east.verizon.net [70.106.135.218]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id A8854240AE4; Tue, 10 Jun 2014 10:17:30 -0700 (PDT) Message-ID: <53973DAE.4050000@joelhalpern.com> Date: Tue, 10 Jun 2014 13:17:34 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Ronald Bonica , Dino Farinacci References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/vhI_bv5d4LcYSo-ffucvLQPP2Mk Cc: LISP mailing list list Subject: Re: [lisp] Restarting last call on LISP threats X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 17:17:36 -0000 I think that the treat scopes for the two cases are different. Gleaning new RLOCs is clearly a significant risk. Gleaning the liveness of an RLOC from the fact that it appears to be talking to you is a much lower risk. With a much higher benefit. I have no problem with noting that there is a risk, albeit somewhat complex. But it should not be viewed in the same manner. (All security is a matter of costs and benefits.) Yours, Joel On 6/10/14, 1:06 PM, Ronald Bonica wrote: > Hi Dino, > > Given that the LISP data packet or ICMP packet may be from an attacker, is it even safe to glean that? I think not. > > Ron > > >> -----Original Message----- >> From: Dino Farinacci [mailto:farinacci@gmail.com] >> Sent: Tuesday, June 10, 2014 1:04 PM >> To: Ronald Bonica >> Cc: LISP mailing list list >> Subject: Re: [lisp] Restarting last call on LISP threats >> >> >> On Jun 10, 2014, at 9:57 AM, Ronald Bonica wrote: >> >>> Earlier in this thread, we agreed that when LISP is deployed on the global >> Internet, mapping information cannot be gleaned safely from incoming LISP >> data packets. Following that train of thought, when LISP is deployed on the >> global Internet, is it safe to glean routing locator reachability information >> from incoming LISP data packets as described in RFC 6830, Section 6.3, bullet >> 1. If not, I think that we need to mention this in the threats document. >> >> What you can glean is that the source RLOC is up, but you cannot glean your >> path to it is reachable. >> >>> Given that ICMP packets are easily spoofed, when LISP is deployed on the >> global Internet, is it safe to glean routing locator reachability information >> from incoming ICMP packets as described in RFC 6830, Section 6.3, bullet 2 >> and bullet 4. If not, I think that we need to mention this in the threats >> document. >> >> What you can glean is that the source RLOC is up, but you cannot glean your >> path to it is reachable. >> >> Dino >> > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > From nobody Tue Jun 10 10:23:35 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22E471A01C4 for ; Tue, 10 Jun 2014 10:23:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 xqyR-nSDN3wl for ; Tue, 10 Jun 2014 10:23:02 -0700 (PDT) Received: from mail-pd0-x236.google.com (mail-pd0-x236.google.com [IPv6:2607:f8b0:400e:c02::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 923BF1A00D4 for ; Tue, 10 Jun 2014 10:23:02 -0700 (PDT) Received: by mail-pd0-f182.google.com with SMTP id y13so425399pdi.13 for ; Tue, 10 Jun 2014 10:23:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=R3+spw3daUV725Wch9ZPFFSyx6pa19MM0pKbT1I+EvY=; b=D6rcDB2h1Fz+8GKv4KAUrkXpGmyHsOEzXASZ3+Th1frPgkCfAnyO5omEjRldjN+bz1 4a+AGtg0M57zYvSrvF0WLGF9Fcc9z7v5DJrmqZAuXV0meBnbATyB3z/puXrjikgqKwHT gXZO1ARQpQ8VsC6IKdlZKlx6wIFxJpGfEi3OHzXZbsgmn4esIJo3GCMA7jz/e7xdezA3 ESNhCL/GXgEw7GwYetCE+dQgJ466FLfDn2O1olwTYSQ7NFKNvVpgNzAxW5E04RRcnykw I1z/TWS0MMR9vpGgTzBii5QmV6WIX2rEjcXEwj48zj3KYh0JCNbvYxd20afb0a34yENf Mp2A== X-Received: by 10.68.254.103 with SMTP id ah7mr12285298pbd.159.1402420982317; Tue, 10 Jun 2014 10:23:02 -0700 (PDT) Received: from [192.168.1.174] ([207.145.253.66]) by mx.google.com with ESMTPSA id no9sm70467218pbc.83.2014.06.10.10.22.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 10 Jun 2014 10:23:00 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Dino Farinacci In-Reply-To: Date: Tue, 10 Jun 2014 10:22:59 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Ronald Bonica X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/S7nDfDAx_iKyZNbDydTLzgwWfmc Cc: LISP mailing list list Subject: Re: [lisp] Restarting last call on LISP threats X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 17:23:04 -0000 As I keep saying Ron, you need to verify anything you intend to glean. = The spec says the gleaning is "a hint" and not gospel. Dino On Jun 10, 2014, at 10:06 AM, Ronald Bonica wrote: > Hi Dino, >=20 > Given that the LISP data packet or ICMP packet may be from an = attacker, is it even safe to glean that? I think not. >=20 > = Ron >=20 >=20 >> -----Original Message----- >> From: Dino Farinacci [mailto:farinacci@gmail.com] >> Sent: Tuesday, June 10, 2014 1:04 PM >> To: Ronald Bonica >> Cc: LISP mailing list list >> Subject: Re: [lisp] Restarting last call on LISP threats >>=20 >>=20 >> On Jun 10, 2014, at 9:57 AM, Ronald Bonica = wrote: >>=20 >>> Earlier in this thread, we agreed that when LISP is deployed on the = global >> Internet, mapping information cannot be gleaned safely from incoming = LISP >> data packets. Following that train of thought, when LISP is deployed = on the >> global Internet, is it safe to glean routing locator reachability = information >> from incoming LISP data packets as described in RFC 6830, Section = 6.3, bullet >> 1. If not, I think that we need to mention this in the threats = document. >>=20 >> What you can glean is that the source RLOC is up, but you cannot = glean your >> path to it is reachable. >>=20 >>> Given that ICMP packets are easily spoofed, when LISP is deployed on = the >> global Internet, is it safe to glean routing locator reachability = information >> from incoming ICMP packets as described in RFC 6830, Section 6.3, = bullet 2 >> and bullet 4. If not, I think that we need to mention this in the = threats >> document. >>=20 >> What you can glean is that the source RLOC is up, but you cannot = glean your >> path to it is reachable. >>=20 >> Dino >>=20 >=20 From nobody Tue Jun 10 12:38:24 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A7481A02D2 for ; Tue, 10 Jun 2014 12:37:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.902 X-Spam-Level: X-Spam-Status: No, score=-101.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 vnku4Fs-2Kro for ; Tue, 10 Jun 2014 12:37:45 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0139.outbound.protection.outlook.com [207.46.163.139]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BC2D1A027F for ; Tue, 10 Jun 2014 12:37:45 -0700 (PDT) Received: from CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) by CO1PR05MB441.namprd05.prod.outlook.com (10.141.73.147) with Microsoft SMTP Server (TLS) id 15.0.949.11; Tue, 10 Jun 2014 19:37:43 +0000 Received: from CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.68]) by CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.92]) with mapi id 15.00.0949.001; Tue, 10 Jun 2014 19:37:43 +0000 From: Ronald Bonica To: Dino Farinacci Thread-Topic: [lisp] Restarting last call on LISP threats Thread-Index: AQHPhM36v1z5qcx3GU+Mb5TT+ra0YZtqkpgAgAAFDICAACBwoA== Date: Tue, 10 Jun 2014 19:37:41 +0000 Message-ID: <40ecc5d773874ecdbdc05763004acfa7@CO1PR05MB442.namprd05.prod.outlook.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.11] x-microsoft-antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: x-forefront-prvs: 0238AEEDB0 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(428001)(24454002)(51444003)(51704005)(377454003)(13464003)(199002)(189002)(76576001)(20776003)(80022001)(46102001)(79102001)(81342001)(19580405001)(66066001)(19580395003)(83322001)(74316001)(85852003)(64706001)(77982001)(92566001)(1411001)(83072002)(76482001)(86362001)(33646001)(101416001)(87936001)(21056001)(2656002)(76176999)(50986999)(54356999)(99396002)(99286001)(31966008)(81542001)(74662001)(4396001)(74502001)(93886003)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB441; H:CO1PR05MB442.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (: juniper.net does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=rbonica@juniper.net; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/POphdXuGhKQKV5DNtjUFWk0U2yo Cc: LISP mailing list list Subject: Re: [lisp] Restarting last call on LISP threats X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 19:37:50 -0000 Dino, Exactly! So, assume the following: - LISP is deployed on the global Internet - An RLOC is mapped to some number of EID prefixes - For a subset of those EID prefixes, the above mentioned RLOC is preferred - An ITR receives a hint indicating that the RLOC is down (either through a= LISP data packet or an ICMP message) The ITR will verify RLOC reachability (possibly by polling the RLOC). But u= ntil the ITR has receives a response to its poll, how should it behave? Sho= uld it continue sending traffic though the above mentioned RLOC? Or should = it begin to send traffic through another RLOC, if one exists? I don't see a= normative recommendation.=20 However, both behaviors have their drawbacks and could be vectors for attac= k. = Ron > -----Original Message----- > From: Dino Farinacci [mailto:farinacci@gmail.com] > Sent: Tuesday, June 10, 2014 1:23 PM > To: Ronald Bonica > Cc: LISP mailing list list > Subject: Re: [lisp] Restarting last call on LISP threats >=20 > As I keep saying Ron, you need to verify anything you intend to glean. Th= e > spec says the gleaning is "a hint" and not gospel. >=20 > Dino >=20 > On Jun 10, 2014, at 10:06 AM, Ronald Bonica wrote: >=20 > > Hi Dino, > > > > Given that the LISP data packet or ICMP packet may be from an attacker,= is > it even safe to glean that? I think not. > > > > > > Ron > > > > > >> -----Original Message----- > >> From: Dino Farinacci [mailto:farinacci@gmail.com] > >> Sent: Tuesday, June 10, 2014 1:04 PM > >> To: Ronald Bonica > >> Cc: LISP mailing list list > >> Subject: Re: [lisp] Restarting last call on LISP threats > >> > >> > >> On Jun 10, 2014, at 9:57 AM, Ronald Bonica wrote= : > >> > >>> Earlier in this thread, we agreed that when LISP is deployed on the > >>> global > >> Internet, mapping information cannot be gleaned safely from incoming > >> LISP data packets. Following that train of thought, when LISP is > >> deployed on the global Internet, is it safe to glean routing locator > >> reachability information from incoming LISP data packets as described > >> in RFC 6830, Section 6.3, bullet 1. If not, I think that we need to me= ntion > this in the threats document. > >> > >> What you can glean is that the source RLOC is up, but you cannot > >> glean your path to it is reachable. > >> > >>> Given that ICMP packets are easily spoofed, when LISP is deployed on > >>> the > >> global Internet, is it safe to glean routing locator reachability > >> information from incoming ICMP packets as described in RFC 6830, > >> Section 6.3, bullet 2 and bullet 4. If not, I think that we need to > >> mention this in the threats document. > >> > >> What you can glean is that the source RLOC is up, but you cannot > >> glean your path to it is reachable. > >> > >> Dino > >> > > From nobody Tue Jun 10 12:47:25 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 732B81A02B0 for ; Tue, 10 Jun 2014 12:47:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 jrXzt-5f5K8Q for ; Tue, 10 Jun 2014 12:47:06 -0700 (PDT) Received: from mail-pd0-x22a.google.com (mail-pd0-x22a.google.com [IPv6:2607:f8b0:400e:c02::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3673F1A02A6 for ; Tue, 10 Jun 2014 12:47:06 -0700 (PDT) Received: by mail-pd0-f170.google.com with SMTP id g10so6447211pdj.1 for ; Tue, 10 Jun 2014 12:47:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=MTQqPd/I2TJLTIfOkMpwMitisFmxuts7zj8oCraikAY=; b=HbtbRV35PdmKxS8PuiTd0KxrHo8a2BqqVXulg24w2YpEf1CDI0gCLAm5vKcyOytfgC F/ZrMEGrTvBUnSbvTZVaQsGQdZG5/xjtpmYqhqEwihGH2j1rqXrDCEWTSOFNidowCRle oPO/B+B8ASLuO6MvbwCqJOOq83hpUatDznSai0+Ci3DrFr33/LaMb6FDoW54DjTKjMgX rQOFoKaDt/gp8+xFrunXl5PEmA9xHP7rjOyKNiTulkm0GkLSKpYr6btMzkM/lKq1RhBb tQX8+OhJg3MxCFyQ+uj0wzVBVtlwSY74SsamjKBjZuIiIiwPvYmMq6epNn1IsbV/8Ow0 Hc6w== X-Received: by 10.66.251.136 with SMTP id zk8mr7569820pac.137.1402429625894; Tue, 10 Jun 2014 12:47:05 -0700 (PDT) Received: from [192.168.1.174] ([207.145.253.66]) by mx.google.com with ESMTPSA id gg3sm70962417pbc.34.2014.06.10.12.46.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 10 Jun 2014 12:47:05 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Dino Farinacci In-Reply-To: <40ecc5d773874ecdbdc05763004acfa7@CO1PR05MB442.namprd05.prod.outlook.com> Date: Tue, 10 Jun 2014 12:46:50 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4E18B802-939B-4332-B800-AA3F7BEC5661@gmail.com> References: <40ecc5d773874ecdbdc05763004acfa7@CO1PR05MB442.namprd05.prod.outlook.com> To: Ronald Bonica X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/o7puARtregnry_v4ifW4uS4NmAQ Cc: LISP mailing list list Subject: Re: [lisp] Restarting last call on LISP threats X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 19:47:07 -0000 > - An ITR receives a hint indicating that the RLOC is down (either = through a LISP data packet or an ICMP message) How? The way you say does not give any such indication. > The ITR will verify RLOC reachability (possibly by polling the RLOC). = But until the ITR has receives a response It needs to verify the mapping first. It needs to determine if the = source-EID in the data packet is associated with the RLOC that was in = the data packet from the mapping database system. > to its poll, how should it behave? Should it continue sending traffic = though the above mentioned RLOC? Or should it begin to send traffic = through another RLOC, if one exists? I don't see a normative = recommendation.=20 Verify the mapping, then cache it locally as "verified" and then = RLOC-probe the best priority RLOCs so you can see if they are reachable. = You can do this before encapsulating packets to the RLOCs or = concurrently. Depending if your implementation wants to take a leap of = faith. > However, both behaviors have their drawbacks and could be vectors for = attack. You did not describe the problem well, so no conclusions should be made. = ;-) Dino >=20 > = Ron >=20 >=20 >> -----Original Message----- >> From: Dino Farinacci [mailto:farinacci@gmail.com] >> Sent: Tuesday, June 10, 2014 1:23 PM >> To: Ronald Bonica >> Cc: LISP mailing list list >> Subject: Re: [lisp] Restarting last call on LISP threats >>=20 >> As I keep saying Ron, you need to verify anything you intend to = glean. The >> spec says the gleaning is "a hint" and not gospel. >>=20 >> Dino >>=20 >> On Jun 10, 2014, at 10:06 AM, Ronald Bonica = wrote: >>=20 >>> Hi Dino, >>>=20 >>> Given that the LISP data packet or ICMP packet may be from an = attacker, is >> it even safe to glean that? I think not. >>>=20 >>>=20 >>> Ron >>>=20 >>>=20 >>>> -----Original Message----- >>>> From: Dino Farinacci [mailto:farinacci@gmail.com] >>>> Sent: Tuesday, June 10, 2014 1:04 PM >>>> To: Ronald Bonica >>>> Cc: LISP mailing list list >>>> Subject: Re: [lisp] Restarting last call on LISP threats >>>>=20 >>>>=20 >>>> On Jun 10, 2014, at 9:57 AM, Ronald Bonica = wrote: >>>>=20 >>>>> Earlier in this thread, we agreed that when LISP is deployed on = the >>>>> global >>>> Internet, mapping information cannot be gleaned safely from = incoming >>>> LISP data packets. Following that train of thought, when LISP is >>>> deployed on the global Internet, is it safe to glean routing = locator >>>> reachability information from incoming LISP data packets as = described >>>> in RFC 6830, Section 6.3, bullet 1. If not, I think that we need to = mention >> this in the threats document. >>>>=20 >>>> What you can glean is that the source RLOC is up, but you cannot >>>> glean your path to it is reachable. >>>>=20 >>>>> Given that ICMP packets are easily spoofed, when LISP is deployed = on >>>>> the >>>> global Internet, is it safe to glean routing locator reachability >>>> information from incoming ICMP packets as described in RFC 6830, >>>> Section 6.3, bullet 2 and bullet 4. If not, I think that we need to >>>> mention this in the threats document. >>>>=20 >>>> What you can glean is that the source RLOC is up, but you cannot >>>> glean your path to it is reachable. >>>>=20 >>>> Dino >>>>=20 >>>=20 >=20 From nobody Wed Jun 11 08:08:56 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1165A1B2838 for ; Wed, 11 Jun 2014 02:04:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 Wbq4wrfQ_Y9p for ; Wed, 11 Jun 2014 02:04:04 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DAAF1B283D for ; Wed, 11 Jun 2014 02:03:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: lisp@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140611090347.7857.8101.idtracker@ietfa.amsl.com> Date: Wed, 11 Jun 2014 02:03:47 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/OQBxZjxHW2xbFzIHWPf-wuybxyw X-Mailman-Approved-At: Wed, 11 Jun 2014 08:08:46 -0700 Subject: [lisp] Milestones changed for lisp WG X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 09:04:06 -0000 Deleted milestone "Submit a deployment model document to the IESG for publication as an Experimental RFC". Deleted milestone "Submit a data model (e.g., a MIB) document to the IESG for publication as an Experimental RFC". URL: http://datatracker.ietf.org/wg/lisp/charter/ From nobody Wed Jun 11 08:09:02 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 475D11B2843 for ; Wed, 11 Jun 2014 04:16:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 9xFCRNJLd3Kd for ; Wed, 11 Jun 2014 04:16:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CA6221B2860 for ; Wed, 11 Jun 2014 04:16:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: lisp@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140611111632.27345.39563.idtracker@ietfa.amsl.com> Date: Wed, 11 Jun 2014 04:16:32 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/m0koFaSz4v4cOm4KciYaEUwqESY X-Mailman-Approved-At: Wed, 11 Jun 2014 08:08:49 -0700 Subject: [lisp] Milestones changed for lisp WG X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 11:16:35 -0000 URL: http://datatracker.ietf.org/wg/lisp/charter/ From nobody Wed Jun 11 09:38:41 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53BC31A017F for ; Wed, 11 Jun 2014 09:38:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 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_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 1n5xE9RIOGx5 for ; Wed, 11 Jun 2014 09:38:38 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E93631A016C for ; Wed, 11 Jun 2014 09:38:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=669; q=dns/txt; s=iport; t=1402504718; x=1403714318; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=GyEVINv7Ye9+y+xTCZUmW0NynxJj4oe6GZbGjFDsnKM=; b=dWWTQPR3swRbrX4j1gRRngktCBPRb7d3GIo1v8aaFOv9ZENXs0TDEA2h p6e81uf54sKfgEM7e82M4ithcWb2qMfe2WQSSXnV3sMbi/hRbZAPWsKgK qm/OOB7U7nLUJYp8rQn6swcc6zJNCdG8KDmuIvs4Lomk0Cfsilho514Kh o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqYFAMOFmFOtJV2T/2dsb2JhbABagw1SWaphAQEBAQEBBQGRX4c8AYEGFnWEAwEBAQMBAQEBNzQLBQsCAQg2ECEGCyUCBA4FiC4DCQgNyV4NhhMTBIVchlqCIweDK4EWBJYkghGBeY1QhXuDPIIv X-IronPort-AV: E=Sophos;i="5.01,459,1400025600"; d="scan'208";a="52227274" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-2.cisco.com with ESMTP; 11 Jun 2014 16:38:37 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s5BGcbJs031771 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 11 Jun 2014 16:38:37 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.249]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0123.003; Wed, 11 Jun 2014 11:38:37 -0500 From: "Darrel Lewis (darlewis)" To: Damien Saucez Thread-Topic: [lisp] LISP EID Block - IPR disclosures Thread-Index: AQHPhZOW7jEBB00+aEOk23yeHB/WNA== Date: Wed, 11 Jun 2014 16:38:35 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.253.184] Content-Type: text/plain; charset="us-ascii" Content-ID: <07AFFDBBBFDDA34E8DA927B71E8951CC@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/ehQbLOFW778X0tBEj2u6-CK6dxU Cc: "draft-ietf-lisp-eid-block@tools.ietf.org" , LISP mailing list list Subject: Re: [lisp] LISP EID Block - IPR disclosures X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 16:38:39 -0000 I am not aware of any IPR pertaining to this document. -Darrel On Jun 10, 2014, at 8:09 AM, Damien Saucez wrote: > Dear all, >=20 > I am the document shepherd for draft-ietf-lisp-eid-block-08. In order > for me to complete the shepherd writeup, I would like first to ask the > authors and the WG if any and all appropriate IPR disclosures required > for full conformance with the provisions of BCP 78 and BCP 79 have > already been filed. >=20 > Best regards, >=20 > Damien Saucez=20 >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From nobody Wed Jun 11 12:52:37 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 025D41B2896 for ; Wed, 11 Jun 2014 12:52:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 TQ03bB5RIX5s for ; Wed, 11 Jun 2014 12:52:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B4DD51B28A1 for ; Wed, 11 Jun 2014 12:52:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: lisp@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140611195232.27962.54929.idtracker@ietfa.amsl.com> Date: Wed, 11 Jun 2014 12:52:32 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/8ptovYdyEBqoum6QUaHMGFavynI Subject: [lisp] Milestones changed for lisp WG X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 19:52:35 -0000 Changed milestone "Submit a deployment model document to the IESG for publication as an Experimental RFC", set state to active from review, accepting new milestone. URL: http://datatracker.ietf.org/wg/lisp/charter/ From nobody Wed Jun 11 12:52:58 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FCEE1A026B for ; Wed, 11 Jun 2014 12:52:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 RAIMy6XZ1L_t for ; Wed, 11 Jun 2014 12:52:56 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F33101A0273 for ; Wed, 11 Jun 2014 12:52:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: lisp@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140611195254.31775.66142.idtracker@ietfa.amsl.com> Date: Wed, 11 Jun 2014 12:52:54 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/rJ4Fm8QDoPVVc6BA4Uq3sJ5GHLM Subject: [lisp] Milestones changed for lisp WG X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 19:52:57 -0000 Changed milestone "Submit a data model (e.g., a MIB) document to the IESG for publication as an Experimental RFC", set state to active from review, accepting new milestone. URL: http://datatracker.ietf.org/wg/lisp/charter/ From nobody Wed Jun 11 15:28:45 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 881071B289B for ; Wed, 11 Jun 2014 15:28:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 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_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 0Jwmx4yZkx9E for ; Wed, 11 Jun 2014 15:28:42 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1774B1A02ED for ; Wed, 11 Jun 2014 15:28:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2867; q=dns/txt; s=iport; t=1402525722; x=1403735322; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=DacJ2RA6N01UNcC6aQjIqVZ1DyQdNllH0WUi47AFI/s=; b=OMbRp1Sm4zJcvqyojkME/+kXa/OwZ18Ul9RZ+Al9eDu6nyI/+MKMvbbN a09R4WEENpLPu2j0afQP2ygreHQpCs/BBCbSw6CE76gYJoyE1o8MmJGPQ foDHtwWa5fd7T7RyIDUiwSOdzY/zVVBbF/jMgNSg5sWoCK7PD1hqxJB7i k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqcFAMLXmFOtJV2c/2dsb2JhbABagw1SWapPAQEBAQEBBQGRX4c8AYEJFnWEAwEBAQMBAQEBawsFBwQCAQgRBAEBAScHIQYLFAkIAgQOBYguAwkIDcooDYYTEwSFXIZagUslMwcGgyWBFgSYNYF5jVCFe4M8gW1C X-IronPort-AV: E=Sophos;i="5.01,460,1400025600"; d="scan'208";a="52327829" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-4.cisco.com with ESMTP; 11 Jun 2014 22:28:41 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s5BMSfwl018863 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 11 Jun 2014 22:28:41 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.249]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0123.003; Wed, 11 Jun 2014 17:28:40 -0500 From: "Darrel Lewis (darlewis)" To: "Joel M. Halpern" Thread-Topic: [lisp] Restarting last call on LISP threats Thread-Index: AQHPhcR+s8rmtoayqUOOlE1jvvjGFA== Date: Wed, 11 Jun 2014 22:28:39 +0000 Message-ID: <3F96F55B-ED0A-436A-97F5-2196B81A1B91@cisco.com> References: <53973DAE.4050000@joelhalpern.com> In-Reply-To: <53973DAE.4050000@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.119.83] Content-Type: text/plain; charset="Windows-1252" Content-ID: <06C0B1794AC280489D20C5EBA6CFEE44@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/5QVraKCGH9XOafFln7VzwME8gVc Cc: LISP mailing list list Subject: Re: [lisp] Restarting last call on LISP threats X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 22:28:43 -0000 On Jun 10, 2014, at 10:17 AM, Joel M. Halpern wrote: > I think that the treat scopes for the two cases are different. Gleaning = new RLOCs is clearly a significant risk. > Gleaning the liveness of an RLOC from the fact that it appears to be talk= ing to you is a much lower risk. With a much higher benefit. I have no pr= oblem with noting that there is a risk, albeit somewhat complex. But it sh= ould not be viewed in the same manner. (All security is a matter of costs = and benefits.) And to add one more bit of detail here, gleaning the liveness of an RLOC wh= o=92s status bit has changed can be (and is in our IOS implementation) veri= fied by a rate-limited RLOC Probe. -Darrel >=20 > Yours, > Joel >=20 > On 6/10/14, 1:06 PM, Ronald Bonica wrote: >> Hi Dino, >>=20 >> Given that the LISP data packet or ICMP packet may be from an attacker, = is it even safe to glean that? I think not. >>=20 >> = Ron >>=20 >>=20 >>> -----Original Message----- >>> From: Dino Farinacci [mailto:farinacci@gmail.com] >>> Sent: Tuesday, June 10, 2014 1:04 PM >>> To: Ronald Bonica >>> Cc: LISP mailing list list >>> Subject: Re: [lisp] Restarting last call on LISP threats >>>=20 >>>=20 >>> On Jun 10, 2014, at 9:57 AM, Ronald Bonica wrote: >>>=20 >>>> Earlier in this thread, we agreed that when LISP is deployed on the gl= obal >>> Internet, mapping information cannot be gleaned safely from incoming LI= SP >>> data packets. Following that train of thought, when LISP is deployed on= the >>> global Internet, is it safe to glean routing locator reachability infor= mation >>> from incoming LISP data packets as described in RFC 6830, Section 6.3, = bullet >>> 1. If not, I think that we need to mention this in the threats document= . >>>=20 >>> What you can glean is that the source RLOC is up, but you cannot glean = your >>> path to it is reachable. >>>=20 >>>> Given that ICMP packets are easily spoofed, when LISP is deployed on t= he >>> global Internet, is it safe to glean routing locator reachability infor= mation >>> from incoming ICMP packets as described in RFC 6830, Section 6.3, bulle= t 2 >>> and bullet 4. If not, I think that we need to mention this in the threa= ts >>> document. >>>=20 >>> What you can glean is that the source RLOC is up, but you cannot glean = your >>> path to it is reachable. >>>=20 >>> Dino >>>=20 >>=20 >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp >>=20 >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From nobody Wed Jun 11 17:17:51 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 037971B28F0 for ; Wed, 11 Jun 2014 17:17:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.902 X-Spam-Level: X-Spam-Status: No, score=-101.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 tAj4JE8VbsI4 for ; Wed, 11 Jun 2014 17:17:48 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0142.outbound.protection.outlook.com [207.46.163.142]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03F601B28E0 for ; Wed, 11 Jun 2014 17:17:47 -0700 (PDT) Received: from CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) by CO1PR05MB441.namprd05.prod.outlook.com (10.141.73.147) with Microsoft SMTP Server (TLS) id 15.0.949.11; Thu, 12 Jun 2014 00:17:45 +0000 Received: from CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.68]) by CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.92]) with mapi id 15.00.0949.001; Thu, 12 Jun 2014 00:17:45 +0000 From: Ronald Bonica To: "Darrel Lewis (darlewis)" , "Joel M. Halpern" Thread-Topic: [lisp] Restarting last call on LISP threats Thread-Index: AQHPhM36v1z5qcx3GU+Mb5TT+ra0YZtqkpgAgAADiACAAek/gIAAHWtg Date: Thu, 12 Jun 2014 00:17:44 +0000 Message-ID: <3608b211928f4d39b0c5a0c18da0ef29@CO1PR05MB442.namprd05.prod.outlook.com> References: <53973DAE.4050000@joelhalpern.com> <3F96F55B-ED0A-436A-97F5-2196B81A1B91@cisco.com> In-Reply-To: <3F96F55B-ED0A-436A-97F5-2196B81A1B91@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.12] x-microsoft-antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: x-forefront-prvs: 02408926C4 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(428001)(24454002)(51444003)(51704005)(479174003)(377454003)(13464003)(199002)(189002)(20776003)(80022001)(46102001)(85852003)(83072002)(76482001)(86362001)(66066001)(76576001)(64706001)(77982001)(83322001)(74316001)(92566001)(33646001)(87936001)(101416001)(21056001)(2656002)(99286001)(54356999)(76176999)(50986999)(99396002)(31966008)(81542001)(19580405001)(81342001)(79102001)(15975445006)(19580395003)(93886003)(74662001)(4396001)(74502001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB441; H:CO1PR05MB442.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (: juniper.net does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=rbonica@juniper.net; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/iraMo3pZQODDtmNl7kte6sAz-F0 Cc: LISP mailing list list Subject: Re: [lisp] Restarting last call on LISP threats X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 00:17:51 -0000 Hi Darrel, Does IOS implement a single RLOC Probe rate limiter (i.e. one rate limiter = per box)? Or does it implement one rate limiter per RLOC? Ron > -----Original Message----- > From: Darrel Lewis (darlewis) [mailto:darlewis@cisco.com] > Sent: Wednesday, June 11, 2014 6:29 PM > To: Joel M. Halpern > Cc: Darrel Lewis (darlewis); Ronald Bonica; Dino Farinacci; LISP mailing = list list > Subject: Re: [lisp] Restarting last call on LISP threats >=20 >=20 > On Jun 10, 2014, at 10:17 AM, Joel M. Halpern > wrote: >=20 > > I think that the treat scopes for the two cases are different. Gleanin= g new > RLOCs is clearly a significant risk. > > Gleaning the liveness of an RLOC from the fact that it appears to be > > talking to you is a much lower risk. With a much higher benefit. I > > have no problem with noting that there is a risk, albeit somewhat > > complex. But it should not be viewed in the same manner. (All > > security is a matter of costs and benefits.) >=20 > And to add one more bit of detail here, gleaning the liveness of an RLOC > who's status bit has changed can be (and is in our IOS implementation) > verified by a rate-limited RLOC Probe. >=20 > -Darrel >=20 > > > > Yours, > > Joel > > > > On 6/10/14, 1:06 PM, Ronald Bonica wrote: > >> Hi Dino, > >> > >> Given that the LISP data packet or ICMP packet may be from an attacker= , > is it even safe to glean that? I think not. > >> > >> > >> Ron > >> > >> > >>> -----Original Message----- > >>> From: Dino Farinacci [mailto:farinacci@gmail.com] > >>> Sent: Tuesday, June 10, 2014 1:04 PM > >>> To: Ronald Bonica > >>> Cc: LISP mailing list list > >>> Subject: Re: [lisp] Restarting last call on LISP threats > >>> > >>> > >>> On Jun 10, 2014, at 9:57 AM, Ronald Bonica > wrote: > >>> > >>>> Earlier in this thread, we agreed that when LISP is deployed on the > >>>> global > >>> Internet, mapping information cannot be gleaned safely from incoming > >>> LISP data packets. Following that train of thought, when LISP is > >>> deployed on the global Internet, is it safe to glean routing locator > >>> reachability information from incoming LISP data packets as > >>> described in RFC 6830, Section 6.3, bullet 1. If not, I think that we= need to > mention this in the threats document. > >>> > >>> What you can glean is that the source RLOC is up, but you cannot > >>> glean your path to it is reachable. > >>> > >>>> Given that ICMP packets are easily spoofed, when LISP is deployed > >>>> on the > >>> global Internet, is it safe to glean routing locator reachability > >>> information from incoming ICMP packets as described in RFC 6830, > >>> Section 6.3, bullet 2 and bullet 4. If not, I think that we need to > >>> mention this in the threats document. > >>> > >>> What you can glean is that the source RLOC is up, but you cannot > >>> glean your path to it is reachable. > >>> > >>> Dino > >>> > >> > >> _______________________________________________ > >> lisp mailing list > >> lisp@ietf.org > >> https://www.ietf.org/mailman/listinfo/lisp > >> > > > > _______________________________________________ > > lisp mailing list > > lisp@ietf.org > > https://www.ietf.org/mailman/listinfo/lisp From nobody Thu Jun 12 05:07:56 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EA6C1B285B for ; Thu, 12 Jun 2014 05:07:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 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, HELO_EQ_FR=0.35, SPF_PASS=-0.001] autolearn=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 09Zams9NLttz for ; Thu, 12 Jun 2014 05:07:50 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8D151B2824 for ; Thu, 12 Jun 2014 05:07:49 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id bs8so2833245wib.15 for ; Thu, 12 Jun 2014 05:07:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=DHWzbuDcYDq+U0D58g7R0Yfkfuiee32NWDX0l115Y3Y=; b=opafUXPndt6NhVtM6lWvpZ3X0cbOlf4uHHDfZgqtnVi4amXpfW5wlkBz4RHvYFN8L+ 4QaCa7/j6z3Spo+0EdcVMvKlLIQmNeRN8yEoTnSq08bRV+WfKqfpP3PCJx/avRt2dnu7 P+IIyx0xFXp5CzgLIKpprURRFg229dVDeQRNF1GITx9vJ615YPwOjgb8+b7xdbLWX4Re TuUaQeLK/t9ISeqwONVNlzy8ziwhMHMCXmkqgHA+amJrFdXUThXXbfyCABxBwwZGs7/k 2KLpkD8yt6Qf0q64+STufp+KVu5XgCqdQFmGjz2Lift7AuyInr/UAITZFqirexVB9oWT 9k5g== X-Received: by 10.180.75.212 with SMTP id e20mr5894978wiw.5.1402574868270; Thu, 12 Jun 2014 05:07:48 -0700 (PDT) Received: from faucon.inria.fr (faucon.inria.fr. [138.96.201.73]) by mx.google.com with ESMTPSA id rw4sm1240434wjb.44.2014.06.12.05.07.47 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 12 Jun 2014 05:07:47 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Damien Saucez In-Reply-To: <40ecc5d773874ecdbdc05763004acfa7@CO1PR05MB442.namprd05.prod.outlook.com> Date: Thu, 12 Jun 2014 14:07:46 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <40ecc5d773874ecdbdc05763004acfa7@CO1PR05MB442.namprd05.prod.outlook.com> To: Ronald Bonica X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/utjGCsFOIVzu99FBtUdDMhurYKg Cc: LISP mailing list list Subject: Re: [lisp] Restarting last call on LISP threats X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 12:07:51 -0000 Hello, I am not sure I understand exactly what you are proposing. How can a LISP router decide that a RLOC is done by simply receiving an ICMP packet from an attacker (except with LSB that is discussed in Sec 4.3.2.1. )? All the other techniques are triggered by the LISP router and are protected by the nonce. Could you describe precisely the attack you have in mind? The only think I can see is relying on the birthday paradox but that is a completely different story. Damien Saucez=20 On 10 Jun 2014, at 21:37, Ronald Bonica wrote: > Dino, >=20 > Exactly! So, assume the following: >=20 > - LISP is deployed on the global Internet > - An RLOC is mapped to some number of EID prefixes > - For a subset of those EID prefixes, the above mentioned RLOC is = preferred > - An ITR receives a hint indicating that the RLOC is down (either = through a LISP data packet or an ICMP message) >=20 > The ITR will verify RLOC reachability (possibly by polling the RLOC). = But until the ITR has receives a response to its poll, how should it = behave? Should it continue sending traffic though the above mentioned = RLOC? Or should it begin to send traffic through another RLOC, if one = exists? I don't see a normative recommendation.=20 >=20 > However, both behaviors have their drawbacks and could be vectors for = attack. >=20 > = Ron >=20 >=20 >> -----Original Message----- >> From: Dino Farinacci [mailto:farinacci@gmail.com] >> Sent: Tuesday, June 10, 2014 1:23 PM >> To: Ronald Bonica >> Cc: LISP mailing list list >> Subject: Re: [lisp] Restarting last call on LISP threats >>=20 >> As I keep saying Ron, you need to verify anything you intend to = glean. The >> spec says the gleaning is "a hint" and not gospel. >>=20 >> Dino >>=20 >> On Jun 10, 2014, at 10:06 AM, Ronald Bonica = wrote: >>=20 >>> Hi Dino, >>>=20 >>> Given that the LISP data packet or ICMP packet may be from an = attacker, is >> it even safe to glean that? I think not. >>>=20 >>>=20 >>> Ron >>>=20 >>>=20 >>>> -----Original Message----- >>>> From: Dino Farinacci [mailto:farinacci@gmail.com] >>>> Sent: Tuesday, June 10, 2014 1:04 PM >>>> To: Ronald Bonica >>>> Cc: LISP mailing list list >>>> Subject: Re: [lisp] Restarting last call on LISP threats >>>>=20 >>>>=20 >>>> On Jun 10, 2014, at 9:57 AM, Ronald Bonica = wrote: >>>>=20 >>>>> Earlier in this thread, we agreed that when LISP is deployed on = the >>>>> global >>>> Internet, mapping information cannot be gleaned safely from = incoming >>>> LISP data packets. Following that train of thought, when LISP is >>>> deployed on the global Internet, is it safe to glean routing = locator >>>> reachability information from incoming LISP data packets as = described >>>> in RFC 6830, Section 6.3, bullet 1. If not, I think that we need to = mention >> this in the threats document. >>>>=20 >>>> What you can glean is that the source RLOC is up, but you cannot >>>> glean your path to it is reachable. >>>>=20 >>>>> Given that ICMP packets are easily spoofed, when LISP is deployed = on >>>>> the >>>> global Internet, is it safe to glean routing locator reachability >>>> information from incoming ICMP packets as described in RFC 6830, >>>> Section 6.3, bullet 2 and bullet 4. If not, I think that we need to >>>> mention this in the threats document. >>>>=20 >>>> What you can glean is that the source RLOC is up, but you cannot >>>> glean your path to it is reachable. >>>>=20 >>>> Dino >>>>=20 >>>=20 >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From nobody Thu Jun 12 08:10:28 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE5931B2A96 for ; Thu, 12 Jun 2014 08:10:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 DMh9tOiNRGM4 for ; Thu, 12 Jun 2014 08:10:08 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0206.outbound.protection.outlook.com [207.46.163.206]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FE721B2A81 for ; Thu, 12 Jun 2014 08:10:02 -0700 (PDT) Received: from CO2PR05MB636.namprd05.prod.outlook.com (10.141.199.24) by BLUPR05MB434.namprd05.prod.outlook.com (10.141.27.147) with Microsoft SMTP Server (TLS) id 15.0.954.9; Thu, 12 Jun 2014 15:09:40 +0000 Received: from CO2PR05MB636.namprd05.prod.outlook.com ([10.141.199.24]) by CO2PR05MB636.namprd05.prod.outlook.com ([10.141.199.24]) with mapi id 15.00.0954.000; Thu, 12 Jun 2014 15:09:38 +0000 From: Ross Callon To: Damien Saucez , Ronald Bonica Thread-Topic: [lisp] Restarting last call on LISP threats Thread-Index: AQHPhM4EWF5k26Wu0Uq+sllpwWiB/5tqkxcAgAAEjYCAACWigIACpvUAgAAxObA= Date: Thu, 12 Jun 2014 15:09:37 +0000 Message-ID: References: <40ecc5d773874ecdbdc05763004acfa7@CO1PR05MB442.namprd05.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.18] x-microsoft-antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: x-forefront-prvs: 02408926C4 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(428001)(13464003)(377454003)(51704005)(51444003)(24454002)(189002)(199002)(76576001)(74502001)(93886003)(2656002)(87936001)(46102001)(33646001)(76482001)(77982001)(74316001)(85852003)(83072002)(86362001)(81542001)(77096999)(54356999)(99286001)(99396002)(76176999)(101416001)(50986999)(74662001)(19580405001)(19580395003)(83322001)(4396001)(15975445006)(66066001)(80022001)(79102001)(20776003)(81342001)(64706001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR05MB434; H:CO2PR05MB636.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: juniper.net does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=rcallon@juniper.net; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/zs3lqsQWbqqyiTxugprvQqfVJLw Cc: LISP mailing list list Subject: Re: [lisp] Restarting last call on LISP threats X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 15:10:13 -0000 > Could you describe precisely the attack you have in mind? The only > think I can see is relying on the birthday paradox but that is a > completely different story. If an attacker is on-path it could see the nonce's (assuming that the LISP = header is not encrypted, regardless of whether the data packet is encrypted= ). This could be an issue if the attacker is physically on-path.=20 This could also be an issue for attackers which are physically off-path if = gleaning is used, since an attacker could use a gleaning attack to temporar= ily insert itself on-path, which in turn would allow it to see the nonce.=20 Ross -----Original Message----- From: lisp [mailto:lisp-bounces@ietf.org] On Behalf Of Damien Saucez Sent: Thursday, June 12, 2014 8:08 AM To: Ronald Bonica Cc: LISP mailing list list Subject: Re: [lisp] Restarting last call on LISP threats Hello, I am not sure I understand exactly what you are proposing. How can a LISP router decide that a RLOC is done by simply receiving an ICMP packet from an attacker (except with LSB that is discussed in Sec 4.3.2.1. )? All the other techniques are triggered by the LISP router and are protected by the nonce. Could you describe precisely the attack you have in mind? The only think I can see is relying on the birthday paradox but that is a completely different story. Damien Saucez=20 On 10 Jun 2014, at 21:37, Ronald Bonica wrote: > Dino, >=20 > Exactly! So, assume the following: >=20 > - LISP is deployed on the global Internet > - An RLOC is mapped to some number of EID prefixes > - For a subset of those EID prefixes, the above mentioned RLOC is preferr= ed > - An ITR receives a hint indicating that the RLOC is down (either through= a LISP data packet or an ICMP message) >=20 > The ITR will verify RLOC reachability (possibly by polling the RLOC). But= until the ITR has receives a response to its poll, how should it behave? S= hould it continue sending traffic though the above mentioned RLOC? Or shoul= d it begin to send traffic through another RLOC, if one exists? I don't see= a normative recommendation.=20 >=20 > However, both behaviors have their drawbacks and could be vectors for att= ack. >=20 > = Ron >=20 >=20 >> -----Original Message----- >> From: Dino Farinacci [mailto:farinacci@gmail.com] >> Sent: Tuesday, June 10, 2014 1:23 PM >> To: Ronald Bonica >> Cc: LISP mailing list list >> Subject: Re: [lisp] Restarting last call on LISP threats >>=20 >> As I keep saying Ron, you need to verify anything you intend to glean. T= he >> spec says the gleaning is "a hint" and not gospel. >>=20 >> Dino >>=20 >> On Jun 10, 2014, at 10:06 AM, Ronald Bonica wrote: >>=20 >>> Hi Dino, >>>=20 >>> Given that the LISP data packet or ICMP packet may be from an attacker,= is >> it even safe to glean that? I think not. >>>=20 >>>=20 >>> Ron >>>=20 >>>=20 >>>> -----Original Message----- >>>> From: Dino Farinacci [mailto:farinacci@gmail.com] >>>> Sent: Tuesday, June 10, 2014 1:04 PM >>>> To: Ronald Bonica >>>> Cc: LISP mailing list list >>>> Subject: Re: [lisp] Restarting last call on LISP threats >>>>=20 >>>>=20 >>>> On Jun 10, 2014, at 9:57 AM, Ronald Bonica wrote= : >>>>=20 >>>>> Earlier in this thread, we agreed that when LISP is deployed on the >>>>> global >>>> Internet, mapping information cannot be gleaned safely from incoming >>>> LISP data packets. Following that train of thought, when LISP is >>>> deployed on the global Internet, is it safe to glean routing locator >>>> reachability information from incoming LISP data packets as described >>>> in RFC 6830, Section 6.3, bullet 1. If not, I think that we need to me= ntion >> this in the threats document. >>>>=20 >>>> What you can glean is that the source RLOC is up, but you cannot >>>> glean your path to it is reachable. >>>>=20 >>>>> Given that ICMP packets are easily spoofed, when LISP is deployed on >>>>> the >>>> global Internet, is it safe to glean routing locator reachability >>>> information from incoming ICMP packets as described in RFC 6830, >>>> Section 6.3, bullet 2 and bullet 4. If not, I think that we need to >>>> mention this in the threats document. >>>>=20 >>>> What you can glean is that the source RLOC is up, but you cannot >>>> glean your path to it is reachable. >>>>=20 >>>> Dino >>>>=20 >>>=20 >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From nobody Thu Jun 12 08:24:40 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1890E1A0263 for ; Thu, 12 Jun 2014 08:24:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 58oM3N4wULKZ for ; Thu, 12 Jun 2014 08:24:35 -0700 (PDT) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 647BC1A00FA for ; Thu, 12 Jun 2014 08:24:35 -0700 (PDT) Received: by mail-pa0-f44.google.com with SMTP id bj1so1117549pad.17 for ; Thu, 12 Jun 2014 08:24:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=n2QKdWkJ6cggC80x77DnZcBHR1WmTdl+BhIdH3st7Y0=; b=aucz7jGVjIqk7GaHc/vkd+AZyGAyqIr3/PtucFQFxUfoTIbooXZWYjaIdL7BceuSlL HbrAAD3LmcAmZ8j7CdT3pnvM3Pi0/CxdGvlI6bz3ZVkM31BqW38obWPmqpqjj3fjV7Wd Pt25N2v6rqa7Zk9yXxVy046ae67ps5GEUV1fv9paWgklX+ATCWy3kYKvM+WmaNOR04AI ZLa6KpFJ1zumL7jqzVcPt04i5GJjXn3hHjubekZZ3Lbj3WSE4Z0P3pW6D9LXE40rwro9 fLKegyKcbL8v2kv7MvCVYgb4ke0WFQorE+xrbIHwnw27G+crpovLViYYjuz+3JoF5o1K T54g== X-Received: by 10.69.19.139 with SMTP id gu11mr13350208pbd.36.1402586674146; Thu, 12 Jun 2014 08:24:34 -0700 (PDT) Received: from dino-macbook.wp.comcast.net (173-8-188-29-SFBA.hfc.comcastbusiness.net. [173.8.188.29]) by mx.google.com with ESMTPSA id vk5sm40549114pbc.44.2014.06.12.08.24.31 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 12 Jun 2014 08:24:32 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Dino Farinacci In-Reply-To: Date: Thu, 12 Jun 2014 08:24:31 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <40ecc5d773874ecdbdc05763004acfa7@CO1PR05MB442.namprd05.prod.outlook.com> To: Ross Callon X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/0dR0R7pzUHj9pieCi2nv65IggaA Cc: LISP mailing list list Subject: Re: [lisp] Restarting last call on LISP threats X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 15:24:38 -0000 >> Could you describe precisely the attack you have in mind? The only >> think I can see is relying on the birthday paradox but that is a >> completely different story. >=20 > If an attacker is on-path it could see the nonce's (assuming that the = LISP header is not encrypted, regardless of whether the data packet is = encrypted). This could be an issue if the attacker is physically = on-path.=20 The source EID is encrypted so it can only see a cleartext source RLOC = and can't associated it with anything. When we merge lisp-cryto logic with echo-noncing, one has to determine = if an xTR should participate in echo-noncing if the payload is not = decrypted properly. That is, if I get a echoed nonce back from an = attacker for a nonce I know I have sent and set the E-bit, and I cannot = decrypt the payload that comes from the attacker, then I don't believe = any NEW reachability information about the RLOC. > This could also be an issue for attackers which are physically = off-path if gleaning is used, since an attacker could use a gleaning = attack to temporarily insert itself on-path, which in turn would allow = it to see the nonce.=20 So by now we know there are many issues with gleaning. So we should = document them and say they shouldn't be used for the general global = Internet use-case. Dino >=20 > Ross >=20 > -----Original Message----- > From: lisp [mailto:lisp-bounces@ietf.org] On Behalf Of Damien Saucez > Sent: Thursday, June 12, 2014 8:08 AM > To: Ronald Bonica > Cc: LISP mailing list list > Subject: Re: [lisp] Restarting last call on LISP threats >=20 > Hello, >=20 > I am not sure I understand exactly what you are proposing. How can a > LISP router decide that a RLOC is done by simply receiving an ICMP > packet from an attacker (except with LSB that is discussed in Sec > 4.3.2.1. )? All the other techniques are triggered by the LISP > router and are protected by the nonce. >=20 > Could you describe precisely the attack you have in mind? The only > think I can see is relying on the birthday paradox but that is a > completely different story. >=20 > Damien Saucez=20 >=20 > On 10 Jun 2014, at 21:37, Ronald Bonica wrote: >=20 >> Dino, >>=20 >> Exactly! So, assume the following: >>=20 >> - LISP is deployed on the global Internet >> - An RLOC is mapped to some number of EID prefixes >> - For a subset of those EID prefixes, the above mentioned RLOC is = preferred >> - An ITR receives a hint indicating that the RLOC is down (either = through a LISP data packet or an ICMP message) >>=20 >> The ITR will verify RLOC reachability (possibly by polling the RLOC). = But until the ITR has receives a response to its poll, how should it = behave? Should it continue sending traffic though the above mentioned = RLOC? Or should it begin to send traffic through another RLOC, if one = exists? I don't see a normative recommendation.=20 >>=20 >> However, both behaviors have their drawbacks and could be vectors for = attack. >>=20 >> = Ron >>=20 >>=20 >>> -----Original Message----- >>> From: Dino Farinacci [mailto:farinacci@gmail.com] >>> Sent: Tuesday, June 10, 2014 1:23 PM >>> To: Ronald Bonica >>> Cc: LISP mailing list list >>> Subject: Re: [lisp] Restarting last call on LISP threats >>>=20 >>> As I keep saying Ron, you need to verify anything you intend to = glean. The >>> spec says the gleaning is "a hint" and not gospel. >>>=20 >>> Dino >>>=20 >>> On Jun 10, 2014, at 10:06 AM, Ronald Bonica = wrote: >>>=20 >>>> Hi Dino, >>>>=20 >>>> Given that the LISP data packet or ICMP packet may be from an = attacker, is >>> it even safe to glean that? I think not. >>>>=20 >>>>=20 >>>> Ron >>>>=20 >>>>=20 >>>>> -----Original Message----- >>>>> From: Dino Farinacci [mailto:farinacci@gmail.com] >>>>> Sent: Tuesday, June 10, 2014 1:04 PM >>>>> To: Ronald Bonica >>>>> Cc: LISP mailing list list >>>>> Subject: Re: [lisp] Restarting last call on LISP threats >>>>>=20 >>>>>=20 >>>>> On Jun 10, 2014, at 9:57 AM, Ronald Bonica = wrote: >>>>>=20 >>>>>> Earlier in this thread, we agreed that when LISP is deployed on = the >>>>>> global >>>>> Internet, mapping information cannot be gleaned safely from = incoming >>>>> LISP data packets. Following that train of thought, when LISP is >>>>> deployed on the global Internet, is it safe to glean routing = locator >>>>> reachability information from incoming LISP data packets as = described >>>>> in RFC 6830, Section 6.3, bullet 1. If not, I think that we need = to mention >>> this in the threats document. >>>>>=20 >>>>> What you can glean is that the source RLOC is up, but you cannot >>>>> glean your path to it is reachable. >>>>>=20 >>>>>> Given that ICMP packets are easily spoofed, when LISP is deployed = on >>>>>> the >>>>> global Internet, is it safe to glean routing locator reachability >>>>> information from incoming ICMP packets as described in RFC 6830, >>>>> Section 6.3, bullet 2 and bullet 4. If not, I think that we need = to >>>>> mention this in the threats document. >>>>>=20 >>>>> What you can glean is that the source RLOC is up, but you cannot >>>>> glean your path to it is reachable. >>>>>=20 >>>>> Dino >>>>>=20 >>>>=20 >>=20 >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From nobody Thu Jun 12 08:28:57 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B92211A00A2 for ; Thu, 12 Jun 2014 08:28:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 u3RfLQKoOBPS for ; Thu, 12 Jun 2014 08:28:53 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0145.outbound.protection.outlook.com [207.46.163.145]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF9D91A00FA for ; Thu, 12 Jun 2014 08:28:52 -0700 (PDT) Received: from CO2PR05MB636.namprd05.prod.outlook.com (10.141.199.24) by DM2PR05MB447.namprd05.prod.outlook.com (10.141.104.150) with Microsoft SMTP Server (TLS) id 15.0.949.11; Thu, 12 Jun 2014 15:28:50 +0000 Received: from CO2PR05MB636.namprd05.prod.outlook.com ([10.141.199.24]) by CO2PR05MB636.namprd05.prod.outlook.com ([10.141.199.24]) with mapi id 15.00.0954.000; Thu, 12 Jun 2014 15:28:50 +0000 From: Ross Callon To: Dino Farinacci Thread-Topic: [lisp] Restarting last call on LISP threats Thread-Index: AQHPhM4EWF5k26Wu0Uq+sllpwWiB/5tqkxcAgAAEjYCAACWigIACpvUAgAAxObCAAAXAgIAAAOZA Date: Thu, 12 Jun 2014 15:28:49 +0000 Message-ID: <47dad9120b114679bb0ec56976f4baa9@CO2PR05MB636.namprd05.prod.outlook.com> References: <40ecc5d773874ecdbdc05763004acfa7@CO1PR05MB442.namprd05.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.18] x-microsoft-antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: x-forefront-prvs: 02408926C4 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(428001)(51444003)(377454003)(164054003)(13464003)(51704005)(189002)(199002)(24454002)(85852003)(1411001)(77982001)(83072002)(74316001)(101416001)(76482001)(86362001)(87936001)(74662001)(2656002)(74502001)(4396001)(19580405001)(46102001)(83322001)(19580395003)(76576001)(99286001)(15975445006)(99396002)(81542001)(93886003)(81342001)(64706001)(20776003)(77096999)(80022001)(66066001)(79102001)(33646001)(54356999)(76176999)(50986999)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:DM2PR05MB447; H:CO2PR05MB636.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: juniper.net does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=rcallon@juniper.net; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/MscCw7ehKdsmOqBjUNkCABQsL7M Cc: LISP mailing list list Subject: Re: [lisp] Restarting last call on LISP threats X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 15:28:55 -0000 > So by now we know there are many issues with gleaning. So we should > document them and say they shouldn't be used for the general global Inter= net use-case. > > Dino This I agree with. I will go off and digest the rest. Thanks, Ross =20 > -----Original Message----- > From: lisp [mailto:lisp-bounces@ietf.org] On Behalf Of Damien Saucez > Sent: Thursday, June 12, 2014 8:08 AM > To: Ronald Bonica > Cc: LISP mailing list list > Subject: Re: [lisp] Restarting last call on LISP threats >=20 > Hello, >=20 > I am not sure I understand exactly what you are proposing. How can a > LISP router decide that a RLOC is done by simply receiving an ICMP > packet from an attacker (except with LSB that is discussed in Sec > 4.3.2.1. )? All the other techniques are triggered by the LISP > router and are protected by the nonce. >=20 > Could you describe precisely the attack you have in mind? The only > think I can see is relying on the birthday paradox but that is a > completely different story. >=20 > Damien Saucez=20 >=20 > On 10 Jun 2014, at 21:37, Ronald Bonica wrote: >=20 >> Dino, >>=20 >> Exactly! So, assume the following: >>=20 >> - LISP is deployed on the global Internet >> - An RLOC is mapped to some number of EID prefixes >> - For a subset of those EID prefixes, the above mentioned RLOC is prefer= red >> - An ITR receives a hint indicating that the RLOC is down (either throug= h a LISP data packet or an ICMP message) >>=20 >> The ITR will verify RLOC reachability (possibly by polling the RLOC). Bu= t until the ITR has receives a response to its poll, how should it behave? = Should it continue sending traffic though the above mentioned RLOC? Or shou= ld it begin to send traffic through another RLOC, if one exists? I don't se= e a normative recommendation.=20 >>=20 >> However, both behaviors have their drawbacks and could be vectors for at= tack. >>=20 >> = Ron >>=20 >>=20 >>> -----Original Message----- >>> From: Dino Farinacci [mailto:farinacci@gmail.com] >>> Sent: Tuesday, June 10, 2014 1:23 PM >>> To: Ronald Bonica >>> Cc: LISP mailing list list >>> Subject: Re: [lisp] Restarting last call on LISP threats >>>=20 >>> As I keep saying Ron, you need to verify anything you intend to glean. = The >>> spec says the gleaning is "a hint" and not gospel. >>>=20 >>> Dino >>>=20 >>> On Jun 10, 2014, at 10:06 AM, Ronald Bonica wrote= : >>>=20 >>>> Hi Dino, >>>>=20 >>>> Given that the LISP data packet or ICMP packet may be from an attacker= , is >>> it even safe to glean that? I think not. >>>>=20 >>>>=20 >>>> Ron >>>>=20 >>>>=20 >>>>> -----Original Message----- >>>>> From: Dino Farinacci [mailto:farinacci@gmail.com] >>>>> Sent: Tuesday, June 10, 2014 1:04 PM >>>>> To: Ronald Bonica >>>>> Cc: LISP mailing list list >>>>> Subject: Re: [lisp] Restarting last call on LISP threats >>>>>=20 >>>>>=20 >>>>> On Jun 10, 2014, at 9:57 AM, Ronald Bonica wrot= e: >>>>>=20 >>>>>> Earlier in this thread, we agreed that when LISP is deployed on the >>>>>> global >>>>> Internet, mapping information cannot be gleaned safely from incoming >>>>> LISP data packets. Following that train of thought, when LISP is >>>>> deployed on the global Internet, is it safe to glean routing locator >>>>> reachability information from incoming LISP data packets as described >>>>> in RFC 6830, Section 6.3, bullet 1. If not, I think that we need to m= ention >>> this in the threats document. >>>>>=20 >>>>> What you can glean is that the source RLOC is up, but you cannot >>>>> glean your path to it is reachable. >>>>>=20 >>>>>> Given that ICMP packets are easily spoofed, when LISP is deployed on >>>>>> the >>>>> global Internet, is it safe to glean routing locator reachability >>>>> information from incoming ICMP packets as described in RFC 6830, >>>>> Section 6.3, bullet 2 and bullet 4. If not, I think that we need to >>>>> mention this in the threats document. >>>>>=20 >>>>> What you can glean is that the source RLOC is up, but you cannot >>>>> glean your path to it is reachable. >>>>>=20 >>>>> Dino >>>>>=20 >>>>=20 >>=20 >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From nobody Thu Jun 12 08:37:40 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9407F1A0127 for ; Thu, 12 Jun 2014 08:37:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 cZLHUpImKeFF for ; Thu, 12 Jun 2014 08:37:38 -0700 (PDT) Received: from mail-pd0-x22d.google.com (mail-pd0-x22d.google.com [IPv6:2607:f8b0:400e:c02::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00BEE1A0113 for ; Thu, 12 Jun 2014 08:37:37 -0700 (PDT) Received: by mail-pd0-f173.google.com with SMTP id r10so1075478pdi.18 for ; Thu, 12 Jun 2014 08:37:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/g1lmVPlWKHSiZ3Y5Ps2ke6cl18fstqOMMIn2WiRAO0=; b=rM79JQIzyLBz+DzwJKkTs+VpU41NZRxOfuCdmB7xK+jNv7Pj6mIfVmwIDUi/d3IRj8 lLdydeDvPRtXV2qCngUkBHBpksd1U+5M/y/5o2KDOE9JbAU/DuwGdjailT7SomnCiZjb I38FJqUL6+OLKVYgafRhCx8kSmZ+LYbHFVLDb8Hx5Sg0znbPKF3oDQtJfV5Oo4JoXd8i gDB8XFgktDgqRBp+i055y1fFPC2mmoxN12G6VgRZeRT669zNhGvj3R0m5yFXBPKUxzKU LzvLTUfEItSlSz+1qUA/zzPV3uHY4KrQqC0eaD3Iu1np1luz0uCT16ZVtpdwg4khB09E cSnA== X-Received: by 10.68.229.36 with SMTP id sn4mr13420401pbc.51.1402587457688; Thu, 12 Jun 2014 08:37:37 -0700 (PDT) Received: from dino-macbook.wp.comcast.net (173-8-188-29-SFBA.hfc.comcastbusiness.net. [173.8.188.29]) by mx.google.com with ESMTPSA id kn1sm4377335pbd.13.2014.06.12.08.37.36 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 12 Jun 2014 08:37:36 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Dino Farinacci In-Reply-To: <47dad9120b114679bb0ec56976f4baa9@CO2PR05MB636.namprd05.prod.outlook.com> Date: Thu, 12 Jun 2014 08:37:35 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <40ecc5d773874ecdbdc05763004acfa7@CO1PR05MB442.namprd05.prod.outlook.com> <47dad9120b114679bb0ec56976f4baa9@CO2PR05MB636.namprd05.prod.outlook.com> To: Ross Callon X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/yDydfyPiOxUSw41WnS9lmE3clms Cc: LISP mailing list list Subject: Re: [lisp] Restarting last call on LISP threats X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 15:37:39 -0000 But Ross I would like to clarify further. There are many issues with = data packet gleaning. I think there are far less with control-plane = packet payload gleaning since there are many more LISP designed = control-plane mechanisms that can be used OUTSIDE of the data path. Dino On Jun 12, 2014, at 8:28 AM, Ross Callon wrote: >> So by now we know there are many issues with gleaning. So we should >> document them and say they shouldn't be used for the general global = Internet use-case. >>=20 >> Dino >=20 > This I agree with. I will go off and digest the rest. >=20 > Thanks, Ross >=20 >=20 >> -----Original Message----- >> From: lisp [mailto:lisp-bounces@ietf.org] On Behalf Of Damien Saucez >> Sent: Thursday, June 12, 2014 8:08 AM >> To: Ronald Bonica >> Cc: LISP mailing list list >> Subject: Re: [lisp] Restarting last call on LISP threats >>=20 >> Hello, >>=20 >> I am not sure I understand exactly what you are proposing. How can a >> LISP router decide that a RLOC is done by simply receiving an ICMP >> packet from an attacker (except with LSB that is discussed in Sec >> 4.3.2.1. )? All the other techniques are triggered by the LISP >> router and are protected by the nonce. >>=20 >> Could you describe precisely the attack you have in mind? The only >> think I can see is relying on the birthday paradox but that is a >> completely different story. >>=20 >> Damien Saucez=20 >>=20 >> On 10 Jun 2014, at 21:37, Ronald Bonica wrote: >>=20 >>> Dino, >>>=20 >>> Exactly! So, assume the following: >>>=20 >>> - LISP is deployed on the global Internet >>> - An RLOC is mapped to some number of EID prefixes >>> - For a subset of those EID prefixes, the above mentioned RLOC is = preferred >>> - An ITR receives a hint indicating that the RLOC is down (either = through a LISP data packet or an ICMP message) >>>=20 >>> The ITR will verify RLOC reachability (possibly by polling the = RLOC). But until the ITR has receives a response to its poll, how should = it behave? Should it continue sending traffic though the above mentioned = RLOC? Or should it begin to send traffic through another RLOC, if one = exists? I don't see a normative recommendation.=20 >>>=20 >>> However, both behaviors have their drawbacks and could be vectors = for attack. >>>=20 >>> = Ron >>>=20 >>>=20 >>>> -----Original Message----- >>>> From: Dino Farinacci [mailto:farinacci@gmail.com] >>>> Sent: Tuesday, June 10, 2014 1:23 PM >>>> To: Ronald Bonica >>>> Cc: LISP mailing list list >>>> Subject: Re: [lisp] Restarting last call on LISP threats >>>>=20 >>>> As I keep saying Ron, you need to verify anything you intend to = glean. The >>>> spec says the gleaning is "a hint" and not gospel. >>>>=20 >>>> Dino >>>>=20 >>>> On Jun 10, 2014, at 10:06 AM, Ronald Bonica = wrote: >>>>=20 >>>>> Hi Dino, >>>>>=20 >>>>> Given that the LISP data packet or ICMP packet may be from an = attacker, is >>>> it even safe to glean that? I think not. >>>>>=20 >>>>>=20 >>>>> Ron >>>>>=20 >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Dino Farinacci [mailto:farinacci@gmail.com] >>>>>> Sent: Tuesday, June 10, 2014 1:04 PM >>>>>> To: Ronald Bonica >>>>>> Cc: LISP mailing list list >>>>>> Subject: Re: [lisp] Restarting last call on LISP threats >>>>>>=20 >>>>>>=20 >>>>>> On Jun 10, 2014, at 9:57 AM, Ronald Bonica = wrote: >>>>>>=20 >>>>>>> Earlier in this thread, we agreed that when LISP is deployed on = the >>>>>>> global >>>>>> Internet, mapping information cannot be gleaned safely from = incoming >>>>>> LISP data packets. Following that train of thought, when LISP is >>>>>> deployed on the global Internet, is it safe to glean routing = locator >>>>>> reachability information from incoming LISP data packets as = described >>>>>> in RFC 6830, Section 6.3, bullet 1. If not, I think that we need = to mention >>>> this in the threats document. >>>>>>=20 >>>>>> What you can glean is that the source RLOC is up, but you cannot >>>>>> glean your path to it is reachable. >>>>>>=20 >>>>>>> Given that ICMP packets are easily spoofed, when LISP is = deployed on >>>>>>> the >>>>>> global Internet, is it safe to glean routing locator reachability >>>>>> information from incoming ICMP packets as described in RFC 6830, >>>>>> Section 6.3, bullet 2 and bullet 4. If not, I think that we need = to >>>>>> mention this in the threats document. >>>>>>=20 >>>>>> What you can glean is that the source RLOC is up, but you cannot >>>>>> glean your path to it is reachable. >>>>>>=20 >>>>>> Dino >>>>>>=20 >>>>>=20 >>>=20 >>> _______________________________________________ >>> lisp mailing list >>> lisp@ietf.org >>> https://www.ietf.org/mailman/listinfo/lisp >>=20 >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp >>=20 >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp >=20 From nobody Thu Jun 12 09:15:59 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 840D01A0178 for ; Thu, 12 Jun 2014 09:15:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 D41AW8ZMU_EG for ; Thu, 12 Jun 2014 09:15:43 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C77691B2A9A for ; Thu, 12 Jun 2014 09:15:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id E8D2521EA1; Thu, 12 Jun 2014 09:15:33 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-134-230.clppva.east.verizon.net [70.106.134.230]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id C2D1D21E9D; Thu, 12 Jun 2014 09:15:32 -0700 (PDT) Message-ID: <5399D22A.2040207@joelhalpern.com> Date: Thu, 12 Jun 2014 12:15:38 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Dino Farinacci , Ross Callon References: <40ecc5d773874ecdbdc05763004acfa7@CO1PR05MB442.namprd05.prod.outlook.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/8LhhkO9-Gtubk6xS8g16_bIUfhc Cc: LISP mailing list list Subject: Re: [lisp] Restarting last call on LISP threats X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 16:15:45 -0000 I will repeat myself. Can we PLEASE not get into debating how we would solve the weakness in the protocol as documented. The question focus on is whether the protocol as specified has the behavior described, and if so does it result in the weakness described. If it does, that should be described in the threats document. if not, then it should not be so described. The presence, absence, validity, or possibility of solutions in other documents, operational practices, or people's heads, are not the topic for the WG at this time. PLEASE stay on topic, or we will never get our current work done. Which means that peoples wonderful ideas on how to do more or better will never get publsihed. Yours, Joel On 6/12/14, 11:24 AM, Dino Farinacci wrote: > >>> Could you describe precisely the attack you have in mind? The only >>> think I can see is relying on the birthday paradox but that is a >>> completely different story. >> >> If an attacker is on-path it could see the nonce's (assuming that the LISP header is not encrypted, regardless of whether the data packet is encrypted). This could be an issue if the attacker is physically on-path. > > The source EID is encrypted so it can only see a cleartext source RLOC and can't associated it with anything. > > When we merge lisp-cryto logic with echo-noncing, one has to determine if an xTR should participate in echo-noncing if the payload is not decrypted properly. That is, if I get a echoed nonce back from an attacker for a nonce I know I have sent and set the E-bit, and I cannot decrypt the payload that comes from the attacker, then I don't believe any NEW reachability information about the RLOC. > >> This could also be an issue for attackers which are physically off-path if gleaning is used, since an attacker could use a gleaning attack to temporarily insert itself on-path, which in turn would allow it to see the nonce. > > So by now we know there are many issues with gleaning. So we should document them and say they shouldn't be used for the general global Internet use-case. > > Dino > >> >> Ross >> >> -----Original Message----- >> From: lisp [mailto:lisp-bounces@ietf.org] On Behalf Of Damien Saucez >> Sent: Thursday, June 12, 2014 8:08 AM >> To: Ronald Bonica >> Cc: LISP mailing list list >> Subject: Re: [lisp] Restarting last call on LISP threats >> >> Hello, >> >> I am not sure I understand exactly what you are proposing. How can a >> LISP router decide that a RLOC is done by simply receiving an ICMP >> packet from an attacker (except with LSB that is discussed in Sec >> 4.3.2.1. )? All the other techniques are triggered by the LISP >> router and are protected by the nonce. >> >> Could you describe precisely the attack you have in mind? The only >> think I can see is relying on the birthday paradox but that is a >> completely different story. >> >> Damien Saucez >> >> On 10 Jun 2014, at 21:37, Ronald Bonica wrote: >> >>> Dino, >>> >>> Exactly! So, assume the following: >>> >>> - LISP is deployed on the global Internet >>> - An RLOC is mapped to some number of EID prefixes >>> - For a subset of those EID prefixes, the above mentioned RLOC is preferred >>> - An ITR receives a hint indicating that the RLOC is down (either through a LISP data packet or an ICMP message) >>> >>> The ITR will verify RLOC reachability (possibly by polling the RLOC). But until the ITR has receives a response to its poll, how should it behave? Should it continue sending traffic though the above mentioned RLOC? Or should it begin to send traffic through another RLOC, if one exists? I don't see a normative recommendation. >>> >>> However, both behaviors have their drawbacks and could be vectors for attack. >>> >>> Ron >>> >>> >>>> -----Original Message----- >>>> From: Dino Farinacci [mailto:farinacci@gmail.com] >>>> Sent: Tuesday, June 10, 2014 1:23 PM >>>> To: Ronald Bonica >>>> Cc: LISP mailing list list >>>> Subject: Re: [lisp] Restarting last call on LISP threats >>>> >>>> As I keep saying Ron, you need to verify anything you intend to glean. The >>>> spec says the gleaning is "a hint" and not gospel. >>>> >>>> Dino >>>> >>>> On Jun 10, 2014, at 10:06 AM, Ronald Bonica wrote: >>>> >>>>> Hi Dino, >>>>> >>>>> Given that the LISP data packet or ICMP packet may be from an attacker, is >>>> it even safe to glean that? I think not. >>>>> >>>>> >>>>> Ron >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Dino Farinacci [mailto:farinacci@gmail.com] >>>>>> Sent: Tuesday, June 10, 2014 1:04 PM >>>>>> To: Ronald Bonica >>>>>> Cc: LISP mailing list list >>>>>> Subject: Re: [lisp] Restarting last call on LISP threats >>>>>> >>>>>> >>>>>> On Jun 10, 2014, at 9:57 AM, Ronald Bonica wrote: >>>>>> >>>>>>> Earlier in this thread, we agreed that when LISP is deployed on the >>>>>>> global >>>>>> Internet, mapping information cannot be gleaned safely from incoming >>>>>> LISP data packets. Following that train of thought, when LISP is >>>>>> deployed on the global Internet, is it safe to glean routing locator >>>>>> reachability information from incoming LISP data packets as described >>>>>> in RFC 6830, Section 6.3, bullet 1. If not, I think that we need to mention >>>> this in the threats document. >>>>>> >>>>>> What you can glean is that the source RLOC is up, but you cannot >>>>>> glean your path to it is reachable. >>>>>> >>>>>>> Given that ICMP packets are easily spoofed, when LISP is deployed on >>>>>>> the >>>>>> global Internet, is it safe to glean routing locator reachability >>>>>> information from incoming ICMP packets as described in RFC 6830, >>>>>> Section 6.3, bullet 2 and bullet 4. If not, I think that we need to >>>>>> mention this in the threats document. >>>>>> >>>>>> What you can glean is that the source RLOC is up, but you cannot >>>>>> glean your path to it is reachable. >>>>>> >>>>>> Dino >>>>>> >>>>> >>> >>> _______________________________________________ >>> lisp mailing list >>> lisp@ietf.org >>> https://www.ietf.org/mailman/listinfo/lisp >> >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp >> >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > From nobody Thu Jun 12 09:23:16 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7F921A0174 for ; Thu, 12 Jun 2014 09:23:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 HiE_onEkS3b2 for ; Thu, 12 Jun 2014 09:23:12 -0700 (PDT) Received: from mail-pb0-x22e.google.com (mail-pb0-x22e.google.com [IPv6:2607:f8b0:400e:c01::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C78381A0127 for ; Thu, 12 Jun 2014 09:23:12 -0700 (PDT) Received: by mail-pb0-f46.google.com with SMTP id md12so321770pbc.33 for ; Thu, 12 Jun 2014 09:23:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=YZfvc3FAvcVEHmI8PWmEWKYeNoD9attddWQ9G36AI9E=; b=QuouRLjpiSrAILRKhl4q2k9U1OZ9UIRrNIh3aw10+OOMjTnWQmH+S7OG5d7MMZ2n2V QOuYIM54/kEFy8XBexOodP8hc3m5OpUb5LFmOS9C9YZvPZhqUEx4gkI6adTa3u5Zmk/Y p4AXDPy/AwGXq4s5GwgfgnGxsbHzLy5s3HLne/kKB1rp8imhYujzMPhx4wF6WY9W21ZU FlOoxbks9S+59zMh4kOX4b+uga3CUTXxTSRGKNCbKRn8BFVQY4hrIoZ+GnEYcD7alvbq h2IaD1LIYi/5SOTAfrgyvbdhLhJ78aLy5wRx4smmtDzZcVyturPj3TC1temdwpmGHuhZ eBsw== X-Received: by 10.68.222.196 with SMTP id qo4mr13849957pbc.14.1402590192499; Thu, 12 Jun 2014 09:23:12 -0700 (PDT) Received: from dino-macbook.wp.comcast.net (173-8-188-29-SFBA.hfc.comcastbusiness.net. [173.8.188.29]) by mx.google.com with ESMTPSA id se3sm81177547pbb.80.2014.06.12.09.23.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 12 Jun 2014 09:23:11 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Dino Farinacci In-Reply-To: <5399D22A.2040207@joelhalpern.com> Date: Thu, 12 Jun 2014 09:23:09 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5CAAEAE6-AF3E-4E27-8D73-FA8A64520379@gmail.com> References: <40ecc5d773874ecdbdc05763004acfa7@CO1PR05MB442.namprd05.prod.outlook.com> <5399D22A.2040207@joelhalpern.com> To: "Joel M. Halpern" X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/lzUAfwg2oKcF5oXG9ZGM4dKkeaU Cc: LISP mailing list list Subject: Re: [lisp] Restarting last call on LISP threats X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 16:23:14 -0000 I agree we should be focused Joel.=20 But where else should we have open discussions about LISP? This mailing list membership is unique in that we have multiple vendors, = operators, and users all in one place. Wouldn't that make for better = protocols? Yes we have business to take care of but let's not stifle ideas and = openness. Do you agree? Dino On Jun 12, 2014, at 9:15 AM, Joel M. Halpern = wrote: > I will repeat myself. > Can we PLEASE not get into debating how we would solve the weakness in = the protocol as documented. >=20 > The question focus on is whether the protocol as specified has the = behavior described, and if so does it result in the weakness described. > If it does, that should be described in the threats document. > if not, then it should not be so described. >=20 > The presence, absence, validity, or possibility of solutions in other = documents, operational practices, or people's heads, are not the topic = for the WG at this time. >=20 > PLEASE stay on topic, or we will never get our current work done. > Which means that peoples wonderful ideas on how to do more or better = will never get publsihed. >=20 > Yours, > Joel >=20 > On 6/12/14, 11:24 AM, Dino Farinacci wrote: >>=20 >>>> Could you describe precisely the attack you have in mind? The only >>>> think I can see is relying on the birthday paradox but that is a >>>> completely different story. >>>=20 >>> If an attacker is on-path it could see the nonce's (assuming that = the LISP header is not encrypted, regardless of whether the data packet = is encrypted). This could be an issue if the attacker is physically = on-path. >>=20 >> The source EID is encrypted so it can only see a cleartext source = RLOC and can't associated it with anything. >>=20 >> When we merge lisp-cryto logic with echo-noncing, one has to = determine if an xTR should participate in echo-noncing if the payload is = not decrypted properly. That is, if I get a echoed nonce back from an = attacker for a nonce I know I have sent and set the E-bit, and I cannot = decrypt the payload that comes from the attacker, then I don't believe = any NEW reachability information about the RLOC. >>=20 >>> This could also be an issue for attackers which are physically = off-path if gleaning is used, since an attacker could use a gleaning = attack to temporarily insert itself on-path, which in turn would allow = it to see the nonce. >>=20 >> So by now we know there are many issues with gleaning. So we should = document them and say they shouldn't be used for the general global = Internet use-case. >>=20 >> Dino >>=20 >>>=20 >>> Ross >>>=20 >>> -----Original Message----- >>> From: lisp [mailto:lisp-bounces@ietf.org] On Behalf Of Damien Saucez >>> Sent: Thursday, June 12, 2014 8:08 AM >>> To: Ronald Bonica >>> Cc: LISP mailing list list >>> Subject: Re: [lisp] Restarting last call on LISP threats >>>=20 >>> Hello, >>>=20 >>> I am not sure I understand exactly what you are proposing. How can = a >>> LISP router decide that a RLOC is done by simply receiving an ICMP >>> packet from an attacker (except with LSB that is discussed in Sec >>> 4.3.2.1. )? All the other techniques are triggered by the LISP >>> router and are protected by the nonce. >>>=20 >>> Could you describe precisely the attack you have in mind? The only >>> think I can see is relying on the birthday paradox but that is a >>> completely different story. >>>=20 >>> Damien Saucez >>>=20 >>> On 10 Jun 2014, at 21:37, Ronald Bonica wrote: >>>=20 >>>> Dino, >>>>=20 >>>> Exactly! So, assume the following: >>>>=20 >>>> - LISP is deployed on the global Internet >>>> - An RLOC is mapped to some number of EID prefixes >>>> - For a subset of those EID prefixes, the above mentioned RLOC is = preferred >>>> - An ITR receives a hint indicating that the RLOC is down (either = through a LISP data packet or an ICMP message) >>>>=20 >>>> The ITR will verify RLOC reachability (possibly by polling the = RLOC). But until the ITR has receives a response to its poll, how should = it behave? Should it continue sending traffic though the above mentioned = RLOC? Or should it begin to send traffic through another RLOC, if one = exists? I don't see a normative recommendation. >>>>=20 >>>> However, both behaviors have their drawbacks and could be vectors = for attack. >>>>=20 >>>> = Ron >>>>=20 >>>>=20 >>>>> -----Original Message----- >>>>> From: Dino Farinacci [mailto:farinacci@gmail.com] >>>>> Sent: Tuesday, June 10, 2014 1:23 PM >>>>> To: Ronald Bonica >>>>> Cc: LISP mailing list list >>>>> Subject: Re: [lisp] Restarting last call on LISP threats >>>>>=20 >>>>> As I keep saying Ron, you need to verify anything you intend to = glean. The >>>>> spec says the gleaning is "a hint" and not gospel. >>>>>=20 >>>>> Dino >>>>>=20 >>>>> On Jun 10, 2014, at 10:06 AM, Ronald Bonica = wrote: >>>>>=20 >>>>>> Hi Dino, >>>>>>=20 >>>>>> Given that the LISP data packet or ICMP packet may be from an = attacker, is >>>>> it even safe to glean that? I think not. >>>>>>=20 >>>>>>=20 >>>>>> Ron >>>>>>=20 >>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: Dino Farinacci [mailto:farinacci@gmail.com] >>>>>>> Sent: Tuesday, June 10, 2014 1:04 PM >>>>>>> To: Ronald Bonica >>>>>>> Cc: LISP mailing list list >>>>>>> Subject: Re: [lisp] Restarting last call on LISP threats >>>>>>>=20 >>>>>>>=20 >>>>>>> On Jun 10, 2014, at 9:57 AM, Ronald Bonica = wrote: >>>>>>>=20 >>>>>>>> Earlier in this thread, we agreed that when LISP is deployed on = the >>>>>>>> global >>>>>>> Internet, mapping information cannot be gleaned safely from = incoming >>>>>>> LISP data packets. Following that train of thought, when LISP is >>>>>>> deployed on the global Internet, is it safe to glean routing = locator >>>>>>> reachability information from incoming LISP data packets as = described >>>>>>> in RFC 6830, Section 6.3, bullet 1. If not, I think that we need = to mention >>>>> this in the threats document. >>>>>>>=20 >>>>>>> What you can glean is that the source RLOC is up, but you cannot >>>>>>> glean your path to it is reachable. >>>>>>>=20 >>>>>>>> Given that ICMP packets are easily spoofed, when LISP is = deployed on >>>>>>>> the >>>>>>> global Internet, is it safe to glean routing locator = reachability >>>>>>> information from incoming ICMP packets as described in RFC 6830, >>>>>>> Section 6.3, bullet 2 and bullet 4. If not, I think that we need = to >>>>>>> mention this in the threats document. >>>>>>>=20 >>>>>>> What you can glean is that the source RLOC is up, but you cannot >>>>>>> glean your path to it is reachable. >>>>>>>=20 >>>>>>> Dino >>>>>>>=20 >>>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> lisp mailing list >>>> lisp@ietf.org >>>> https://www.ietf.org/mailman/listinfo/lisp >>>=20 >>> _______________________________________________ >>> lisp mailing list >>> lisp@ietf.org >>> https://www.ietf.org/mailman/listinfo/lisp >>>=20 >>> _______________________________________________ >>> lisp mailing list >>> lisp@ietf.org >>> https://www.ietf.org/mailman/listinfo/lisp >>=20 >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp >>=20 From nobody Thu Jun 12 10:21:12 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 356641A01CB for ; Thu, 12 Jun 2014 10:21:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.602 X-Spam-Level: X-Spam-Status: No, score=-102.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 mRe5rvHCBInZ for ; Thu, 12 Jun 2014 10:21:01 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0243.outbound.protection.outlook.com [207.46.163.243]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C44E31B27C6 for ; Thu, 12 Jun 2014 10:21:01 -0700 (PDT) Received: from CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) by CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) with Microsoft SMTP Server (TLS) id 15.0.949.11; Thu, 12 Jun 2014 17:21:00 +0000 Received: from CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.68]) by CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.92]) with mapi id 15.00.0949.001; Thu, 12 Jun 2014 17:21:00 +0000 From: Ronald Bonica To: Damien Saucez Thread-Topic: [lisp] Restarting last call on LISP threats Thread-Index: AQHPhM36v1z5qcx3GU+Mb5TT+ra0YZtqkpgAgAAFDICAACBwoIACrCcAgABQBFA= Date: Thu, 12 Jun 2014 17:20:59 +0000 Message-ID: <439e37b7cb4b48f99a446bf737dae095@CO1PR05MB442.namprd05.prod.outlook.com> References: <40ecc5d773874ecdbdc05763004acfa7@CO1PR05MB442.namprd05.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.17] x-microsoft-antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: x-forefront-prvs: 02408926C4 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(428001)(13464003)(51704005)(51444003)(199002)(189002)(377454003)(24454002)(99286001)(2656002)(81542001)(87936001)(93886003)(101416001)(83072002)(85852003)(86362001)(83322001)(19580395003)(19580405001)(81342001)(74662001)(74502001)(99396002)(46102001)(15975445006)(76482001)(33646001)(4396001)(77982001)(74316001)(76176999)(54356999)(50986999)(76576001)(66066001)(79102001)(80022001)(20776003)(64706001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB442; H:CO1PR05MB442.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (: juniper.net does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=rbonica@juniper.net; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/aK8SiEu40upjU-xa_i8WlJRvVUQ Cc: LISP mailing list list Subject: Re: [lisp] Restarting last call on LISP threats X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 17:21:07 -0000 Hi Damien, According to RFC 6830, Section 6.3, bullet 2: "An ITR may receive an ICMP Network Unreachable or Host Unreachable message= for an RLOC it is using. This indicates that the RLOC is likely down. No= te that trusting ICMP messages may not be desirable, but neither is ignori= ng them completely. Implementations are encouraged to follow current best = practices in treating these conditions." Where are those best common practices defined? Since this is a trust issue,= I would look to the threats document. = Ron > -----Original Message----- > From: Damien Saucez [mailto:damien.saucez@gmail.com] > Sent: Thursday, June 12, 2014 8:08 AM > To: Ronald Bonica > Cc: Dino Farinacci; LISP mailing list list > Subject: Re: [lisp] Restarting last call on LISP threats >=20 > Hello, >=20 > I am not sure I understand exactly what you are proposing. How can a LIS= P > router decide that a RLOC is done by simply receiving an ICMP packet from= an > attacker (except with LSB that is discussed in Sec 4.3.2.1. )? All the = other > techniques are triggered by the LISP router and are protected by the nonc= e. >=20 > Could you describe precisely the attack you have in mind? The only think= I > can see is relying on the birthday paradox but that is a completely diffe= rent > story. >=20 > Damien Saucez >=20 > On 10 Jun 2014, at 21:37, Ronald Bonica wrote: >=20 > > Dino, > > > > Exactly! So, assume the following: > > > > - LISP is deployed on the global Internet > > - An RLOC is mapped to some number of EID prefixes > > - For a subset of those EID prefixes, the above mentioned RLOC is > > preferred > > - An ITR receives a hint indicating that the RLOC is down (either > > through a LISP data packet or an ICMP message) > > > > The ITR will verify RLOC reachability (possibly by polling the RLOC). B= ut until > the ITR has receives a response to its poll, how should it behave? Should= it > continue sending traffic though the above mentioned RLOC? Or should it > begin to send traffic through another RLOC, if one exists? I don't see a > normative recommendation. > > > > However, both behaviors have their drawbacks and could be vectors for > attack. > > > > > > Ron > > > > > >> -----Original Message----- > >> From: Dino Farinacci [mailto:farinacci@gmail.com] > >> Sent: Tuesday, June 10, 2014 1:23 PM > >> To: Ronald Bonica > >> Cc: LISP mailing list list > >> Subject: Re: [lisp] Restarting last call on LISP threats > >> > >> As I keep saying Ron, you need to verify anything you intend to > >> glean. The spec says the gleaning is "a hint" and not gospel. > >> > >> Dino > >> > >> On Jun 10, 2014, at 10:06 AM, Ronald Bonica > wrote: > >> > >>> Hi Dino, > >>> > >>> Given that the LISP data packet or ICMP packet may be from an > >>> attacker, is > >> it even safe to glean that? I think not. > >>> > >>> > >>> Ron > >>> > >>> > >>>> -----Original Message----- > >>>> From: Dino Farinacci [mailto:farinacci@gmail.com] > >>>> Sent: Tuesday, June 10, 2014 1:04 PM > >>>> To: Ronald Bonica > >>>> Cc: LISP mailing list list > >>>> Subject: Re: [lisp] Restarting last call on LISP threats > >>>> > >>>> > >>>> On Jun 10, 2014, at 9:57 AM, Ronald Bonica > wrote: > >>>> > >>>>> Earlier in this thread, we agreed that when LISP is deployed on > >>>>> the global > >>>> Internet, mapping information cannot be gleaned safely from > >>>> incoming LISP data packets. Following that train of thought, when > >>>> LISP is deployed on the global Internet, is it safe to glean > >>>> routing locator reachability information from incoming LISP data > >>>> packets as described in RFC 6830, Section 6.3, bullet 1. If not, I > >>>> think that we need to mention > >> this in the threats document. > >>>> > >>>> What you can glean is that the source RLOC is up, but you cannot > >>>> glean your path to it is reachable. > >>>> > >>>>> Given that ICMP packets are easily spoofed, when LISP is deployed > >>>>> on the > >>>> global Internet, is it safe to glean routing locator reachability > >>>> information from incoming ICMP packets as described in RFC 6830, > >>>> Section 6.3, bullet 2 and bullet 4. If not, I think that we need to > >>>> mention this in the threats document. > >>>> > >>>> What you can glean is that the source RLOC is up, but you cannot > >>>> glean your path to it is reachable. > >>>> > >>>> Dino > >>>> > >>> > > > > _______________________________________________ > > lisp mailing list > > lisp@ietf.org > > https://www.ietf.org/mailman/listinfo/lisp From nobody Fri Jun 13 09:19:30 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E9FE1A0546 for ; Fri, 13 Jun 2014 09:19:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 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, HELO_EQ_FR=0.35, SPF_PASS=-0.001] autolearn=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 bCWR-03b66_g for ; Fri, 13 Jun 2014 09:19:25 -0700 (PDT) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7ED141A00D2 for ; Fri, 13 Jun 2014 09:19:25 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id b13so2941082wgh.11 for ; Fri, 13 Jun 2014 09:19:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version; bh=GuOwkijKUPD01lPZAxNu6S6PCB2ZLDEIfiPVx5n7Yps=; b=tzep6wk+kF8KVAexRUu7m+ltwLr6WCXekniwcBsUue7Y+1c5m0HJjNG8eoGcPgxA+E 84mxg1+zpWqLknbaxsErMDSrhP12lfJ4uf/fUVX/7l7L2TN9jOXgRdKnzec44Kw+JmIk MJ8uBH/Iwe0HS8QHMCOc29XwQA9Q1Cic8UD/gZg0fda/xjHK0NttNCFjBwe8Kwk2H9Vu CwOvlHX5exnFTMb1UB3xLJkbSQZQBUpUWWTS9uRtOWlhBKA/2sMTme/BOcWkj40wHton 2T7IqFjWTfcevJSqWCsKHFjeVb85DUUBQVfUQEX5C6dHHmVkGzBGqMOrPKPmLkqjwmoy aOSA== X-Received: by 10.180.38.38 with SMTP id d6mr6351630wik.12.1402676363669; Fri, 13 Jun 2014 09:19:23 -0700 (PDT) Received: from faucon.inria.fr (faucon.inria.fr. [138.96.201.73]) by mx.google.com with ESMTPSA id fh5sm3293526wic.9.2014.06.13.09.19.22 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 13 Jun 2014 09:19:23 -0700 (PDT) From: Damien Saucez Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 13 Jun 2014 18:19:21 +0200 Message-Id: To: LISP mailing list list Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/TL9b9KGYYfI1S5tzPjkNlPZb8XQ Cc: Benoit Donnet Subject: [lisp] On the Performance of the LISP Beta Network X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 16:19:27 -0000 Dear all, We carried out some measurement constraints on the LISP Beta Network. More precisely, we evaluated the performance of the mapping system and the interworking mechanism. Our measurements highlight that performance offered by the LISP interworking infrastructure is strongly dependent on BGP routing policies (which was expected). Also, if we exclude misconfigured nodes, the mapping system typically provides reliable performance and relatively low median mapping resolution delays. Although the bias is not very important, control plane performance favors USA sites as a result of its larger LISP user base but also because European infrastructure appears to be less reliable. The full document can be downloaded at http://orbi.ulg.ac.be/bitstream/2268/164736/1/paper.pdf Cheers, The authors From nobody Fri Jun 13 09:26:41 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C5581B2974 for ; Fri, 13 Jun 2014 09:26:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 FhuwOiR9nBzr for ; Fri, 13 Jun 2014 09:26:36 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0142.outbound.protection.outlook.com [207.46.163.142]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C72831A00D2 for ; Fri, 13 Jun 2014 09:26:35 -0700 (PDT) Received: from CO2PR05MB636.namprd05.prod.outlook.com (10.141.199.24) by CO2PR05MB633.namprd05.prod.outlook.com (10.141.199.12) with Microsoft SMTP Server (TLS) id 15.0.954.9; Fri, 13 Jun 2014 16:26:32 +0000 Received: from CO2PR05MB636.namprd05.prod.outlook.com ([10.141.199.24]) by CO2PR05MB636.namprd05.prod.outlook.com ([10.141.199.24]) with mapi id 15.00.0954.000; Fri, 13 Jun 2014 16:26:32 +0000 From: Ross Callon To: "damien.saucez@inria.fr" , "luigi.iannone@telecom-paristech.fr" , "olivier.bonaventure@uclouvain.be" Thread-Topic: possible text for LISP threats Thread-Index: AQHPhyMnC8QSqTBqz0alNjaiEG8PF5tvOB5g Date: Fri, 13 Jun 2014 16:26:31 +0000 Message-ID: <898c27d33fdd452499848408c9eac47f@CO2PR05MB636.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.11] x-microsoft-antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: x-forefront-prvs: 0241D5F98C x-forefront-antispam-report: SFV:NSPM; SFS:(979002)(6009001)(428001)(189002)(199002)(164054003)(4396001)(46102001)(20776003)(77096999)(92566001)(2201001)(85852003)(76576001)(33646001)(83072002)(2656002)(87936001)(74662001)(54356999)(66066001)(80022001)(50986999)(64706001)(86362001)(76482001)(31966008)(101416001)(74502001)(81342001)(99396002)(74316001)(83322001)(21056001)(99286001)(77982001)(81542001)(79102001)(105586001)(24736002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:; SCL:1; SRVR:CO2PR05MB633; H:CO2PR05MB636.namprd05.prod.outlook.com; FPR:; MLV:ovrnspm; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: juniper.net does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=rcallon@juniper.net; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/70A8SEN3lUTTJ3_uIPS7RtFo-c8 Cc: LISP mailing list list Subject: [lisp] possible text for LISP threats X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 16:26:38 -0000 We have had significant discussion of attacks against the control plane of = routers, and some discussion of the relative capacity of the control plane = versus data plane. I have been thinking that the LISP threats document shou= ld give examples of DoS attacks against the control plane of the xTR's. If = this will help with progression of the document, some possible text is belo= w. I am not sure if this is complete but it might be a start.=20 It is not completely obvious where this text would best fit into the existi= ng document, and my understanding is that some restructuring of the documen= t is underway. Perhaps as new subsection(s) at the end of section 5.2 (Deni= al of Service) of the existing document might be appropriate. I have writte= n the text below as two subsections 5.2.3 and 5.2.4 of section 5.2, but of = course there are other ways that this could be incorporated into the threat= s document.=20 Thanks, Ross ------------ 5.2.3 Control Plane versus Data Plane DOS attacks In some cases, particularly very high speed routers, there may be a very la= rge difference between the capacity of the data plane versus the control pl= ane. For example, at the time this is written there are widely deployed rou= ters which can handle a few terabits of data in the data plane. These route= rs might typically have gigabit Ethernet links to the control processor, bu= t it is unlikely that they could handle Map-Requests coming in at line rate= at a gigabit. Thus in some routers (particularly very high speed ones) the= ratio between the speed of the control plane and the speed of the data pla= ne may be significantly greater than 1,000. This implies that DoS attacks against the control plane of routers may be m= ore serious than DOS attacks which only target the data plane. LISP allows = data plane traffic to impact the control plane. Examples are included in th= e following section.=20 5.2.4 Examples of DoS attacks Suppose that the attacker has a single system that he controls, and that hi= s ISP does not check the source address of outgoing packets. Suppose gleani= ng is turned off (so that gleaning cannot be utilized in the attack):=20 1. Attacker could send a lot of packets to one address behind a particular = xTR, each packet with a different source EID. This causes the xTR to do a m= apping lookup for each one. This causes two problems in the xTR: (i) contro= l plane load (a simple data plane DOS has turned into a control plane DOS);= (ii) potential exhaustion of the cache. Optionally the attacker could use = the same source RLOC for each, but this could in theory lead to the attacke= d xTR noticing and putting in a packet filter for that source RLOC, so that= varying the source RLOC may make this attack more difficult to counter.=20 2. Attacker could send a lot of packets to many remote xTRs, one packet to = each, all with the same source forged EID and source RLOC, with the source = EID and source RLOC being that of the system that he really wants to attack= . This causes each to do the same mapping lookup, which might overwhelm the= mapping system serving the system under attack.=20 3. Attacker could send a large number of map requests to many remote xTRs, = all with the same forged source EID and source RLOC, again with the source = EID and source RLOC being that of the system that he really wants to attack= . This causes each to send a map response to the system under attack. This = again would be intended to overwhelm the control plane and cache of the sys= tem under attack.=20 Suppose that the attacker controls a moderate sized BOTNET, consisting of a= few thousand captive systems. He might install enough software on his BOT'= s to send a packet that looks like a LISP packet. In this case each of the = attacks discussed above can be multiplied by having a wider range of system= s participating in the attack.=20 From nobody Fri Jun 13 09:53:46 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B312A1B2938 for ; Fri, 13 Jun 2014 09:53:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.201 X-Spam-Level: X-Spam-Status: No, score=-7.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 swNuQq4WylaP for ; Fri, 13 Jun 2014 09:53:38 -0700 (PDT) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D53471B291C for ; Fri, 13 Jun 2014 09:53:37 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,472,1400018400"; d="scan'208";a="67081499" Received: from faucon.inria.fr ([138.96.201.73]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/AES128-SHA; 13 Jun 2014 18:53:35 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Damien Saucez In-Reply-To: <898c27d33fdd452499848408c9eac47f@CO2PR05MB636.namprd05.prod.outlook.com> Date: Fri, 13 Jun 2014 18:53:35 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <898c27d33fdd452499848408c9eac47f@CO2PR05MB636.namprd05.prod.outlook.com> To: Ross Callon X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/2l-nLCt6R4HDkYflfFvUfCERRFY Cc: Luigi Iannone , LISP mailing list list Subject: Re: [lisp] possible text for LISP threats X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 16:53:41 -0000 Hello Ross, Thank you for the input. Indeed we are working on the new version of the draft that will arrive for the cut-off date and hence for a big = (huge?) discussion at IETF. 90=20 For the moment, I am compiling all the comments and examples given on the list to construct the most compact abstraction that covers = everything. To avoid delaying the document any longer and hence the working group, I however think that we should not provide any example of attack in the draft but instead provide the most compact abstraction of attacks that permits to reconstruct any possible attack. Why? Because if we open the Pandora box of putting examples in the document, then we will never be able to close the document as it will always be possible to add an example even though these example would not add any information to the system. Another reason is that providing a 100 pages document would make it useless as the potential readers would get lost while reading which is not the case if the document is synthetic but still complete. Hence all the work we are doing for the moment is to construct the right abstraction so that any possible attack can really be casted into something in the document. Nevertheless, we all value examples, and I can propose you to write a whitepaper with examples of attacks, and in each example showing to which part of the abstraction of the threats document they refer. So as you can understand with this vision the challenge is to make the right abstraction. What do you think of all this? Damien Saucez=20 On 13 Jun 2014, at 18:26, Ross Callon wrote: > We have had significant discussion of attacks against the control = plane of routers, and some discussion of the relative capacity of the = control plane versus data plane. I have been thinking that the LISP = threats document should give examples of DoS attacks against the control = plane of the xTR's. If this will help with progression of the document, = some possible text is below. I am not sure if this is complete but it = might be a start.=20 >=20 > It is not completely obvious where this text would best fit into the = existing document, and my understanding is that some restructuring of = the document is underway. Perhaps as new subsection(s) at the end of = section 5.2 (Denial of Service) of the existing document might be = appropriate. I have written the text below as two subsections 5.2.3 and = 5.2.4 of section 5.2, but of course there are other ways that this could = be incorporated into the threats document.=20 >=20 > Thanks, Ross > ------------ >=20 > 5.2.3 Control Plane versus Data Plane DOS attacks >=20 > In some cases, particularly very high speed routers, there may be a = very large difference between the capacity of the data plane versus the = control plane. For example, at the time this is written there are widely = deployed routers which can handle a few terabits of data in the data = plane. These routers might typically have gigabit Ethernet links to the = control processor, but it is unlikely that they could handle = Map-Requests coming in at line rate at a gigabit. Thus in some routers = (particularly very high speed ones) the ratio between the speed of the = control plane and the speed of the data plane may be significantly = greater than 1,000. >=20 > This implies that DoS attacks against the control plane of routers may = be more serious than DOS attacks which only target the data plane. LISP = allows data plane traffic to impact the control plane. Examples are = included in the following section.=20 >=20 > 5.2.4 Examples of DoS attacks >=20 > Suppose that the attacker has a single system that he controls, and = that his ISP does not check the source address of outgoing packets. = Suppose gleaning is turned off (so that gleaning cannot be utilized in = the attack):=20 >=20 > 1. Attacker could send a lot of packets to one address behind a = particular xTR, each packet with a different source EID. This causes the = xTR to do a mapping lookup for each one. This causes two problems in the = xTR: (i) control plane load (a simple data plane DOS has turned into a = control plane DOS); (ii) potential exhaustion of the cache. Optionally = the attacker could use the same source RLOC for each, but this could in = theory lead to the attacked xTR noticing and putting in a packet filter = for that source RLOC, so that varying the source RLOC may make this = attack more difficult to counter.=20 >=20 > 2. Attacker could send a lot of packets to many remote xTRs, one = packet to each, all with the same source forged EID and source RLOC, = with the source EID and source RLOC being that of the system that he = really wants to attack. This causes each to do the same mapping lookup, = which might overwhelm the mapping system serving the system under = attack.=20 >=20 > 3. Attacker could send a large number of map requests to many remote = xTRs, all with the same forged source EID and source RLOC, again with = the source EID and source RLOC being that of the system that he really = wants to attack. This causes each to send a map response to the system = under attack. This again would be intended to overwhelm the control = plane and cache of the system under attack.=20 >=20 > Suppose that the attacker controls a moderate sized BOTNET, consisting = of a few thousand captive systems. He might install enough software on = his BOT's to send a packet that looks like a LISP packet. In this case = each of the attacks discussed above can be multiplied by having a wider = range of systems participating in the attack.=20 >=20 >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From nobody Fri Jun 13 10:38:53 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 564271A0645 for ; Fri, 13 Jun 2014 10:38:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 GuSvhg5JEh5N for ; Fri, 13 Jun 2014 10:38:47 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0186.outbound.protection.outlook.com [207.46.163.186]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B84E1A0178 for ; Fri, 13 Jun 2014 10:38:47 -0700 (PDT) Received: from CO2PR05MB636.namprd05.prod.outlook.com (10.141.199.24) by CO2PR05MB634.namprd05.prod.outlook.com (10.141.199.17) with Microsoft SMTP Server (TLS) id 15.0.954.9; Fri, 13 Jun 2014 17:38:44 +0000 Received: from CO2PR05MB636.namprd05.prod.outlook.com ([10.141.199.24]) by CO2PR05MB636.namprd05.prod.outlook.com ([10.141.199.24]) with mapi id 15.00.0954.000; Fri, 13 Jun 2014 17:38:44 +0000 From: Ross Callon To: Damien Saucez Thread-Topic: [lisp] possible text for LISP threats Thread-Index: AQHPhyMnC8QSqTBqz0alNjaiEG8PF5tvOB5ggAAJo4CAAAxhwA== Date: Fri, 13 Jun 2014 17:38:43 +0000 Message-ID: <7513f69eda9b4417912f13dd90592775@CO2PR05MB636.namprd05.prod.outlook.com> References: <898c27d33fdd452499848408c9eac47f@CO2PR05MB636.namprd05.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.11] x-microsoft-antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: x-forefront-prvs: 0241D5F98C x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(428001)(189002)(164054003)(199002)(76104003)(13464003)(377454003)(24454002)(51704005)(99396002)(83322001)(19580405001)(99286001)(31966008)(101416001)(87936001)(74502001)(19580395003)(81542001)(77982001)(79102001)(74662001)(105586001)(74316001)(21056001)(64706001)(76482001)(15975445006)(92566001)(77096999)(54356999)(46102001)(76176999)(4396001)(2656002)(20776003)(33646001)(80022001)(76576001)(50986999)(81342001)(86362001)(83072002)(66066001)(85852003)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:CO2PR05MB634; H:CO2PR05MB636.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: juniper.net does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=rcallon@juniper.net; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/643z1kn6QrDS9ETdMWdNtbxCHts Cc: Luigi Iannone , LISP mailing list list Subject: Re: [lisp] possible text for LISP threats X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 17:38:50 -0000 > ... and I can propose you to write a > whitepaper with examples of attacks, and in each example showing to > which part of the abstraction of the threats document they refer. What do you propose would be done with this whitepaper?=20 Thanks, Ross -----Original Message----- From: Damien Saucez [mailto:damien.saucez@inria.fr]=20 Sent: Friday, June 13, 2014 12:54 PM To: Ross Callon Cc: Luigi Iannone; Olivier Bonaventure; LISP mailing list list Subject: Re: [lisp] possible text for LISP threats Hello Ross, Thank you for the input. Indeed we are working on the new version of the draft that will arrive for the cut-off date and hence for a big (huge?) discussion at IETF. 90=20 For the moment, I am compiling all the comments and examples given on the list to construct the most compact abstraction that covers everything. To avoid delaying the document any longer and hence the working group, I however think that we should not provide any example of attack in the draft but instead provide the most compact abstraction of attacks that permits to reconstruct any possible attack. Why? Because if we open the Pandora box of putting examples in the document, then we will never be able to close the document as it will always be possible to add an example even though these example would not add any information to the system. Another reason is that providing a 100 pages document would make it useless as the potential readers would get lost while reading which is not the case if the document is synthetic but still complete. Hence all the work we are doing for the moment is to construct the right abstraction so that any possible attack can really be casted into something in the document. Nevertheless, we all value examples, and I can propose you to write a whitepaper with examples of attacks, and in each example showing to which part of the abstraction of the threats document they refer. So as you can understand with this vision the challenge is to make the right abstraction. What do you think of all this? Damien Saucez=20 On 13 Jun 2014, at 18:26, Ross Callon wrote: > We have had significant discussion of attacks against the control plane o= f routers, and some discussion of the relative capacity of the control plan= e versus data plane. I have been thinking that the LISP threats document sh= ould give examples of DoS attacks against the control plane of the xTR's. I= f this will help with progression of the document, some possible text is be= low. I am not sure if this is complete but it might be a start.=20 >=20 > It is not completely obvious where this text would best fit into the exis= ting document, and my understanding is that some restructuring of the docum= ent is underway. Perhaps as new subsection(s) at the end of section 5.2 (De= nial of Service) of the existing document might be appropriate. I have writ= ten the text below as two subsections 5.2.3 and 5.2.4 of section 5.2, but o= f course there are other ways that this could be incorporated into the thre= ats document.=20 >=20 > Thanks, Ross > ------------ >=20 > 5.2.3 Control Plane versus Data Plane DOS attacks >=20 > In some cases, particularly very high speed routers, there may be a very = large difference between the capacity of the data plane versus the control = plane. For example, at the time this is written there are widely deployed r= outers which can handle a few terabits of data in the data plane. These rou= ters might typically have gigabit Ethernet links to the control processor, = but it is unlikely that they could handle Map-Requests coming in at line ra= te at a gigabit. Thus in some routers (particularly very high speed ones) t= he ratio between the speed of the control plane and the speed of the data p= lane may be significantly greater than 1,000. >=20 > This implies that DoS attacks against the control plane of routers may be= more serious than DOS attacks which only target the data plane. LISP allow= s data plane traffic to impact the control plane. Examples are included in = the following section.=20 >=20 > 5.2.4 Examples of DoS attacks >=20 > Suppose that the attacker has a single system that he controls, and that = his ISP does not check the source address of outgoing packets. Suppose glea= ning is turned off (so that gleaning cannot be utilized in the attack):=20 >=20 > 1. Attacker could send a lot of packets to one address behind a particula= r xTR, each packet with a different source EID. This causes the xTR to do a= mapping lookup for each one. This causes two problems in the xTR: (i) cont= rol plane load (a simple data plane DOS has turned into a control plane DOS= ); (ii) potential exhaustion of the cache. Optionally the attacker could us= e the same source RLOC for each, but this could in theory lead to the attac= ked xTR noticing and putting in a packet filter for that source RLOC, so th= at varying the source RLOC may make this attack more difficult to counter.= =20 >=20 > 2. Attacker could send a lot of packets to many remote xTRs, one packet t= o each, all with the same source forged EID and source RLOC, with the sourc= e EID and source RLOC being that of the system that he really wants to atta= ck. This causes each to do the same mapping lookup, which might overwhelm t= he mapping system serving the system under attack.=20 >=20 > 3. Attacker could send a large number of map requests to many remote xTRs= , all with the same forged source EID and source RLOC, again with the sourc= e EID and source RLOC being that of the system that he really wants to atta= ck. This causes each to send a map response to the system under attack. Thi= s again would be intended to overwhelm the control plane and cache of the s= ystem under attack.=20 >=20 > Suppose that the attacker controls a moderate sized BOTNET, consisting of= a few thousand captive systems. He might install enough software on his BO= T's to send a packet that looks like a LISP packet. In this case each of th= e attacks discussed above can be multiplied by having a wider range of syst= ems participating in the attack.=20 >=20 >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From nobody Fri Jun 13 10:54:50 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E418A1B2993 for ; Fri, 13 Jun 2014 10:54:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 ov24ADG1aHpG for ; Fri, 13 Jun 2014 10:54:46 -0700 (PDT) Received: from mail-pb0-x22a.google.com (mail-pb0-x22a.google.com [IPv6:2607:f8b0:400e:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F07671B297B for ; Fri, 13 Jun 2014 10:54:45 -0700 (PDT) Received: by mail-pb0-f42.google.com with SMTP id ma3so2106899pbc.1 for ; Fri, 13 Jun 2014 10:54:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=p6e4Aj6cdWTO2C49WCWg+6y6MYO68QeMuhCrWPLXsPM=; b=iExyP2wy4Vbggra6eB0ZbtmGLdd2NyM63pppq4Ajcb6TX9iv4/iUnWfloe+9XRV3EE PdOPhxACd7dXjg07z/JfesDYXryhn+2W0NOqs+8E5tC/gPEqZ/TLqTh8+LhLbWJnvH73 ZpxeJ1tSqJr4vUiGkJZZJAjfdhagL4owv5giQHTOqY2n5ek5JzUnczNFGvht1AmNMcTn K9jNzMXgfqZ03YRs8IstqZmsIh37nMnEG7f5bh2j6WZwXztxflMbCfwlDbm8/Ifbahmk rOvTMTg0cWyYpMYCIOgTyL6xuYpBfajOR6rulKyW/ZP540Zq5OtRQF4VPUpEivnrNKAC 5uqg== X-Received: by 10.68.129.99 with SMTP id nv3mr5143058pbb.128.1402682085612; Fri, 13 Jun 2014 10:54:45 -0700 (PDT) Received: from [10.169.113.83] (71-6-80-11.static-ip.telepacific.net. [71.6.80.11]) by mx.google.com with ESMTPSA id ei4sm4732448pbb.42.2014.06.13.10.54.44 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 13 Jun 2014 10:54:44 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Dino Farinacci In-Reply-To: <898c27d33fdd452499848408c9eac47f@CO2PR05MB636.namprd05.prod.outlook.com> Date: Fri, 13 Jun 2014 10:54:42 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <898c27d33fdd452499848408c9eac47f@CO2PR05MB636.namprd05.prod.outlook.com> To: Ross Callon X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/vc60kzpKCUsPLoegrRRbzEOnQyQ Cc: Damien Saucez , Luigi Iannone , LISP mailing list list Subject: Re: [lisp] possible text for LISP threats X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 17:54:48 -0000 > 5.2.4 Examples of DoS attacks >=20 > Suppose that the attacker has a single system that he controls, and = that his ISP does not check the source address of outgoing packets. = Suppose gleaning is turned off (so that gleaning cannot be utilized in = the attack):=20 Ross you have to be much more precise in your language or no one will = understand exactly what you are trying to get across. See my comments = below. For the above text, you shoudl say "all ISPs on the path do not do a = source check". > 1. Attacker could send a lot of packets to one address behind a = particular xTR, each packet with a different=20 You should state where the attacker is. In this case it is not at the = LISP site where you refer to the xTR. > source EID. This causes the xTR to do a mapping lookup for each one. = This causes two problems in the xTR: (i)=20 You need to say that the attacker is not necessarily at a LISP site but = its source address will be used by the xTR FOR RETURN TRAFFIC. You need = to make it clear if the mapping database should return a set of RLOCs or = what is returned is a negative Map-Reply. I presume the former since you = said the attacker uses a "source EID". > control plane load (a simple data plane DOS has turned into a control = plane DOS); (ii) potential exhaustion of I think you should make it clear this is not unique to LISP. Because = what you refer to as a data-plane DoS means that the hardware can drop = packets, where as you know any packet that needs to go to the control = plane would result the same way. You don't want to mislead people to think LISP is worse in this case. > the cache. Optionally the attacker could use the same source RLOC for = each, but this could in theory lead to=20 If the cache is going to be exhausted you need to say that each source = EID chosen will match a different EID-prefix in the mapping database = causing distinct entries to be created. Otherwise, if all the source = EIDs come out of a registered coarse prefix, then only one cach entry is = used. > the attacked xTR noticing and putting in a packet filter for that = source RLOC, so that varying the source RLOC may make this attack more = difficult to counter.=20 You shouldn't say how the xTR would handle this or else, yes, it will = get worse. Because if you choose a faulty solution, you will introduce = more issues. > 2. Attacker could send a lot of packets to many remote xTRs, one = packet to each, all with the same source forged EID and source RLOC, = with the source EID and source RLOC being that of the system that he = really wants to attack. This causes each to do the same mapping lookup, = which might overwhelm the mapping system serving the system under = attack.=20 This is written well and clear if (1) is written with more detail. > 3. Attacker could send a large number of map requests to many remote = xTRs, all with the same forged source EID and source RLOC, again with = the source EID and source RLOC being that of the system that he really = wants to attack. This causes each to send a map response to the system = under attack. This again would be intended to overwhelm the control = plane and cache of the system under attack.=20 This is written well. Thanks. > Suppose that the attacker controls a moderate sized BOTNET, consisting = of a few thousand captive systems. He might install enough software on = his BOT's to send a packet that looks like a LISP packet. In this case = each of the attacks discussed above can be multiplied by having a wider = range of systems participating in the attack.=20 Ditto. Thanks, Dino From nobody Fri Jun 13 11:36:23 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16A461A05F5 for ; Fri, 13 Jun 2014 11:36:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 GBLfN7W-jm52 for ; Fri, 13 Jun 2014 11:36:18 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0239.outbound.protection.outlook.com [207.46.163.239]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A66A51B29C8 for ; Fri, 13 Jun 2014 11:36:18 -0700 (PDT) Received: from CO2PR05MB636.namprd05.prod.outlook.com (10.141.199.24) by CO2PR05MB636.namprd05.prod.outlook.com (10.141.199.24) with Microsoft SMTP Server (TLS) id 15.0.954.9; Fri, 13 Jun 2014 18:36:17 +0000 Received: from CO2PR05MB636.namprd05.prod.outlook.com ([10.141.199.24]) by CO2PR05MB636.namprd05.prod.outlook.com ([10.141.199.24]) with mapi id 15.00.0954.000; Fri, 13 Jun 2014 18:36:17 +0000 From: Ross Callon To: Dino Farinacci Thread-Topic: [lisp] possible text for LISP threats Thread-Index: AQHPhyMnC8QSqTBqz0alNjaiEG8PF5tvOB5ggAAatgCAAAJXEA== Date: Fri, 13 Jun 2014 18:36:16 +0000 Message-ID: <68c3feb199e840908a8516ee7dc9f357@CO2PR05MB636.namprd05.prod.outlook.com> References: <898c27d33fdd452499848408c9eac47f@CO2PR05MB636.namprd05.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.11] x-microsoft-antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: x-forefront-prvs: 0241D5F98C x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(428001)(164054003)(54094003)(199002)(51704005)(51444003)(189002)(33646001)(4396001)(46102001)(21056001)(2656002)(99396002)(80022001)(101416001)(92566001)(66066001)(99286001)(105586001)(83322001)(74502001)(76482001)(77982001)(50986999)(83072002)(85852003)(87936001)(74316001)(79102001)(31966008)(74662001)(76576001)(20776003)(1411001)(81342001)(81542001)(64706001)(77096999)(54356999)(76176999)(86362001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:CO2PR05MB636; H:CO2PR05MB636.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (: juniper.net does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=rcallon@juniper.net; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/g4ZMDFTn4oPDDlYEpTrDzjuPF00 Cc: Damien Saucez , Luigi Iannone , LISP mailing list list Subject: Re: [lisp] possible text for LISP threats X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 18:36:21 -0000 A few snippets (with the rest dropped, at least for this one email)... > Ross you have to be much more precise in your language... More precision and detail is a good idea. > For the above text, you shoudl say "all ISPs on the path do not do a sour= ce check". When you are looking at "big core ISP" connected to another "big core ISP",= my understanding is that source checks are normally not done because it is= too hard to know what source IP addresses a very large ISP might legitimat= ely source (other than "all"). Yes, if a very small ISP (say, a single univ= ersity network) is attacked to a larger ISP (say, a national service provid= er) then the source check might be done either at the entry from the host t= o the small ISP, or from the small ISP to the larger ISP. Both would need t= o be missing for my attack #1 to succeed, at least if the source RLOC's wer= e forged.=20 > You should state where the attacker is. In this case it is not at the LIS= P site where you refer to the xTR. That was my intention, so yes it should be stated. I was specifically think= ing of the "attacks from elsewhere in the worldwide open Internet" case, wh= ich probably should be stated.=20 > You need to say that the attacker is not necessarily at a LISP site Correct... > but its source address will be used by the xTR FOR RETURN TRAFFIC. You ne= ed to make it > clear if the mapping database should return a set of RLOCs or what is ret= urned is a > negative Map-Reply. I presume the former since you said the attacker uses= a "source EID". I think that you are correct that a bit more detail is appropriate here. Ho= wever, in my scenario 1 I am concerned about the control plane load of the = xTR being forced to send out a lot of map requests, so it is not clear that= it matters what the response will be to those map requests. Of course ther= e is also the problem that if the forged source EID's span a large fraction= of the full LISP database, then the replies that the xTR receives from its= map requests will also span the LISP database and fill the cache. Thus you= are correct that more detail would be appropriate here.=20 > I think you should make it clear this is not unique to LISP... > You don't want to mislead people to think LISP is worse in this case. For the host to which the attack packets are destined, I don't think that L= ISP is worse in this case. However, it is not the effect on a host that I a= m concerned about. If the xTR serving that host in this case is either a CE= router or a PE router, then this is a lot worse for the xTR, since the att= ack packets cause a reaction in its control plane. Of course if the effect = of the attack is to fill the cache, then again LISP is worse since "non-LIS= P Internet operation" doesn't have a cache. I understand that we are not pl= anning to describe solutions in this text, but if rate limiting of map requ= ests is considered to be normal practice, I wonder if it would be worth men= tioning that rate limiting could prevent overload of the xTR's control plan= e, but that in this case the attack could prevent map requests in support o= f legitimate users.=20 > If the cache is going to be exhausted you need to say that each source EI= D chosen > will match a different EID-prefix in the mapping database causing distinc= t entries to be created... Correct. >> the attacked xTR noticing and putting in a packet filter for that source= RLOC, >> so that varying the source RLOC may make this attack more difficult to c= ounter.=20 > > You shouldn't say how the xTR would handle this or else, yes, it will get= worse. > Because if you choose a faulty solution, you will introduce more issues. I am fine with dropping the sentence stating "Optionally the attacker could= use the same source RLOC for each, but this could in theory lead to the at= tacked xTR noticing and putting in a packet filter for that source RLOC, so= that varying the source RLOC may make this attack more difficult to counte= r". However, I do wonder, what would happen if a single attacker sent a lar= ge number of packets which look like LISP packets with the same RLOC for al= l (perhaps the legitimate RLOC of the attacker) but with different EID's, e= ach EID chosen from a different EID block. Would the xTR receiving all of t= hese incoming packets send a map request for each EID? This could be a way = to get around source IP address checks (where they are deployed), since the= source RLOC would be correct and legitimate.=20 > Thanks, > Dino Thanks, Ross From nobody Fri Jun 13 12:02:44 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40D2F1B29E1 for ; Fri, 13 Jun 2014 12:02:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.302 X-Spam-Level: X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 QRoLkY9UPEQ0 for ; Fri, 13 Jun 2014 12:02:40 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0167C1A01FF for ; Fri, 13 Jun 2014 12:02:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 8168D301EF8 for ; Fri, 13 Jun 2014 12:02:39 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-134-230.clppva.east.verizon.net [70.106.134.230]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 9C324301EF6 for ; Fri, 13 Jun 2014 12:02:38 -0700 (PDT) Message-ID: <539B4AD4.2050208@joelhalpern.com> Date: Fri, 13 Jun 2014 15:02:44 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "lisp@ietf.org" References: <27940.1402685371@sandelman.ca> In-Reply-To: <27940.1402685371@sandelman.ca> X-Forwarded-Message-Id: <27940.1402685371@sandelman.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/g-vhsej9Q7dTDumYt0l2lo3ZkFQ Subject: [lisp] Fwd: third call: NomCom 2014-2015 Call for Volunteers (version 2.0) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 19:02:41 -0000 -------- Original Message -------- Subject: third call: NomCom 2014-2015 Call for Volunteers (version 2.0) Date: Fri, 13 Jun 2014 14:49:31 -0400 From: Michael Richardson Reply-To: mcr+nomcom@sandelman.ca To: ietf@ietf.org <#secure method=pgpmime mode=sign> This is the third call for volunteers. (appologies for duplication: there are unresolved datatracker<->lists.ietf.org issues with the automatic tool) This message also differs in that the list of volunteers has grown slightly since attempts to post earlier today, and some duplicates removed. VOLUNTEER NOW: we need to make 200. The DEADLINE is June 26 to volunteer. The IETF nomcom appoints folks to fill the open slots on the IAOC, the IAB, and the IESG (including IETF Chair). If your name is on the below, then you have volunteered and are qualified. In addition to those who volunteered by email, it also includes those who indicated their willingness to serve on the IETF90 registration form, and whose eligibility has been confirmed. The total is up to 118 people confirmed. An additional 60 people who volunteered on the registration form have yet to confirmed as eligible, and have been contacted directly. If you have heard from me, but are not on the list, then there is some problem, and you should have gotten a query from me to determine your eligibility. If you have volunteered and not heard from me, then please resend;it got lost. Ten voting members for the nomcom are selected in a verifiably random way from a pool of volunteers. The more volunteers, the better chance we have of choosing a random yet representative cross section of the IETF population. Let's break the 200 volunteer mark again this year! We are at 118 volunteers so far, and WE NEED TO HAVE 200!!! The details of the operation of the nomcom can be found in RFC 3777, and BCP10/RFC3797 details the selection algorithm. Volunteers must have attended 3 of the past 5 IETF meetings. As specified in RFC 3777, that means three out of the five past meetings up to the time this email announcement goes out to start the solicitation of volunteers. The five meetings out of which you must have attended *three* are IETF 85(Atlanta), \ 86(Orlando), \ 87(Berlin), *** ANY THREE! 88(Vancouver), / 89(London) / If you qualify, please volunteer. However, much as we want this, before you decide to volunteer, please be sure you are willing to forgo appointment to any of the positions for which this nomcom is responsible. The list of people and posts whose terms end with the March 2015 IETF meeting, and thus the positions for which this nomcom is responsible, are IAOC: To be confirmed IAB: Joel Halpern Russ Housley Eliot Lear Xing Li Andrew Sullivan Dave Thaler IESG: Pete Resnick (Applications) Ted Lemon (Internet) Joel Jaeggli (Operations and Management) Richard Barnes (RAI) Adrian Farrel* (Routing) Stephen Farrell (Security) Spencer Dawkins (Transport) Jari Arkko (Gen) (names with * have publically indicated they will not serve another term) The primary activity for this nomcom will begin in July 2014 and should be completed in January 2015. The nomcom will have regularly scheduled conference calls to ensure progress. (We might dogfood WebRTC) There will be activities to collect requirements from the community, review candidate questionnaires, review feedback from community members about candidates, and talk to candidates. Thus, being a nomcom member does require some time commitment; but it is also a very rewarding experience. It is very important that you be able to attend IETF91 to conduct interviews. Being at IETF90 is useful for training. Being at IETF92 is not essential. Please volunteer by sending me an email before 11:59 pm EDT (UTC -4 hours) June 22, 2013, as follows: To: nomcom-chair-2014@ietf.org Subject: Nomcom 2014-15 Volunteer Please include the following 4 lines the email body (it is simplest if you just include the info); Your Full Name Emails used to register Telephone Current Primary Affiliation You should expect an email response from me within 3 business days stating whether or not you are qualified. If you don't receive this response, please re-send your email with the tag "RESEND"" added to the subject line. If you are not yet sure if you would like to volunteer, please consider that nomcom members play a very important role in shaping the leadership of the IETF. Questions by email or voice are welcome. Volunteering for the nomcom is a great way to contribute to the IETF! You can find a detailed timeline on the nomcom web site at: https://datatracker.ietf.org/nomcom/2014/ I will be publishing a more detailed target timetable, as well as details of the randomness seeds to be used for the RFC 3797 selection process, within the next couple weeks. Thank you! Michael Richardson mcr+nomcom@sandelman.ca nomcom-chair-2014@ietf.org ===== qualified volunteers so far, in alphabetical order by first name ANM Zaheduzzaman Sarker Adam Montville Ari Ker?nen Benson Schliesser Bhumip Khasnabish Bill VerSteeg Carl Williams Carlos Martinez Charles Eckel Charles Perkins Christer Holmberg Craig White DHRUV DHODY Dacheng Zhang Damien Saucez Dapeng Liu Dean Bogdanovic Dimitri Papadimitriou Donald Eastlake Edward Crabbe Emil Ivov Eric Rescorla Eric VYNCKE Fangwei Hu Fatai Zhang Fernando Gont Fred Baker Giles Heron Gonzalo Salgueiro Gregory Mirsky Hannes Gredler Hongyu Li Hosnieh Rafiee Hugo Salgado Hui Deng Iuniana Oprescu Jeff Tantsura John E Drake John Jason Brzozowski John Levine John Scudder Jon Hudson Jon Mitchell Joseph Abley Karen O'Donoghue Karen Seo Kaveh Ranjbar Klaas Wierenga Kostas Pentikousis Larry Masinter Lars Eggert Lee Howard Lei Zhu Li Xue Linda Dunbar Lingli Deng Louis (Lou) Berger Luca Martini Lucy Lynch -900 Lucy Yong Luigi Iannone Mach Chen Mahesh Jethanandani Marcelo Bagnulo Mark Townsley Matt Lepinski Matthew Bocci Mehmet Ersue Melinda Shore Michael Jones Min Ye Mingui Zhang Ning Zong Ole Troan Pascal Thubert Paul Hoffman Peter Lothberg Peter Yee QIN WU Ralph Droms Ron Bonica Ross Callon Ross Finlayson Russ White Sam K. Aldrin Samuel Weiler Sandeep Kumar Sanjay Mishra Scott Mansfield Sheng JIANG Shucheng Liu Simon Pietro Romano Stan Ratliff Stephan Friedl Stephan Wenger Stephen Kent Stewart Bryant Stig Venaas Suhas Nandakumar Suresh Krishnan Susan Hares Thomas Walsh Tim Wicinski Tissa Senevirathne Toerless Eckert Tony Hansen Ulrich Herberg Varun Singh Wassim Haddad Xiaohu XU Yi Zhao Yizhou Li Yong Cui Yuanlong Jiang Yunfei Zhang Zhaohui Zhang Zhen Cao iuniana oprescu From nobody Fri Jun 13 12:36:37 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D856E1B2A06 for ; Fri, 13 Jun 2014 12:36:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 LElPvMrIEMNY for ; Fri, 13 Jun 2014 12:36:32 -0700 (PDT) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46E161B29EC for ; Fri, 13 Jun 2014 12:36:32 -0700 (PDT) Received: by mail-pa0-f43.google.com with SMTP id lf10so2448497pab.30 for ; Fri, 13 Jun 2014 12:36:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=RTPrVIOo8pMvat0CviohBRSMxky4Lo/BhbaJTn77vpk=; b=zyJajeaUM8tTijjTDrWZ7T4LpN9H/Y25rhRsn9SKoXuQxfOEljvcIVP0z932EajDCl pzxEik9BBnuLyq8eV/z5vDNOmKdQ1jM9RY72r15kQn0NNGWjQUcuVNPJ+dWyJWpWGHTx BbHlAJmz2qdJP1+UUnJPa3GJmnoWXYx6hGNrrKW3xd6w+7Zg8ny0HBzY7pAB886fAzrr 9mReva3nBwNcXUPMPkLzfHtC/Zz5BJuYUIaDmn75LDtIclyAO+tMtKi4S3h7Aev5MnDI 7rRbjA1Gkc8FYKJQqCET3DFAcTVKQu6NkEASLL0kNSjfgTazve7HvRrJdjo8tgBMpUVQ NoKg== X-Received: by 10.66.146.105 with SMTP id tb9mr5697425pab.157.1402688191912; Fri, 13 Jun 2014 12:36:31 -0700 (PDT) Received: from [192.168.1.174] ([207.145.253.66]) by mx.google.com with ESMTPSA id kq10sm5005464pbc.90.2014.06.13.12.36.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 13 Jun 2014 12:36:30 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Dino Farinacci In-Reply-To: <68c3feb199e840908a8516ee7dc9f357@CO2PR05MB636.namprd05.prod.outlook.com> Date: Fri, 13 Jun 2014 12:36:27 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <898c27d33fdd452499848408c9eac47f@CO2PR05MB636.namprd05.prod.outlook.com> <68c3feb199e840908a8516ee7dc9f357@CO2PR05MB636.namprd05.prod.outlook.com> To: Ross Callon X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/vcFlTBTwDheMxyHIjqaFshmGUPQ Cc: Damien Saucez , Luigi Iannone , LISP mailing list list Subject: Re: [lisp] possible text for LISP threats X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 19:36:34 -0000 > For the host to which the attack packets are destined, I don't think = that LISP is worse in this case. However, it is not the effect on a host = that I am concerned about. If the xTR serving that host in this case is = either a CE router or a PE router, then this is a lot worse for the xTR, = since the attack packets cause a reaction in its control plane. Of = course if the effect of the attack is to fill the cache, then again LISP = is worse since "non-LISP Internet operation" doesn't have a cache. I = understand that we are not planning to describe solutions in this text, = but if rate limiting of map requests is considered to be normal = practice, I wonder if it would be worth mentioning that rate limiting = could prevent overload of the xTR's control plane, but that in this case = the attack could prevent map requests in support of legitimate users.=20 I beg to differ, because what you refer to a cache makes assumptions = that it is finite size. A BGP RIB is finite size as well. And even a = legit BGP peer can fill up a finite size RIB. So it is my claim that LISP is no worse. > the attacked xTR noticing and putting in a packet filter for that = source RLOC, >>> so that varying the source RLOC may make this attack more difficult = to counter.=20 >>=20 >> You shouldn't say how the xTR would handle this or else, yes, it will = get worse. >> Because if you choose a faulty solution, you will introduce more = issues. >=20 > I am fine with dropping the sentence stating "Optionally the attacker = could use the same source RLOC for each, but this could in theory lead = to the attacked xTR noticing and putting in a packet filter for that = source RLOC,=20 I wouldn't put in a packet filter or else the real RLOC is denied = service by the attacked xTR itself. > so that varying the source RLOC may make this attack more difficult to = counter". However, I do wonder, what would happen if a single attacker = sent a large number of packets which look like LISP packets with the = same RLOC for all (perhaps the legitimate RLOC of the attacker) but with = different EID's, each EID chosen from a different EID block. Would the = xTR receiving all of these incoming packets send a map request for each = EID?=20 This is what Ron brought up. > This could be a way to get around source IP address checks (where they = are deployed), since the source RLOC would be correct and legitimate.=20 Right, understand. It all comes down to the (source-EID, source-RLOC)-tuple needs to be = authenticated to be the legitimate source. Dino From nobody Mon Jun 16 08:16:43 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B63611A0076 for ; Mon, 16 Jun 2014 08:16:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, SPF_PASS=-0.001] autolearn=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 x0q0hA6m5kh9 for ; Mon, 16 Jun 2014 08:16:38 -0700 (PDT) Received: from zproxy110.enst.fr (zproxy110.enst.fr [137.194.52.33]) by ietfa.amsl.com (Postfix) with ESMTP id 29E2E1A0071 for ; Mon, 16 Jun 2014 08:16:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zproxy110.enst.fr (Postfix) with ESMTP id 65B5D1013FD; Mon, 16 Jun 2014 17:16:37 +0200 (CEST) Received: from zproxy110.enst.fr ([127.0.0.1]) by localhost (zproxy110.enst.fr [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id B_G2kzSHBIkN; Mon, 16 Jun 2014 17:16:33 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zproxy110.enst.fr (Postfix) with ESMTP id 5698310111F; Mon, 16 Jun 2014 17:16:33 +0200 (CEST) X-Virus-Scanned: amavisd-new at zproxy110.enst.fr Received: from zproxy110.enst.fr ([127.0.0.1]) by localhost (zproxy110.enst.fr [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id BbG-Q-A3OjGZ; Mon, 16 Jun 2014 17:16:33 +0200 (CEST) Received: from dhcp164-99.enst.fr (dhcp164-99.enst.fr [137.194.165.99]) by zproxy110.enst.fr (Postfix) with ESMTPSA id 0EBE6101030; Mon, 16 Jun 2014 17:16:33 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Luigi Iannone In-Reply-To: <7513f69eda9b4417912f13dd90592775@CO2PR05MB636.namprd05.prod.outlook.com> Date: Mon, 16 Jun 2014 17:16:31 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1112BE1B-1842-4551-A7F5-DDB4FF00D80F@telecom-paristech.fr> References: <898c27d33fdd452499848408c9eac47f@CO2PR05MB636.namprd05.prod.outlook.com> <7513f69eda9b4417912f13dd90592775@CO2PR05MB636.namprd05.prod.outlook.com> To: Ross Callon X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/W8oytpLjptRe_YwtkcVhFMtpiXo Cc: Damien Saucez , LISP mailing list list Subject: Re: [lisp] possible text for LISP threats X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 15:16:40 -0000 Hi, I guess that Damien=92s point was about the fact that we could find = zillions of examples on how to carry out the very same attack. Whitepaper is an =93example=94 of where those examples can be written, = he was not proposing to actually write one. The threats document is an analysis of LISP-related threats and IMHO = should not be transformed in a LISP-hacking 101 guide. Luigi On 13 Jun 2014, at 19:38, Ross Callon wrote: >> ... and I can propose you to write a >> whitepaper with examples of attacks, and in each example showing to >> which part of the abstraction of the threats document they refer. >=20 > What do you propose would be done with this whitepaper?=20 >=20 > Thanks, Ross >=20 > -----Original Message----- > From: Damien Saucez [mailto:damien.saucez@inria.fr]=20 > Sent: Friday, June 13, 2014 12:54 PM > To: Ross Callon > Cc: Luigi Iannone; Olivier Bonaventure; LISP mailing list list > Subject: Re: [lisp] possible text for LISP threats >=20 > Hello Ross, >=20 > Thank you for the input. Indeed we are working on the new version of > the draft that will arrive for the cut-off date and hence for a big = (huge?) > discussion at IETF. 90=20 >=20 > For the moment, I am compiling all the comments and examples given on > the list to construct the most compact abstraction that covers = everything. >=20 > To avoid delaying the document any longer and hence the working group, > I however think that we should not provide any example of attack in > the draft but instead provide the most compact abstraction of attacks > that permits to reconstruct any possible attack. Why? Because if we > open the Pandora box of putting examples in the document, then we will > never be able to close the document as it will always be possible to > add an example even though these example would not add any information > to the system. Another reason is that providing a 100 pages document > would make it useless as the potential readers would get lost while > reading which is not the case if the document is synthetic but still > complete. Hence all the work we are doing for the moment is to > construct the right abstraction so that any possible attack can really > be casted into something in the document. >=20 > Nevertheless, we all value examples, and I can propose you to write a > whitepaper with examples of attacks, and in each example showing to > which part of the abstraction of the threats document they refer. >=20 > So as you can understand with this vision the challenge is to make the > right abstraction. >=20 > What do you think of all this? >=20 > Damien Saucez=20 >=20 > On 13 Jun 2014, at 18:26, Ross Callon wrote: >=20 >> We have had significant discussion of attacks against the control = plane of routers, and some discussion of the relative capacity of the = control plane versus data plane. I have been thinking that the LISP = threats document should give examples of DoS attacks against the control = plane of the xTR's. If this will help with progression of the document, = some possible text is below. I am not sure if this is complete but it = might be a start.=20 >>=20 >> It is not completely obvious where this text would best fit into the = existing document, and my understanding is that some restructuring of = the document is underway. Perhaps as new subsection(s) at the end of = section 5.2 (Denial of Service) of the existing document might be = appropriate. I have written the text below as two subsections 5.2.3 and = 5.2.4 of section 5.2, but of course there are other ways that this could = be incorporated into the threats document.=20 >>=20 >> Thanks, Ross >> ------------ >>=20 >> 5.2.3 Control Plane versus Data Plane DOS attacks >>=20 >> In some cases, particularly very high speed routers, there may be a = very large difference between the capacity of the data plane versus the = control plane. For example, at the time this is written there are widely = deployed routers which can handle a few terabits of data in the data = plane. These routers might typically have gigabit Ethernet links to the = control processor, but it is unlikely that they could handle = Map-Requests coming in at line rate at a gigabit. Thus in some routers = (particularly very high speed ones) the ratio between the speed of the = control plane and the speed of the data plane may be significantly = greater than 1,000. >>=20 >> This implies that DoS attacks against the control plane of routers = may be more serious than DOS attacks which only target the data plane. = LISP allows data plane traffic to impact the control plane. Examples are = included in the following section.=20 >>=20 >> 5.2.4 Examples of DoS attacks >>=20 >> Suppose that the attacker has a single system that he controls, and = that his ISP does not check the source address of outgoing packets. = Suppose gleaning is turned off (so that gleaning cannot be utilized in = the attack):=20 >>=20 >> 1. Attacker could send a lot of packets to one address behind a = particular xTR, each packet with a different source EID. This causes the = xTR to do a mapping lookup for each one. This causes two problems in the = xTR: (i) control plane load (a simple data plane DOS has turned into a = control plane DOS); (ii) potential exhaustion of the cache. Optionally = the attacker could use the same source RLOC for each, but this could in = theory lead to the attacked xTR noticing and putting in a packet filter = for that source RLOC, so that varying the source RLOC may make this = attack more difficult to counter.=20 >>=20 >> 2. Attacker could send a lot of packets to many remote xTRs, one = packet to each, all with the same source forged EID and source RLOC, = with the source EID and source RLOC being that of the system that he = really wants to attack. This causes each to do the same mapping lookup, = which might overwhelm the mapping system serving the system under = attack.=20 >>=20 >> 3. Attacker could send a large number of map requests to many remote = xTRs, all with the same forged source EID and source RLOC, again with = the source EID and source RLOC being that of the system that he really = wants to attack. This causes each to send a map response to the system = under attack. This again would be intended to overwhelm the control = plane and cache of the system under attack.=20 >>=20 >> Suppose that the attacker controls a moderate sized BOTNET, = consisting of a few thousand captive systems. He might install enough = software on his BOT's to send a packet that looks like a LISP packet. In = this case each of the attacks discussed above can be multiplied by = having a wider range of systems participating in the attack.=20 >>=20 >>=20 >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From nobody Mon Jun 16 08:22:08 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F5751A0085 for ; Mon, 16 Jun 2014 08:22:06 -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, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 BRR8gsa_l4BU for ; Mon, 16 Jun 2014 08:22:02 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A508B1A008D for ; Mon, 16 Jun 2014 08:22:01 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id x13so5797527wgg.27 for ; Mon, 16 Jun 2014 08:22:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=99QSU4Ny1VCjRk8LXb0K7FsoMaGKlfMSjFEHqZviK9Q=; b=YfAwR3uPm05q7RjLZ7gIq7a/fMFA8aFD7DOS4I8roC0T196uO/ZV1X6kXDSdnsZbIP dwmjnKflAJltzLUko/yDCbuvlK2tZwIYHmuPTCd4KG17YaujwAd+fmZl4w3xXoCX5k3K 7mYHqIU3ZzjAhXO+eqTmEsYnJNge0uvQRg5GwHflSZkm16Qi5OMsqE5dByTacyVt/Gkh ys/0aw9P939jYR5hcj+mwFCSHPORwCN3eTncpNRHkQBKhLqaVQZa2qGtjuwfoRE4YF+R ndJ7Q0sxw/dMwm8yt4EhXrcgWAfQ0cPk5HhwXp+tXj1LYwHbepWprasjT5DYyPb5jMIe 83Bw== X-Gm-Message-State: ALoCoQlNjvsETgPT083s431Z2lwuhyGO93JGZ0fRvWN6rOBnuYasBySFoli1ZogPtVwZUkPM95lJ X-Received: by 10.194.10.130 with SMTP id i2mr28971301wjb.70.1402932119937; Mon, 16 Jun 2014 08:21:59 -0700 (PDT) Received: from ?IPv6:2001:660:330f:a4:cc6e:8e41:364c:3f86? ([2001:660:330f:a4:cc6e:8e41:364c:3f86]) by mx.google.com with ESMTPSA id f7sm19182943wjy.24.2014.06.16.08.21.58 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 16 Jun 2014 08:21:58 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Luigi Iannone In-Reply-To: <5CAAEAE6-AF3E-4E27-8D73-FA8A64520379@gmail.com> Date: Mon, 16 Jun 2014 17:21:56 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <40ecc5d773874ecdbdc05763004acfa7@CO1PR05MB442.namprd05.prod.outlook.com> <5399D22A.2040207@joelhalpern.com> <5CAAEAE6-AF3E-4E27-8D73-FA8A64520379@gmail.com> To: Dino Farinacci X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/oI5QYiVNVMyrsEo_3zFBrszklVA Cc: LISP mailing list list Subject: Re: [lisp] Restarting last call on LISP threats X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 15:22:06 -0000 Hi Dino, fair point. I guess that Joel=92s point was on the fact that this = specific thread should focus on the LISP threats document. Obviously this mailing list is the place where all technical discussions = about LISP can take place.=20 We should just fork the discussion. So to clearly separate what is related to the threats document and what = are new proposals to alleviate some threats.=20 ciao Luigi =20 On 12 Jun 2014, at 18:23, Dino Farinacci wrote: > I agree we should be focused Joel.=20 >=20 > But where else should we have open discussions about LISP? >=20 > This mailing list membership is unique in that we have multiple = vendors, operators, and users all in one place. Wouldn't that make for = better protocols? >=20 > Yes we have business to take care of but let's not stifle ideas and = openness. Do you agree? >=20 > Dino >=20 > On Jun 12, 2014, at 9:15 AM, Joel M. Halpern = wrote: >=20 >> I will repeat myself. >> Can we PLEASE not get into debating how we would solve the weakness = in the protocol as documented. >>=20 >> The question focus on is whether the protocol as specified has the = behavior described, and if so does it result in the weakness described. >> If it does, that should be described in the threats document. >> if not, then it should not be so described. >>=20 >> The presence, absence, validity, or possibility of solutions in other = documents, operational practices, or people's heads, are not the topic = for the WG at this time. >>=20 >> PLEASE stay on topic, or we will never get our current work done. >> Which means that peoples wonderful ideas on how to do more or better = will never get publsihed. >>=20 >> Yours, >> Joel >>=20 >> On 6/12/14, 11:24 AM, Dino Farinacci wrote: >>>=20 >>>>> Could you describe precisely the attack you have in mind? The = only >>>>> think I can see is relying on the birthday paradox but that is a >>>>> completely different story. >>>>=20 >>>> If an attacker is on-path it could see the nonce's (assuming that = the LISP header is not encrypted, regardless of whether the data packet = is encrypted). This could be an issue if the attacker is physically = on-path. >>>=20 >>> The source EID is encrypted so it can only see a cleartext source = RLOC and can't associated it with anything. >>>=20 >>> When we merge lisp-cryto logic with echo-noncing, one has to = determine if an xTR should participate in echo-noncing if the payload is = not decrypted properly. That is, if I get a echoed nonce back from an = attacker for a nonce I know I have sent and set the E-bit, and I cannot = decrypt the payload that comes from the attacker, then I don't believe = any NEW reachability information about the RLOC. >>>=20 >>>> This could also be an issue for attackers which are physically = off-path if gleaning is used, since an attacker could use a gleaning = attack to temporarily insert itself on-path, which in turn would allow = it to see the nonce. >>>=20 >>> So by now we know there are many issues with gleaning. So we should = document them and say they shouldn't be used for the general global = Internet use-case. >>>=20 >>> Dino >>>=20 >>>>=20 >>>> Ross >>>>=20 >>>> -----Original Message----- >>>> From: lisp [mailto:lisp-bounces@ietf.org] On Behalf Of Damien = Saucez >>>> Sent: Thursday, June 12, 2014 8:08 AM >>>> To: Ronald Bonica >>>> Cc: LISP mailing list list >>>> Subject: Re: [lisp] Restarting last call on LISP threats >>>>=20 >>>> Hello, >>>>=20 >>>> I am not sure I understand exactly what you are proposing. How can = a >>>> LISP router decide that a RLOC is done by simply receiving an ICMP >>>> packet from an attacker (except with LSB that is discussed in Sec >>>> 4.3.2.1. )? All the other techniques are triggered by the LISP >>>> router and are protected by the nonce. >>>>=20 >>>> Could you describe precisely the attack you have in mind? The only >>>> think I can see is relying on the birthday paradox but that is a >>>> completely different story. >>>>=20 >>>> Damien Saucez >>>>=20 >>>> On 10 Jun 2014, at 21:37, Ronald Bonica = wrote: >>>>=20 >>>>> Dino, >>>>>=20 >>>>> Exactly! So, assume the following: >>>>>=20 >>>>> - LISP is deployed on the global Internet >>>>> - An RLOC is mapped to some number of EID prefixes >>>>> - For a subset of those EID prefixes, the above mentioned RLOC is = preferred >>>>> - An ITR receives a hint indicating that the RLOC is down (either = through a LISP data packet or an ICMP message) >>>>>=20 >>>>> The ITR will verify RLOC reachability (possibly by polling the = RLOC). But until the ITR has receives a response to its poll, how should = it behave? Should it continue sending traffic though the above mentioned = RLOC? Or should it begin to send traffic through another RLOC, if one = exists? I don't see a normative recommendation. >>>>>=20 >>>>> However, both behaviors have their drawbacks and could be vectors = for attack. >>>>>=20 >>>>> = Ron >>>>>=20 >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Dino Farinacci [mailto:farinacci@gmail.com] >>>>>> Sent: Tuesday, June 10, 2014 1:23 PM >>>>>> To: Ronald Bonica >>>>>> Cc: LISP mailing list list >>>>>> Subject: Re: [lisp] Restarting last call on LISP threats >>>>>>=20 >>>>>> As I keep saying Ron, you need to verify anything you intend to = glean. The >>>>>> spec says the gleaning is "a hint" and not gospel. >>>>>>=20 >>>>>> Dino >>>>>>=20 >>>>>> On Jun 10, 2014, at 10:06 AM, Ronald Bonica = wrote: >>>>>>=20 >>>>>>> Hi Dino, >>>>>>>=20 >>>>>>> Given that the LISP data packet or ICMP packet may be from an = attacker, is >>>>>> it even safe to glean that? I think not. >>>>>>>=20 >>>>>>>=20 >>>>>>> Ron >>>>>>>=20 >>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: Dino Farinacci [mailto:farinacci@gmail.com] >>>>>>>> Sent: Tuesday, June 10, 2014 1:04 PM >>>>>>>> To: Ronald Bonica >>>>>>>> Cc: LISP mailing list list >>>>>>>> Subject: Re: [lisp] Restarting last call on LISP threats >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On Jun 10, 2014, at 9:57 AM, Ronald Bonica = wrote: >>>>>>>>=20 >>>>>>>>> Earlier in this thread, we agreed that when LISP is deployed = on the >>>>>>>>> global >>>>>>>> Internet, mapping information cannot be gleaned safely from = incoming >>>>>>>> LISP data packets. Following that train of thought, when LISP = is >>>>>>>> deployed on the global Internet, is it safe to glean routing = locator >>>>>>>> reachability information from incoming LISP data packets as = described >>>>>>>> in RFC 6830, Section 6.3, bullet 1. If not, I think that we = need to mention >>>>>> this in the threats document. >>>>>>>>=20 >>>>>>>> What you can glean is that the source RLOC is up, but you = cannot >>>>>>>> glean your path to it is reachable. >>>>>>>>=20 >>>>>>>>> Given that ICMP packets are easily spoofed, when LISP is = deployed on >>>>>>>>> the >>>>>>>> global Internet, is it safe to glean routing locator = reachability >>>>>>>> information from incoming ICMP packets as described in RFC = 6830, >>>>>>>> Section 6.3, bullet 2 and bullet 4. If not, I think that we = need to >>>>>>>> mention this in the threats document. >>>>>>>>=20 >>>>>>>> What you can glean is that the source RLOC is up, but you = cannot >>>>>>>> glean your path to it is reachable. >>>>>>>>=20 >>>>>>>> Dino >>>>>>>>=20 >>>>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> lisp mailing list >>>>> lisp@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/lisp >>>>=20 >>>> _______________________________________________ >>>> lisp mailing list >>>> lisp@ietf.org >>>> https://www.ietf.org/mailman/listinfo/lisp >>>>=20 >>>> _______________________________________________ >>>> lisp mailing list >>>> lisp@ietf.org >>>> https://www.ietf.org/mailman/listinfo/lisp >>>=20 >>> _______________________________________________ >>> lisp mailing list >>> lisp@ietf.org >>> https://www.ietf.org/mailman/listinfo/lisp >>>=20 >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From nobody Mon Jun 16 08:48:53 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F0BE1A0063 for ; Mon, 16 Jun 2014 08:48:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.601 X-Spam-Level: X-Spam-Status: No, score=-102.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 rZjZjNAq7p1l for ; Mon, 16 Jun 2014 08:48:46 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0209.outbound.protection.outlook.com [207.46.163.209]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA1861A003B for ; Mon, 16 Jun 2014 08:48:45 -0700 (PDT) Received: from CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) by CO1PR05MB441.namprd05.prod.outlook.com (10.141.73.147) with Microsoft SMTP Server (TLS) id 15.0.949.11; Mon, 16 Jun 2014 15:48:43 +0000 Received: from CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.68]) by CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.92]) with mapi id 15.00.0949.001; Mon, 16 Jun 2014 15:48:43 +0000 From: Ronald Bonica To: Luigi Iannone , Dino Farinacci Thread-Topic: [lisp] Restarting last call on LISP threats Thread-Index: AQHPhM36v1z5qcx3GU+Mb5TT+ra0YZtqkpgAgAAFDICAACBwoIACrCcAgAAyz4CAAAQqgIAADkgAgAACGoCABjg4AIAABbBw Date: Mon, 16 Jun 2014 15:48:43 +0000 Message-ID: <8f3ee88f9b9649359d5222d324568e07@CO1PR05MB442.namprd05.prod.outlook.com> References: <40ecc5d773874ecdbdc05763004acfa7@CO1PR05MB442.namprd05.prod.outlook.com> <5399D22A.2040207@joelhalpern.com> <5CAAEAE6-AF3E-4E27-8D73-FA8A64520379@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.10] x-microsoft-antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: x-forefront-prvs: 0244637DEA x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(428001)(51444003)(479174003)(43544003)(189002)(24454002)(13464003)(377454003)(51704005)(199002)(76176999)(76482001)(92566001)(54356999)(66066001)(86362001)(105586001)(85852003)(99396002)(21056001)(77096002)(50986999)(80022001)(101416001)(33646001)(83072002)(93886003)(74662001)(83322001)(31966008)(19580405001)(81342001)(76576001)(4396001)(99286001)(20776003)(74502001)(87936001)(15975445006)(77982001)(46102001)(79102001)(64706001)(19580395003)(2656002)(74316001)(81542001)(85306003)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB441; H:CO1PR05MB442.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: juniper.net does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=rbonica@juniper.net; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/iH5VePYJ_96u6ZWY-c_H4bCWzuY Cc: LISP mailing list list Subject: Re: [lisp] Restarting last call on LISP threats X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 15:48:48 -0000 Ciao Luigi, If only it were that easy! In the threats document, we have two choices: - enumerate every attack that we can imagine - document abstractions that describe broad classes of threats If we enumerate every attack, we will never finish. Therefore, we are force= d to document attack classes. IMHO, two attacks can be grouped together int= o a class if both of the following conditions are true: - the attacks exploit the same features of the protocol - the attacks can be addressed using the same mitigation If we don't understand mitigations, how will we ever group attacks into cla= sses? = Ron > -----Original Message----- > From: lisp [mailto:lisp-bounces@ietf.org] On Behalf Of Luigi Iannone > Sent: Monday, June 16, 2014 11:22 AM > To: Dino Farinacci > Cc: LISP mailing list list > Subject: Re: [lisp] Restarting last call on LISP threats >=20 > Hi Dino, >=20 > fair point. I guess that Joel's point was on the fact that this specific = thread > should focus on the LISP threats document. >=20 > Obviously this mailing list is the place where all technical discussions = about > LISP can take place. >=20 > We should just fork the discussion. >=20 > So to clearly separate what is related to the threats document and what a= re > new proposals to alleviate some threats. >=20 > ciao >=20 > Luigi >=20 >=20 >=20 > On 12 Jun 2014, at 18:23, Dino Farinacci wrote: >=20 > > I agree we should be focused Joel. > > > > But where else should we have open discussions about LISP? > > > > This mailing list membership is unique in that we have multiple vendors= , > operators, and users all in one place. Wouldn't that make for better > protocols? > > > > Yes we have business to take care of but let's not stifle ideas and > openness. Do you agree? > > > > Dino > > > > On Jun 12, 2014, at 9:15 AM, Joel M. Halpern > wrote: > > > >> I will repeat myself. > >> Can we PLEASE not get into debating how we would solve the weakness > in the protocol as documented. > >> > >> The question focus on is whether the protocol as specified has the > behavior described, and if so does it result in the weakness described. > >> If it does, that should be described in the threats document. > >> if not, then it should not be so described. > >> > >> The presence, absence, validity, or possibility of solutions in other > documents, operational practices, or people's heads, are not the topic fo= r > the WG at this time. > >> > >> PLEASE stay on topic, or we will never get our current work done. > >> Which means that peoples wonderful ideas on how to do more or better > will never get publsihed. > >> > >> Yours, > >> Joel > >> > >> On 6/12/14, 11:24 AM, Dino Farinacci wrote: > >>> > >>>>> Could you describe precisely the attack you have in mind? The > >>>>> only think I can see is relying on the birthday paradox but that > >>>>> is a completely different story. > >>>> > >>>> If an attacker is on-path it could see the nonce's (assuming that th= e LISP > header is not encrypted, regardless of whether the data packet is > encrypted). This could be an issue if the attacker is physically on-path. > >>> > >>> The source EID is encrypted so it can only see a cleartext source RLO= C > and can't associated it with anything. > >>> > >>> When we merge lisp-cryto logic with echo-noncing, one has to > determine if an xTR should participate in echo-noncing if the payload is = not > decrypted properly. That is, if I get a echoed nonce back from an attacke= r for > a nonce I know I have sent and set the E-bit, and I cannot decrypt the > payload that comes from the attacker, then I don't believe any NEW > reachability information about the RLOC. > >>> > >>>> This could also be an issue for attackers which are physically off-p= ath if > gleaning is used, since an attacker could use a gleaning attack to tempor= arily > insert itself on-path, which in turn would allow it to see the nonce. > >>> > >>> So by now we know there are many issues with gleaning. So we should > document them and say they shouldn't be used for the general global > Internet use-case. > >>> > >>> Dino > >>> > >>>> > >>>> Ross > >>>> > >>>> -----Original Message----- > >>>> From: lisp [mailto:lisp-bounces@ietf.org] On Behalf Of Damien > >>>> Saucez > >>>> Sent: Thursday, June 12, 2014 8:08 AM > >>>> To: Ronald Bonica > >>>> Cc: LISP mailing list list > >>>> Subject: Re: [lisp] Restarting last call on LISP threats > >>>> > >>>> Hello, > >>>> > >>>> I am not sure I understand exactly what you are proposing. How can > >>>> a LISP router decide that a RLOC is done by simply receiving an > >>>> ICMP packet from an attacker (except with LSB that is discussed in > >>>> Sec 4.3.2.1. )? All the other techniques are triggered by the > >>>> LISP router and are protected by the nonce. > >>>> > >>>> Could you describe precisely the attack you have in mind? The only > >>>> think I can see is relying on the birthday paradox but that is a > >>>> completely different story. > >>>> > >>>> Damien Saucez > >>>> > >>>> On 10 Jun 2014, at 21:37, Ronald Bonica wrote: > >>>> > >>>>> Dino, > >>>>> > >>>>> Exactly! So, assume the following: > >>>>> > >>>>> - LISP is deployed on the global Internet > >>>>> - An RLOC is mapped to some number of EID prefixes > >>>>> - For a subset of those EID prefixes, the above mentioned RLOC is > >>>>> preferred > >>>>> - An ITR receives a hint indicating that the RLOC is down (either > >>>>> through a LISP data packet or an ICMP message) > >>>>> > >>>>> The ITR will verify RLOC reachability (possibly by polling the RLOC= ). But > until the ITR has receives a response to its poll, how should it behave? = Should > it continue sending traffic though the above mentioned RLOC? Or should it > begin to send traffic through another RLOC, if one exists? I don't see a > normative recommendation. > >>>>> > >>>>> However, both behaviors have their drawbacks and could be vectors > for attack. > >>>>> > >>>>> > >>>>> Ron > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Dino Farinacci [mailto:farinacci@gmail.com] > >>>>>> Sent: Tuesday, June 10, 2014 1:23 PM > >>>>>> To: Ronald Bonica > >>>>>> Cc: LISP mailing list list > >>>>>> Subject: Re: [lisp] Restarting last call on LISP threats > >>>>>> > >>>>>> As I keep saying Ron, you need to verify anything you intend to > >>>>>> glean. The spec says the gleaning is "a hint" and not gospel. > >>>>>> > >>>>>> Dino > >>>>>> > >>>>>> On Jun 10, 2014, at 10:06 AM, Ronald Bonica > wrote: > >>>>>> > >>>>>>> Hi Dino, > >>>>>>> > >>>>>>> Given that the LISP data packet or ICMP packet may be from an > >>>>>>> attacker, is > >>>>>> it even safe to glean that? I think not. > >>>>>>> > >>>>>>> > >>>>>>> Ron > >>>>>>> > >>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: Dino Farinacci [mailto:farinacci@gmail.com] > >>>>>>>> Sent: Tuesday, June 10, 2014 1:04 PM > >>>>>>>> To: Ronald Bonica > >>>>>>>> Cc: LISP mailing list list > >>>>>>>> Subject: Re: [lisp] Restarting last call on LISP threats > >>>>>>>> > >>>>>>>> > >>>>>>>> On Jun 10, 2014, at 9:57 AM, Ronald Bonica > wrote: > >>>>>>>> > >>>>>>>>> Earlier in this thread, we agreed that when LISP is deployed > >>>>>>>>> on the global > >>>>>>>> Internet, mapping information cannot be gleaned safely from > >>>>>>>> incoming LISP data packets. Following that train of thought, > >>>>>>>> when LISP is deployed on the global Internet, is it safe to > >>>>>>>> glean routing locator reachability information from incoming > >>>>>>>> LISP data packets as described in RFC 6830, Section 6.3, bullet > >>>>>>>> 1. If not, I think that we need to mention > >>>>>> this in the threats document. > >>>>>>>> > >>>>>>>> What you can glean is that the source RLOC is up, but you > >>>>>>>> cannot glean your path to it is reachable. > >>>>>>>> > >>>>>>>>> Given that ICMP packets are easily spoofed, when LISP is > >>>>>>>>> deployed on the > >>>>>>>> global Internet, is it safe to glean routing locator > >>>>>>>> reachability information from incoming ICMP packets as > >>>>>>>> described in RFC 6830, Section 6.3, bullet 2 and bullet 4. If > >>>>>>>> not, I think that we need to mention this in the threats documen= t. > >>>>>>>> > >>>>>>>> What you can glean is that the source RLOC is up, but you > >>>>>>>> cannot glean your path to it is reachable. > >>>>>>>> > >>>>>>>> Dino > >>>>>>>> > >>>>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> lisp mailing list > >>>>> lisp@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/lisp > >>>> > >>>> _______________________________________________ > >>>> lisp mailing list > >>>> lisp@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/lisp > >>>> > >>>> _______________________________________________ > >>>> lisp mailing list > >>>> lisp@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/lisp > >>> > >>> _______________________________________________ > >>> lisp mailing list > >>> lisp@ietf.org > >>> https://www.ietf.org/mailman/listinfo/lisp > >>> > > > > _______________________________________________ > > lisp mailing list > > lisp@ietf.org > > https://www.ietf.org/mailman/listinfo/lisp >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From nobody Mon Jun 16 09:04:27 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4553B1A004A for ; Mon, 16 Jun 2014 09:04:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 CPp7dyhB8SpN for ; Mon, 16 Jun 2014 09:04:23 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF8161A0027 for ; Mon, 16 Jun 2014 09:04:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id ED36124042D; Mon, 16 Jun 2014 09:04:20 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from host-78-64-19-211.homerun.telia.com (host-78-64-19-211.homerun.telia.com [78.64.19.211]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id C4418240264; Mon, 16 Jun 2014 09:04:19 -0700 (PDT) Message-ID: <539F1582.3010406@joelhalpern.com> Date: Mon, 16 Jun 2014 12:04:18 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Ronald Bonica , Luigi Iannone , Dino Farinacci References: <40ecc5d773874ecdbdc05763004acfa7@CO1PR05MB442.namprd05.prod.outlook.com> <5399D22A.2040207@joelhalpern.com> <5CAAEAE6-AF3E-4E27-8D73-FA8A64520379@gmail.com> <8f3ee88f9b9649359d5222d324568e07@CO1PR05MB442.namprd05.prod.outlook.com> In-Reply-To: <8f3ee88f9b9649359d5222d324568e07@CO1PR05MB442.namprd05.prod.outlook.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/d2nK7nmVpRul9RVk8K753JJOg48 Cc: LISP mailing list list Subject: Re: [lisp] Restarting last call on LISP threats X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 16:04:26 -0000 Personally, I don't see any need to analyse mitigations to discuss classes of attacks. Yours, Joel On 6/16/14, 11:48 AM, Ronald Bonica wrote: > Ciao Luigi, > > If only it were that easy! In the threats document, we have two choices: > > - enumerate every attack that we can imagine > - document abstractions that describe broad classes of threats > > If we enumerate every attack, we will never finish. Therefore, we are forced to document attack classes. IMHO, two attacks can be grouped together into a class if both of the following conditions are true: > > - the attacks exploit the same features of the protocol > - the attacks can be addressed using the same mitigation > > If we don't understand mitigations, how will we ever group attacks into classes? > > Ron > >> -----Original Message----- >> From: lisp [mailto:lisp-bounces@ietf.org] On Behalf Of Luigi Iannone >> Sent: Monday, June 16, 2014 11:22 AM >> To: Dino Farinacci >> Cc: LISP mailing list list >> Subject: Re: [lisp] Restarting last call on LISP threats >> >> Hi Dino, >> >> fair point. I guess that Joel's point was on the fact that this specific thread >> should focus on the LISP threats document. >> >> Obviously this mailing list is the place where all technical discussions about >> LISP can take place. >> >> We should just fork the discussion. >> >> So to clearly separate what is related to the threats document and what are >> new proposals to alleviate some threats. >> >> ciao >> >> Luigi >> >> >> >> On 12 Jun 2014, at 18:23, Dino Farinacci wrote: >> >>> I agree we should be focused Joel. >>> >>> But where else should we have open discussions about LISP? >>> >>> This mailing list membership is unique in that we have multiple vendors, >> operators, and users all in one place. Wouldn't that make for better >> protocols? >>> >>> Yes we have business to take care of but let's not stifle ideas and >> openness. Do you agree? >>> >>> Dino >>> >>> On Jun 12, 2014, at 9:15 AM, Joel M. Halpern >> wrote: >>> >>>> I will repeat myself. >>>> Can we PLEASE not get into debating how we would solve the weakness >> in the protocol as documented. >>>> >>>> The question focus on is whether the protocol as specified has the >> behavior described, and if so does it result in the weakness described. >>>> If it does, that should be described in the threats document. >>>> if not, then it should not be so described. >>>> >>>> The presence, absence, validity, or possibility of solutions in other >> documents, operational practices, or people's heads, are not the topic for >> the WG at this time. >>>> >>>> PLEASE stay on topic, or we will never get our current work done. >>>> Which means that peoples wonderful ideas on how to do more or better >> will never get publsihed. >>>> >>>> Yours, >>>> Joel >>>> >>>> On 6/12/14, 11:24 AM, Dino Farinacci wrote: >>>>> >>>>>>> Could you describe precisely the attack you have in mind? The >>>>>>> only think I can see is relying on the birthday paradox but that >>>>>>> is a completely different story. >>>>>> >>>>>> If an attacker is on-path it could see the nonce's (assuming that the LISP >> header is not encrypted, regardless of whether the data packet is >> encrypted). This could be an issue if the attacker is physically on-path. >>>>> >>>>> The source EID is encrypted so it can only see a cleartext source RLOC >> and can't associated it with anything. >>>>> >>>>> When we merge lisp-cryto logic with echo-noncing, one has to >> determine if an xTR should participate in echo-noncing if the payload is not >> decrypted properly. That is, if I get a echoed nonce back from an attacker for >> a nonce I know I have sent and set the E-bit, and I cannot decrypt the >> payload that comes from the attacker, then I don't believe any NEW >> reachability information about the RLOC. >>>>> >>>>>> This could also be an issue for attackers which are physically off-path if >> gleaning is used, since an attacker could use a gleaning attack to temporarily >> insert itself on-path, which in turn would allow it to see the nonce. >>>>> >>>>> So by now we know there are many issues with gleaning. So we should >> document them and say they shouldn't be used for the general global >> Internet use-case. >>>>> >>>>> Dino >>>>> >>>>>> >>>>>> Ross >>>>>> >>>>>> -----Original Message----- >>>>>> From: lisp [mailto:lisp-bounces@ietf.org] On Behalf Of Damien >>>>>> Saucez >>>>>> Sent: Thursday, June 12, 2014 8:08 AM >>>>>> To: Ronald Bonica >>>>>> Cc: LISP mailing list list >>>>>> Subject: Re: [lisp] Restarting last call on LISP threats >>>>>> >>>>>> Hello, >>>>>> >>>>>> I am not sure I understand exactly what you are proposing. How can >>>>>> a LISP router decide that a RLOC is done by simply receiving an >>>>>> ICMP packet from an attacker (except with LSB that is discussed in >>>>>> Sec 4.3.2.1. )? All the other techniques are triggered by the >>>>>> LISP router and are protected by the nonce. >>>>>> >>>>>> Could you describe precisely the attack you have in mind? The only >>>>>> think I can see is relying on the birthday paradox but that is a >>>>>> completely different story. >>>>>> >>>>>> Damien Saucez >>>>>> >>>>>> On 10 Jun 2014, at 21:37, Ronald Bonica wrote: >>>>>> >>>>>>> Dino, >>>>>>> >>>>>>> Exactly! So, assume the following: >>>>>>> >>>>>>> - LISP is deployed on the global Internet >>>>>>> - An RLOC is mapped to some number of EID prefixes >>>>>>> - For a subset of those EID prefixes, the above mentioned RLOC is >>>>>>> preferred >>>>>>> - An ITR receives a hint indicating that the RLOC is down (either >>>>>>> through a LISP data packet or an ICMP message) >>>>>>> >>>>>>> The ITR will verify RLOC reachability (possibly by polling the RLOC). But >> until the ITR has receives a response to its poll, how should it behave? Should >> it continue sending traffic though the above mentioned RLOC? Or should it >> begin to send traffic through another RLOC, if one exists? I don't see a >> normative recommendation. >>>>>>> >>>>>>> However, both behaviors have their drawbacks and could be vectors >> for attack. >>>>>>> >>>>>>> >>>>>>> Ron >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Dino Farinacci [mailto:farinacci@gmail.com] >>>>>>>> Sent: Tuesday, June 10, 2014 1:23 PM >>>>>>>> To: Ronald Bonica >>>>>>>> Cc: LISP mailing list list >>>>>>>> Subject: Re: [lisp] Restarting last call on LISP threats >>>>>>>> >>>>>>>> As I keep saying Ron, you need to verify anything you intend to >>>>>>>> glean. The spec says the gleaning is "a hint" and not gospel. >>>>>>>> >>>>>>>> Dino >>>>>>>> >>>>>>>> On Jun 10, 2014, at 10:06 AM, Ronald Bonica >> wrote: >>>>>>>> >>>>>>>>> Hi Dino, >>>>>>>>> >>>>>>>>> Given that the LISP data packet or ICMP packet may be from an >>>>>>>>> attacker, is >>>>>>>> it even safe to glean that? I think not. >>>>>>>>> >>>>>>>>> >>>>>>>>> Ron >>>>>>>>> >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Dino Farinacci [mailto:farinacci@gmail.com] >>>>>>>>>> Sent: Tuesday, June 10, 2014 1:04 PM >>>>>>>>>> To: Ronald Bonica >>>>>>>>>> Cc: LISP mailing list list >>>>>>>>>> Subject: Re: [lisp] Restarting last call on LISP threats >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Jun 10, 2014, at 9:57 AM, Ronald Bonica >> wrote: >>>>>>>>>> >>>>>>>>>>> Earlier in this thread, we agreed that when LISP is deployed >>>>>>>>>>> on the global >>>>>>>>>> Internet, mapping information cannot be gleaned safely from >>>>>>>>>> incoming LISP data packets. Following that train of thought, >>>>>>>>>> when LISP is deployed on the global Internet, is it safe to >>>>>>>>>> glean routing locator reachability information from incoming >>>>>>>>>> LISP data packets as described in RFC 6830, Section 6.3, bullet >>>>>>>>>> 1. If not, I think that we need to mention >>>>>>>> this in the threats document. >>>>>>>>>> >>>>>>>>>> What you can glean is that the source RLOC is up, but you >>>>>>>>>> cannot glean your path to it is reachable. >>>>>>>>>> >>>>>>>>>>> Given that ICMP packets are easily spoofed, when LISP is >>>>>>>>>>> deployed on the >>>>>>>>>> global Internet, is it safe to glean routing locator >>>>>>>>>> reachability information from incoming ICMP packets as >>>>>>>>>> described in RFC 6830, Section 6.3, bullet 2 and bullet 4. If >>>>>>>>>> not, I think that we need to mention this in the threats document. >>>>>>>>>> >>>>>>>>>> What you can glean is that the source RLOC is up, but you >>>>>>>>>> cannot glean your path to it is reachable. >>>>>>>>>> >>>>>>>>>> Dino >>>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> lisp mailing list >>>>>>> lisp@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/lisp >>>>>> >>>>>> _______________________________________________ >>>>>> lisp mailing list >>>>>> lisp@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/lisp >>>>>> >>>>>> _______________________________________________ >>>>>> lisp mailing list >>>>>> lisp@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/lisp >>>>> >>>>> _______________________________________________ >>>>> lisp mailing list >>>>> lisp@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/lisp >>>>> >>> >>> _______________________________________________ >>> lisp mailing list >>> lisp@ietf.org >>> https://www.ietf.org/mailman/listinfo/lisp >> >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > From nobody Mon Jun 16 09:39:58 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C56F1A010C for ; Mon, 16 Jun 2014 09:39:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.602 X-Spam-Level: X-Spam-Status: No, score=-102.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 1iLZwWDH0iLS for ; Mon, 16 Jun 2014 09:39:52 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0235.outbound.protection.outlook.com [207.46.163.235]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EF3C1A0109 for ; Mon, 16 Jun 2014 09:39:51 -0700 (PDT) Received: from CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) by CO1PR05MB441.namprd05.prod.outlook.com (10.141.73.147) with Microsoft SMTP Server (TLS) id 15.0.949.11; Mon, 16 Jun 2014 16:39:49 +0000 Received: from CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.68]) by CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.92]) with mapi id 15.00.0949.001; Mon, 16 Jun 2014 16:39:49 +0000 From: Ronald Bonica To: "Joel M. Halpern" , Luigi Iannone , Dino Farinacci Thread-Topic: [lisp] Restarting last call on LISP threats Thread-Index: AQHPhM36v1z5qcx3GU+Mb5TT+ra0YZtqkpgAgAAFDICAACBwoIACrCcAgAAyz4CAAAQqgIAADkgAgAACGoCABjg4AIAABbBwgAAGJwCAAARkIA== Date: Mon, 16 Jun 2014 16:39:48 +0000 Message-ID: References: <40ecc5d773874ecdbdc05763004acfa7@CO1PR05MB442.namprd05.prod.outlook.com> <5399D22A.2040207@joelhalpern.com> <5CAAEAE6-AF3E-4E27-8D73-FA8A64520379@gmail.com> <8f3ee88f9b9649359d5222d324568e07@CO1PR05MB442.namprd05.prod.outlook.com> <539F1582.3010406@joelhalpern.com> In-Reply-To: <539F1582.3010406@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.10] x-microsoft-antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: x-forefront-prvs: 0244637DEA x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(428001)(51444003)(479174003)(43544003)(189002)(24454002)(13464003)(377454003)(51704005)(199002)(76176999)(54356999)(92566001)(76482001)(66066001)(86362001)(105586001)(99396002)(85852003)(21056001)(77096002)(50986999)(80022001)(101416001)(33646001)(83072002)(93886003)(74662001)(83322001)(31966008)(19580405001)(81342001)(76576001)(4396001)(99286001)(20776003)(77982001)(87936001)(74502001)(15975445006)(46102001)(79102001)(64706001)(19580395003)(2656002)(74316001)(81542001)(85306003)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB441; H:CO1PR05MB442.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: juniper.net does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=rbonica@juniper.net; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/lmXsCHbUHGUHiYLj6OmKm0miwDM Cc: LISP mailing list list Subject: Re: [lisp] Restarting last call on LISP threats X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 16:39:55 -0000 Joel, IMHO, there is a very distinct need.=20 As we have seen previously in this email thread, some mitigations introduce= new threats. For example, the ITR's self-imposed rate limit on map request= s mitigates one threat and introduces another. If we don't discuss mitigations at all, we sweep a very important fact unde= r the carpet. = = Ron > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Sent: Monday, June 16, 2014 12:04 PM > To: Ronald Bonica; Luigi Iannone; Dino Farinacci > Cc: LISP mailing list list > Subject: Re: [lisp] Restarting last call on LISP threats >=20 > Personally, I don't see any need to analyse mitigations to discuss classe= s of > attacks. >=20 > Yours, > Joel >=20 > On 6/16/14, 11:48 AM, Ronald Bonica wrote: > > Ciao Luigi, > > > > If only it were that easy! In the threats document, we have two choices= : > > > > - enumerate every attack that we can imagine > > - document abstractions that describe broad classes of threats > > > > If we enumerate every attack, we will never finish. Therefore, we are > forced to document attack classes. IMHO, two attacks can be grouped > together into a class if both of the following conditions are true: > > > > - the attacks exploit the same features of the protocol > > - the attacks can be addressed using the same mitigation > > > > If we don't understand mitigations, how will we ever group attacks into > classes? > > > > > > Ron > > > >> -----Original Message----- > >> From: lisp [mailto:lisp-bounces@ietf.org] On Behalf Of Luigi Iannone > >> Sent: Monday, June 16, 2014 11:22 AM > >> To: Dino Farinacci > >> Cc: LISP mailing list list > >> Subject: Re: [lisp] Restarting last call on LISP threats > >> > >> Hi Dino, > >> > >> fair point. I guess that Joel's point was on the fact that this > >> specific thread should focus on the LISP threats document. > >> > >> Obviously this mailing list is the place where all technical > >> discussions about LISP can take place. > >> > >> We should just fork the discussion. > >> > >> So to clearly separate what is related to the threats document and > >> what are new proposals to alleviate some threats. > >> > >> ciao > >> > >> Luigi > >> > >> > >> > >> On 12 Jun 2014, at 18:23, Dino Farinacci wrote: > >> > >>> I agree we should be focused Joel. > >>> > >>> But where else should we have open discussions about LISP? > >>> > >>> This mailing list membership is unique in that we have multiple > >>> vendors, > >> operators, and users all in one place. Wouldn't that make for better > >> protocols? > >>> > >>> Yes we have business to take care of but let's not stifle ideas and > >> openness. Do you agree? > >>> > >>> Dino > >>> > >>> On Jun 12, 2014, at 9:15 AM, Joel M. Halpern > >> wrote: > >>> > >>>> I will repeat myself. > >>>> Can we PLEASE not get into debating how we would solve the > weakness > >> in the protocol as documented. > >>>> > >>>> The question focus on is whether the protocol as specified has the > >> behavior described, and if so does it result in the weakness described= . > >>>> If it does, that should be described in the threats document. > >>>> if not, then it should not be so described. > >>>> > >>>> The presence, absence, validity, or possibility of solutions in > >>>> other > >> documents, operational practices, or people's heads, are not the > >> topic for the WG at this time. > >>>> > >>>> PLEASE stay on topic, or we will never get our current work done. > >>>> Which means that peoples wonderful ideas on how to do more or > >>>> better > >> will never get publsihed. > >>>> > >>>> Yours, > >>>> Joel > >>>> > >>>> On 6/12/14, 11:24 AM, Dino Farinacci wrote: > >>>>> > >>>>>>> Could you describe precisely the attack you have in mind? The > >>>>>>> only think I can see is relying on the birthday paradox but that > >>>>>>> is a completely different story. > >>>>>> > >>>>>> If an attacker is on-path it could see the nonce's (assuming that > >>>>>> the LISP > >> header is not encrypted, regardless of whether the data packet is > >> encrypted). This could be an issue if the attacker is physically on-pa= th. > >>>>> > >>>>> The source EID is encrypted so it can only see a cleartext source > >>>>> RLOC > >> and can't associated it with anything. > >>>>> > >>>>> When we merge lisp-cryto logic with echo-noncing, one has to > >> determine if an xTR should participate in echo-noncing if the payload > >> is not decrypted properly. That is, if I get a echoed nonce back from > >> an attacker for a nonce I know I have sent and set the E-bit, and I > >> cannot decrypt the payload that comes from the attacker, then I don't > >> believe any NEW reachability information about the RLOC. > >>>>> > >>>>>> This could also be an issue for attackers which are physically > >>>>>> off-path if > >> gleaning is used, since an attacker could use a gleaning attack to > >> temporarily insert itself on-path, which in turn would allow it to see= the > nonce. > >>>>> > >>>>> So by now we know there are many issues with gleaning. So we > >>>>> should > >> document them and say they shouldn't be used for the general global > >> Internet use-case. > >>>>> > >>>>> Dino > >>>>> > >>>>>> > >>>>>> Ross > >>>>>> > >>>>>> -----Original Message----- > >>>>>> From: lisp [mailto:lisp-bounces@ietf.org] On Behalf Of Damien > >>>>>> Saucez > >>>>>> Sent: Thursday, June 12, 2014 8:08 AM > >>>>>> To: Ronald Bonica > >>>>>> Cc: LISP mailing list list > >>>>>> Subject: Re: [lisp] Restarting last call on LISP threats > >>>>>> > >>>>>> Hello, > >>>>>> > >>>>>> I am not sure I understand exactly what you are proposing. How > >>>>>> can a LISP router decide that a RLOC is done by simply receiving > >>>>>> an ICMP packet from an attacker (except with LSB that is > >>>>>> discussed in Sec 4.3.2.1. )? All the other techniques are > >>>>>> triggered by the LISP router and are protected by the nonce. > >>>>>> > >>>>>> Could you describe precisely the attack you have in mind? The > >>>>>> only think I can see is relying on the birthday paradox but that > >>>>>> is a completely different story. > >>>>>> > >>>>>> Damien Saucez > >>>>>> > >>>>>> On 10 Jun 2014, at 21:37, Ronald Bonica > wrote: > >>>>>> > >>>>>>> Dino, > >>>>>>> > >>>>>>> Exactly! So, assume the following: > >>>>>>> > >>>>>>> - LISP is deployed on the global Internet > >>>>>>> - An RLOC is mapped to some number of EID prefixes > >>>>>>> - For a subset of those EID prefixes, the above mentioned RLOC > >>>>>>> is preferred > >>>>>>> - An ITR receives a hint indicating that the RLOC is down > >>>>>>> (either through a LISP data packet or an ICMP message) > >>>>>>> > >>>>>>> The ITR will verify RLOC reachability (possibly by polling the > >>>>>>> RLOC). But > >> until the ITR has receives a response to its poll, how should it > >> behave? Should it continue sending traffic though the above mentioned > >> RLOC? Or should it begin to send traffic through another RLOC, if one > >> exists? I don't see a normative recommendation. > >>>>>>> > >>>>>>> However, both behaviors have their drawbacks and could be > >>>>>>> vectors > >> for attack. > >>>>>>> > >>>>>>> > >>>>>>> Ron > >>>>>>> > >>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: Dino Farinacci [mailto:farinacci@gmail.com] > >>>>>>>> Sent: Tuesday, June 10, 2014 1:23 PM > >>>>>>>> To: Ronald Bonica > >>>>>>>> Cc: LISP mailing list list > >>>>>>>> Subject: Re: [lisp] Restarting last call on LISP threats > >>>>>>>> > >>>>>>>> As I keep saying Ron, you need to verify anything you intend to > >>>>>>>> glean. The spec says the gleaning is "a hint" and not gospel. > >>>>>>>> > >>>>>>>> Dino > >>>>>>>> > >>>>>>>> On Jun 10, 2014, at 10:06 AM, Ronald Bonica > >>>>>>>> > >> wrote: > >>>>>>>> > >>>>>>>>> Hi Dino, > >>>>>>>>> > >>>>>>>>> Given that the LISP data packet or ICMP packet may be from an > >>>>>>>>> attacker, is > >>>>>>>> it even safe to glean that? I think not. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Ron > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> -----Original Message----- > >>>>>>>>>> From: Dino Farinacci [mailto:farinacci@gmail.com] > >>>>>>>>>> Sent: Tuesday, June 10, 2014 1:04 PM > >>>>>>>>>> To: Ronald Bonica > >>>>>>>>>> Cc: LISP mailing list list > >>>>>>>>>> Subject: Re: [lisp] Restarting last call on LISP threats > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> On Jun 10, 2014, at 9:57 AM, Ronald Bonica > >> wrote: > >>>>>>>>>> > >>>>>>>>>>> Earlier in this thread, we agreed that when LISP is deployed > >>>>>>>>>>> on the global > >>>>>>>>>> Internet, mapping information cannot be gleaned safely from > >>>>>>>>>> incoming LISP data packets. Following that train of thought, > >>>>>>>>>> when LISP is deployed on the global Internet, is it safe to > >>>>>>>>>> glean routing locator reachability information from incoming > >>>>>>>>>> LISP data packets as described in RFC 6830, Section 6.3, > >>>>>>>>>> bullet 1. If not, I think that we need to mention > >>>>>>>> this in the threats document. > >>>>>>>>>> > >>>>>>>>>> What you can glean is that the source RLOC is up, but you > >>>>>>>>>> cannot glean your path to it is reachable. > >>>>>>>>>> > >>>>>>>>>>> Given that ICMP packets are easily spoofed, when LISP is > >>>>>>>>>>> deployed on the > >>>>>>>>>> global Internet, is it safe to glean routing locator > >>>>>>>>>> reachability information from incoming ICMP packets as > >>>>>>>>>> described in RFC 6830, Section 6.3, bullet 2 and bullet 4. If > >>>>>>>>>> not, I think that we need to mention this in the threats > document. > >>>>>>>>>> > >>>>>>>>>> What you can glean is that the source RLOC is up, but you > >>>>>>>>>> cannot glean your path to it is reachable. > >>>>>>>>>> > >>>>>>>>>> Dino > >>>>>>>>>> > >>>>>>>>> > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> lisp mailing list > >>>>>>> lisp@ietf.org > >>>>>>> https://www.ietf.org/mailman/listinfo/lisp > >>>>>> > >>>>>> _______________________________________________ > >>>>>> lisp mailing list > >>>>>> lisp@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/lisp > >>>>>> > >>>>>> _______________________________________________ > >>>>>> lisp mailing list > >>>>>> lisp@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/lisp > >>>>> > >>>>> _______________________________________________ > >>>>> lisp mailing list > >>>>> lisp@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/lisp > >>>>> > >>> > >>> _______________________________________________ > >>> lisp mailing list > >>> lisp@ietf.org > >>> https://www.ietf.org/mailman/listinfo/lisp > >> > >> _______________________________________________ > >> lisp mailing list > >> lisp@ietf.org > >> https://www.ietf.org/mailman/listinfo/lisp > > > > _______________________________________________ > > lisp mailing list > > lisp@ietf.org > > https://www.ietf.org/mailman/listinfo/lisp > > From nobody Mon Jun 16 10:18:54 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ABF31A000B for ; Mon, 16 Jun 2014 10:18:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 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, HELO_EQ_FR=0.35, SPF_PASS=-0.001] autolearn=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 pA6c1t_1Bg9S for ; Mon, 16 Jun 2014 10:18:51 -0700 (PDT) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C038D1A0113 for ; Mon, 16 Jun 2014 10:18:50 -0700 (PDT) Received: by mail-wg0-f42.google.com with SMTP id z12so5854674wgg.25 for ; Mon, 16 Jun 2014 10:18:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=xSpuAc+nVVpPf71eUu1ME+o9mlEdMpwiiHfxRjG781I=; b=ZtiRwWy/8zjYH+EuruhucXklxnWxMClrYr1AisuwmfnB62SHD7Crry87zLhbqvhUDl xQWDjP92HHuxKQfli/I7gelz8MVN4SwCe5KhYFn9SCA5xwPE9hyZi39XpcXt6xrg0dcL Q76mr6w7xdJHvUo1H2GHiJrGwPqQjAWz/BAdCE0NIKIJnosUX4ijxWJK3VE0YNjdOZA8 q/pf+E3o3E3aqW1QqP1B1G19kS2Qhz8Ab83WQ9zVoryPLg1fo9j22Y2OoRa7PM/DxLZp 1Gn4fRl5QwBmBBVdw4mRPOFrRtt6VyuQRrgN1OTS6KAV+4YagLb8wunzn+xWCTtJoyRL 37CQ== X-Received: by 10.194.91.144 with SMTP id ce16mr30112231wjb.18.1402939128018; Mon, 16 Jun 2014 10:18:48 -0700 (PDT) Received: from faucon.inria.fr (faucon.inria.fr. [138.96.201.73]) by mx.google.com with ESMTPSA id a1sm15815088wiy.15.2014.06.16.10.18.47 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 16 Jun 2014 10:18:47 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Damien Saucez In-Reply-To: Date: Mon, 16 Jun 2014 19:18:46 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1D4F04D1-43F4-4756-9941-F4499F2A1DA8@gmail.com> References: <40ecc5d773874ecdbdc05763004acfa7@CO1PR05MB442.namprd05.prod.outlook.com> <5399D22A.2040207@joelhalpern.com> <5CAAEAE6-AF3E-4E27-8D73-FA8A64520379@gmail.com> <8f3ee88f9b9649359d5222d324568e07@CO1PR05MB442.namprd05.prod.outlook.com> <539F1582.3010406@joelhalpern.com> To: Ronald Bonica X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/EHNipBrqouSXOBsnxN6C74mhKco Cc: LISP mailing list list Subject: Re: [lisp] Restarting last call on LISP threats X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 17:18:53 -0000 Hello Ron, If ever a mitigation introduces a new threat, it does not mean that it is impossible to make threat categories. Actually, if a threat can be put in one category, the threat on the mitigation can correspond to another. That does not weaken the document. So all what we need is to be able to construct a complete threat categorisation. Thank you, Damien Saucez=20 On 16 Jun 2014, at 18:39, Ronald Bonica wrote: > Joel, >=20 > IMHO, there is a very distinct need.=20 >=20 > As we have seen previously in this email thread, some mitigations = introduce new threats. For example, the ITR's self-imposed rate limit on = map requests mitigates one threat and introduces another. >=20 > If we don't discuss mitigations at all, we sweep a very important fact = under the carpet. >=20 > = = Ron >=20 >> -----Original Message----- >> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >> Sent: Monday, June 16, 2014 12:04 PM >> To: Ronald Bonica; Luigi Iannone; Dino Farinacci >> Cc: LISP mailing list list >> Subject: Re: [lisp] Restarting last call on LISP threats >>=20 >> Personally, I don't see any need to analyse mitigations to discuss = classes of >> attacks. >>=20 >> Yours, >> Joel >>=20 >> On 6/16/14, 11:48 AM, Ronald Bonica wrote: >>> Ciao Luigi, >>>=20 >>> If only it were that easy! In the threats document, we have two = choices: >>>=20 >>> - enumerate every attack that we can imagine >>> - document abstractions that describe broad classes of threats >>>=20 >>> If we enumerate every attack, we will never finish. Therefore, we = are >> forced to document attack classes. IMHO, two attacks can be grouped >> together into a class if both of the following conditions are true: >>>=20 >>> - the attacks exploit the same features of the protocol >>> - the attacks can be addressed using the same mitigation >>>=20 >>> If we don't understand mitigations, how will we ever group attacks = into >> classes? >>>=20 >>>=20 >>> Ron >>>=20 >>>> -----Original Message----- >>>> From: lisp [mailto:lisp-bounces@ietf.org] On Behalf Of Luigi = Iannone >>>> Sent: Monday, June 16, 2014 11:22 AM >>>> To: Dino Farinacci >>>> Cc: LISP mailing list list >>>> Subject: Re: [lisp] Restarting last call on LISP threats >>>>=20 >>>> Hi Dino, >>>>=20 >>>> fair point. I guess that Joel's point was on the fact that this >>>> specific thread should focus on the LISP threats document. >>>>=20 >>>> Obviously this mailing list is the place where all technical >>>> discussions about LISP can take place. >>>>=20 >>>> We should just fork the discussion. >>>>=20 >>>> So to clearly separate what is related to the threats document and >>>> what are new proposals to alleviate some threats. >>>>=20 >>>> ciao >>>>=20 >>>> Luigi >>>>=20 >>>>=20 >>>>=20 >>>> On 12 Jun 2014, at 18:23, Dino Farinacci = wrote: >>>>=20 >>>>> I agree we should be focused Joel. >>>>>=20 >>>>> But where else should we have open discussions about LISP? >>>>>=20 >>>>> This mailing list membership is unique in that we have multiple >>>>> vendors, >>>> operators, and users all in one place. Wouldn't that make for = better >>>> protocols? >>>>>=20 >>>>> Yes we have business to take care of but let's not stifle ideas = and >>>> openness. Do you agree? >>>>>=20 >>>>> Dino >>>>>=20 >>>>> On Jun 12, 2014, at 9:15 AM, Joel M. Halpern >>>> wrote: >>>>>=20 >>>>>> I will repeat myself. >>>>>> Can we PLEASE not get into debating how we would solve the >> weakness >>>> in the protocol as documented. >>>>>>=20 >>>>>> The question focus on is whether the protocol as specified has = the >>>> behavior described, and if so does it result in the weakness = described. >>>>>> If it does, that should be described in the threats document. >>>>>> if not, then it should not be so described. >>>>>>=20 >>>>>> The presence, absence, validity, or possibility of solutions in >>>>>> other >>>> documents, operational practices, or people's heads, are not the >>>> topic for the WG at this time. >>>>>>=20 >>>>>> PLEASE stay on topic, or we will never get our current work done. >>>>>> Which means that peoples wonderful ideas on how to do more or >>>>>> better >>>> will never get publsihed. >>>>>>=20 >>>>>> Yours, >>>>>> Joel >>>>>>=20 >>>>>> On 6/12/14, 11:24 AM, Dino Farinacci wrote: >>>>>>>=20 >>>>>>>>> Could you describe precisely the attack you have in mind? The >>>>>>>>> only think I can see is relying on the birthday paradox but = that >>>>>>>>> is a completely different story. >>>>>>>>=20 >>>>>>>> If an attacker is on-path it could see the nonce's (assuming = that >>>>>>>> the LISP >>>> header is not encrypted, regardless of whether the data packet is >>>> encrypted). This could be an issue if the attacker is physically = on-path. >>>>>>>=20 >>>>>>> The source EID is encrypted so it can only see a cleartext = source >>>>>>> RLOC >>>> and can't associated it with anything. >>>>>>>=20 >>>>>>> When we merge lisp-cryto logic with echo-noncing, one has to >>>> determine if an xTR should participate in echo-noncing if the = payload >>>> is not decrypted properly. That is, if I get a echoed nonce back = from >>>> an attacker for a nonce I know I have sent and set the E-bit, and I >>>> cannot decrypt the payload that comes from the attacker, then I = don't >>>> believe any NEW reachability information about the RLOC. >>>>>>>=20 >>>>>>>> This could also be an issue for attackers which are physically >>>>>>>> off-path if >>>> gleaning is used, since an attacker could use a gleaning attack to >>>> temporarily insert itself on-path, which in turn would allow it to = see the >> nonce. >>>>>>>=20 >>>>>>> So by now we know there are many issues with gleaning. So we >>>>>>> should >>>> document them and say they shouldn't be used for the general global >>>> Internet use-case. >>>>>>>=20 >>>>>>> Dino >>>>>>>=20 >>>>>>>>=20 >>>>>>>> Ross >>>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: lisp [mailto:lisp-bounces@ietf.org] On Behalf Of Damien >>>>>>>> Saucez >>>>>>>> Sent: Thursday, June 12, 2014 8:08 AM >>>>>>>> To: Ronald Bonica >>>>>>>> Cc: LISP mailing list list >>>>>>>> Subject: Re: [lisp] Restarting last call on LISP threats >>>>>>>>=20 >>>>>>>> Hello, >>>>>>>>=20 >>>>>>>> I am not sure I understand exactly what you are proposing. How >>>>>>>> can a LISP router decide that a RLOC is done by simply = receiving >>>>>>>> an ICMP packet from an attacker (except with LSB that is >>>>>>>> discussed in Sec 4.3.2.1. )? All the other techniques are >>>>>>>> triggered by the LISP router and are protected by the nonce. >>>>>>>>=20 >>>>>>>> Could you describe precisely the attack you have in mind? The >>>>>>>> only think I can see is relying on the birthday paradox but = that >>>>>>>> is a completely different story. >>>>>>>>=20 >>>>>>>> Damien Saucez >>>>>>>>=20 >>>>>>>> On 10 Jun 2014, at 21:37, Ronald Bonica >> wrote: >>>>>>>>=20 >>>>>>>>> Dino, >>>>>>>>>=20 >>>>>>>>> Exactly! So, assume the following: >>>>>>>>>=20 >>>>>>>>> - LISP is deployed on the global Internet >>>>>>>>> - An RLOC is mapped to some number of EID prefixes >>>>>>>>> - For a subset of those EID prefixes, the above mentioned RLOC >>>>>>>>> is preferred >>>>>>>>> - An ITR receives a hint indicating that the RLOC is down >>>>>>>>> (either through a LISP data packet or an ICMP message) >>>>>>>>>=20 >>>>>>>>> The ITR will verify RLOC reachability (possibly by polling the >>>>>>>>> RLOC). But >>>> until the ITR has receives a response to its poll, how should it >>>> behave? Should it continue sending traffic though the above = mentioned >>>> RLOC? Or should it begin to send traffic through another RLOC, if = one >>>> exists? I don't see a normative recommendation. >>>>>>>>>=20 >>>>>>>>> However, both behaviors have their drawbacks and could be >>>>>>>>> vectors >>>> for attack. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Ron >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Dino Farinacci [mailto:farinacci@gmail.com] >>>>>>>>>> Sent: Tuesday, June 10, 2014 1:23 PM >>>>>>>>>> To: Ronald Bonica >>>>>>>>>> Cc: LISP mailing list list >>>>>>>>>> Subject: Re: [lisp] Restarting last call on LISP threats >>>>>>>>>>=20 >>>>>>>>>> As I keep saying Ron, you need to verify anything you intend = to >>>>>>>>>> glean. The spec says the gleaning is "a hint" and not gospel. >>>>>>>>>>=20 >>>>>>>>>> Dino >>>>>>>>>>=20 >>>>>>>>>> On Jun 10, 2014, at 10:06 AM, Ronald Bonica >>>>>>>>>> >>>> wrote: >>>>>>>>>>=20 >>>>>>>>>>> Hi Dino, >>>>>>>>>>>=20 >>>>>>>>>>> Given that the LISP data packet or ICMP packet may be from = an >>>>>>>>>>> attacker, is >>>>>>>>>> it even safe to glean that? I think not. >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> Ron >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: Dino Farinacci [mailto:farinacci@gmail.com] >>>>>>>>>>>> Sent: Tuesday, June 10, 2014 1:04 PM >>>>>>>>>>>> To: Ronald Bonica >>>>>>>>>>>> Cc: LISP mailing list list >>>>>>>>>>>> Subject: Re: [lisp] Restarting last call on LISP threats >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> On Jun 10, 2014, at 9:57 AM, Ronald Bonica >>>> wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>>> Earlier in this thread, we agreed that when LISP is = deployed >>>>>>>>>>>>> on the global >>>>>>>>>>>> Internet, mapping information cannot be gleaned safely from >>>>>>>>>>>> incoming LISP data packets. Following that train of = thought, >>>>>>>>>>>> when LISP is deployed on the global Internet, is it safe to >>>>>>>>>>>> glean routing locator reachability information from = incoming >>>>>>>>>>>> LISP data packets as described in RFC 6830, Section 6.3, >>>>>>>>>>>> bullet 1. If not, I think that we need to mention >>>>>>>>>> this in the threats document. >>>>>>>>>>>>=20 >>>>>>>>>>>> What you can glean is that the source RLOC is up, but you >>>>>>>>>>>> cannot glean your path to it is reachable. >>>>>>>>>>>>=20 >>>>>>>>>>>>> Given that ICMP packets are easily spoofed, when LISP is >>>>>>>>>>>>> deployed on the >>>>>>>>>>>> global Internet, is it safe to glean routing locator >>>>>>>>>>>> reachability information from incoming ICMP packets as >>>>>>>>>>>> described in RFC 6830, Section 6.3, bullet 2 and bullet 4. = If >>>>>>>>>>>> not, I think that we need to mention this in the threats >> document. >>>>>>>>>>>>=20 >>>>>>>>>>>> What you can glean is that the source RLOC is up, but you >>>>>>>>>>>> cannot glean your path to it is reachable. >>>>>>>>>>>>=20 >>>>>>>>>>>> Dino >>>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> lisp mailing list >>>>>>>>> lisp@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/lisp >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> lisp mailing list >>>>>>>> lisp@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/lisp >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> lisp mailing list >>>>>>>> lisp@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/lisp >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> lisp mailing list >>>>>>> lisp@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/lisp >>>>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> lisp mailing list >>>>> lisp@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/lisp >>>>=20 >>>> _______________________________________________ >>>> lisp mailing list >>>> lisp@ietf.org >>>> https://www.ietf.org/mailman/listinfo/lisp >>>=20 >>> _______________________________________________ >>> lisp mailing list >>> lisp@ietf.org >>> https://www.ietf.org/mailman/listinfo/lisp >>>=20 >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From nobody Mon Jun 16 11:32:57 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B647C1A013B for ; Mon, 16 Jun 2014 11:32:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 7_x2B2o9XEcU for ; Mon, 16 Jun 2014 11:32:54 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EE651A0058 for ; Mon, 16 Jun 2014 11:32:54 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 3D3D3880F0 for ; Mon, 16 Jun 2014 11:32:54 -0700 (PDT) Received: from clemson.local (addr16212925014.ippl.jhmi.edu [162.129.250.14]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id F361B71C0002 for ; Mon, 16 Jun 2014 11:32:53 -0700 (PDT) Message-ID: <539F3856.4060401@innovationslab.net> Date: Mon, 16 Jun 2014 14:32:54 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: lisp@ietf.org References: <40ecc5d773874ecdbdc05763004acfa7@CO1PR05MB442.namprd05.prod.outlook.com> <5399D22A.2040207@joelhalpern.com> <5CAAEAE6-AF3E-4E27-8D73-FA8A64520379@gmail.com> <8f3ee88f9b9649359d5222d324568e07@CO1PR05MB442.namprd05.prod.outlook.com> <539F1582.3010406@joelhalpern.com> In-Reply-To: <539F1582.3010406@joelhalpern.com> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Vs4DpmwHhSXwojce86HKSi0KtBj2mgXM8" Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/UGmkE0uWikRQ96XE3LZ-qWxpJek Subject: Re: [lisp] Restarting last call on LISP threats X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 18:32:55 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Vs4DpmwHhSXwojce86HKSi0KtBj2mgXM8 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Let's just say I am commenting as an interest observer... On 6/16/14 12:04 PM, Joel M. Halpern wrote: > Personally, I don't see any need to analyse mitigations to discuss > classes of attacks. Is the above meant to imply that the lisp-threats document should not discuss the costs imposed by the mitigation technique? If not, will lisp-sec document the approaches to mitigating all the attacks listed in lisp-threats (and their perceived costs)? Regards, Brian --Vs4DpmwHhSXwojce86HKSi0KtBj2mgXM8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJTnzhcAAoJEBOZRqCi7goq56wIAJaNa7fMsdx1FfeX7bpQyyRq UTcGjkO4AdzII/ktstyUTM2YXVxoSfCNEokSblAe22exMjAOg4pY+L6VQt28LVu1 TElBnE/C9XQD4a9f28lCJt2J66HxN0Ziv2SN94hvcSpsS0vj1J1pGfm4RXnetpCw QeCPq5LYztHWAZ7J79kiUSpN68DXP0jU1biyfv/6In7RCbImFdP/d0ox7Ic2qfAz x5fiMlmKdsakTRX+FnzbmZw+FPRfInHZqVTJaDnHatWZPw+HuYQdR0l3kuI3jvIc BG0rcl2GdeQGHDnSPZwIdAjUkwyFDXFKrhFlVJR7E+XCjM5aIhH4y9nTnK7kw0g= =cmte -----END PGP SIGNATURE----- --Vs4DpmwHhSXwojce86HKSi0KtBj2mgXM8-- From nobody Mon Jun 16 11:44:00 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 122481A0161 for ; Mon, 16 Jun 2014 11:43:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 FeFzbUPBuc-W for ; Mon, 16 Jun 2014 11:43:57 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA42E1A014E for ; Mon, 16 Jun 2014 11:43:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 836BD24049A; Mon, 16 Jun 2014 11:43:57 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from host-78-64-19-211.homerun.telia.com (host-78-64-19-211.homerun.telia.com [78.64.19.211]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id E45CA240191; Mon, 16 Jun 2014 11:43:56 -0700 (PDT) Message-ID: <539F3AEB.4030201@joelhalpern.com> Date: Mon, 16 Jun 2014 14:43:55 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Brian Haberman , lisp@ietf.org References: <40ecc5d773874ecdbdc05763004acfa7@CO1PR05MB442.namprd05.prod.outlook.com> <5399D22A.2040207@joelhalpern.com> <5CAAEAE6-AF3E-4E27-8D73-FA8A64520379@gmail.com> <8f3ee88f9b9649359d5222d324568e07@CO1PR05MB442.namprd05.prod.outlook.com> <539F1582.3010406@joelhalpern.com> <539F3856.4060401@innovationslab.net> In-Reply-To: <539F3856.4060401@innovationslab.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/LmwoX3mKXsaDRpn7MTdCy0iaafI Subject: Re: [lisp] Restarting last call on LISP threats X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 18:43:59 -0000 My understanding is that security oriented threat analyses documents do not generally, and the charter item for this document does not specifically, call out mitigations. Mitigation is, as your comment suggests, a complex tradeoff as different mitigations have different costs and different efficacy. So the tradeoff in using mitigation would, it seems to me, need to be in the document that proposes the mechanisms. Yours, Joel On 6/16/14, 2:32 PM, Brian Haberman wrote: > Let's just say I am commenting as an interest observer... > > > On 6/16/14 12:04 PM, Joel M. Halpern wrote: >> Personally, I don't see any need to analyse mitigations to discuss >> classes of attacks. > > Is the above meant to imply that the lisp-threats document should not > discuss the costs imposed by the mitigation technique? > > If not, will lisp-sec document the approaches to mitigating all the > attacks listed in lisp-threats (and their perceived costs)? > > Regards, > Brian > > > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > From nobody Mon Jun 16 11:50:13 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D04E11A014F for ; Mon, 16 Jun 2014 11:50:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 Cb7s5rSH-7Nj for ; Mon, 16 Jun 2014 11:50:08 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 669FC1A014C for ; Mon, 16 Jun 2014 11:50:08 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 37CD8880F0 for ; Mon, 16 Jun 2014 11:50:08 -0700 (PDT) Received: from clemson.local (addr16212925014.ippl.jhmi.edu [162.129.250.14]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id ED3A771C0002 for ; Mon, 16 Jun 2014 11:50:07 -0700 (PDT) Message-ID: <539F3C5D.8020907@innovationslab.net> Date: Mon, 16 Jun 2014 14:50:05 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: lisp@ietf.org References: <40ecc5d773874ecdbdc05763004acfa7@CO1PR05MB442.namprd05.prod.outlook.com> <5399D22A.2040207@joelhalpern.com> <5CAAEAE6-AF3E-4E27-8D73-FA8A64520379@gmail.com> <8f3ee88f9b9649359d5222d324568e07@CO1PR05MB442.namprd05.prod.outlook.com> <539F1582.3010406@joelhalpern.com> <539F3856.4060401@innovationslab.net> <539F3AEB.4030201@joelhalpern.com> In-Reply-To: <539F3AEB.4030201@joelhalpern.com> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="V9dKxgSAsgXFHl3ntHvRlGKJr2J1sr5nP" Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/TXZr6uOe24wm0o7rMenHxZlJxsE Subject: Re: [lisp] Restarting last call on LISP threats X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 18:50:13 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --V9dKxgSAsgXFHl3ntHvRlGKJr2J1sr5nP Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Joel, On 6/16/14 2:43 PM, Joel M. Halpern wrote: > My understanding is that security oriented threat analyses documents do= > not generally, and the charter item for this document does not > specifically, call out mitigations. Mitigation is, as your comment > suggests, a complex tradeoff as different mitigations have different > costs and different efficacy. So the tradeoff in using mitigation > would, it seems to me, need to be in the document that proposes the > mechanisms. The charter work item says: - LISP security threats and solutions My question was whether the WG plans to overhaul lisp-sec to describe the mitigations/solutions to the threats described in lisp-threats or just put them in one document. Regards, Brian --V9dKxgSAsgXFHl3ntHvRlGKJr2J1sr5nP Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJTnzxjAAoJEBOZRqCi7goqurMH/RDgcRtfbxOlwL1XHDqW8CGA ydDcLU/GYzTsB/UqEj+KmbGEmp/Z0sCGkJKJqX5FLx1bS5Qow9RDnnGVKrTDqoTe MdRvqOSN7MDtxyzIIbXD7oddVX03A98rpB88cVa+FjV2h1vNfjGFADJvMdqYN0bj kU6YZY0+UMxp/+Ti9PXc3tQcCwNGU0H3nIQ3bdGGwiYc3vun1WwRakJRlChvKYHx DXfPwSjiUrRz3EgkWcjYnrl9FqQ8jXVcmerCBpSU9CTUK5m4hBU62+0DoZCNhmK2 e88HWHePQJe7+Xbi2I09IjOI80jyBBdDIaGFAXafWQn1G7K+nH2dxj0M0hJpD/8= =hiL5 -----END PGP SIGNATURE----- --V9dKxgSAsgXFHl3ntHvRlGKJr2J1sr5nP-- From nobody Tue Jun 17 01:43:15 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A6AF1A0322 for ; Tue, 17 Jun 2014 01:43:14 -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, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 Dn4cIb61oZVF for ; Tue, 17 Jun 2014 01:43:12 -0700 (PDT) Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D3DB1A0313 for ; Tue, 17 Jun 2014 01:43:12 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id cc10so5364528wib.0 for ; Tue, 17 Jun 2014 01:43:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=HIiPlUVxIAwsEZVIJIigOo4T9BEVawMKNMTkqsTuIg4=; b=AupP0+JVlKXsX77cshBcsIVWjizHz5olVdKJvXb2uMNa+n29KTtAiwXSiwW1Xa5s/a Sldgh6JO0fmLM5aV0LZwWQN73scg/F1fACwgpGKrsicjd/nXSq6QGARacUvVohOEdWcp YMx3vyv6yKiLCb1eKnR2suZXz01H2olw15D1wmBETwQ4kiy1sjfRrjYNCUHXI/tL4D1q GprbBQDT4gh0PAgiSIGg2OFTaJ0TKamGPekeyrLJNU0UVTHj18FFB0JXY1E51wpDXuDT UQuN/E3N6RoR2AlG4Ymh0pKXWGpvYq1wsMF6Z51lR1VP1hG9gi3fLj1/3jZYXwYTyLEC tD8Q== X-Gm-Message-State: ALoCoQlKAxCtlTFuGd1ym9KLaVr7GXmJFxxkb315eRf7QD2nGZIcS2q6j/z0um5aNPvRtk8FfKQB X-Received: by 10.180.81.72 with SMTP id y8mr15771370wix.7.1402994590802; Tue, 17 Jun 2014 01:43:10 -0700 (PDT) Received: from ?IPv6:2001:660:330f:a4:5dd0:712c:105e:e755? ([2001:660:330f:a4:5dd0:712c:105e:e755]) by mx.google.com with ESMTPSA id h3sm22277465wjz.48.2014.06.17.01.43.09 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 17 Jun 2014 01:43:09 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Luigi Iannone In-Reply-To: <539F3C5D.8020907@innovationslab.net> Date: Tue, 17 Jun 2014 10:43:09 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1863B228-D011-4CCD-99A5-2C3B491F96B2@gigix.net> References: <40ecc5d773874ecdbdc05763004acfa7@CO1PR05MB442.namprd05.prod.outlook.com> <5399D22A.2040207@joelhalpern.com> <5CAAEAE6-AF3E-4E27-8D73-FA8A64520379@gmail.com> <8f3ee88f9b9649359d5222d324568e07@CO1PR05MB442.namprd05.prod.outlook.com> <539F1582.3010406@joelhalpern.com> <539F3856.4060401@innovationslab.net> <539F3AEB.4030201@joelhalpern.com> <539F3C5D.8020907@innovationslab.net> To: Brian Haberman X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/qkGKJmlT478lGSZ1qTrTGwbFEuI Cc: lisp@ietf.org Subject: Re: [lisp] Restarting last call on LISP threats X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 08:43:14 -0000 Hi, On 16 Jun 2014, at 20:50, Brian Haberman = wrote: > Hi Joel, >=20 > On 6/16/14 2:43 PM, Joel M. Halpern wrote: >> My understanding is that security oriented threat analyses documents = do >> not generally, and the charter item for this document does not >> specifically, call out mitigations. Mitigation is, as your comment >> suggests, a complex tradeoff as different mitigations have different >> costs and different efficacy. So the tradeoff in using mitigation >> would, it seems to me, need to be in the document that proposes the >> mechanisms. >=20 > The charter work item says: >=20 > - LISP security threats and solutions Previous versions of the threats document gave some =93recommendations=94 = (like fo instance the use of lisp-sec), but discuss on the ML and WG = meetings lead to drop that section. So, why going back now? >=20 > My question was whether the WG plans to overhaul lisp-sec to describe > the mitigations/solutions to the threats described in lisp-threats or > just put them in one document. >=20 IMHO LISP-sec is a specific solution for a specific set of threats, = hence, while it has to clearly state which attacks it solves I do not = think that has to discuss all possible mitigations for the all possible = threats.=20 I was also thinking that similarly to the fact that threats are = described by class, mitigation techniques (if we ever want to = re-introduce them) should also be =93cited=94 by class.=20 I use the word =93cited=94 because I do not think we need to document = the details but just refer to existing techniques that can be used. (note that this was more or less what we had in early versions of the = document) ciao Luigi > Regards, > Brian >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From nobody Tue Jun 17 01:43:42 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 790671A0329 for ; Tue, 17 Jun 2014 01:43:40 -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, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 c43mtZC6oMYT for ; Tue, 17 Jun 2014 01:43:37 -0700 (PDT) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52A4A1A0327 for ; Tue, 17 Jun 2014 01:43:37 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id cc10so6486407wib.1 for ; Tue, 17 Jun 2014 01:43:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=jvyZ4t0VD4/fCBrjsp59CgvGz6oR3OD2oJSyWyC2spA=; b=C2SGdf6R5ihJbC2kDLWoUGcIjTJXsqh02S989Xn2G0h+m4RsAxOQ0M0zqsffhDOdSD nzwTnK2n5HxPsCCWyo1adc3l/nWqs+lpwqnjWUcLvSLUlPYcKoHioB8Fs+9+/9fLe1/O uwUzt//YbYBClCiKCDuZv/X4ulXz7Fp4cGOp3XOyPm7/F6QUb/mVaZzYOF+Mpgoy9uHo zLeTFqAUv4UDNfa61u+2sBC3GC5Wt/DSNhQcIY8B3Y/mZ+zm+MXDULEZObWls/thmw6q y2HjQabnGmvd+YKwiqiJtP6UWpYgZn9bfLIK119s1SzMtyteaRW+3u0XmuLRjbvyIA26 wLaw== X-Gm-Message-State: ALoCoQmE/Vvzi5pxwlzhv2CsoG7VRtFQYmNf6DNxp++sAIRQjsOZF0J7RWXOTPfP8zcsojHQWtmE X-Received: by 10.180.90.141 with SMTP id bw13mr34276487wib.23.1402994615699; Tue, 17 Jun 2014 01:43:35 -0700 (PDT) Received: from ?IPv6:2001:660:330f:a4:5dd0:712c:105e:e755? ([2001:660:330f:a4:5dd0:712c:105e:e755]) by mx.google.com with ESMTPSA id h3sm22277465wjz.48.2014.06.17.01.43.34 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 17 Jun 2014 01:43:34 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Luigi Iannone In-Reply-To: Date: Tue, 17 Jun 2014 10:43:26 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0EF2C75D-5C59-433E-B869-8E677666B8C1@gigix.net> References: <40ecc5d773874ecdbdc05763004acfa7@CO1PR05MB442.namprd05.prod.outlook.com> <5399D22A.2040207@joelhalpern.com> <5CAAEAE6-AF3E-4E27-8D73-FA8A64520379@gmail.com> <8f3ee88f9b9649359d5222d324568e07@CO1PR05MB442.namprd05.prod.outlook.com> <539F1582.3010406@joelhalpern.com> To: Ronald Bonica X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/FF2LaJYV0DDMNrDRdoSiAiqo5-k Cc: LISP mailing list list Subject: Re: [lisp] Restarting last call on LISP threats X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 08:43:40 -0000 Hi Ron, I tend to agree with Joel on the fact that to class attacks we do not = need the mitigations.=20 Yet, I agree that if a possible mitigation for a threat can introduce = another threat then this induced threat should be document. ciao Luigi On 16 Jun 2014, at 18:39, Ronald Bonica wrote: > Joel, >=20 > IMHO, there is a very distinct need.=20 >=20 > As we have seen previously in this email thread, some mitigations = introduce new threats. For example, the ITR's self-imposed rate limit on = map requests mitigates one threat and introduces another. >=20 > If we don't discuss mitigations at all, we sweep a very important fact = under the carpet. >=20 > = = Ron >=20 >> -----Original Message----- >> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >> Sent: Monday, June 16, 2014 12:04 PM >> To: Ronald Bonica; Luigi Iannone; Dino Farinacci >> Cc: LISP mailing list list >> Subject: Re: [lisp] Restarting last call on LISP threats >>=20 >> Personally, I don't see any need to analyse mitigations to discuss = classes of >> attacks. >>=20 >> Yours, >> Joel >>=20 >> On 6/16/14, 11:48 AM, Ronald Bonica wrote: >>> Ciao Luigi, >>>=20 >>> If only it were that easy! In the threats document, we have two = choices: >>>=20 >>> - enumerate every attack that we can imagine >>> - document abstractions that describe broad classes of threats >>>=20 >>> If we enumerate every attack, we will never finish. Therefore, we = are >> forced to document attack classes. IMHO, two attacks can be grouped >> together into a class if both of the following conditions are true: >>>=20 >>> - the attacks exploit the same features of the protocol >>> - the attacks can be addressed using the same mitigation >>>=20 >>> If we don't understand mitigations, how will we ever group attacks = into >> classes? >>>=20 >>>=20 >>> Ron >>>=20 >>>> -----Original Message----- >>>> From: lisp [mailto:lisp-bounces@ietf.org] On Behalf Of Luigi = Iannone >>>> Sent: Monday, June 16, 2014 11:22 AM >>>> To: Dino Farinacci >>>> Cc: LISP mailing list list >>>> Subject: Re: [lisp] Restarting last call on LISP threats >>>>=20 >>>> Hi Dino, >>>>=20 >>>> fair point. I guess that Joel's point was on the fact that this >>>> specific thread should focus on the LISP threats document. >>>>=20 >>>> Obviously this mailing list is the place where all technical >>>> discussions about LISP can take place. >>>>=20 >>>> We should just fork the discussion. >>>>=20 >>>> So to clearly separate what is related to the threats document and >>>> what are new proposals to alleviate some threats. >>>>=20 >>>> ciao >>>>=20 >>>> Luigi >>>>=20 >>>>=20 >>>>=20 >>>> On 12 Jun 2014, at 18:23, Dino Farinacci = wrote: >>>>=20 >>>>> I agree we should be focused Joel. >>>>>=20 >>>>> But where else should we have open discussions about LISP? >>>>>=20 >>>>> This mailing list membership is unique in that we have multiple >>>>> vendors, >>>> operators, and users all in one place. Wouldn't that make for = better >>>> protocols? >>>>>=20 >>>>> Yes we have business to take care of but let's not stifle ideas = and >>>> openness. Do you agree? >>>>>=20 >>>>> Dino >>>>>=20 >>>>> On Jun 12, 2014, at 9:15 AM, Joel M. Halpern >>>> wrote: >>>>>=20 >>>>>> I will repeat myself. >>>>>> Can we PLEASE not get into debating how we would solve the >> weakness >>>> in the protocol as documented. >>>>>>=20 >>>>>> The question focus on is whether the protocol as specified has = the >>>> behavior described, and if so does it result in the weakness = described. >>>>>> If it does, that should be described in the threats document. >>>>>> if not, then it should not be so described. >>>>>>=20 >>>>>> The presence, absence, validity, or possibility of solutions in >>>>>> other >>>> documents, operational practices, or people's heads, are not the >>>> topic for the WG at this time. >>>>>>=20 >>>>>> PLEASE stay on topic, or we will never get our current work done. >>>>>> Which means that peoples wonderful ideas on how to do more or >>>>>> better >>>> will never get publsihed. >>>>>>=20 >>>>>> Yours, >>>>>> Joel >>>>>>=20 >>>>>> On 6/12/14, 11:24 AM, Dino Farinacci wrote: >>>>>>>=20 >>>>>>>>> Could you describe precisely the attack you have in mind? The >>>>>>>>> only think I can see is relying on the birthday paradox but = that >>>>>>>>> is a completely different story. >>>>>>>>=20 >>>>>>>> If an attacker is on-path it could see the nonce's (assuming = that >>>>>>>> the LISP >>>> header is not encrypted, regardless of whether the data packet is >>>> encrypted). This could be an issue if the attacker is physically = on-path. >>>>>>>=20 >>>>>>> The source EID is encrypted so it can only see a cleartext = source >>>>>>> RLOC >>>> and can't associated it with anything. >>>>>>>=20 >>>>>>> When we merge lisp-cryto logic with echo-noncing, one has to >>>> determine if an xTR should participate in echo-noncing if the = payload >>>> is not decrypted properly. That is, if I get a echoed nonce back = from >>>> an attacker for a nonce I know I have sent and set the E-bit, and I >>>> cannot decrypt the payload that comes from the attacker, then I = don't >>>> believe any NEW reachability information about the RLOC. >>>>>>>=20 >>>>>>>> This could also be an issue for attackers which are physically >>>>>>>> off-path if >>>> gleaning is used, since an attacker could use a gleaning attack to >>>> temporarily insert itself on-path, which in turn would allow it to = see the >> nonce. >>>>>>>=20 >>>>>>> So by now we know there are many issues with gleaning. So we >>>>>>> should >>>> document them and say they shouldn't be used for the general global >>>> Internet use-case. >>>>>>>=20 >>>>>>> Dino >>>>>>>=20 >>>>>>>>=20 >>>>>>>> Ross >>>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: lisp [mailto:lisp-bounces@ietf.org] On Behalf Of Damien >>>>>>>> Saucez >>>>>>>> Sent: Thursday, June 12, 2014 8:08 AM >>>>>>>> To: Ronald Bonica >>>>>>>> Cc: LISP mailing list list >>>>>>>> Subject: Re: [lisp] Restarting last call on LISP threats >>>>>>>>=20 >>>>>>>> Hello, >>>>>>>>=20 >>>>>>>> I am not sure I understand exactly what you are proposing. How >>>>>>>> can a LISP router decide that a RLOC is done by simply = receiving >>>>>>>> an ICMP packet from an attacker (except with LSB that is >>>>>>>> discussed in Sec 4.3.2.1. )? All the other techniques are >>>>>>>> triggered by the LISP router and are protected by the nonce. >>>>>>>>=20 >>>>>>>> Could you describe precisely the attack you have in mind? The >>>>>>>> only think I can see is relying on the birthday paradox but = that >>>>>>>> is a completely different story. >>>>>>>>=20 >>>>>>>> Damien Saucez >>>>>>>>=20 >>>>>>>> On 10 Jun 2014, at 21:37, Ronald Bonica >> wrote: >>>>>>>>=20 >>>>>>>>> Dino, >>>>>>>>>=20 >>>>>>>>> Exactly! So, assume the following: >>>>>>>>>=20 >>>>>>>>> - LISP is deployed on the global Internet >>>>>>>>> - An RLOC is mapped to some number of EID prefixes >>>>>>>>> - For a subset of those EID prefixes, the above mentioned RLOC >>>>>>>>> is preferred >>>>>>>>> - An ITR receives a hint indicating that the RLOC is down >>>>>>>>> (either through a LISP data packet or an ICMP message) >>>>>>>>>=20 >>>>>>>>> The ITR will verify RLOC reachability (possibly by polling the >>>>>>>>> RLOC). But >>>> until the ITR has receives a response to its poll, how should it >>>> behave? Should it continue sending traffic though the above = mentioned >>>> RLOC? Or should it begin to send traffic through another RLOC, if = one >>>> exists? I don't see a normative recommendation. >>>>>>>>>=20 >>>>>>>>> However, both behaviors have their drawbacks and could be >>>>>>>>> vectors >>>> for attack. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Ron >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Dino Farinacci [mailto:farinacci@gmail.com] >>>>>>>>>> Sent: Tuesday, June 10, 2014 1:23 PM >>>>>>>>>> To: Ronald Bonica >>>>>>>>>> Cc: LISP mailing list list >>>>>>>>>> Subject: Re: [lisp] Restarting last call on LISP threats >>>>>>>>>>=20 >>>>>>>>>> As I keep saying Ron, you need to verify anything you intend = to >>>>>>>>>> glean. The spec says the gleaning is "a hint" and not gospel. >>>>>>>>>>=20 >>>>>>>>>> Dino >>>>>>>>>>=20 >>>>>>>>>> On Jun 10, 2014, at 10:06 AM, Ronald Bonica >>>>>>>>>> >>>> wrote: >>>>>>>>>>=20 >>>>>>>>>>> Hi Dino, >>>>>>>>>>>=20 >>>>>>>>>>> Given that the LISP data packet or ICMP packet may be from = an >>>>>>>>>>> attacker, is >>>>>>>>>> it even safe to glean that? I think not. >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> Ron >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: Dino Farinacci [mailto:farinacci@gmail.com] >>>>>>>>>>>> Sent: Tuesday, June 10, 2014 1:04 PM >>>>>>>>>>>> To: Ronald Bonica >>>>>>>>>>>> Cc: LISP mailing list list >>>>>>>>>>>> Subject: Re: [lisp] Restarting last call on LISP threats >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> On Jun 10, 2014, at 9:57 AM, Ronald Bonica >>>> wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>>> Earlier in this thread, we agreed that when LISP is = deployed >>>>>>>>>>>>> on the global >>>>>>>>>>>> Internet, mapping information cannot be gleaned safely from >>>>>>>>>>>> incoming LISP data packets. Following that train of = thought, >>>>>>>>>>>> when LISP is deployed on the global Internet, is it safe to >>>>>>>>>>>> glean routing locator reachability information from = incoming >>>>>>>>>>>> LISP data packets as described in RFC 6830, Section 6.3, >>>>>>>>>>>> bullet 1. If not, I think that we need to mention >>>>>>>>>> this in the threats document. >>>>>>>>>>>>=20 >>>>>>>>>>>> What you can glean is that the source RLOC is up, but you >>>>>>>>>>>> cannot glean your path to it is reachable. >>>>>>>>>>>>=20 >>>>>>>>>>>>> Given that ICMP packets are easily spoofed, when LISP is >>>>>>>>>>>>> deployed on the >>>>>>>>>>>> global Internet, is it safe to glean routing locator >>>>>>>>>>>> reachability information from incoming ICMP packets as >>>>>>>>>>>> described in RFC 6830, Section 6.3, bullet 2 and bullet 4. = If >>>>>>>>>>>> not, I think that we need to mention this in the threats >> document. >>>>>>>>>>>>=20 >>>>>>>>>>>> What you can glean is that the source RLOC is up, but you >>>>>>>>>>>> cannot glean your path to it is reachable. >>>>>>>>>>>>=20 >>>>>>>>>>>> Dino >>>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> lisp mailing list >>>>>>>>> lisp@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/lisp >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> lisp mailing list >>>>>>>> lisp@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/lisp >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> lisp mailing list >>>>>>>> lisp@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/lisp >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> lisp mailing list >>>>>>> lisp@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/lisp >>>>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> lisp mailing list >>>>> lisp@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/lisp >>>>=20 >>>> _______________________________________________ >>>> lisp mailing list >>>> lisp@ietf.org >>>> https://www.ietf.org/mailman/listinfo/lisp >>>=20 >>> _______________________________________________ >>> lisp mailing list >>> lisp@ietf.org >>> https://www.ietf.org/mailman/listinfo/lisp >>>=20 From nobody Tue Jun 17 21:43:45 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 375421A0202 for ; Tue, 17 Jun 2014 21:43:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 OFt1XskWbAik for ; Tue, 17 Jun 2014 21:43:41 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0243.outbound.protection.outlook.com [207.46.163.243]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 523DC1A0172 for ; Tue, 17 Jun 2014 21:43:41 -0700 (PDT) Received: from CO2PR05MB636.namprd05.prod.outlook.com (10.141.199.24) by DM2PR05MB445.namprd05.prod.outlook.com (10.141.104.154) with Microsoft SMTP Server (TLS) id 15.0.954.9; Wed, 18 Jun 2014 04:43:39 +0000 Received: from CO2PR05MB636.namprd05.prod.outlook.com ([10.141.199.24]) by CO2PR05MB636.namprd05.prod.outlook.com ([10.141.199.24]) with mapi id 15.00.0954.000; Wed, 18 Jun 2014 04:43:38 +0000 From: Ross Callon To: "Joel M. Halpern" , Ronald Bonica , Luigi Iannone , Dino Farinacci Thread-Topic: [lisp] Restarting last call on LISP threats Thread-Index: AQHPhM4EWF5k26Wu0Uq+sllpwWiB/5tqkxcAgAAEjYCAACWigIACpvUAgAAxObCAAAXAgIAADkgAgAACGoCABjg4AIAAB3yAgAAEWwCAAmYTUA== Date: Wed, 18 Jun 2014 04:43:37 +0000 Message-ID: <20aa1d96f01541b4969eb27b9654ccfa@CO2PR05MB636.namprd05.prod.outlook.com> References: <40ecc5d773874ecdbdc05763004acfa7@CO1PR05MB442.namprd05.prod.outlook.com> <5399D22A.2040207@joelhalpern.com> <5CAAEAE6-AF3E-4E27-8D73-FA8A64520379@gmail.com> <8f3ee88f9b9649359d5222d324568e07@CO1PR05MB442.namprd05.prod.outlook.com> <539F1582.3010406@joelhalpern.com> In-Reply-To: <539F1582.3010406@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.12] x-microsoft-antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: x-forefront-prvs: 02462830BE x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(428001)(13464003)(51704005)(189002)(43544003)(51444003)(479174003)(377454003)(199002)(24454002)(83322001)(1941001)(19580405001)(74662001)(19580395003)(74502001)(15975445006)(87936001)(76576001)(31966008)(50986999)(81342001)(21056001)(81542001)(99396002)(101416001)(76176999)(33646001)(83072002)(54356999)(77982001)(46102001)(85306003)(76482001)(20776003)(85852003)(74316001)(2656002)(93886003)(92566001)(86362001)(4396001)(79102001)(95666004)(64706001)(99286002)(80022001)(66066001)(105586002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:DM2PR05MB445; H:CO2PR05MB636.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: juniper.net does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=rcallon@juniper.net; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/x4QS4YNHMrfbrwCzkmlh57XFWV4 Cc: LISP mailing list list Subject: Re: [lisp] Restarting last call on LISP threats X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2014 04:43:44 -0000 Is the goal to actually understand whether LISP would be secure if deployed= operationally on Internet-wide scale, or is the goal to satisfy some check= list issue in order to complete the work?=20 Ross -----Original Message----- From: lisp [mailto:lisp-bounces@ietf.org] On Behalf Of Joel M. Halpern Sent: Monday, June 16, 2014 12:04 PM To: Ronald Bonica; Luigi Iannone; Dino Farinacci Cc: LISP mailing list list Subject: Re: [lisp] Restarting last call on LISP threats Personally, I don't see any need to analyse mitigations to discuss=20 classes of attacks. Yours, Joel On 6/16/14, 11:48 AM, Ronald Bonica wrote: > Ciao Luigi, > > If only it were that easy! In the threats document, we have two choices: > > - enumerate every attack that we can imagine > - document abstractions that describe broad classes of threats > > If we enumerate every attack, we will never finish. Therefore, we are for= ced to document attack classes. IMHO, two attacks can be grouped together i= nto a class if both of the following conditions are true: > > - the attacks exploit the same features of the protocol > - the attacks can be addressed using the same mitigation > > If we don't understand mitigations, how will we ever group attacks into c= lasses? > > = Ron > >> -----Original Message----- >> From: lisp [mailto:lisp-bounces@ietf.org] On Behalf Of Luigi Iannone >> Sent: Monday, June 16, 2014 11:22 AM >> To: Dino Farinacci >> Cc: LISP mailing list list >> Subject: Re: [lisp] Restarting last call on LISP threats >> >> Hi Dino, >> >> fair point. I guess that Joel's point was on the fact that this specific= thread >> should focus on the LISP threats document. >> >> Obviously this mailing list is the place where all technical discussions= about >> LISP can take place. >> >> We should just fork the discussion. >> >> So to clearly separate what is related to the threats document and what = are >> new proposals to alleviate some threats. >> >> ciao >> >> Luigi >> >> >> >> On 12 Jun 2014, at 18:23, Dino Farinacci wrote: >> >>> I agree we should be focused Joel. >>> >>> But where else should we have open discussions about LISP? >>> >>> This mailing list membership is unique in that we have multiple vendors= , >> operators, and users all in one place. Wouldn't that make for better >> protocols? >>> >>> Yes we have business to take care of but let's not stifle ideas and >> openness. Do you agree? >>> >>> Dino >>> >>> On Jun 12, 2014, at 9:15 AM, Joel M. Halpern >> wrote: >>> >>>> I will repeat myself. >>>> Can we PLEASE not get into debating how we would solve the weakness >> in the protocol as documented. >>>> >>>> The question focus on is whether the protocol as specified has the >> behavior described, and if so does it result in the weakness described. >>>> If it does, that should be described in the threats document. >>>> if not, then it should not be so described. >>>> >>>> The presence, absence, validity, or possibility of solutions in other >> documents, operational practices, or people's heads, are not the topic f= or >> the WG at this time. >>>> >>>> PLEASE stay on topic, or we will never get our current work done. >>>> Which means that peoples wonderful ideas on how to do more or better >> will never get publsihed. >>>> >>>> Yours, >>>> Joel >>>> >>>> On 6/12/14, 11:24 AM, Dino Farinacci wrote: >>>>> >>>>>>> Could you describe precisely the attack you have in mind? The >>>>>>> only think I can see is relying on the birthday paradox but that >>>>>>> is a completely different story. >>>>>> >>>>>> If an attacker is on-path it could see the nonce's (assuming that th= e LISP >> header is not encrypted, regardless of whether the data packet is >> encrypted). This could be an issue if the attacker is physically on-path= . >>>>> >>>>> The source EID is encrypted so it can only see a cleartext source RLO= C >> and can't associated it with anything. >>>>> >>>>> When we merge lisp-cryto logic with echo-noncing, one has to >> determine if an xTR should participate in echo-noncing if the payload is= not >> decrypted properly. That is, if I get a echoed nonce back from an attack= er for >> a nonce I know I have sent and set the E-bit, and I cannot decrypt the >> payload that comes from the attacker, then I don't believe any NEW >> reachability information about the RLOC. >>>>> >>>>>> This could also be an issue for attackers which are physically off-p= ath if >> gleaning is used, since an attacker could use a gleaning attack to tempo= rarily >> insert itself on-path, which in turn would allow it to see the nonce. >>>>> >>>>> So by now we know there are many issues with gleaning. So we should >> document them and say they shouldn't be used for the general global >> Internet use-case. >>>>> >>>>> Dino >>>>> >>>>>> >>>>>> Ross >>>>>> >>>>>> -----Original Message----- >>>>>> From: lisp [mailto:lisp-bounces@ietf.org] On Behalf Of Damien >>>>>> Saucez >>>>>> Sent: Thursday, June 12, 2014 8:08 AM >>>>>> To: Ronald Bonica >>>>>> Cc: LISP mailing list list >>>>>> Subject: Re: [lisp] Restarting last call on LISP threats >>>>>> >>>>>> Hello, >>>>>> >>>>>> I am not sure I understand exactly what you are proposing. How can >>>>>> a LISP router decide that a RLOC is done by simply receiving an >>>>>> ICMP packet from an attacker (except with LSB that is discussed in >>>>>> Sec 4.3.2.1. )? All the other techniques are triggered by the >>>>>> LISP router and are protected by the nonce. >>>>>> >>>>>> Could you describe precisely the attack you have in mind? The only >>>>>> think I can see is relying on the birthday paradox but that is a >>>>>> completely different story. >>>>>> >>>>>> Damien Saucez >>>>>> >>>>>> On 10 Jun 2014, at 21:37, Ronald Bonica wrote: >>>>>> >>>>>>> Dino, >>>>>>> >>>>>>> Exactly! So, assume the following: >>>>>>> >>>>>>> - LISP is deployed on the global Internet >>>>>>> - An RLOC is mapped to some number of EID prefixes >>>>>>> - For a subset of those EID prefixes, the above mentioned RLOC is >>>>>>> preferred >>>>>>> - An ITR receives a hint indicating that the RLOC is down (either >>>>>>> through a LISP data packet or an ICMP message) >>>>>>> >>>>>>> The ITR will verify RLOC reachability (possibly by polling the RLOC= ). But >> until the ITR has receives a response to its poll, how should it behave?= Should >> it continue sending traffic though the above mentioned RLOC? Or should i= t >> begin to send traffic through another RLOC, if one exists? I don't see a >> normative recommendation. >>>>>>> >>>>>>> However, both behaviors have their drawbacks and could be vectors >> for attack. >>>>>>> >>>>>>> >>>>>>> Ron >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Dino Farinacci [mailto:farinacci@gmail.com] >>>>>>>> Sent: Tuesday, June 10, 2014 1:23 PM >>>>>>>> To: Ronald Bonica >>>>>>>> Cc: LISP mailing list list >>>>>>>> Subject: Re: [lisp] Restarting last call on LISP threats >>>>>>>> >>>>>>>> As I keep saying Ron, you need to verify anything you intend to >>>>>>>> glean. The spec says the gleaning is "a hint" and not gospel. >>>>>>>> >>>>>>>> Dino >>>>>>>> >>>>>>>> On Jun 10, 2014, at 10:06 AM, Ronald Bonica >> wrote: >>>>>>>> >>>>>>>>> Hi Dino, >>>>>>>>> >>>>>>>>> Given that the LISP data packet or ICMP packet may be from an >>>>>>>>> attacker, is >>>>>>>> it even safe to glean that? I think not. >>>>>>>>> >>>>>>>>> >>>>>>>>> Ron >>>>>>>>> >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Dino Farinacci [mailto:farinacci@gmail.com] >>>>>>>>>> Sent: Tuesday, June 10, 2014 1:04 PM >>>>>>>>>> To: Ronald Bonica >>>>>>>>>> Cc: LISP mailing list list >>>>>>>>>> Subject: Re: [lisp] Restarting last call on LISP threats >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Jun 10, 2014, at 9:57 AM, Ronald Bonica >> wrote: >>>>>>>>>> >>>>>>>>>>> Earlier in this thread, we agreed that when LISP is deployed >>>>>>>>>>> on the global >>>>>>>>>> Internet, mapping information cannot be gleaned safely from >>>>>>>>>> incoming LISP data packets. Following that train of thought, >>>>>>>>>> when LISP is deployed on the global Internet, is it safe to >>>>>>>>>> glean routing locator reachability information from incoming >>>>>>>>>> LISP data packets as described in RFC 6830, Section 6.3, bullet >>>>>>>>>> 1. If not, I think that we need to mention >>>>>>>> this in the threats document. >>>>>>>>>> >>>>>>>>>> What you can glean is that the source RLOC is up, but you >>>>>>>>>> cannot glean your path to it is reachable. >>>>>>>>>> >>>>>>>>>>> Given that ICMP packets are easily spoofed, when LISP is >>>>>>>>>>> deployed on the >>>>>>>>>> global Internet, is it safe to glean routing locator >>>>>>>>>> reachability information from incoming ICMP packets as >>>>>>>>>> described in RFC 6830, Section 6.3, bullet 2 and bullet 4. If >>>>>>>>>> not, I think that we need to mention this in the threats documen= t. >>>>>>>>>> >>>>>>>>>> What you can glean is that the source RLOC is up, but you >>>>>>>>>> cannot glean your path to it is reachable. >>>>>>>>>> >>>>>>>>>> Dino >>>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> lisp mailing list >>>>>>> lisp@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/lisp >>>>>> >>>>>> _______________________________________________ >>>>>> lisp mailing list >>>>>> lisp@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/lisp >>>>>> >>>>>> _______________________________________________ >>>>>> lisp mailing list >>>>>> lisp@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/lisp >>>>> >>>>> _______________________________________________ >>>>> lisp mailing list >>>>> lisp@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/lisp >>>>> >>> >>> _______________________________________________ >>> lisp mailing list >>> lisp@ietf.org >>> https://www.ietf.org/mailman/listinfo/lisp >> >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From nobody Tue Jun 17 21:45:58 2014 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BEB61A0223 for ; Tue, 17 Jun 2014 21:45:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 4llIc9Jpm7cg for ; Tue, 17 Jun 2014 21:45:56 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABAF51A0172 for ; Tue, 17 Jun 2014 21:45:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 89700246BFF; Tue, 17 Jun 2014 21:45:56 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from host-78-64-19-251.homerun.telia.com (host-78-64-19-251.homerun.telia.com [78.64.19.251]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 34970246AC8; Tue, 17 Jun 2014 21:45:55 -0700 (PDT) Message-ID: <53A11986.7080504@joelhalpern.com> Date: Wed, 18 Jun 2014 00:45:58 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Ross Callon , Ronald Bonica , Luigi Iannone , Dino Farinacci References: <40ecc5d773874ecdbdc05763004acfa7@CO1PR05MB442.namprd05.prod.outlook.com> <5399D22A.2040207@joelhalpern.com> <5CAAEAE6-AF3E-4E27-8D73-FA8A64520379@gmail.com> <8f3ee88f9b9649359d5222d324568e07@CO1PR05MB442.namprd05.prod.outlook.com> <539F1582.3010406@joelhalpern.com> <20aa1d96f01541b4969eb27b9654ccfa@CO2PR05MB636.namprd05.prod.outlook.com> In-Reply-To: <20aa1d96f01541b4969eb27b9654ccfa@CO2PR05MB636.namprd05.prod.outlook.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/tVNwsVh7DMexaP7goXPm3z_TA98 Cc: LISP mailing list list Subject: Re: [lisp] Restarting last call on LISP threats X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2014 04:45:58 -0000 Both of course. We as a working group agreed to separate the document tasks. One document is to understand the threats, and others (because it is a continuing task) to address them. Yours, Joel On 6/18/14, 12:43 AM, Ross Callon wrote: > Is the goal to actually understand whether LISP would be secure if deployed operationally on Internet-wide scale, or is the goal to satisfy some checklist issue in order to complete the work? > > Ross > > -----Original Message----- > From: lisp [mailto:lisp-bounces@ietf.org] On Behalf Of Joel M. Halpern > Sent: Monday, June 16, 2014 12:04 PM > To: Ronald Bonica; Luigi Iannone; Dino Farinacci > Cc: LISP mailing list list > Subject: Re: [lisp] Restarting last call on LISP threats > > Personally, I don't see any need to analyse mitigations to discuss > classes of attacks. > > Yours, > Joel > > On 6/16/14, 11:48 AM, Ronald Bonica wrote: >> Ciao Luigi, >> >> If only it were that easy! In the threats document, we have two choices: >> >> - enumerate every attack that we can imagine >> - document abstractions that describe broad classes of threats >> >> If we enumerate every attack, we will never finish. Therefore, we are forced to document attack classes. IMHO, two attacks can be grouped together into a class if both of the following conditions are true: >> >> - the attacks exploit the same features of the protocol >> - the attacks can be addressed using the same mitigation >> >> If we don't understand mitigations, how will we ever group attacks into classes? >> >> Ron >> >>> -----Original Message----- >>> From: lisp [mailto:lisp-bounces@ietf.org] On Behalf Of Luigi Iannone >>> Sent: Monday, June 16, 2014 11:22 AM >>> To: Dino Farinacci >>> Cc: LISP mailing list list >>> Subject: Re: [lisp] Restarting last call on LISP threats >>> >>> Hi Dino, >>> >>> fair point. I guess that Joel's point was on the fact that this specific thread >>> should focus on the LISP threats document. >>> >>> Obviously this mailing list is the place where all technical discussions about >>> LISP can take place. >>> >>> We should just fork the discussion. >>> >>> So to clearly separate what is related to the threats document and what are >>> new proposals to alleviate some threats. >>> >>> ciao >>> >>> Luigi >>> >>> >>> >>> On 12 Jun 2014, at 18:23, Dino Farinacci wrote: >>> >>>> I agree we should be focused Joel. >>>> >>>> But where else should we have open discussions about LISP? >>>> >>>> This mailing list membership is unique in that we have multiple vendors, >>> operators, and users all in one place. Wouldn't that make for better >>> protocols? >>>> >>>> Yes we have business to take care of but let's not stifle ideas and >>> openness. Do you agree? >>>> >>>> Dino >>>> >>>> On Jun 12, 2014, at 9:15 AM, Joel M. Halpern >>> wrote: >>>> >>>>> I will repeat myself. >>>>> Can we PLEASE not get into debating how we would solve the weakness >>> in the protocol as documented. >>>>> >>>>> The question focus on is whether the protocol as specified has the >>> behavior described, and if so does it result in the weakness described. >>>>> If it does, that should be described in the threats document. >>>>> if not, then it should not be so described. >>>>> >>>>> The presence, absence, validity, or possibility of solutions in other >>> documents, operational practices, or people's heads, are not the topic for >>> the WG at this time. >>>>> >>>>> PLEASE stay on topic, or we will never get our current work done. >>>>> Which means that peoples wonderful ideas on how to do more or better >>> will never get publsihed. >>>>> >>>>> Yours, >>>>> Joel >>>>> >>>>> On 6/12/14, 11:24 AM, Dino Farinacci wrote: >>>>>> >>>>>>>> Could you describe precisely the attack you have in mind? The >>>>>>>> only think I can see is relying on the birthday paradox but that >>>>>>>> is a completely different story. >>>>>>> >>>>>>> If an attacker is on-path it could see the nonce's (assuming that the LISP >>> header is not encrypted, regardless of whether the data packet is >>> encrypted). This could be an issue if the attacker is physically on-path. >>>>>> >>>>>> The source EID is encrypted so it can only see a cleartext source RLOC >>> and can't associated it with anything. >>>>>> >>>>>> When we merge lisp-cryto logic with echo-noncing, one has to >>> determine if an xTR should participate in echo-noncing if the payload is not >>> decrypted properly. That is, if I get a echoed nonce back from an attacker for >>> a nonce I know I have sent and set the E-bit, and I cannot decrypt the >>> payload that comes from the attacker, then I don't believe any NEW >>> reachability information about the RLOC. >>>>>> >>>>>>> This could also be an issue for attackers which are physically off-path if >>> gleaning is used, since an attacker could use a gleaning attack to temporarily >>> insert itself on-path, which in turn would allow it to see the nonce. >>>>>> >>>>>> So by now we know there are many issues with gleaning. So we should >>> document them and say they shouldn't be used for the general global >>> Internet use-case. >>>>>> >>>>>> Dino >>>>>> >>>>>>> >>>>>>> Ross >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: lisp [mailto:lisp-bounces@ietf.org] On Behalf Of Damien >>>>>>> Saucez >>>>>>> Sent: Thursday, June 12, 2014 8:08 AM >>>>>>> To: Ronald Bonica >>>>>>> Cc: LISP mailing list list >>>>>>> Subject: Re: [lisp] Restarting last call on LISP threats >>>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> I am not sure I understand exactly what you are proposing. How can >>>>>>> a LISP router decide that a RLOC is done by simply receiving an >>>>>>> ICMP packet from an attacker (except with LSB that is discussed in >>>>>>> Sec 4.3.2.1. )? All the other techniques are triggered by the >>>>>>> LISP router and are protected by the nonce. >>>>>>> >>>>>>> Could you describe precisely the attack you have in mind? The only >>>>>>> think I can see is relying on the birthday paradox but that is a >>>>>>> completely different story. >>>>>>> >>>>>>> Damien Saucez >>>>>>> >>>>>>> On 10 Jun 2014, at 21:37, Ronald Bonica wrote: >>>>>>> >>>>>>>> Dino, >>>>>>>> >>>>>>>> Exactly! So, assume the following: >>>>>>>> >>>>>>>> - LISP is deployed on the global Internet >>>>>>>> - An RLOC is mapped to some number of EID prefixes >>>>>>>> - For a subset of those EID prefixes, the above mentioned RLOC is >>>>>>>> preferred >>>>>>>> - An ITR receives a hint indicating that the RLOC is down (either >>>>>>>> through a LISP data packet or an ICMP message) >>>>>>>> >>>>>>>> The ITR will verify RLOC reachability (possibly by polling the RLOC). But >>> until the ITR has receives a response to its poll, how should it behave? Should >>> it continue sending traffic though the above mentioned RLOC? Or should it >>> begin to send traffic through another RLOC, if one exists? I don't see a >>> normative recommendation. >>>>>>>> >>>>>>>> However, both behaviors have their drawbacks and could be vectors >>> for attack. >>>>>>>> >>>>>>>> >>>>>>>> Ron >>>>>>>> >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Dino Farinacci [mailto:farinacci@gmail.com] >>>>>>>>> Sent: Tuesday, June 10, 2014 1:23 PM >>>>>>>>> To: Ronald Bonica >>>>>>>>> Cc: LISP mailing list list >>>>>>>>> Subject: Re: [lisp] Restarting last call on LISP threats >>>>>>>>> >>>>>>>>> As I keep saying Ron, you need to verify anything you intend to >>>>>>>>> glean. The spec says the gleaning is "a hint" and not gospel. >>>>>>>>> >>>>>>>>> Dino >>>>>>>>> >>>>>>>>> On Jun 10, 2014, at 10:06 AM, Ronald Bonica >>> wrote: >>>>>>>>> >>>>>>>>>> Hi Dino, >>>>>>>>>> >>>>>>>>>> Given that the LISP data packet or ICMP packet may be from an >>>>>>>>>> attacker, is >>>>>>>>> it even safe to glean that? I think not. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Ron >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: Dino Farinacci [mailto:farinacci@gmail.com] >>>>>>>>>>> Sent: Tuesday, June 10, 2014 1:04 PM >>>>>>>>>>> To: Ronald Bonica >>>>>>>>>>> Cc: LISP mailing list list >>>>>>>>>>> Subject: Re: [lisp] Restarting last call on LISP threats >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Jun 10, 2014, at 9:57 AM, Ronald Bonica >>> wrote: >>>>>>>>>>> >>>>>>>>>>>> Earlier in this thread, we agreed that when LISP is deployed >>>>>>>>>>>> on the global >>>>>>>>>>> Internet, mapping information cannot be gleaned safely from >>>>>>>>>>> incoming LISP data packets. Following that train of thought, >>>>>>>>>>> when LISP is deployed on the global Internet, is it safe to >>>>>>>>>>> glean routing locator reachability information from incoming >>>>>>>>>>> LISP data packets as described in RFC 6830, Section 6.3, bullet >>>>>>>>>>> 1. If not, I think that we need to mention >>>>>>>>> this in the threats document. >>>>>>>>>>> >>>>>>>>>>> What you can glean is that the source RLOC is up, but you >>>>>>>>>>> cannot glean your path to it is reachable. >>>>>>>>>>> >>>>>>>>>>>> Given that ICMP packets are easily spoofed, when LISP is >>>>>>>>>>>> deployed on the >>>>>>>>>>> global Internet, is it safe to glean routing locator >>>>>>>>>>> reachability information from incoming ICMP packets as >>>>>>>>>>> described in RFC 6830, Section 6.3, bullet 2 and bullet 4. If >>>>>>>>>>> not, I think that we need to mention this in the threats document. >>>>>>>>>>> >>>>>>>>>>> What you can glean is that the source RLOC is up, but you >>>>>>>>>>> cannot glean your path to it is reachable. >>>>>>>>>>> >>>>>>>>>>> Dino >>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> lisp mailing list >>>>>>>> lisp@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/lisp >>>>>>> >>>>>>> _______________________________________________ >>>>>>> lisp mailing list >>>>>>> lisp@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/lisp >>>>>>> >>>>>>> _______________________________________________ >>>>>>> lisp mailing list >>>>>>> lisp@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/lisp >>>>>> >>>>>> _______________________________________________ >>>>>> lisp mailing list >>>>>> lisp@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/lisp >>>>>> >>>> >>>> _______________________________________________ >>>> lisp mailing list >>>> lisp@ietf.org >>>> https://www.ietf.org/mailman/listinfo/lisp >>> >>> _______________________________________________ >>> lisp mailing list >>> lisp@ietf.org >>> https://www.ietf.org/mailman/listinfo/lisp >> >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp >> > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp >