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

From: [email-masked]
Date: Fri, 13 Jan 2017 21:52:54 +0100

Adding [email-masked] for reality check.

On 13 Jan 2017, 21:19 +0100, Carlos M. Martinez <[email-masked]>, 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 be delegated as far away from the network´s core as possible.
>
>
> -Carlos
>
>
> On 13 Jan 2017, at 17:13, [email-masked] wrote:
>
>
> > I am advocating a strong security posture, in which each ASN takes their responsibility to the best of their abilities in maintaining a healthy global routing system. KNOWINGLY distributing routes which are considered Invalid is the wrong thing to do.
> >
> > If an ASN (read Route Server) doesn't want to participate in keeping the routing system clean, they should perhaps consider ceasing their BGP operations, but certainly not hide under the guise of "offering customers all options".
> >
> > An autonomous system is an autonomous system. IXP operators do not get a free pass to propagate garbage, the same garbage we expect the rest of the operators to reject.
> >
> > This draft promotes an insecure mode of operation.
> >
> > Kind regards,
> >
> > Job
> >
> >
> >
> > On 13 Jan 2017, 20:57 +0100, Carlos M. Martinez <[email-masked]>, wrote:
> > > Hi Job,
> > >
> > > I believe what what you propose would be deciding on behalf of people
> > > who are not your customers and with whom you only have a loose
> > > relationship based on sharing something. I don´t think a route server
> > > should in fact drop invalid routes when re-announcing them to the other
> > > peers.
> > >
> > > I understand that this could be different depending on the arrangements
> > > among members of the IXP, but, I like to have the option for marking
> > > open.
> > >
> > > Cheers!
> > >
> > > -Carlos
> > >
> > > On 13 Jan 2017, at 15:40, Job Snijders wrote:
> > >
> > > > Hi all,
> > > >
> > > > I have trouble with the idea proposed in this draft. It reads to me
> > > > "When the route server receives a hijacked prefix, it will decorate it
> > > > with an extended community and propagate it to all its peers".
> > > >
> > > > This is not a responsible thing to do. Route Server operators should
> > > > configure there route servers to reject/drop/ignore 'RPKI invalid'
> > > > announcements, and thats should be the end of it.
> > > >
> > > > Kind regards,
> > > >
> > > > Job
> > > >
> > > > On Fri, Jan 13, 2017 at 10:28:24AM -0800, [email-masked]
> > > > wrote:
> > > > >
> > > > > A New Internet-Draft is available from the on-line Internet-Drafts
> > > > > directories.
> > > > > This draft is a work item of the SIDR Operations of the IETF.
> > > > >
> > > > > Title : Signaling Prefix Origin Validation Results
> > > > > from a Route-Server to Peers
> > > > > Authors : Thomas King
> > > > > Daniel Kopp
> > > > > Aristidis Lambrianidis
> > > > > Arnaud Fenioux
> > > > > Filename : draft-ietf-sidrops-route-server-rpki-light-00.txt
> > > > > Pages : 6
> > > > > Date : 2017-01-13
> > > > >
> > > > > Abstract:
> > > > > This document defines the usage of the BGP Prefix Origin
> > > > > Validation
> > > > > State Extended Community
> > > > > [I-D.ietf-sidr-origin-validation-signaling]
> > > > > to signal prefix origin validation results from a route-server to
> > > > > its
> > > > > peers. Upon reception of prefix origin validation results peers
> > > > > can
> > > > > use this information in their local routing decision process.
> > > > >
> > > > >
> > > > >
> > > > > The IETF datatracker status page for this draft is:
> > > > > https://datatracker.ietf.org/doc/draft-ietf-sidrops-route-server-rpki-light/
> > > > >
> > > > > There's also a htmlized version available at:
> > > > > https://tools.ietf.org/html/draft-ietf-sidrops-route-server-rpki-light-00
> > > > >
> > > > >
> > > > > Please note that it may take a couple of minutes from the time of
> > > > > submission
> > > > > until the htmlized version and diff are available at tools.ietf.org.
> > > > >
> > > > > Internet-Drafts are also available by anonymous FTP at:
> > > > > ftp://ftp.ietf.org/internet-drafts/
> > > > >
> > > > > _______________________________________________
> > > > > Sidrops mailing list
> > > > > [email-masked]
> > > > > https://www.ietf.org/mailman/listinfo/sidrops
> > > >
> > > > _______________________________________________
> > > > Sidrops mailing list
> > > > [email-masked]
> > > > https://www.ietf.org/mailman/listinfo/sidrops
> > >
> > > _______________________________________________
> > > Sidrops mailing list
> > > [email-masked]
> > > https://www.ietf.org/mailman/listinfo/sidrops
> _______________________________________________
> Sidrops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidrops

---

From: Randy Bush <[email-masked]>
Date: Sat, 14 Jan 2017 06:20:16 +0900

> Adding [email-masked] 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 might tell the server to drop invalids.  if i do not take that
(configurable, i presume) option, having the server mark them seems
helpful.

randy

--

0 - i suspect none of job, carlos, or i do.  so this is the experts
    telling other people what they should do. :)

---

From: Marco Marzetti <[email-masked]>
Date: Fri, 13 Jan 2017 22:54:55 +0100

<rant>
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?
</rant>

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 invalid the owner requested it to be verified
by the other parties.

I suggest to default to drop and, if possible, to switch to announce
with community if the peer requests it (for instance someone may want
to collect invalid routes for analysis).

On Fri, Jan 13, 2017 at 10:20 PM, Randy Bush <[email-masked]> wrote:
> GROW mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/grow

-- 
Marco

---

From: Christopher Morrow <[email-masked]>
Date: Fri, 13 Jan 2017 17:05:09 -0500

> After all if a prefix is invalid the owner requested it to be verified
I think part of job's point (and randy's in a way) is that you actually
don't know if:
  192.168.0.0/23 AS1 AS3 AS8

is valid, even if you see a ROA:
192.168.0.0/16 AS8 max-len /23

... because there's nothing that keeps AS-ME from sending AS-JOB a route
with AS8 prepended on the as-path.

> to collect invalid routes for analysis).
i think you are describing implementations that the IXP may choose... I
don't know that this draft needs to specify that at all.

-chris

---

From: Marco Marzetti <[email-masked]>
Date: Fri, 13 Jan 2017 23:22:36 +0100

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? In that case i apologize.

About the forged AS_PATHs: why is this important only when it comes to IXPs?

Regards

-- 
Marco

---

From: joel jaeggli <[email-masked]>
Date: Fri, 13 Jan 2017 14:28:23 -0800

> After all if a prefix is invalid the owner requested it to be verified
In general the consequences for IX operator that either allows it
customers to attack each other over the exchange route-server or does so
itself seems severe. Loss of confidence in the disposition of one's own
routes seems like immediate grounds for depeering. If the routes remain
afterwards with the short as path; the operator is engaged in prefix
hijakcing.

I personally find it dubious that I would choose to honor a third
parties efforts at origin validation if I did not myself validate them
but a signal from the exchange that it did validate the origin or that
there an invalid roa floating around is at a minimum very interesting.

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 13 Jan 2017 22:51:55 +0000

> Adding [email-masked] for reality check.

We live in a post-truth world.

On a more serious note, this draft is the wrong way around and this
probably means it's not operationally useful in most cases.

Let's say there's a route server R with clients A, B and C.  Clients A
and B announce a prefix, the intention being that the route server will
propagate this to C.  The route server will inject both prefixes into
client C's Loc-RIB, and will then run the routing decision engine on
that Loc-RIB.  The best path will be computed and the result will be
sent to C.

If this draft is implemented the way it's stated, and client A injects a
prefix which is has a valid rpki signature, and client B illegitimately
injects the same prefix with an attribute set which ensures that it's
the preferred prefix (doesn't matter whether it's signed or not), then
the RDE will run and will unilaterally prefer the prefix from client B,
ignoring the signed prefix from client A.  Client C will receive the
hijacked prefix.  Not good.

Or assume that client A injects a prefix which has an invalid rpki
signature, and client B legitimately injects the same prefix with an
attribute set which ensures that it's not the preferred prefix (again,
it doesn't matter whether it's signed or not), the prefix from client A
will be preferred in client C's Loc-RIB.  If client C drops invalid
prefixes, then the route server R has contributed to path hiding (see
rfc7947).

In both these cases, and some other easily identifiable situations, the
draft as stated contributes to topologically surprising results which
wouldn't necessarily be what any of clients A, B or particularly C might
expect or want.

There are two ways to fix this:

1. either this draft should mandate that add-path must be used for tx
from the point of view of the route server.  This is not operationally
very useful because most clients and many route servers don't support
ebgp add path, either due to policy or technical limitations.

2. by far the easiest and best way to solve this particular problem
would be for the IXP operator to allow the IXP participants to specify
how to handle rpki-signed prefixes for their route server configs.  You
would need two binary tickboxes in the IXP's provisioning system: drop
or don't drop notfound, and drop or don't drop invalid.  I would assume
that there's no requirement for the same sort of tickbox for valid
prefixes.  If the IXP operator implemented this, then the Adj-RIB-In to
Loc-RIB-out prefix filter would be able to make a decision about whether
to accept or drop the RPKI notfound/invalid prefixes on a per client
basis, which is what IXP route server client operators would want and
expect.

Obviously, this is a local IXP provisioning system issue, and it would
be up to the IXP as to how to implement it, i.e. allow the customer to
modify this themselves using a portal, or raise a ticket with the IXP
support desk.  Consequently, as this is not an problem which would be
best solved by the IETF, I'd suggest it would be better for this draft
not to progress further.

Nick

---

From: Christopher Morrow <[email-masked]>
Date: Fri, 13 Jan 2017 17:53:51 -0500

> Am i wrong? In that case i apologize.

it actually, I think , just says: "put a community that can be interpreted
as valid/invalid/etc"

I don't know that you'd want an RS keeping information from you, as a
downstream of that RS, would you? I'd rather see the things so I can decide
what's best for me.

I think because this seems like a 'per network' or 'per ixp' concept, let's
let the document not define the implementation, but just the capability.

> About the forged AS_PATHs: why is this important only when it comes to
I don't think it is.

---

From: Job Snijders <[email-masked]>
Date: Fri, 13 Jan 2017 23:53:58 +0100

On Fri, Jan 13, 2017 at 02:28:23PM -0800, joel jaeggli wrote:
> > days arguing if it affects the neutrality and how. Do we really
> > need that?
> > </rant>
> >
> > 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 invalid the owner requested it to be
> > verified by the other parties.
>
> customers to attack each other over the exchange route-server or does
> so itself seems severe. Loss of confidence in the disposition of one's
> own routes seems like immediate grounds for depeering. If the routes
> remain afterwards with the short as path; the operator is engaged in
> prefix hijakcing.
> 

I still don't understand how there can be a justification as to why it
would be OK for route servers to redistribute poisonous routes and say
"trust me its OK i added a community!", and we expect some different
behaviour from 'the rest of the AS's'?

In a case like this http://mailman.nanog.org/pipermail/nanog/2017-January/089823.html,
assuming a ROA had existed for 206.125.164.0/22, what would've been the
appropiate response from any AS involved (including route servers)?

    A) "its fine, i tagged it with a community and amplified the problem
    by propagating it to all my peers"

    B) "the buck stops with me, the invalid route will not be propagated by me"

At the very least, i'd prefer the default mode should be a secure mode,
not a 'scientifically interesting' mode.

Kind regards,

Job

---

From: joel jaeggli <[email-masked]>
Date: Fri, 13 Jan 2017 15:09:47 -0800

> not a 'scientifically interesting' mode.
I do wonder about the rational for saying "this is invalid, but here you 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.

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Sat, 14 Jan 2017 03:04:48 +0000

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 legitimate AS, then his AS-PATH will
be longer than that of the legitimate route in the large majority of the Internet.
But only if each AS that registers a ROA advertises every prefix matched by the ROA.
If it does not, then another AS can easily steal the prefix like you said.

If you need to protect a prefix that you don't advertise then put ASN 0 into the ROA for it.
Then nobody can advertise it.

Thanks,
Jakob.

From: Sidrops [mailto:[email-masked]] On Behalf Of Christopher Morrow
Sent: Friday, January 13, 2017 2:05 PM
To: Marco Marzetti <[email-masked]>
Cc: Randy Bush <[email-masked]>; [email-masked]; GMO Crops <[email-masked]>; Job Snijders <[email-masked]>
Subject: Re: [Sidrops] [GROW] I-D Action: draft-ietf-sidrops-route-server-rpki-light-00.txt

On Fri, Jan 13, 2017 at 4:54 PM, Marco Marzetti <[email-masked]<mailto:[email-masked]>> wrote:
<rant>
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?
</rant>

I think part of job's point (and randy's in a way) is that you actually don't know if:
  192.168.0.0/23<http://192.168.0.0/23> AS1 AS3 AS8

is valid, even if you see a ROA:
192.168.0.0/16<http://192.168.0.0/16> AS8 max-len /23

... because there's nothing that keeps AS-ME from sending AS-JOB a route with AS8 prepended on the as-path.

i think you are describing implementations that the IXP may choose... I don't know that this draft needs to specify that at all.

-chris

On Fri, Jan 13, 2017 at 10:20 PM, Randy Bush <[email-masked]<mailto:[email-masked]>> wrote:
>> Adding [email-masked]<mailto:[email-masked]> for reality check.
>
> no comment :)
>
> [email-masked]<mailto:[email-masked]>

--
Marco

_______________________________________________
GROW mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/grow

---

From: Randy Bush <[email-masked]>
Date: Sat, 14 Jan 2017 12:08:02 +0900

> If you need to protect a prefix that you don't advertise then put ASN
> 0 into the ROA for it.  Then nobody can advertise it.

not exactly.  someone (with credentials) can issue a roa for the same
prefix to as 42, and it will validate the origination.  there can be
many roas which match a single announcement; all it takes is one to be
valid.

randy

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Sat, 14 Jan 2017 03:15:49 +0000

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:[email-masked]]
> Sent: Friday, January 13, 2017 7:08 PM
> To: Jakob Heitz (jheitz) <[email-masked]>
> Cc: Christopher Morrow <[email-masked]>; Marco Marzetti <[email-masked]>; [email-masked]; GMO
> Crops <[email-masked]>; Job Snijders <[email-masked]>

---

From: Matthias Waehlisch <[email-masked]>
Date: Sat, 14 Jan 2017 11:22:14 +0100

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 that the RS selects the best path on behalf 
of the client), the IXP provisioning system needs to provide all knobs 
to implement potential policies -- as you mentioned below. Should be s 
side note.

  In case (2), route-server-rpki-light would be still helpful.

  Maybe this should be clarified in route-server-rpki-light.

Cheers
  matthias

-- 
Matthias Waehlisch
.  Freie Universitaet Berlin, Computer Science
.. http://www.cs.fu-berlin.de/~waehl

---

From: Nick Hilliard <[email-masked]>
Date: Sat, 14 Jan 2017 10:42:28 +0000

Christopher Morrow wrote:
> downstream of that RS, would you? I'd rather see the things so I can
> decide what's best for me.

Chris, this is not how route servers work.

What you're suggesting will only work if the route server implements
add-path tx, allowing the client to receive all the candidate prefixes
for a particular route, not just the calculated best path.

In practice, what happens is that the route server calculates the best
path on a per-client basis and sends the best path to the client rather
than all the candidate paths.  In order to do this, the route server
needs to be configured so that the BGP decision process knows whether to
take the rpki-invalid or rpki-unknown prefixes into account when
calculating the best path for each client's Loc-RIB.  This configuration
needs to be done on the route server in advance, and on a per-client
basis, and can only be handled properly by config flags in the IXP
provisioning system.

> I think because this seems like a 'per network' or 'per ixp' concept,
> let's let the document not define the implementation, but just the
> capability.

This is the wrong way to solve this particular problem.  It's a local
IXP provisioning system flag, not an ietf issue.

Nick

---

From: Nick Hilliard <[email-masked]>
Date: Sat, 14 Jan 2017 10:56:15 +0000

>   In case (2), route-server-rpki-light would be still helpful.

Case (1) is not an ietf problem.

Case (2) is already documented in
draft-ietf-sidr-origin-validation-signaling, which proposes a generic
BGP signaling mechanism, i.e. nothing particularly to do with route
servers.  In fact, if the -sidr- draft progresses, it should probably be
mentioned somewhere that the proposed mechanism is likely to cause
unexpected behaviour on route servers unless add-path tx is enabled on
the route server.

Nick

---

From: Marco Marzetti <[email-masked]>
Date: Sat, 14 Jan 2017 12:58:14 +0100

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

-- 
Marco

---

From: Marco Marzetti <[email-masked]>
Date: Sat, 14 Jan 2017 13:03:56 +0100

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

-- 
Marco

---

From: Nick Hilliard <[email-masked]>
Date: Sat, 14 Jan 2017 15:06:16 +0000

> 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 list of things that are taken
into account for the best path calculation, which means that there is a
genuine difficulty in providing enough fine-grained levers so that the
route server can handle this in a way that works well for clients.

As others have pointed out, the control mechanisms that rpki allows are
much easier to handle on bilateral bgp sessions than multilateral.

These problems mostly disappear if the route server and client use
add-path, because that shifts the burden of handling the policy
application fully to the client.  Where add-path is used, there is no
requirement to mark routes with communities firstly because no routing
policy action has been taken by the route server and secondly because
the client can check the ROA themselves.  The usual caveats about
add-path apply.

Stepping back a bit, most organisations who use route servers are
sufficiently small that they don't need anything more than highly
simplistic exterior routing policies, where almost everything is handled
by the default bgp decision process documented in rfc4271, and final
tweaks are handled by applying a single med or localpref for all peers
or all transits or whatever.  This is the category of ASNs that route
servers work best for. Once an organisation grows beyond a certain size,
it's quite usual to move away from using route servers - and at a later
stage still, to move away from using IXPs in favour of PNIs.

If an organisation's routing policies are more complicated than most,
then route servers are generally unsuitable anyway.  RPKI will reduce
that boundary of suitability, but not by much.  I'd hazard a guess that
if an IXP were to provide a primitive facility in their provisioning
system to allow clients to specify whether they wanted rpki-invalid or
rpki-notfound dropped or used in the decision engine, that would satisfy
most route server client organisations' policy requirements.  Obviously
this is not going to work for all organisations, but adding in more
fine-grained controls runs into diminishing returns very quickly indeed,
as has been implicitly noted in the ixp industry by the scarcity of
generally accepted policy controls outside the usual "redistribute or
don't redistribute my prefixes to ASN X" community tags.

If AS path validation ever happens, then this probably not work with
route servers at all, but that's a different thing, outside the scope of
this conversation.

Nick

---

From: Matthias Waehlisch <[email-masked]>
Date: Sat, 14 Jan 2017 16:30:09 +0100

> unexpected behaviour on route servers unless add-path tx is enabled on
  the current discussion makes clear that documentation of 
origin-validation-signaling in IXP context is needed, either in 
sidr-origin-validation-signaling or in a separate document such as 
route-server-rpki-light. Personally, I tend to a separate doc 
(informational or best practice).

Cheers
  matthias

---

From: Marco Marzetti <[email-masked]>
Date: Sat, 14 Jan 2017 16:49:02 +0100

Nick,

You know the IXPs's world better then me so i take your analysis as valid.

But there's something that i would like to point out.
The concept of IXP has changed and we cannot longer consider them as
simple LANs run on top of a bunch of switches.
Of course there are small entities that fit into the original
definition, but there are also *very* large networks that move your
packets between distant locations over MPLS.
And that's much like what transit networks do.

So i can't understand why we should not encourage (in a very strong
way) RSs to run RPKI.
That doesn't mean the RS MUST drop the prefixes: They should lower the
LOCAL_PREF and as Joel has suggested add a prepend (or 2 or 3).

Regards

-- 
Marco

---

From: Christopher Morrow <[email-masked]>
Date: Sat, 14 Jan 2017 12:19:00 -0500

backup up a tad... somehow *(probably late-work-night clicking) I added
joel/marco to the 'reject mail' list :( (note that both are now subscribed
to the list.. if you do not want that you should go unsubscribe)

I'm sorry there were 4 messages, copied here, which didn't make it to
sidrops@

---------------- msg 1 --------------------

On 1/13/17 2:53 PM, Job Snijders wrote:
> In a case like this
http://mailman.nanog.org/pipermail/nanog/2017-January/089823.html,

---------------- end msg 1 -----------------------
---------------- msg 2 -----------------------------

From: Marco Marzetti <[email-masked]>
Subject: Re: [GROW] [Sidrops] I-D Action:
draft-ietf-sidrops-route-server-rpki-light-00.txt
To: joel jaeggli <[email-masked]>
Cc: Randy Bush <[email-masked]>, [email-masked], GMO Crops <[email-masked]>,
 Job Snijders <[email-masked]>
Date: Sat, 14 Jan 2017 12:58:14 +0100

Joel,

Regards

--------------- end msg 2 ----------------------
-------------- msg 3 -----------------------------
From: Marco Marzetti <[email-masked]>
Subject: Re: [GROW] [Sidrops] I-D Action:
draft-ietf-sidrops-route-server-rpki-light-00.txt
To: Christopher Morrow <[email-masked]>
Cc: Randy Bush <[email-masked]>, [email-masked], GMO Crops <[email-masked]>,
 Job Snijders <[email-masked]>
Date: Sat, 14 Jan 2017 13:03:56 +0100

Christopher,

Regards

--------------- end msg 3 ---------------------
--------------- msg 4 ---------------------------
From: Marco Marzetti <[email-masked]>
Subject: Re: [GROW] [Sidrops] I-D Action:
draft-ietf-sidrops-route-server-rpki-light-00.txt
To: Nick Hilliard <[email-masked]>
Cc: Christopher Morrow <[email-masked]>, [email-masked],
 GMO Crops <[email-masked]>, Job Snijders <[email-masked]>
Date: Sat, 14 Jan 2017 16:49:02 +0100

Nick,

Regards

---

From: joel jaeggli <[email-masked]>
Date: Fri, 13 Jan 2017 15:09:47 -0800

---

From: joel jaeggli <[email-masked]>
Date: Sat, 14 Jan 2017 12:10:37 -0800

> 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  device an
"upstream" it exists to service the policy needs of the peers on the
fabric  rather than that of the exchange operator.

I would  expect that a ixp route server that had a state policy of
validating rpki would not propagate invalid routes.

> prefix/path validation by yourself.

No, I setup bilateral peering arrangements because they actually load
balance to my multiple ports, because the loci of control is
unambiguous, because it facilitates greatly build per session prefix
filters, and because they converge the control and forwarding path,
which has a tendency to fail much more gracefully in the face of l2
failures in distributed exchange fabric designs then does the route-server.

---

From: Nick Hilliard <[email-masked]>
Date: Sat, 14 Jan 2017 21:53:45 +0000

Matthias Waehlisch wrote:
> 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

---

From: Randy Bush <[email-masked]>
Date: Sun, 15 Jan 2017 09:32:22 +0900

[ 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. ]

> fabric  rather than that of the exchange operator.

to repeat my previous; those policy needs might vary across ix members.
some may want the ix to enforce origin validation for them, some may
not.  those exchanges which offer validation today offer the choice.  i
think that is the right thing; let the member make the choice at set-up
with the route server.

> failures in distributed exchange fabric designs then does the

there's a draft for that :)

randy

---

From: Marco Marzetti <[email-masked]>
Date: Sun, 15 Jan 2017 15:35:56 +0100

> fabric  rather than that of the exchange operator.

You can easily do the same in transit providers by disabling next-hop-self.

> failures in distributed exchange fabric designs then does the route-server.

Aren't we saying the same thing?
Bilateral peering brings more control over what you send and receive.

I just take an additional step and say that RPKI should be part of the
default decision process of RSs

Regards.

-- 
Marco

---

From: Marco Marzetti <[email-masked]>
Date: Sun, 15 Jan 2017 15:39:37 +0100

> think that is the right thing; let the member make the choice at set-up

I think RSs should do RPKI by default and allow for two behaviors:
1) Drop (default)
2) Add ext-community as this draft suggests (upon request)

Regards
-- 
Marco

---

From: Job Snijders <[email-masked]>
Date: Sun, 15 Jan 2017 15:49:43 +0100

> 2) Add ext-community as this draft suggests (upon request)

Or perhaps we consider a Route Server to be "Just Yet Another Autonomous
System"? Why should there be a difference between Autonomous Systems
with regard to routing security recommendations?

If the recommendation is to drop/ignore/reject "RPKI Invalid"
announcements, then that applies to Route Servers too, if the
recommendation is to just attach an Extended BGP Community, then that
will apply to all ASNs.

Kind regards,

Job

---

From: Marco Marzetti <[email-masked]>
Date: Sun, 15 Jan 2017 16:03:48 +0100

> with regard to routing security recommendations?

I do consider it "another AS".

> recommendation is to just attach an Extended BGP Community, then that

What's the current recommendation now?

Regards

-- 
Marco

---

From: Matthias Waehlisch <[email-masked]>
Date: Mon, 16 Jan 2017 00:03:40 +0100

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

---

From: "i3D.net - Martijn Schmidt" <[email-masked]>
Date: Mon, 16 Jan 2017 13:42:07 +0100

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

---

From: joel jaeggli <[email-masked]>
Date: Mon, 16 Jan 2017 15:10:42 -0800

> You can easily do the same in transit providers by disabling next-hop-self.

Nope, The router expressing nexthop self retains the available nexthops.
Under no circumstance is the router-server in the forwarding path, were
it, the route-server would be an upstream.

>>> prefix/path validation by yourself.

Consider the case where the invalid route masks an valid but longer path
from being advertised via the route server as the best path. in that
case the validating route-server is facilitating a prefix hijacking
which it would not have, had it discarded the route. You might argue
that this is no worse than not validating, however I think that is a
somewhat dubious point given that the rib on the route-server would show
otherwise.

> Bilateral peering brings more control over what you send and receive.

we have a similar concurrence respecting the advantages. We appear to
differ on whether the route server offering a feature or not confers a
similar outcome.

> default decision process of RSs

To confer the advantage you need to not allow invalid routes into your
best path selection processing.

---

From: Marco Marzetti <[email-masked]>
Date: Tue, 17 Jan 2017 15:05:20 +0100

> it, the route-server would be an upstream.

That;s correct.
But is the specific device really relevant?

I mean: you send your traffic to another network's forwarding plane.
Do you really care about the role of the devices your packets pass through?

> somewhat dubious point given that the rib on the route-server would show

I argue that the same could happen with transit and we would consider it legit.
Why?

> best path selection processing.

Again, I really do think that the same logic of transit applies here.

Regards

-- 
Marco