On Fri, Nov 22, 2013 at 6:40 PM, Jakob Heitz <jakob.he...@ericsson.com> wrote: > 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.
is this a default-on property? or do I configure bgp-peer-A as 'i am a customer' and peer-b as 'I am a transit'? what is the default expected value? how do I verify that the value is correct? or do I just trust the 3-as-hops away path I see? how is this better than today's: "filter your routes" situation? > -----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