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, 2017 at 11:53 PM, Christopher Morrow <[email protected]> wrote: > > > On Fri, Jan 13, 2017 at 5:22 PM, Marco Marzetti <[email protected]> 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? 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 >> IXPs? >> > > I don't think it is. > >> >> Regards >> >> >> On Fri, Jan 13, 2017 at 11:05 PM, Christopher Morrow >> <[email protected]> wrote: >> > >> > >> > On Fri, Jan 13, 2017 at 4:54 PM, Marco Marzetti <[email protected]> >> > 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. >> >> >> > >> > 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. >> > >> >> >> >> 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). >> >> >> > >> > 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 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 >> > >> > >> >> >> >> -- >> Marco > > -- Marco _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
