Re: [sidr] comments on the repository analysis I-D
Hi Christopher, Christopher Morrow wrote: Comment 1 (also related with 44): I agree that ISPs may operate caches in behalf end-users ASNs, but also I think that more than 1 cache may be operated by a single ISP. Imagine a global ASN operator with routers in several places. Are they going to have just one master cache? Or are they have one or two (backup), and just in one location? Considering this, even the 40k clients may be low as worse case IMHO. oops, so... we need to be clear in terminology here there are at least: o publication points - places/machines AS Operators would make their authoritative information available to the world. In our analysis we associate number of CAs in the global RPKI with the number of distinct IP resource holders. You seem to associate publication points (that directly relate to CAs) with AS Operators. Since it's a second place where publication points are associated with AS Operators (another is the RPKI rsync Download Delay Modeling presentation), I wonder if I miss something? -- Oleg Muravskiy RIPE NCC ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] DDoS mitigation example (was: RE: comments on the repository analysis I-D)
..in line.. On Wed, Mar 20, 2013 at 10:57 PM, Danny McPherson da...@tcb.net wrote: On Mar 20, 2013, at 7:23 PM, Sriram, Kotikalapudi kotikalapudi.sri...@nist.gov wrote: The DDoS mitigation example was discussed before. It appeared there was a reasonable solution. Please see this post: http://www.ietf.org/mail-archive/web/sidr/current/msg05605.html Might work for Joel, not me... -danny Could you help us understand why? In the thread, it sounds like it will/does work for Joel as your customer, as he specifically mentions using Verisign for mitigation. Is Joel mistaken? Is there something about Verisign's deployment that prevents this from working as a temporary measure in an emergency situation? ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] Princeton University:: Impacting IP Address Reachability via RPKI Manipulations
On Mar 20, 2013, at 2:35 PM, Murphy, Sandra sandra.mur...@sparta.com wrote: Speaking as regular ol' member That all depends on the policy undertaken by each specific provider, doesn't it? How can you tell the difference between a route with no ROA because the registry has decertified, and a route with no ROA simply because one hasn't ever been created? To an ISP who wants to reclaim address space from a customer who has walked or violated their agreement, the ability to decertify that allocated space is a very good feature. One would hope that ISP's are smart enough to have signed legally binding agreements with their customers to whom they've 'leased' IP address space, as part of the customer's Internet transit service. And, if such a situation were to arise, they would first look to seek advice from their legal counsel *before* taking any actions which may result in damages/harm being caused to that former customer's operations, such as revocation of certificates that would decertify the address space occupied by that customer. Generally, but perhaps not always, both parties usually come to a mutual agreement as to a timetable whereby the former customer is able to renumber out of the former address space in order to return it. You certainly would not want to end up with a system that would not allow reclaiming address space. One should question the validity of this statement in the face of IPv6, which (for all intents and purposes) is nearly unlimited. On the one hand, RIR's have (IMO) extremely generous allocation policies for IPv6 address space, at the moment, and any business would be foolish to not consider approaching their RIR(s) to acquire PIv6 space to number their networks to never have to worry about having to renumber (ever). On the other hand, for those sites that may not be fortunate enough to acquire PIv6 space and, instead, need PAv6 addresses ... the future is far from certain. However, in my opinion, the following are at least plausible in the near future: a) Loss of IPv6 addresses, due to customer's walking, is considered by ISP's as an acceptable cost of doing business, i.e.: not worth the costs to engage legal counsel to reclaim them; b) We (the IETF -or- /the market/) figure out less painful multi-homing with PAv6 addresses. The IETF may yet figure this out with something like ILNP (Experimental) or something that is developed in HOMENET. OTOH, the market may solve this on its own by adopting ULAv6+NPTv6. Just my $0.02, -shane --Sandy ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] Princeton University:: Impacting IP Address Reachability via RPKI Manipulations
On Mar 21, 2013, at 8:36 AM, Randy Bush ra...@psg.com wrote: randy, who is not learning anything else new from this rinse repeat So, you're stating that operator input wrt impacts the RPKI will have on their networks is not useful to SIDR? OK, got it. -shane ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] Princeton University:: Impacting IP Address Reachability via RPKI Manipulations
randy, who is not learning anything else new from this rinse repeat So, you're stating that operator input wrt impacts the RPKI will have on their networks is not useful to SIDR? OK, got it. no. i am saying nobody seems to be saying anything that has not already been said. but if you're uninterested in input, i can understand that randy ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] Princeton University:: Impacting IP Address Reachability via RPKI Manipulations
randy, who is not learning anything else new from this rinse repeat So, you're stating that operator input wrt impacts the RPKI will have on their networks is not useful to SIDR? OK, got it. Randy said nothing new, not nothing. --Sandy, speaking as regular ol' member. ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] comments on the repository analysis I-D
On Thu, Mar 21, 2013 at 6:09 AM, Oleg Muravskiy o...@ripe.net wrote: Hi Christopher, Christopher Morrow wrote: Comment 1 (also related with 44): I agree that ISPs may operate caches in behalf end-users ASNs, but also I think that more than 1 cache may be operated by a single ISP. Imagine a global ASN operator with routers in several places. Are they going to have just one master cache? Or are they have one or two (backup), and just in one location? Considering this, even the 40k clients may be low as worse case IMHO. oops, so... we need to be clear in terminology here there are at least: o publication points - places/machines AS Operators would make their authoritative information available to the world. In our analysis we associate number of CAs in the global RPKI with the number of distinct IP resource holders. sure, and as a proxy for that 'AS Operator', it's not a 1:1 correlation to be sure but it should be reasonably close, no? You seem to associate publication points (that directly relate to CAs) with AS Operators. Since it's a second place where publication points are associated with AS Operators (another is the RPKI rsync Download Delay Modeling presentation), I wonder if I miss something? most likely you are not... I think I jump to 'CA == REPO == AS-Operator == ASN allocated' because lacking any direct data otherwise it seems like a good estimation of numbers. Essentially each ASN allocated is going to be a repository that needs to be gathered, right? If there are 10% more repositories due to EndSite allocations without an ASN also allocated to them I think it's still in the ballpark to say number of Repos == ASN allocation number. I could be wrong. ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] comments on the repository analysis I-D
In our analysis we associate number of CAs in the global RPKI with the number of distinct IP resource holders. sure, and as a proxy for that 'AS Operator', it's not a 1:1 correlation to be sure but it should be reasonably close, no? do we have anything other than conjecture on which to base estimations of the numbers of CAs or repositories? I jump to 'CA == REPO == AS-Operator == ASN allocated' because lacking any direct data otherwise it seems like a good estimation of numbers. great example of conjecture. do you have any fact/measurement-based idea of how many CAs or repositories there might be five or ten years from now? the only data i have is the small number of IRR repositories and whois servers. and i suspect/hope that is a poor estimator. but i very strongly doubt that any significant portion of the stub ASs, 84% of the ASs, will run CAs. randy ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] comments on the repository analysis I-D
On Thu, Mar 21, 2013 at 11:43 AM, Randy Bush ra...@psg.com wrote: In our analysis we associate number of CAs in the global RPKI with the number of distinct IP resource holders. sure, and as a proxy for that 'AS Operator', it's not a 1:1 correlation to be sure but it should be reasonably close, no? do we have anything other than conjecture on which to base estimations of the numbers of CAs or repositories? no, since there aren't any CA's in existence... we have, or I have, a model that says: If you want to publish a ROA, you need to have a CA and you need to run a publication point To me that means at the least every ASN will have a publication point (and this a roa and a CA). I jump to 'CA == REPO == AS-Operator == ASN allocated' because lacking any direct data otherwise it seems like a good estimation of numbers. great example of conjecture. do you have any fact/measurement-based idea of how many CAs or repositories there might be five or ten years from now? the only data i have is the small number of IRR repositories and whois servers. and i suspect/hope that is a poor estimator. I really don't know how to estimate ASIDE from saying: it seems reasonable that the repo number will track with assigned ASN I could be wrong, I could also be corrected if someone else has a compelling story... I don't think it's harmful to say tracks to ASN numbers though, if it's too large a number we can be surprised by performance... if it's too small, we can also be surprised :) but i very strongly doubt that any significant portion of the stub ASs, 84% of the ASs, will run CAs. they may not. they may use a hosted-model product. I suspect that very soon after 'hosted model' comes into being in the large, the operators of these systems will realize that if someone dislikes one of their customers they can't survive as a business if all other customers also disappear. They will be forced to run the system with unique names/ips for each customer (names at a minimum so they can shift problem children away). So, in the above case... CA == ASN == REPO -chris ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] DDoS mitigation example (was: RE: comments on the repository analysis I-D)
On 3/20/13 7:57 PM, Danny McPherson wrote: On Mar 20, 2013, at 7:23 PM, Sriram, Kotikalapudi kotikalapudi.sri...@nist.gov wrote: The DDoS mitigation example was discussed before. It appeared there was a reasonable solution. Please see this post: http://www.ietf.org/mail-archive/web/sidr/current/msg05605.html Might work for Joel, not me... That's entirely possible. I was only filtering through my experience as one customer. -danny ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] Princeton University:: Impacting IP Address Reachability via RPKI Manipulations
Thanks for the interest in our work. We wanted to clarify a few points: -- We have a technical report, which contains motivation and details that the slide deck does not. See http://www.cs.bu.edu/~goldbe/papers/RPKImanip.pdf -- As we point out in the paper (and as John Curran, Carlos, and others have noted here) a missing ROA will not necessarily make the target unreachable. That depends on the policy at relying parties. We discuss this in Section 3 of the report. For example, if a route for a prefix becomes invalid due to a missing/invalid ROA, and if everyone uses a drop invalid policy, that prefix would become unreachable. However, with other policies (e.g. depref invalid) the prefix may still be reachable. -- Per John Curran and others' points, we want to emphasize that a missing ROA can make a route either unknown or invalid. That depends on whether there is another ROA for a covering prefix and a different AS (see http://tools.ietf.org/html/rfc6483#section-2). -- We show that it is possible to revoke a ROA surreptitiously, through methods other than (the obvious) revocation lists. See Section 2.2.1 of the report. -- We show that targeted revocation can be accomplished by entities other than a ROA's issuer, some of which may control many ROAs. The means by which this is accomplished often looks similar to grandparenting. See Sections 2.2.2, 2.2.3, and 2.3 of the report. -- We agree with the observation that watching the RPKI repositories for changes/anomalies is a good first to step to mitigating the impact of manipulations. We are working on such a system right now. More comments are welcome. Sharon, Leo, Danny, Ethan, and Kyle (At Boston University, not Princeton!) -- Sharon Goldberg Computer Science, Boston University http://www.cs.bu.edu/~goldbe ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] comments on the repository analysis I-D
I have, a model that says: If you want to publish a ROA, you need to have a CA and you need to run a publication point land this a roa and a CA). Wherever did you get that? what is the ratio of hosted LIRs to delegated today? -- phone email, so sucky ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] comments on the repository analysis I-D
On Thu, Mar 21, 2013 at 1:55 PM, Randy Bush ra...@psg.com wrote: I have, a model that says: If you want to publish a ROA, you need to have a CA and you need to run a publication point land this a roa and a CA). Wherever did you get that? I figured in the worst case you'd end up with 1:1... I don't think it'll be much worse than 1:1, it could be better, of course. what is the ratio of hosted LIRs to delegated today? not sure... I believe that hosted == delegated though in the long run, from the perspective of what ip/name you have to connect to in order to access the data stored in the repositories. ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] DDoS mitigation example (was: RE: comments on the repository analysis I-D)
On 2013-03-21 10:45, joel jaeggli wrote: Might work for Joel, not me... That's entirely possible. I was only filtering through my experience as one customer. Yep, I concur, hence my comment :-) We have _lots of customers with varying requirements and capabilities, not that that's in scope of SIDR. -danny ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] comments on the repository analysis I-D
Chris, ...most likely you are not... I think I jump to 'CA == REPO == AS-Operator == ASN allocated' because lacking any direct data otherwise it seems like a good estimation of numbers. Essentially each ASN allocated is going to be a repository that needs to be gathered, right? If there are 10% more repositories due to EndSite allocations without an ASN also allocated to them I think it's still in the ballpark to say number of Repos == ASN allocation number. I could be wrong. So far the 1,300+ folks who have signed up for managed CA services have also let the RIRs manage their pub points, which dramatically reduces the number of repositories. That could change over time, e.g., if these folks become unhappy with the repository management, but for now I think it is reasonable to assume a much smaller number of repositories, which is what Sriram and I did in our model. ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] comments on the repository analysis I-D
On 03/21/2013 04:11 PM, Stephen Kent wrote: Chris, ...most likely you are not... I think I jump to 'CA == REPO == AS-Operator == ASN allocated' because lacking any direct data otherwise it seems like a good estimation of numbers. Essentially each ASN allocated is going to be a repository that needs to be gathered, right? If there are 10% more repositories due to EndSite allocations without an ASN also allocated to them I think it's still in the ballpark to say number of Repos == ASN allocation number. I could be wrong. So far the 1,300+ folks who have signed up for managed CA services have also let the RIRs manage their pub points, which dramatically reduces the number of repositories. That could change over time, e.g., if these TODAY it reduces the number, yes. 100% agree. TOMORROW the number of repositories, even those which are 'hosted' will be split up by name and/or ip-address... I have a feeling these will be like DNS servers and likely ripe (ha!) points for attack by bad folks. So sharing fate for all customers just seems like a bad idea. folks become unhappy with the repository management, but for now I think it is reasonable to assume a much smaller number of repositories, which is what Sriram and I did in our model. yup. but having the ability to increase the number of repositories in the model means we can say: today with N repositories and M objects we see times of Y. Tomorrow when we have X repositories with Y objects we should see times of Z -chris ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] comments on the repository analysis I-D
On 03/21/2013 04:15 PM, Stephen Kent wrote: Chris, On Thu, Mar 21, 2013 at 11:43 AM, Randy Bush ra...@psg.com wrote: In our analysis we associate number of CAs in the global RPKI with the number of distinct IP resource holders. sure, and as a proxy for that 'AS Operator', it's not a 1:1 correlation to be sure but it should be reasonably close, no? do we have anything other than conjecture on which to base estimations of the numbers of CAs or repositories? no, since there aren't any CA's in existence... well, there are over 1,300 so far, but almost all are managed CAs. we have, or I have, a model that says: If you want to publish a ROA, you need to have a CA and you need to run a publication point still true, even for managed CAs. To me that means at the least every ASN will have a publication point (and this a roa and a CA). it's a ROA, a manifest, a CRL, maybe a GB record, and a CA cert in the parent's pub point. sure, I abbreviated the list. I jump to 'CA == REPO == AS-Operator == ASN allocated' because lacking any direct data otherwise it seems like a good estimation of numbers. great example of conjecture. do you have any fact/measurement-based idea of how many CAs or repositories there might be five or ten years from now? the only data i have is the small number of IRR repositories and whois servers. and i suspect/hope that is a poor estimator. I really don't know how to estimate ASIDE from saying: it seems reasonable that the repo number will track with assigned ASN see my earlier comment re this possible equivalency. I could be wrong, I could also be corrected if someone else has a compelling story... I don't think it's harmful to say tracks to ASN numbers though, if it's too large a number we can be surprised by performance... if it's too small, we can also be surprised :) but i very strongly doubt that any significant portion of the stub ASs, 84% of the ASs, will run CAs. they may not. they may use a hosted-model product. but even in the hosted model each of these folks is represented by a CA and a pub point. I think the only issue is whether each is a separate repository. correct. one contiguous repo is a great target ... once or twice that'll work, then the repository operator will split all customers into separate names at the least that she can steer to infrastructure in case of a problem. I suspect that very soon after 'hosted model' comes into being in the large, the operators of these systems will realize that if someone dislikes one of their customers they can't survive as a business if all other customers also disappear. They will be forced to run the system with unique names/ips for each customer (names at a minimum so they can shift problem children away). So, in the above case... CA == ASN == REPO I don't understand that last argument. Can you expand on it? Today, if you look at: dig NS ly ly.cctld.authdns.ripe.net. is one of the servers listed... ripe sets up a separate name/ip for each CC they serve. This gives them the flexibility to move one victim off to a dedicated server(s) in the case of really bad problems. I suspect that the hosted repository model will evolve to this over time. -chris ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] comments on the repository analysis I-D
On Thu, Mar 21, 2013 at 4:42 PM, Danny McPherson da...@tcb.net wrote: On 2013-03-21 14:29, Chris Morrow wrote: TODAY it reduces the number, yes. 100% agree. TOMORROW the number of repositories, even those which are 'hosted' will be split up by name and/or ip-address... I have a feeling these will be like DNS servers and likely ripe (ha!) points for attack by bad folks. So sharing fate for all customers just seems like a bad idea. folks become unhappy with the repository management, but for now I think it is reasonable to assume a much smaller number of repositories, which is what Sriram and I did in our model. yup. but having the ability to increase the number of repositories in the model means we can say: today with N repositories and M objects we see times of Y. Tomorrow when we have X repositories with Y objects we should see times of Z Agreed. Additionally, this perspective may well change when things like BGPSEC router keys need to be published and then ingested by operational routers for update signing, as the trust model is fairly different, methinks. so, to me, this is just 'more objects with a tight(er) timeframe on delivery' right? meaning: today you have (for sake of the conversation) relatively static content in the repository, where data changes 1/2/3 objects/day, and it's important to get the data distributed, but (again, for the conversation) 24hrs is 'fine' as a timeline between: publish object and rendered onto the router. but: tomorrow if you followed (for the sake of the conversation) Sriram's model of 'roll router keys hourly to ensure ttls on routes' (loosely paraphrased and with times I don't even think he put into his slides/discussions), you'd be talking about #-of-routers * 24 objects changing every day, and with a timescale for: publish to render on the order of 1hr. (likely less than 1hr, something closer to 5-10 minutes has been discussed previously). right? -chris ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] comments on the repository analysis I-D
On Thu, Mar 21, 2013 at 5:42 PM, Danny McPherson da...@tcb.net wrote: so, to me, this is just 'more objects with a tight(er) timeframe on delivery' right? meaning: today you have (for sake of the conversation) relatively static content in the repository, where data changes 1/2/3 objects/day, and it's important to get the data distributed, but (again, for the conversation) 24hrs is 'fine' as a timeline between: publish object and rendered onto the router. but: tomorrow if you followed (for the sake of the conversation) Sriram's model of 'roll router keys hourly to ensure ttls on routes' (loosely paraphrased and with times I don't even think he put into his slides/discussions), you'd be talking about #-of-routers * 24 objects changing every day, and with a timescale for: publish to render on the order of 1hr. (likely less than 1hr, something closer to 5-10 minutes has been discussed previously). right? Yeah, I think so under steady state. It gets more interesting when the RIR is attacked and I can't reach them, or I have a failure of a control card or systems where I cache them locally, or something to that effect. AND I have to know when *everyone* else in the system picks them up and pushes them out to their routers in preparation for validation so that I know when it's safe to starting signing with them, etc.. true, but the repository conversation stops at: all gatherers in the system have the data inside each ASN it's really up to the ASN operator to get from gatherer - cache - router in a 'timely fashion'. ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] comments on the repository analysis I-D
true, but the repository conversation stops at: all gatherers in the system have the data inside each ASN it's really up to the ASN operator to get from gatherer - cache - router in a 'timely fashion'. If you're signing a route with something, and your upstreams are signing their secure path elements of that route with something, and my routers haven't been provisioned (from data obtained from the RPKI) to validate with the corresponding public versions of those somethings (for whatever reason - e.g., latency in fetching, DoS, failure, etc..), then this *tight coupling* between the public key repositories (i.e., RPKI) will result in my router as a relying party not having the information it need to validate those signed somethings, and I therefore downgrade or break for that route. You not knowing when I have the information to validate something because I may not have fetched it from the RPKI yet (or ingested it in my routers yet, for whatever reason) means you can't send a route with the new signatures because it will fail validation, thereby causing a downgrade attack or something to break for the route. This looseness about an expanding array of validation states and acceptable downgrade attacks in BGPSEC because the RPKI may not be available, or local systems may be operating on stale data, continues to give me pause given the overhead we're introducing and the expanding set of residual vulnerabilities some are willing to accept. -danny ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] comments on the repository analysis I-D
So far the 1,300+ folks who have signed up for managed CA services have also let the RIRs manage their pub points, which dramatically reduces the number of repositories. That could change over time, e.g., if these this is measurement TODAY it reduces the number, yes. 100% agree. TOMORROW the number of repositories, even those which are 'hosted' will be split up by name and/or ip-address... this is pure conjecture. can we please reduce the ratio of the latter to the former? randy ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
