On Nov 7, 2012, at 11:11 AM, Christopher Morrow wrote: > > resource certification, in the form of RPKI, would at least remove a > barrier people put up about using IRR data to make prefix-filters... > so ideally we get some win with just RPKI.
I agree we need resource certification, but if I now have to replicate policy data (e.g., ROAs) contained in that new system in IRRs and then fix the problems in the IRRs anyway, well... > Origin validation is also handy for the cases where people > mis-originate (happens some). And you can get that from IRR data today, without ANY of the machinery from rtr-rpki or BGPSEC. > Path validation is handy for cases where people attempt to insert > false information into the path (for whatever reason they seem to > think is important). > > there isn't data in bgp today data which tells you 'this path is a > leak'. Even at the immediately-leaked-to peer there isn't data in the > message that's helpful for this problem. And I'm not convinced it needs to be in BGP. NOT being in BGP could be considered a feature. > go poke bdickson about his draft? (done several times, fyi) > figure out how to tell if the 'leak' is a 'leak' based only on bgp > data on the wire, from more than 2 as-hops away? (several proposals) I'm not convinced that is the right approach, I don't think it needs to be IN BGP. Hence the original route leak draft, which we just updated, mind you: <http://tools.ietf.org/html/draft-foo-sidr-simple-leak-attack-bgpsec-no-help-02> > the leak draft submitted (the id I mean) doesn't say what a leak is in > any way that's helpful given the bgp data today from more than outside > the immediate leaked-to asn. I don't believe this needs to be fixed IN BGP. > I thought the determination was that there wasn't anything today in > BGP that would be available to tell you that the data you see is > actually a 'leak' and not a 'backup path' (or something similar, > hidden path not previously seen || new transit path coming online || > ....) and that SIDR asked IDR to make something be exposed, to which > IDR said: "Is this a problem? ask GROW folks pls to determine if there > is a problem to be worked on." GROW hasn't seen input on this... I don't think this needs to be done IN BGP. > take that up with the secretariat? I'm not sure how 'sidr chairs have > a conflict with grow chairs, since they are the same person' isn't a > clear signal to: "do not schedule these at the sametime". Telling, indeed.. > sure... and people willing to actually make filtering happen on their > bgp peerings (pccw seems to just not do that, at least not in any sort > of a reliable manner) Agreed.. > >> anyway, and if we'd did just that we could remove most of the threats in the >> routing system, then we sure appear to be doing a helluva lot of work here >> while totally ignoring these problems? > > the threats doc I think does try to outline other problems, and I > don't think anyone working on SIDR things is ignoring this problem. Not on my last read, e.g.: " (These behaviors are not precluded by the specification for BGP, and might be the result of a local policy that is not publicly disclosed. As a result, they are not considered attacks. See Section 5 for additional discussion.)" and "Moreover, route leaks are outside the scope of PATHSEC, at this time, based on the SIDR charter." _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
