On Tue, May 20, 2014 at 5:42 AM, Nick Hilliard <[email protected]> wrote: > On 20/05/2014 02:11, Jared Mauch wrote: >> Is there a need for this to be explicitly documented within the IETF? I >> certainly agree there is a problem, but this feels like operational >> guidance or perhaps a BCP or similar document? (eg: Filter your peer >> ASNs from your other peers). > > Well-maintained prefix / asn filters work well up to a certain size, but no > further. Poorly maintained filters break connectivity in ways which > surprise and amaze. Operationally there is an intersection of operator > clue, network size and peer network size where prefix filters can work > really well, but thar be dragons outside that intersection.
one point of the draft (perhaps not the point people are hoping for) is that 'bgpsec + rpki do not stop valley-free breakage'. I don't know that this was ever a goal for bgpsec/rpki though. One goal which I think people (me too) were hoping for with a draft in GROW was: "Define what a route leak is" followed by: "Tell me if this is a problem for operations of networks" I think 'is this a problem" is fairly well coverved by: o increased latency (unplanned long paths) o increased loss (paths not properly sized/planned/capacity-ready) There MAY be MiTM problems, but one argument is that there are whenever a packet crosses out of your administrative control. I don't know that the hyperbolic argument (everything is a mitm chance!) is helpful here, so I'd skip that. I would say that there are certainly cases where a well planned leak can cause traffic inspection to be possible (and MiTM) where the network operators were previously unaware of such hazards. The draft with it's current goal, I think, is easily summed up by: "If you don't police the routes in/out of your network bad things could happen. BGPSEC/RPKI do not inherently police the routes in/out of your network." so in like 2 sentences the point made by the authors is clear... Still no definition of 'route leak' though. -chris _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
