to the best of my knowledge, no one has looked at this for origin validation. sharon goldberg and co-conspirators have done a lot of work in the area, see her pubs at https://www.cs.bu.edu/~goldbe/. but the concentration seems to be on bgpsec which deploys quite differently randy
On Thu, Apr 3, 2014 at 8:50 PM, Randy Bush <randy@psg.com> wrote:
Right, we (and others) have not looked at the efficacy of a partial deployment of origin validation (using the RPKI) yet. But, we did look at partial deployments of BGPSEC. We found that a large number of networks (around 50% of ASes) need to deploy BGPSEC before its security benefits really kick in. The reasons for this include (1) routing policies during partial deployment might not prioritize the BGPSEC validity over its AS path or local pref, (2) you need every node on an AS path to deploy BGPSEC before it works. Full paper here: https://www.cs.bu.edu/~goldbe/papers/partialSec.pdf We also looked at prefix filtering and found that it has better partial deployment characteristics. Our analysis assumed that ISPs only filter routes from their *stub* customers. (We defined a stub an AS that does not have its own customers.) Then we looked at the fraction of attacks that would be eliminated, if the X largest ISPs correctly implemented prefix filtering. ("Large" was measured in terms of the number of customers ASes the ISP had.) See Figure 18 on pg 15 of this paper, and the text explaining it in the middle of the right column on pg 15: http://research.microsoft.com/pubs/120428/BGPAttack-full.pdf Finally, like Randy says, RPKI deploys quite different from BGPSEC. My intuition says that (1) once the RPKI is fully populated with ROAs for all originated prefixes, then (2) a partial deployment of origin validation at a few large ISPs should be fairly effective. But I would have to validate this with experiments before I can be sure, or say exactly how many ISPs, etc. Sharon -- Sharon Goldberg Computer Science, Boston University http://www.cs.bu.edu/~goldbe
On Fri, Apr 4, 2014 at 1:15 AM, Mark Tinka <mark.tinka@seacom.mu> wrote:
Right, we didn't include that in our analysis because we didn't have a good sense for how many ISPs actually do filter their downstream downstreams. So we chose to give a conservative estimate of the impact of prefix filtering in partial deployment: we assumed that no one filters their downstreams downstreams. I'm honestly not sure exactly what including this assumption would do to our results, except to say that it would make them better (ie. that more attacks would be stopped). Might be a good experiment for one of my summer interns. Actually, since this is NANOG, might as well ask: Do you all view filtering your downstream's downstreams as much more difficult than filtering only downstreams, or only stub ASes? Do you have a sense for how many networks filter only their direct downstreams but no further, versus those that also filter downstreams downstreams? Sharon -- Sharon Goldberg Computer Science, Boston University http://www.cs.bu.edu/~goldbe
On Fri, Apr 4, 2014 at 11:17 AM, Sharon Goldberg <goldbe@cs.bu.edu> wrote>
I set up a quick anonymous survey (2 questions) to gather some info on this. If you have a minute, go here: https://docs.google.com/forms/d/1x6Bbe7OYvuWeOzO8xpxbIZzW3N14wI1SVVbQer4FSa4... We will share our anonymized results on NANOG. Thanks, Sharon
On Friday, April 04, 2014 05:17:36 PM Sharon Goldberg wrote:
I've typically been on the side where we filter just the downstream and apply AS_PATH filtering liberally for their downstreams. At $current_job, we're now filtering both downstream and downstream's downstreams on AS_PATH + prefix list, taking the prefix aggregate and suffixing "le 24" or "le 48". We are now thinking about how to scale this without using RPSL, as that creates lots and lots of clutter in the configuration, as well as sub-optimal forwarding when customers are sending routes you aren't accepting when they forget that RPSL-based filtering is prefix-specific. Mark.
On Sat, Apr 5, 2014 at 7:11 AM, Mark Tinka <mark.tinka@seacom.mu> wrote:
These looking glasses are helpful: http://www.labs.lacnic.net/rpkitools/looking_glass/ http://www-x.antd.nist.gov/rpki-monitor/ http://certification-stats.ripe.net/ http://rpki.surfnet.nl/index.html But naturally it's harder to see who has turned on origin validation. Sharon -- Sharon Goldberg Computer Science, Boston University http://www.cs.bu.edu/~goldbe
On Sunday, April 06, 2014 02:34:47 PM Sharon Goldberg wrote:
But naturally it's harder to see who has turned on origin validation.
Indeed, especially since there is no co-relation between providers issuing ROA's for their own allocations and turning on origin validation in their network. Mark.
On 04/04/2014 05:06 AM, Sharon Goldberg wrote:
Indeed. A MSc. project did a (limited) evaluation measuring the effects of RPKI route origin validation of a Dutch ISP xs4all which prefixes where incorrectly injected by another (larger according to CAIDA cone ranking) European ISP. With ROAs published and a small percentage (order of 5%) of the largest ISPs doing route origin validation, this would filter the incorrect announcement and result in about ~98% globally correct routes in the 35000 ASes (this work is done a couple years ago). With no route origin validation (or any other filtering) the percentage of correct routes at the ASes would be ~25% globally. Again, this was a specific scenario. See for results and figures the slides at http://www.caida.org/workshops/bgp-traceroute/slides/bgp-traceroute1108_rpki... (slide 18). Best, -- Benno -- Benno J. Overeinder NLnet Labs http://www.nlnetlabs.nl/
participants (5)
-
Benno Overeinder -
Mark Tinka -
Nick Hilliard -
Randy Bush -
Sharon Goldberg