On Sat, Jan 14, 2017 at 9:10 PM, joel jaeggli <[email protected]> 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, 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. >
You can easily do the same in transit providers by disabling next-hop-self. > 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. > 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. >> Regards >> >> >> On Fri, Jan 13, 2017 at 11:28 PM, joel jaeggli <[email protected]> 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 <[email protected]> wrote: >>>>>> Adding [email protected] 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 >>>>> [email protected] >>>>> https://www.ietf.org/mailman/listinfo/grow >>>> >>>> >>> >>> >> >> >> > > -- Marco _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
