Re: [lisp] Restarting last call on LISP threats
Ross Callon <rcallon@juniper.net> Thu, 12 June 2014 15:10 UTC
Return-Path: <rcallon@juniper.net>
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 <lisp@ietfa.amsl.com>; 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 <lisp@ietfa.amsl.com>; 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 <lisp@ietf.org>; 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 <rcallon@juniper.net>
To: Damien Saucez <damien.saucez@gmail.com>, Ronald Bonica <rbonica@juniper.net>
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: <db040d02b9a3402c9e53e1ae6374b2bb@CO2PR05MB636.namprd05.prod.outlook.com>
References: <d690563db20d4fca945b810a14f37090@CO1PR05MB442.namprd05.prod.outlook.com> <B3A9D234-A6A2-45DC-B8FA-623B3A86DCE8@gmail.com> <a7c188aabbfe41ef80645d2ee1d6df99@CO1PR05MB442.namprd05.prod.outlook.com> <E0485205-9FCD-46FC-B852-06259334A47C@gmail.com> <40ecc5d773874ecdbdc05763004acfa7@CO1PR05MB442.namprd05.prod.outlook.com> <A2225E25-FE9E-4F97-B86F-9C078BB6A312@gmail.com>
In-Reply-To: <A2225E25-FE9E-4F97-B86F-9C078BB6A312@gmail.com>
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 <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 <lisp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lisp>, <mailto:lisp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/lisp/>
List-Post: <mailto:lisp@ietf.org>
List-Help: <mailto:lisp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lisp>, <mailto:lisp-request@ietf.org?subject=subscribe>
X-List-Received-Date: 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. 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. 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 <rbonica@juniper.net> 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 <rbonica@juniper.net> 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 <rbonica@juniper.net> 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] Restarting last call on LISP threats Joel M. Halpern
- Re: [lisp] Restarting last call on LISP threats Ross Callon
- Re: [lisp] Restarting last call on LISP threats Roger Jørgensen
- Re: [lisp] Restarting last call on LISP threats Ross Callon
- Re: [lisp] Restarting last call on LISP threats Ronald Bonica
- Re: [lisp] Restarting last call on LISP threats Ronald Bonica
- Re: [lisp] Restarting last call on LISP threats Dino Farinacci
- Re: [lisp] Restarting last call on LISP threats Joel M. Halpern
- Re: [lisp] Restarting last call on LISP threats Roger Jørgensen
- Re: [lisp] Restarting last call on LISP threats Ronald Bonica
- Re: [lisp] Restarting last call on LISP threats Joel Halpern Direct
- Re: [lisp] Restarting last call on LISP threats Ronald Bonica
- Re: [lisp] Restarting last call on LISP threats Ronald Bonica
- Re: [lisp] Restarting last call on LISP threats Dino Farinacci
- Re: [lisp] Restarting last call on LISP threats Ronald Bonica
- Re: [lisp] Restarting last call on LISP threats Ross Callon
- Re: [lisp] Restarting last call on LISP threats Joel M. Halpern
- Re: [lisp] Restarting last call on LISP threats Ross Callon
- Re: [lisp] Restarting last call on LISP threats Dino Farinacci
- Re: [lisp] Restarting last call on LISP threats Sander Steffann
- Re: [lisp] Restarting last call on LISP threats Dino Farinacci
- Re: [lisp] Restarting last call on LISP threats Roger Jørgensen
- Re: [lisp] Restarting last call on LISP threats Ronald Bonica
- Re: [lisp] Restarting last call on LISP threats Dino Farinacci
- Re: [lisp] Restarting last call on LISP threats Damien Saucez
- Re: [lisp] Restarting last call on LISP threats Ross Callon
- Re: [lisp] Restarting last call on LISP threats Ronald Bonica
- Re: [lisp] Restarting last call on LISP threats Damien Saucez
- Re: [lisp] Restarting last call on LISP threats Ross Callon
- Re: [lisp] Restarting last call on LISP threats Damien Saucez
- Re: [lisp] Restarting last call on LISP threats Ronald Bonica
- Re: [lisp] Restarting last call on LISP threats Dino Farinacci
- Re: [lisp] Restarting last call on LISP threats Ronald Bonica
- Re: [lisp] Restarting last call on LISP threats Damien Saucez
- Re: [lisp] Restarting last call on LISP threats Dino Farinacci
- Re: [lisp] Restarting last call on LISP threats Ross Callon
- Re: [lisp] Restarting last call on LISP threats Ronald Bonica
- Re: [lisp] Restarting last call on LISP threats Ronald Bonica
- Re: [lisp] Restarting last call on LISP threats Roger Jørgensen
- Re: [lisp] Restarting last call on LISP threats Joel M. Halpern
- Re: [lisp] Restarting last call on LISP threats Ronald Bonica
- Re: [lisp] Restarting last call on LISP threats Sharon
- Re: [lisp] Restarting last call on LISP threats Paul Vinciguerra
- Re: [lisp] Restarting last call on LISP threats Joel M. Halpern
- Re: [lisp] Restarting last call on LISP threats Marc Binderberger
- Re: [lisp] Restarting last call on LISP threats Ronald Bonica
- Re: [lisp] Restarting last call on LISP threats Dino Farinacci
- Re: [lisp] Restarting last call on LISP threats Dino Farinacci
- Re: [lisp] Restarting last call on LISP threats Joel M. Halpern
- Re: [lisp] Restarting last call on LISP threats Dino Farinacci
- Re: [lisp] Restarting last call on LISP threats Sharon Barkai
- Re: [lisp] Restarting last call on LISP threats Dino Farinacci
- Re: [lisp] Restarting last call on LISP threats Damien Saucez
- Re: [lisp] Restarting last call on LISP threats Ronald Bonica
- Re: [lisp] Restarting last call on LISP threats Ronald Bonica
- Re: [lisp] Restarting last call on LISP threats Dino Farinacci
- Re: [lisp] Restarting last call on LISP threats Ronald Bonica
- Re: [lisp] Restarting last call on LISP threats Dino Farinacci
- Re: [lisp] Restarting last call on LISP threats Florin Coras
- Re: [lisp] Restarting last call on LISP threats Marc Binderberger
- Re: [lisp] Restarting last call on LISP threats Florin Coras
- Re: [lisp] Restarting last call on LISP threats Ross Callon
- Re: [lisp] Restarting last call on LISP threats Dino Farinacci
- Re: [lisp] Restarting last call on LISP threats Ronald Bonica
- Re: [lisp] Restarting last call on LISP threats Ronald Bonica
- Re: [lisp] Restarting last call on LISP threats Dino Farinacci
- Re: [lisp] Restarting last call on LISP threats Ronald Bonica
- Re: [lisp] Restarting last call on LISP threats Joel M. Halpern
- Re: [lisp] Restarting last call on LISP threats Dino Farinacci
- Re: [lisp] Restarting last call on LISP threats Ronald Bonica
- Re: [lisp] Restarting last call on LISP threats Dino Farinacci
- Re: [lisp] Restarting last call on LISP threats Darrel Lewis (darlewis)
- Re: [lisp] Restarting last call on LISP threats Ronald Bonica
- Re: [lisp] Restarting last call on LISP threats Damien Saucez
- Re: [lisp] Restarting last call on LISP threats Ross Callon
- Re: [lisp] Restarting last call on LISP threats Dino Farinacci
- Re: [lisp] Restarting last call on LISP threats Ross Callon
- Re: [lisp] Restarting last call on LISP threats Dino Farinacci
- Re: [lisp] Restarting last call on LISP threats Joel M. Halpern
- Re: [lisp] Restarting last call on LISP threats Dino Farinacci
- Re: [lisp] Restarting last call on LISP threats Ronald Bonica
- Re: [lisp] Restarting last call on LISP threats Luigi Iannone
- Re: [lisp] Restarting last call on LISP threats Ronald Bonica
- Re: [lisp] Restarting last call on LISP threats Joel M. Halpern
- Re: [lisp] Restarting last call on LISP threats Ronald Bonica
- Re: [lisp] Restarting last call on LISP threats Damien Saucez
- Re: [lisp] Restarting last call on LISP threats Brian Haberman
- Re: [lisp] Restarting last call on LISP threats Joel M. Halpern
- Re: [lisp] Restarting last call on LISP threats Brian Haberman
- Re: [lisp] Restarting last call on LISP threats Luigi Iannone
- Re: [lisp] Restarting last call on LISP threats Luigi Iannone
- Re: [lisp] Restarting last call on LISP threats Ross Callon
- Re: [lisp] Restarting last call on LISP threats Joel M. Halpern