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 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. > 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. 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. > Regards > > > On Fri, Jan 13, 2017 at 11:28 PM, joel jaeggli <joe...@bogus.com> wrote: >> On 1/13/17 1:54 PM, Marco Marzetti 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> >>> >>> 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. >> 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. >>> 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 <ra...@psg.com> wrote: >>>>> 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 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. :) >>>> >>>> _______________________________________________ >>>> GROW mailing list >>>> GROW@ietf.org >>>> https://www.ietf.org/mailman/listinfo/grow >>> >>> >> >> > > >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
