On 11/17/14, 12:13 AM, "Randy Bush" <ra...@psg.com> wrote:
>could you please describe how an attacker can send many long bgpsec >paths? how are these long paths signed? Though I'm guessing it might be possible to try it as a replay attack (grab a string of signed ASNs from the path of one or more routes that go past you, then add them to another set of routes that doesn't already have them), I was thinking the attacker likely has to have the ability to sign those ASNs (they have the keys) so that they're valid, otherwise the route just gets dropped. It's not hard to get an ASN or 10. $Dayjob have 12 or 15 that I know about, Comcast has 30+ ASNs, and plenty of hosting providers use an ASN per location to avoid needing ways to connect islands of the same ASN together. Normally they don't have routes that go through each ASN, but spinning up BGP speaking VM instances on Quagga or similar to generate routes to inject and sign from one ASN to another is not hard. In order to avoid the protections that Origin Validation would provide, it's less likely that this is going to be done at origin, but rather by an ASN that is in the middle of the path. I.e. <origin> -- <upstream 1> -- <bad upstream> -- <upstream 3> Bad upstream receives routes from its downstream, and adds the list of ASNs it can sign for plus any churn it wants to induce, sends it to upstream 3, which in this case would be the target of the attack, and if it propagates the routes further, networks beyond it would also be affected. Even if the added ASNs in the path have the result of redirecting traffic to another candidate with a shorter AS Path, the route update itself will propagate on and still eat CPU and memory on the routers it transits, and maybe even be amplified as it gets duplicated to be sent to the learning router's BGP peers. This attack is different from the normal AS Path attacks BGPSec was designed to protect against, because it's not necessarily trying to add a specific ASN to shift traffic to a certain network, that's just a side-effect of the attempt to attack the routers running BGPSec themselves. I'm thinking of this in terms of worst-case scenario, where one builds a nice long ASN path, then uses it to lengthen a few thousand routes as they pass, and then churn them, either on the assumption that RFD isn't configured, or keeping the churn on an individual route low enough to keep from triggering the dampening, but churn lots of routes simultaneously. I admit that this seems like a stretch since exploiting it requires access to ASNs and keys and possibly compromising a router in the middle of a network so that you can have a platform to launch the attack, but there is also the possibility that the simple act of having a long string of valid ASNs in the actual forwarding path could cause this, especially in conjunction with churn, lots of route deaggregation, and misconfiguration (route leaks) that has the net result of taking a long AS path and making it longer. The key question as to how much of a problem this actually might be is, "how long of an AS Path is too long in BGPSec?" or alternately, "when does the product of number of signed routes and number of ASNs per route start causing performance degradation during validation?") I'm not sure we can know that at this point, because it'll depend on a lot of things, so unless we can make some common-sense inferences based on what we see in the routing table, we mainly have to identify it as a potential problem. Thanks, Wes Anything below this line has been added by my company’s mail server, I have no control over it. ----------- 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. _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
