Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidrops-route-server-rpki-light-00.txt

On Tue, Jan 17, 2017 at 12:10 AM, joel jaeggli wrote: > On 1/15/17 6:35 AM, Marco Marzetti wrote: >> On Sat, Jan 14, 2017 at 9:10 PM, joel jaeggli wrote: >>> On 1/14/17 3:58 AM, Marco Marzetti wrote: Joel, So you don't want your upstreams to

Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidrops-route-server-rpki-light-00.txt

On 1/15/17 6:35 AM, Marco Marzetti wrote: > On Sat, Jan 14, 2017 at 9:10 PM, joel jaeggli wrote: >> On 1/14/17 3:58 AM, Marco Marzetti wrote: >>> Joel, >>> >>> So you don't want your upstreams to honor RPKI just because they're >>> 3rd parties between you and the other end? >>

Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidrops-route-server-rpki-light-00.txt

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

Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidrops-route-server-rpki-light-00.txt

On Sun, Jan 15, 2017 at 3:49 PM, Job Snijders wrote: > On Sun, Jan 15, 2017 at 03:39:37PM +0100, Marco Marzetti wrote: >> On Sun, Jan 15, 2017 at 1:32 AM, Randy Bush wrote: >> > [ first, i do not use route serves (because of the data/control non- >> >

Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidrops-route-server-rpki-light-00.txt

On Sun, Jan 15, 2017 at 03:39:37PM +0100, Marco Marzetti wrote: > On Sun, Jan 15, 2017 at 1:32 AM, Randy Bush wrote: > > [ first, i do not use route serves (because of the data/control non- > > congruence), so my opinion here is worth even less than it normally > > is. ] > > >

Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidrops-route-server-rpki-light-00.txt

On Sun, Jan 15, 2017 at 1:32 AM, Randy Bush wrote: > [ first, i do not use route serves (because of the data/control non- > congruence), so my opinion here is worth even less than it normally > is. ] > >> An ixp route-server is not a transit provider, all of the nexthops >>

Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidrops-route-server-rpki-light-00.txt

On Sat, Jan 14, 2017 at 9:10 PM, joel jaeggli wrote: > On 1/14/17 3:58 AM, Marco Marzetti wrote: >> Joel, >> >> So you don't want your upstreams to honor RPKI just because they're >> 3rd parties between you and the other end? > > An ixp route-server is not a transit provider,

Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidrops-route-server-rpki-light-00.txt

[ first, i do not use route serves (because of the data/control non- congruence), so my opinion here is worth even less than it normally is. ] > An ixp route-server is not a transit provider, all of the nexthops > exposed are in fact peers. So no I do not consider such a device an >

Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidrops-route-server-rpki-light-00.txt

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

Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidrops-route-server-rpki-light-00.txt

On 1/14/17 3:58 AM, Marco Marzetti wrote: > Joel, > > So you don't want your upstreams to honor RPKI just because they're > 3rd parties between you and the other end? An ixp route-server is not a transit provider, all of the nexthops exposed are in fact peers. So no I do not consider such a

Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidrops-route-server-rpki-light-00.txt

go" if I'm validating ROAs and my posture is that I don't accept routes with invalid ROAS then I'm not taking any action on the basis of this community. If I don't validate, I'm not taking any action on the basis of this community. > Kind regards, > > Job > e

Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidrops-route-server-rpki-light-00.txt

On Sat, 14 Jan 2017, Nick Hilliard wrote: > Matthias Waehlisch wrote: > > I think there are two cases: (1) RS client peers only with route > > server, (2) RS client peers additionally with other BGP speakers that > > don't peer with the RS. > > > > In case (1) (and assuming that the RS

Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidrops-route-server-rpki-light-00.txt

Marco Marzetti wrote: > Why RPKI can't be part of that? tl;dr: route servers and rpki are an uncomfortable fit. rpki can be part of that, but it's problematic because the route server is running the routing decision engine on the part of the client. RPKI is a relatively fine-grained tool in the

Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidrops-route-server-rpki-light-00.txt

Christopher, As Nick has already pointed out as soon as you peer with the RS you've already delegated some part of the decision process to the IXP. Why RPKI can't be part of that? After all there are IXPs that filter advertisements not covered by IRR route objects. Regards On Fri, Jan 13,

Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidrops-route-server-rpki-light-00.txt

Joel, So you don't want your upstreams to honor RPKI just because they're 3rd parties between you and the other end? In the context of IXPs: instead of peering with the RS you should setup direct sessions with your partners if you really want to do prefix/path validation by yourself. Regards

Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidrops-route-server-rpki-light-00.txt

Hi Nick, interesting. You are arguing who is doing the best path selection for a specific prefix. I think there are two cases: (1) RS client peers only with route server, (2) RS client peers additionally with other BGP speakers that don't peer with the RS. In case (1) (and assuming

Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidrops-route-server-rpki-light-00.txt

With credentials. Surely if you own the prefix, then you have power over those with credentials and the ability to remove all ROAs for it that point to as 42. Thanks, Jakob. > -Original Message- > From: Randy Bush [mailto:ra...@psg.com] > Sent: Friday, January 13, 2017 7:08 PM > To:

Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidrops-route-server-rpki-light-00.txt

That's path validation. Anyway, the diameter of the Internet is only about 4 to 5 AS hops. Tier 1's only care about the radius, which is mostly 1, 2 or 3 AS hops. Given such short AS paths, RPKI can provide a good level of protection already. If the attacker originates a route prepended by the

Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidrops-route-server-rpki-light-00.txt

On Fri, Jan 13, 2017 at 02:28:23PM -0800, joel jaeggli wrote: > On 1/13/17 1:54 PM, Marco Marzetti wrote: > > > > Every time one suggests a change related to the IXPs world we spend > > days arguing if it affects the neutrality and how. Do we really > > need that? > > > > > > Anyway, i can't see

Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidrops-route-server-rpki-light-00.txt

On Fri, Jan 13, 2017 at 5:22 PM, Marco Marzetti wrote: > Christopher, > > I have to admit that i am not aware of the ongoing work on sidrops, so > i may lack the needed background, but this draft only suggests to > re-advertise all the prefixes. No matter what. > Am i wrong?

Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidrops-route-server-rpki-light-00.txt

On 1/13/17 1:54 PM, Marco Marzetti wrote: > > Every time one suggests a change related to the IXPs world we spend > days arguing if it affects the neutrality and how. > Do we really need that? > > > Anyway, i can't see why IXPs can blackhole traffic (if the destination > requests it), but cannot

Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidrops-route-server-rpki-light-00.txt

On Fri, Jan 13, 2017 at 4:54 PM, Marco Marzetti wrote: > > Every time one suggests a change related to the IXPs world we spend > days arguing if it affects the neutrality and how. > Do we really need that? > > > Anyway, i can't see why IXPs can blackhole traffic (if the

Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidrops-route-server-rpki-light-00.txt

Every time one suggests a change related to the IXPs world we spend days arguing if it affects the neutrality and how. Do we really need that? Anyway, i can't see why IXPs can blackhole traffic (if the destination requests it), but cannot do the same with prefixes. After all if a prefix is

Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidrops-route-server-rpki-light-00.txt

> Adding grow@ietf.org for reality check. no comment :) when you choose to use a route server [0], you have out-sourced much of your policy and operational responsibilities. seems to me that whether this includes security decisions is a contract between the user and the route server. so i

Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidrops-route-server-rpki-light-00.txt

Adding grow@ietf.org for reality check. On 13 Jan 2017, 21:19 +0100, Carlos M. Martinez , wrote: > > We agree to disagree then. I strongly believe the Internet strives to > delegate decision making and doesn’t like hierarchies very much. > > > I’d prefer these decisions to