I think you mean "paths with valleys are all instances of unintended routing".
Surely, that can be fixed: A provider can reject valleyed routes from a customer BY DEFAULT, but allow some through if so configured. The point is that such a valley attribute can provide good information to prevent the majority of route leaks without leaking customer relationship information. --Jakob. -----Original Message----- From: Geoff Huston [mailto:g...@apnic.net] Sent: Friday, November 22, 2013 3:21 PM To: Jakob Heitz Cc: Christopher Morrow; g...@ietf.org g...@ietf.org Subject: Re: [GROW] I-D Action: draft-ietf-grow-simple-leak-attack-bgpsec-no-help-03.txt If you are referring to the proposal that "valley free paths are all instances of unintended routing", then as I recall there is a line of argument that says that some paths that contain valleys are intentional. On 23 Nov 2013, at 7:03 am, Jakob Heitz <jakob.he...@ericsson.com> wrote: > Wasn't there once a proposal along the lines of: > > The originator adds a signed attribute that says "this update is going up the > chain". > Each AS signs it before passing it on. > When an AS sends the update down the chain, it removes the attribute. > When an AS receives an update clearly "from below", it checks for the > presence of the attribute. > > What were the objections to this? > > --Jakob. > > -----Original Message----- > From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Geoff Huston > Sent: Friday, November 22, 2013 11:44 AM > To: Christopher Morrow > Cc: g...@ietf.org g...@ietf.org > Subject: Re: [GROW] I-D Action: > draft-ietf-grow-simple-leak-attack-bgpsec-no-help-03.txt > > > On 23 Nov 2013, at 2:57 am, Christopher Morrow <christopher.mor...@gmail.com> > wrote: > >> 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?) > > > Chris, you have READ the draft I assume? > >> >>> 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?" >> > > I hear different responses in other parts of the network, where communities > have invested significant levels of effort in publishing routing policies and > attempting to compute across them. > > It seems to me that ensuring that the protocol operates correctly does not > provide sufficient levels of assurance that a BGP speaker can reliably > distinguish between routing information that is in some sense "genuine" and > routing information that is intended to corrupt the speaker's forwarding > state. > > >>> >>>> 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. > > I'm not sure its worth repeating the arguments that lead to the work in RPSL. > > Apparently, folk at the time who worked on RPSL held the belief that it was > more helpful. > >> 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? > > > good question - the folk in Japan seem to have been one of the communities > that invested heavily in populating a local route registry with current > information. But its tue that in many communities a local route policy > registry is variously populated with current and lapsed information, as well > as large gaps. > > I think that the draft that triggered this interchange is spot on when it > observes: > > "This document describes an attack on an RPKI-enabled BGPSEC and is > meant to inform the IETF community that this vulnerability exists as > a result of route-leaks and attacks that conform to this type of > behavior, and that operators should not assume that that work items > and designs address these operational security issues." > > The next sentence was what motivated me to respond: > > "The authors believe the capability to prevent route-leaks and leak- > attacks should be a primary engineering objective in any secure > routing architecture." > > i.e. the concepts of a "secure routing architecture", as envisaged by SIDR, > are inadequate. > > > > >>> 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. > > > As I read your thoughts I am left with the impression that you hold the view > that IDR that inherited the "requirements for securing the routing system" > task. Have I got this right? > > > >> >>> 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. >> > > > If one is allowed to assume that "leaks" redirect traffic, then isn't > one AS operator's "route leak" indistinguishable from another AS > operator's attack via the inter-domain routing system, as the draft > itself clearly points out? Or is your use of the term "leak" in this > context intended to distinguish between the two forms of corruption of > the inter-domain routing system based on the assumed purity of motives of the > perpetrator? > > Or do we currently have a collective belief that if we assign the same > problem space to enough working groups one of them will eventually > have a bright idea? :-) > > >>> [...] >>> >>> 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... :) > > neither am I - which is why I asked the question. > > Geoff > > _______________________________________________ > GROW mailing list > g...@ietf.org > https://www.ietf.org/mailman/listinfo/grow _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
