On 5/14/14, 8:38 AM, "Danny McPherson" <da...@tcb.net> wrote:
>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. So at a minimum your draft should include references to the relevant sections of http://tools.ietf.org/html/draft-ietf-opsec-bgp-security and probably the routing-policy-considerations doc along with discussion of what gaps still exist in those tools’ ability to prevent the attack described in this document. I’m not suggesting that it has to be an exhaustive list of all attacks of this type and whether these tools will prevent each, but at least making it clear the scenarios where these tools aren’t enough by themselves to prevent this *specific* attack is pretty important to this discussion. In other words, either a solution exists but is not widely deployed for reasons discussed in policy-considerations, or a solution exists but it can’t address foo and bar (or both). > 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. I don’t think that anyone has claimed that BGPSec solves this, so I’m not concerned about people being fooled. You assert that IRR-based filtering and good BGP neighbor hygiene mostly resolve the problem, and that even entry level BGP operators are familiar with this issue, yet it occurs all of the time. So why is it useful to single out BGPSec on this particular attack vector as being no help? Please don’t misconstrue this as me defending BGPSec. I am skeptical it will ever see deployment for much the same reasons you detail, but that makes it all the more strange to have it be the primary focus of a discussion of route leaks and the associated attack vector since it never claimed to solve that problem. In other words, route leaks are a problem whether BGPSec lives or dies, so let’s focus on that, rather than re-hashing the discussion about whether BGPSec SHOULD have protected against this attack or 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. Again, I’m not asking for that text. I’m not sure how much clearer I can be about that. The less said about SIDR’s design choices and process in this context and WG, the better. >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. Yet none of that work is referenced in this document, and when I point out that the document is a bit thin, you keep harping on BGPSec and SIDR. >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, No it’s not documented elsewhere, and I’m not saying you shouldn’t document it, nor do I think I’m asking for a broad array of stuff. I’m saying that you haven’t documented it completely enough for it to be at all useful as input to future work as the document claims it is supposed to be. >That document, coupled with the IRR document, do provide a lot of this >context, hence their parallel progression. But in their current form(s) that logical link between the two doesn’t exist, since the documents don’t even reference one another. You need to connect the dots a bit better under the assumption that not all readers are necessarily aware of their parallel progression. >This document discusses precisely why BGPSEC doesn’t solve this problem >in section 2. What do you believe is missing there? No, it discusses HOW this set of announcements appears valid in BGPSec. The WHY is what I’ve been trying to get you to add, which is that BGP has no way to convey intent or the explicit limits of route propagation on a per-ASN basis, and therefore there is no attribute being manipulated such that it could be secured by a system that secures a subset of BGP attributes like BGPSec. >FWIW, I’m reluctant to use this document to point out all the other warts >with BGPSEC for an array of reasons And while it would be entertaining reading, I would be opposed to you doing so. Such a document belongs in SIDR, not GROW. From my perspective, you have several points to make in this draft to provide a stable reference documenting this problem: 1) route leaks are [definition, see text suggestion in previous message] 2) there are ways for this sort of leak to be used as a MITM attack [example from your draft] 3) these leaks occur very frequently [data citations from your draft] 3a) but not all are malicious, some are misconfigurations, some are intentional 4) routing hygiene helps to prevent, but not eliminate [discuss gaps] 5) BGPSec doesn’t fix, because it can only secure BGP attributes, and BGP has no semantics to convey intent or this type of inter-AS propagation boundary policy Thanks Wes This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. _______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
