On Fri, Nov 22, 2013 at 11:10 AM, Smith, Donald <[email protected]> wrote: > Prevent this: > > http://www.renesys.com/2013/11/mitm-internet-hijacking/ > > > > I suspect that is what Chris is talking about. I know it concerns me. >
yea, but this is: "Y PROVIDER NO FILTER??" because now, in 2013 ... what excuse is there left? :) > > > > > (coffee != sleep) & (!coffee == sleep) > [email protected] > ________________________________ > From: GROW [[email protected]] on behalf of Christopher Morrow > [[email protected]] > Sent: Friday, November 22, 2013 8:57 AM > To: Geoff Huston > Cc: [email protected] [email protected] > Subject: Re: [GROW] I-D Action: > draft-ietf-grow-simple-leak-attack-bgpsec-no-help-03.txt > > On Fri, Nov 22, 2013 at 4:47 AM, Geoff Huston <[email protected]> wrote: >> >> On 22 Nov 2013, at 3:43 pm, Christopher Morrow >> <[email protected]> wrote: >> >>> On Thu, Nov 21, 2013 at 5:48 PM, Geoff Huston <[email protected]> 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 > [email protected] > https://www.ietf.org/mailman/listinfo/grow _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
