On Wed, Nov 7, 2012 at 10:25 AM, Danny McPherson <[email protected]> wrote: > > On Nov 7, 2012, at 10:13 AM, Christopher Morrow wrote: > >> On Wed, Nov 7, 2012 at 9:11 AM, Dan York <[email protected]> wrote: >>> Agreed, sadly... but the good news is that this whole thing did get more >>> people thinking about the underlying router infrastructure. So if it gets >>> some people to wake up and pay more attention, I think that's a good thing. >> >> yep. > > > Chris, > Given that all the RPKI/BGPSEC machinery fully deployed would NOT have > helped here, what is your key desire for this RPKI/SIDR/BGPSEC work? Is
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. Origin validation is also handy for the cases where people mis-originate (happens some). 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. > it simply for resource certification? > > What do you believe we should do about THIS problem? 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) > This is precisely why we wrote the "leak" draft (and the IRR draft) - work 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. > areas which are somehow out of scope of the _secure _inter-domain _routing 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... > WG. Heck, the Friday conflict with the GROW WG illustrates the disconnect > here as well. 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". > > And if at the end of the day the answer is that we need IRR-esque capabilities 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) > 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. -chris _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
