IETF Logo Mail Archive

Re: [GROW] [Idr] operator inputs -- route leak solution

Andrei Robachevsky <andrei.robachevsky@gmail.com> Thu, 23 March 2017 14:51 UTC

Return-Path: <andrei.robachevsky@gmail.com>
X-Original-To: grow@ietfa.amsl.com
Delivered-To: grow@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B09E71294CF; Thu, 23 Mar 2017 07:51:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.5
X-Spam-Level:
X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m7WsX89OWpiX; Thu, 23 Mar 2017 07:51:31 -0700 (PDT)
Received: from mail-wr0-x22c.google.com (mail-wr0-x22c.google.com [IPv6:2a00:1450:400c:c0c::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB0CC126B72; Thu, 23 Mar 2017 07:51:30 -0700 (PDT)
Received: by mail-wr0-x22c.google.com with SMTP id l37so149342841wrc.1; Thu, 23 Mar 2017 07:51:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to; bh=1BpgAPOAkYfbxkDw+k1f1jmn2bdQhqMKg3umU1HXWtU=; b=OGdSDQ2iFlqbTaAnP8Dh2h12qr8DtFLpX5dZIFObgxFH0M3u2+USS3zAY0yNYWpnz5 5sR1wawuNrcWznEN5c7g8V9VnJ3TUwK1Clvamq7XNKx3lMJWvS8vuZHV4Jmi6zfiR7Av bKuemrGdEFwhJBmKsPJo3lzOzO7kB0QEoZriDcWh/XvHcTasK6JLXcWxtnCb9HRRmwtg Ia1TTKP7lYqrnsDU3aUDIuHxLWBi0p96VStNg9gq9OwxV0gEx5XrZnV2RgKp0nEFUhli /zS2r/I8vYqS5NI5Qz0rCesaNXYkyAuW1Iz2SuR8AHueejjVAP4pqgpb2qWo/9sKHAEG +NTA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=1BpgAPOAkYfbxkDw+k1f1jmn2bdQhqMKg3umU1HXWtU=; b=auUek8Cwrd0GdYEh75q2QKywdJXg/nXeuy80fW19LNzBWxq0cxCnbH2TJEdLS9tn0/ pT19uF7Tos4P4wrgKNpWvS3TQMhkWUsZvy8CF0EGzFHYurtGJJBT90xzX2Hzy162NrOv m4VwhrRbwZP6P5Sl5p+8ojM96wPt2cCdx/clpBDcpFUXRX57qJdUFNpYUq6JDI9mwlF3 PgsbTdg+t0H6lCOSVHN8BRhYFsFMN3ELNW4WjlbjdZsXXOFHCXnqZm+8H5V1GyOaCy3p TixcO9dcFlIDtsl2dHHhWwllu5HWnUQxGHte9gWvxR6b4sN6nANXXdACPuyU9TnyUKan zr6g==
X-Gm-Message-State: AFeK/H0IP1zXdbn/mTOi4yCmvzJhY59jg+i1hWcteSOpiuaBlisa94zgc1kg2vy47xANvA==
X-Received: by 10.223.150.205 with SMTP id u71mr2969022wrb.195.1490280689368; Thu, 23 Mar 2017 07:51:29 -0700 (PDT)
Received: from ISOC-A1FD58.local ([147.67.241.226]) by smtp.googlemail.com with ESMTPSA id 92sm6162655wrh.8.2017.03.23.07.51.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Mar 2017 07:51:27 -0700 (PDT)
To: Gert Doering <gert@space.net>, Nick Hilliard <nick@foobar.org>
References: <DM2PR09MB044656C168037D0BEF7A78CB843D0@DM2PR09MB0446.namprd09.prod.outlook.com> <20170321205513.GA2367@Space.Net> <CAH1iCirbAnj+Tyn0rs5Zs9-RyY=Qj2onqNh=DehEkDQtPrRSJA@mail.gmail.com> <20170322143302.GG2367@Space.Net> <58D2F5E7.80205@foobar.org> <20170323074557.GK2367@Space.Net>
Cc: "idr@ietf.org" <idr@ietf.org>, "grow@ietf.org" <grow@ietf.org>
From: Andrei Robachevsky <andrei.robachevsky@gmail.com>
Message-ID: <7d3b762d-6117-46a1-ef1e-3182b44a0cf7@gmail.com>
Date: Thu, 23 Mar 2017 15:51:26 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <20170323074557.GK2367@Space.Net>
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="tWG8Gv3Dg66oNAI41cb0Asi5vCAalxn9M"
Archived-At: <https://mailarchive.ietf.org/arch/msg/grow/ZlOY-yraNYIcLkVM9cE-fMhCjF8>
Subject: Re: [GROW] [Idr] operator inputs -- route leak solution
X-BeenThere: grow@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Grow Working Group Mailing List <grow.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/grow>, <mailto:grow-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/grow/>
List-Post: <mailto:grow@ietf.org>
List-Help: <mailto:grow-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/grow>, <mailto:grow-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Mar 2017 14:51:33 -0000

Gert Doering wrote on 23/03/2017 08:45:
> Please explain to me how this is going to work if "lazy upstream ISP" 
> keeps being lazy, and does nothing.

I agree. However the motivation for the proposed solution comes from the
desire to fix the problem in the future when RPKI and BGPSEC are
deployed, but neither of these technologies protects against leaks.

In the meantime a lazy upstream ISP can still turn the check on, which
is much easier than maintaining filters for their customers cone.

Andrei

v2.23.0 | Report a Bug | By Email