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 > >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
