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: grow@ietf.org grow@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 GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow _______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
