IETF Logo Mail Archive

[lisp] VPN Leaks

Ronald Bonica <rbonica@juniper.net> Mon, 20 April 2015 11:30 UTC

Return-Path: <rbonica@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 6753E1B2AC8 for <lisp@ietfa.amsl.com>; Mon, 20 Apr 2015 04:30:55 -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, 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 g9_ZUJbhOYki for <lisp@ietfa.amsl.com>; Mon, 20 Apr 2015 04:30:53 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0713.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:713]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D0321B2AC7 for <lisp@ietf.org>; Mon, 20 Apr 2015 04:30:53 -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.1.136.25; Mon, 20 Apr 2015 11:30:36 +0000
Received: from CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.238]) by CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.238]) with mapi id 15.01.0136.026; Mon, 20 Apr 2015 11:30:36 +0000
From: Ronald Bonica <rbonica@juniper.net>
To: LISP mailing list list <lisp@ietf.org>
Thread-Topic: VPN Leaks
Thread-Index: AdB7XFnvt4mhwTyvQCG1wXN2axrNNQ==
Date: Mon, 20 Apr 2015 11:30:35 +0000
Message-ID: <CO1PR05MB442D045DE318D5BCA82259CAEE00@CO1PR05MB442.namprd05.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;
x-originating-ip: [66.129.241.14]
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB444;
x-microsoft-antispam-prvs: <CO1PR05MB444F299438781BF77501E00AEE00@CO1PR05MB444.namprd05.prod.outlook.com>
x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(40100003)(122556002)(221733001)(46102003)(450100001)(62966003)(77156002)(66066001)(86362001)(87936001)(2656002)(74316001)(33656002)(102836002)(50986999)(54356999)(229853001)(99286002)(92566002)(2900100001)(110136001)(107886001)(76576001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB444; H:CO1PR05MB442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5002010); SRVR:CO1PR05MB444; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB444;
x-forefront-prvs: 05529C6FDB
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Apr 2015 11:30:35.4778 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB444
Archived-At: <http://mailarchive.ietf.org/arch/msg/lisp/P5c5GluU6U_BIg_Qwauq5SlRWIc>
Subject: [lisp] VPN Leaks
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: Mon, 20 Apr 2015 11:30:55 -0000

Folks,

In draft-ietf-lisp-eid-block-10 you say:

  Avoid excessive stretch:  In some deployment scenarios, in order to
         avoid packet drops, packets triggering a LISP Cache miss are
         forwarded toward a PETR, during the time necessary to perform a
         mapping lookup over the LISP mapping system.  Once a mapping is
         obtained packet are not forwarded anymore toward the PETR, they
         are LISP encapsulated and forwarded according to the LISP
         specifications.  The existence of a LISP specific EID block
         would allow to avoid scenarios with excessive overhead, where
         the destination is a LISP EID and where (while the mapping is
         looked up) packets are forwarded over paths like
         Source->ITR->PETR->PITR->ETR->Destination, which may show an
         excessive stretch factor and degraded performance.

Is this behavior documented anywhere else? If so, where?

Is this behavior also observed in IPv4 implementations?

Also, is there serious consideration to using LISP as a VPN mechanism (as suggested in draft-ietf-lisp-impact-01 and draft-ietf-lisp-introduction-13). If so, this behavior should be mentioned in the Threats document.

Ron Bonica

v2.23.0 | Report a Bug | By Email