On Fri, Nov 22, 2013 at 4:47 AM, Geoff Huston <g...@apnic.net> wrote: > > On 22 Nov 2013, at 3:43 pm, Christopher Morrow <christopher.mor...@gmail.com> > wrote: > >> On Thu, Nov 21, 2013 at 5:48 PM, Geoff Huston <gih...@gmail.com> wrote: >>> but in our haste to comply with the timelines dictated by DHS's project >>> funding >>> I guess we've got what DHS were prepared to pay for, and not what we >>> actually >>> wanted or need. And for many its an unsatisfactory outcome. >> >> just asking about one part here... so DHS aside, because i'm not sure >> that who the funder is is relevant to the work, exactly... what >> options are there for securing more than the aspath? > > > As I understand the draft correctly, the draft is saying even if you secure > ASPATH > along the lines proposed in secure BGP, there are still ways in which an > attacker can > inject a path that was not intended by the originator.
inject a path... hrm, I'm not parsing that properly I bet. Did you mean prepend on random asns? (no, don't think so, not and stay validated) Did you mean pull a route down a customer link and pass it back up the hill to the other transit? (sure, but that's known, right?) > So the question that the draft raises in my head is is it possible to > communicate > routing policies in a secure manner? so far this keeps coming up and keeps ending in a deathspiral of: "People don't want to share their byzantine routing policy stuff 'publicly'" or: "sure, you could make a global registry of routing policy... isn't rpsl that? and it's working out how well so far?" > >> Additionally, the draft in question here still doesn't say how you'd >> know 'thats a route leak' more than 1 as-hop away form the 'leak'. (it >> also doesn't take into account any of the comments I provided to the >> authors :( which is another matter entirely) > > so we get back to RPSL. maybe? though I'm not sure that it's any more helpful than just IRR based filtering with prefixes only and no policy-foo. People have to be willing to be pretty damned specific in their policy language there.. Is 702 going to publish that they are a transit of NTT in Japan? > But I am still wondering:... > > Why are we using GROW to host this discussion? So.. I think part of this is: 1) no one has published a good definition of 'route leak' (that 'people' agree upon) 2) without the definition (which might not be 'required', debate later pls) 'operations people' can't say (or haven't said): "Hey, this route leak thing is a problem, could you ietf-smarty-pants figure out how to fix it for us?" 3) IDR can chew on this requirement and spit out 'Yes, you should do XXX' or 'OH HAI! we changed the bgp protocol to add this widget you can use to signal intent!' (or something) 4) SIDR can then whack that with authentication/etc bits in essence the 4 steps there are what was agreed upon by the routing-ads, idr/sidr folks + grow folks... it looks like things that smell rolling downhill a bit :) but, welp there you have it. > What are GROW's intended objectives in considering this draft? I hope: 1) define in a useful fashion route leak 2) get grow folks to agree (or not) that 'route leaks' (as defined) are some form of operational problem that needs ietf assistance in solving. If we don't agree that they are a problem then ... nothing happens, I suppose. > [...] > > And if we are ready to reopen this consideration of requirements for securing > the operation > of BGP, just how much of this are we willing to re-consider? Is it all the > way back to > RPSL and RPSS? not sure... :) _______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
