Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidrops-route-server-rpki-light-00.txt
"i3D.net - Martijn Schmidt" <martijnschmidt@i3d.net> Mon, 16 January 2017 12:45 UTC
Return-Path: <martijnschmidt@i3d.net>
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 75BCA127076; Mon, 16 Jan 2017 04:45:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jKQTVwCiL3jW; Mon, 16 Jan 2017 04:45:38 -0800 (PST)
Received: from mail.i3d.net (mail.i3d.nl [213.163.77.240]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59C481294C0; Mon, 16 Jan 2017 04:42:20 -0800 (PST)
X-Footer: aTNkLm5s
Received: from localhost ([127.0.0.1]) by mail.i3d.net with ESMTPSA (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128 bits)); Mon, 16 Jan 2017 13:42:07 +0100
To: Matthias Waehlisch <m.waehlisch@fu-berlin.de>, Nick Hilliard <nick@foobar.org>
References: <148433210469.9788.12815016683609966013.idtracker@ietfa.amsl.com> <20170113184009.GC1055@Vurt.local> <7C35D47D-6605-4D6D-A97E-BD7139F36DBA@gmail.com> <7f08f967-247e-4060-b643-52bc45d8ab29@Spark> <1E278B10-A5BF-40BE-95C4-7A9B6AF6C817@gmail.com> <c55845cc-ca06-45c8-9b2e-075421d0447c@Spark> <58795A0B.6000009@foobar.org> <alpine.WNT.2.00.1701141045460.14048@mw-PC> <587A03CF.3010001@foobar.org> <alpine.WNT.2.00.1701141619550.14048@mw-PC> <587A9DE9.1000608@foobar.org> <alpine.WNT.2.00.1701152315390.14048@mw-PC>
From: "i3D.net - Martijn Schmidt" <martijnschmidt@i3d.net>
Organization: i3D.net
Message-ID: <85dbabda-3381-84fe-8ee2-961ce381a204@i3d.net>
Date: Mon, 16 Jan 2017 13:42:07 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0
MIME-Version: 1.0
In-Reply-To: <alpine.WNT.2.00.1701152315390.14048@mw-PC>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/grow/OR3cTvzjgHSVxRe_wzNLdsG4zvY>
Cc: sidrops@ietf.org, GMO Crops <grow@ietf.org>, job@ntt.net
Subject: Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidrops-route-server-rpki-light-00.txt
X-BeenThere: grow@ietf.org
X-Mailman-Version: 2.1.17
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: Mon, 16 Jan 2017 12:45:40 -0000
Hi all, Invalid is invalid: it means that someone is hijacking the prefix, because the owner of the resource is telling us through RPKI that the route should be originated by a different ASN. If your BGP implementation is able to detect that it should not propagate the hijacked route. If your BGP implementation is not able to understand RPKI (hi Brocade), then it would be nice to receive at least some form of protection via the route-server if you choose to use it. The argument that it should just be another parameter for the best path election on the route-server is weak at best, many networks wouldn't advertise their valid prefix with correct origin to that specific route-server - or not to any route-server at all. And that'd automatically mean that the invalid prefix is going to be propagated by the route-server.. which is undesirable. Best regards, Martijn Schmidt On 01/16/2017 12:03 AM, Matthias Waehlisch wrote: > I don't know if we are losing sight. The argument that RS is doing best > path selection was stated several times. > > However, I still don't buy the argument "route servers and rpki are an > uncomfortable fit." > > I buy the argument that fine-grained policy configuration challenges RS > operation. And for sure the principle is indepdent of RPKI. In the most > boring case, the decision results in "Prefer the route received from the > lowest peer address." Ups, is this the IP address of the peering LAN, > given by the IXP. > > What is specific to RPKI is proxying of security-related meta data > (i.e., easier deployment of new protocols via RS). > > For example, in the case of policy prefer-valid-over-invalid AND there > is no valid, RS would announce the (invalid) prefix to peer P. P also > established private peering and receives announcement for the invalid > prefix. Without deploying RPKI, this BGP speaker could benefit from RS > meta data, dropping both. > > > > Cheers > matthias > > On Sat, 14 Jan 2017, Nick Hilliard wrote: > >> Matthias Waehlisch wrote: >>> the current discussion makes clear that documentation of >>> origin-validation-signaling in IXP context is needed >> rpki is conceptually no different to any other type of signaling >> mechanism: it's simply another input into the BGP decision engine >> process, just like communities or meds or as-path. >> >> What we're losing sight of here is that it's the route server which >> calculates the best path for each route using the routing decision >> engine, and then sends a _single_ best path to the client. Conceptually, >> it doesn't matter whether the tie-breaker on the route server is >> communities, meds, as-path or rpki: the point is that the policy >> decision mechanism needs to be configured on the route server itself, >> because the route server is the device which is calculating the best >> path. If the route server operator doesn't do this, the clients will >> end up with path hiding (see 2.3.1 in rfc7947). I.e. it's nothing >> specific to rpki. >> >> This is already extensively documented in rfc7947 and rfc7948. >> >> Nick >> >
- Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidro… job
- Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidro… Randy Bush
- Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidro… Marco Marzetti
- Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidro… Christopher Morrow
- Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidro… Marco Marzetti
- Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidro… joel jaeggli
- Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidro… Nick Hilliard
- Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidro… Christopher Morrow
- Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidro… Job Snijders
- Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidro… joel jaeggli
- Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidro… Jakob Heitz (jheitz)
- Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidro… Randy Bush
- Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidro… Jakob Heitz (jheitz)
- Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidro… Matthias Waehlisch
- Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidro… Nick Hilliard
- Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidro… Nick Hilliard
- Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidro… Marco Marzetti
- Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidro… Marco Marzetti
- Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidro… Nick Hilliard
- Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidro… Matthias Waehlisch
- Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidro… Marco Marzetti
- Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidro… Christopher Morrow
- Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidro… joel jaeggli
- Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidro… Nick Hilliard
- Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidro… Randy Bush
- Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidro… Marco Marzetti
- Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidro… Marco Marzetti
- Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidro… Job Snijders
- Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidro… Marco Marzetti
- Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidro… Matthias Waehlisch
- Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidro… i3D.net - Martijn Schmidt
- Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidro… joel jaeggli
- Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidro… Marco Marzetti