Re: [GROW] WGLC: draft-ietf-grow-simple-leak-attack-bgpsec-no-help

[Danny McPherson <[e-mail]>]

On May 13, 2014, at 9:51 AM, George, Wes <[e-mail]> wrote:

> On 5/12/14, 6:06 PM, "Danny McPherson" <[e-mail]> wrote:
> 
> 
>>> still does not do much to provide
>>> guidance on how such a leak would be systematically identified,
>> 
>> Nor does it have to in any programmatic way, IMO.  It's easy for an
>> entry level routing person to understand what the problem is here, hell,
>> they have to deal with them every day.  It doesn't have to expand to
>> every possible reason or define detection mechanisms.
> 
> That’s exactly my point. We don’t need better understanding of the
> symptom, which is what documenting an example (or many examples) provides.

Actually, I disagree.  I believe it’s precisely what we need, unless you’re aware of it documented and understood elsewhere?
 
> What we need is a discussion around WHY it’s not possible or practical to
> prevent unintentional route leaks with existing or proposed (BGPSec) tools
> - i.e. can’t know intent and/or may not be able to represent intent in
> existing policy language such that it can be derived from available info.

You can prevent most of these attacks today with IRR-based filtering and the sort of things that some folks do (e.g., accept only customer registered prefixes, don’t allow customers to send me prefixes with AS paths of my peers, etc..), things that many of us did from a policy perspective 20 years ago, literally.

The SIDR WG considered this out of scope of their threats and subsequent requirements documents (which I believe both were subsequent to the solutions provided) because the solution they developed didn’t give ANY consideration to these frequent operational and security issues.  With their frequency and ease of occurrence we figured it was important for folks to be aware and consider the issues, ideally, operators smart folk outside of the SIDR circle, else they could be fooled into thinking these problems are solved by BGPSEC, when they are not. 

We could write a lot of text about why some operators believe where SIDR is and how they got there was not appropriate, and how tightly coupling resource certification to routing is a bad idea, particularly within the IETF and the current Internet governance climate, but I don’t think that’s going to do anyone any good here and we’d be forever getting this document published.  If others want to do that work so be it.  I know some new work is happening with IRRs informed by resource certification and driving *persistent* policy configurations in routers and IMO, that solves 99% of what I care about, whereas, BGPSEC solves very little of what I’m concerned about. YMMV.

> Well, yes, the words “policy” and “intent” did occur more than once, so I
> guess that’s a discussion in the strictest sense of the word. However I
> don’t think that it’s been adequately covered in the document even to the
> point that it would spur a follow-on document. And though it might seem
> otherwise, IETF shouldn’t be generating documents for the sake of having
> documents. I don’t see any reason why the discussion of some of the
> challenges around this problem should be punted to a separate
> document/discussion. Put another way, I don’t think that this document has
> enough meat to stand alone with just the example of the problem.

Is this attack vector documented somewhere else?  So unless we can enumerate some broad array of stuff we shouldn’t document a trivial attack vector, all while the SIDR WG is solving [creating] other problems for us?

> I’m not suggesting that it needs to be the kitchen sink for attack
> vectors. I’m suggesting that it needs to discuss this *one* more
> thoroughly, such that folks can actually understand the underlying
> challenge about why it hasn’t already been addressed and still exists as a
> real problem in the wild. That will be significantly more helpful if folks
> are to do research into solutions, or even see if data analysis can lead
> to a way to derive things like intent and policy more effectively.

That document, coupled with the IRR document, do provide a lot of this context, hence their parallel progression.  If you have other ideas or other work items or text then I’m sure folks here would welcome them.

> Yes. That’s what I’m asking you to do. I’m not asking for you to design a
> solution, but discussing existing solutions that don’t work, and why they
> don’t work helps to more completely define the problem. I consider that a
> key issue that the document currently does not discuss.


This document discusses precisely why BGPSEC doesn’t solve this problem in section 2.  What do you believe is missing there?  

FWIW, I’m reluctant to use this document to point out all the other warts with BGPSEC for an array of reasons (e.g., only covers prefix/path, not attributes, tightly coupled to external system new parties and dependencies and control points, not persistent state in routers and bootstrap issues, unlikely to ever have a single RPKI root TA, dependencies on RPKI with own attack vectors and other issues, requires topology exposure with per-router keying globally published, new control regime for routing system makes operator lose autonomy, signature/validation and timing dependencies with external systems and other ASNs) turns BGP into RIPv1 with periodic updates, …) but I don’t really care about BGPSEC that much anymore and the SIDR WG is on greased rails so I’d rather not spend any more cycles on it.  

-danny