free dinner at nanog/van for anyone who can explain how the dnssec approach meets the defcon attack. hint: it is a path attack, not an origin attack, and the dns pidgeon has no hooks to path attack prevention. at ripe, joe gersh asked me for an example of a path attack and i told him of the defcon demo. seems he also did not bother to do his homework. but it makes good pr. .... you are right, you have not done your homework. rpki-based origin validation asks no changes to bgp.

Free dinner to anyone who can explain how the RPKI piece of the SIDR work resolves path attacks. You're comparing apples to oranges here. Neither a DNS based solution nor the RPKI will resolve path attacks, so neither apply to the type of attack you're talking about. There are solutions for this sort of attack. Everything from completely loose, community based solutions to totally control freak horrible solutions, like BGP-SEC (and which doesn't really solve the problem anyway).

yes. rpki can also have that issue as the certs can have urls that use domain names. i believe they could use ip address urls instead. but the gathering operation differs greatly between the rpki and the dnssec based proposal. with the latter, you can't even tell you have the full set.

The problem at hand is relying on routing to build the routing system. How does using an IP address rather than a DNS based hostname change the need for routing to work before routing can work? Reality check: I don't know that this is all that important, in the end. So long as you can use an IGP locally with a default route to reach a copy of the database, whether it be based on DNS, an RPKI, or anything else, then you can bootstrap your EGP routing. If everything goes down at the same time, then you would just start rebuilding from the places where the root servers live, no matter what system's root servers we're talking about. So I think this is a bit of a red herring at the EGP level.

i do not like it either. but it is a trade you make for security. and, at ripe ljubljana, i think alex started to discuss some schemes to ameliorate it. more later on this.

The problem is worse than your initial estimate. A day's worth of downtime can cost you your business in total, not just some lost revenue. No matter whether or not you agree with the article's premise, at least some provider folks are starting to ask some hard questions --which is a good thing! Let's not shut the conversation down by making broad proclamations about how the problem has been solved, "move along, nothing to see here," etc. There is something to see here, so slow down and take a look. Rubbernecking, in this case, is encouraged. Russ -- <>< Scripture Alone, Grace Alone, Faith Alone http://thinkinginchrist.com/

I want to be sure of the terminology: what is deployed presently is the bundle RPKI+ROA. As their name say, ROA can only be used against origin attacks. But RPKI can be used for other things than RPKI+ROA, including BGP-sec (against path-based attacks), no?

wfm

The idea as such isn't new, this has been floating around for four years or more, including at least one Internet draft, draft-donnerhacke-sidr-bgp-verification-dnssec.

draft-bates-bgp4-nlri-orig-verif-00.txt was '98 and we dropped it for good reasons randy

* Alex Band:

...

I don't know if we can get RPKI to deployment because RIPE and RIPE NCC have rather serious issues with it. On the other hand, there doesn't seem to be anything else which keeps RIRs relevant in the post-scarcity world, so we'll see what happens.

Could you elaborate on what those issues are?

From the comments on these events, I infer that RIPE NCC still does not want to exercise this level of control over routing, and the RIPE community does not want RIPE to have such control. But assuming that

A year ago, RIPE NCC received legal advice that RPKI-based takedowns would not happen under Dutch law because Dutch law lacked any provisions for that. This was used to deflect criticism that RPKI deployment would result in too much concentration of power: <http://www.ripe.net/ripe/mail/archives/address-policy-wg/2011-May/005858.html> The legal analysis turned out to be incomplete and the results incorrect---legal counsel failed to consider public order legislation. The validaty of such an order (issued in the Dnschanger context) is currently being challenged in a Dutch court. the order stands, RPKI will provide RIPE NCC with a tool that nobody wants it to have, and RIPE NCC can be forced to use it. Depending on the seriousness of those concerns, that's the end of RPKI deployment. (However, the most likely outcome of the current court case is that this particular police order will be found invalid on a formality, such as lack of effectiveness, providing little insight on the validity of future orders which are more carefully crafted.) Regarding the post-scarcity future, if most address holders never have to come back to the RIR to request more addresses, the number of address-related RIR/LIR transactions will decrease. Organizations have a tendency to resist decreases in business (even non-profits), and RPKI is an obvious source of future business.

* Alex Band:

At RIPE 63, six months ago, the RIPE NCC membership got a chance to vote on RPKI at the general meeting. The result was that the RIPE NCC has the green light to continue offering the Resource Certification service, including all BGP Origin Validation related functionality.

But this was done outside the Policy Development Process, which is supposed to handle such things.

It's correct that concerns were raised in the area of security, resilience and operator autonomy, as you mention. These concerns are continuously being evaluated and addressed.

I don't think so. Ultimately, it does not seem to be possible to get this through the PDP. The whole discussion is a bit odd: Even without RPKI, RIPE NCC already has the power to directly influence global routing because it's unreasonable to expect that the majority of their BGP peers employ strict filtering. So they could inject more specifics as they see fit, and thus blackhole pretty arbitrary chunks of address space. However, so can most folks who of those who control routers in the DFZ, and RPKI (or something similar) would change that at least.

Nick Hilliard (nick) writes:

Leaving aside technical matters, this is one of the more contentious political issues with RPKI. RPKI is a tool which can be used to locally influence routing decisions, but allows centralised control of prefix authenticity. If this central point is influenced to invalidate a specific prefix, then that will cause serious reachability problems for that prefix on the Internet.

To me that seems like the most obvious problem, but as Alex put it, "Everyone has the ability to apply an override on data they do not trust, or have a specific local policy for."

It will be difficult for politicians / legislators / LEAs to look at a technology like this and not see its potential for implementing wide-area Internet blocking.

For sure, the LEAs currently looking at it are extremely interested.

Or the ITU ? :) Cheers, Phil

On 28 Apr 2012, at 19:45, Nick Hilliard wrote:

On 28/04/2012 18:27, Phil Regnauld wrote:

...

To me that seems like the most obvious problem, but as Alex put it, "Everyone has the ability to apply an override on data they do not trust, or have a specific local policy for."

So what do you suggest to do with a roa lookup which returns "Invalid"?

In case you feel a BGP announcement should not be "RPKI Invalid" but something else, you do what's described on slide 15-17: https://ripe64.ripe.net/presentations/77-RIPE64-Plenery-RPKI.pdf -Alex

Rubens Kuhl (rubensk) writes:

...

In case you feel a BGP announcement should not be "RPKI Invalid" but something else, you do what's described on slide 15-17:

https://ripe64.ripe.net/presentations/77-RIPE64-Plenery-RPKI.pdf

The same currently happens with DNSSEC, doing what Comcast calls "negative trust anchors": http://tools.ietf.org/html/draft-livingood-negative-trust-anchors-01

Yes, NTAs was the comparison that came to my mind as well. Or even in classic DNS, overriding with stubs. You will get bitten by a bogus/ flawed ROA, but you'll have to the chance to mitigate it. Any kind of centralized mechanism like this is subject to these risks, no matter what the distribution mechanism is.

...

the worry in the ripe region and elsewhere is what i call the 'virginia court attack', also called the 'dutch court attack'. some rights holder claims their movie is being hosted in your datacenter and they get the RIR to jerk the attestation to your ownership of the prefix or your ROA.

If a Dutch court would order the RIPE NCC to remove a certificate or ROA from the system, the effect would be that there no longer is an RPKI statement about a BGP route announcement. The result is that the announcement will have the RPKI status *UNKNOWN*. It will be like the organization never used RPKI to make the statement in the first place.

Thus, removing a certificate or ROA *does NOT* result in an RPKI INVALID route announcement; the result is RPKI UNKNOWN.

The only way a court order could make a route announcement get the RPKI status *INVALID* would be to: 1: Remove the original, legitimate ROA 2: Tamper with the Registry, inject a false ROA authorizing another AS to make the announcement look like a hijack

How does this interact with the presence of certificates for supernets, though? That is, suppose an ISP creates a legitimate ROA for 12.0.0.0/8, after ensuring that all of its customers have legitimate ROAs for the various subnets of 12.0.0.0/8. Now, suppose one of these customers has its legitimate ROA revoked by a court order. Would the legitimate announcement of that subnet (originated by the customer's ASN) still result in UNKNOWN status, or would it look like a sub-prefix hijack because the announcement has a different ASN than the matching 12.0.0.0/8 prefix? -- Jen

On 29 Apr 2012, at 22:03, David Conrad wrote:

Alex,

On Apr 29, 2012, at 8:16 AM, Alex Band wrote:

...

All in all, for an RPKI-specific court order to be effective in taking a network offline, the RIR would have to tamper with the registry, inject false data and try to make sure it's not detected so nobody applies a local override.

I suspect the court order would simply say something like 'RIPE-NCC must, upon pain of contempt of court, take sufficient steps to invalidate the allocations made to customer X' and leave it up to you all to figure out how to do it. I doubt they'd care all that much about implementation details. Are you saying it is not possible for RIPE-NCC staff to do this? I also doubt the court would care too much about 'local override' as the "Tyranny of Defaults" would be sufficient for their needs (and they could probably sanction the folks in the Netherlands who they discovered did the override).

As Randy points out, this is not unique to SIDR-defined RPKI. It is applicable to any top-down hierarchical authorization mechanism. Security has (non-monetary) costs.

Thanks David, I know that a court order doesn't have to specific. I just want to make people aware that in the case of RPKI, things are not as clear cut as "Revoked ROA = Offline network". It depends on many factors and I just want to offer a little perspective of what's involved. -Alex (P.S. I'm going on holiday for a week without internet access, so I won't be able to follow up on this thread for a while)

On 29/04/2012 16:16, Alex Band wrote:

All in all, for an RPKI-specific court order to be effective in taking a network offline, the RIR would have to tamper with the registry, inject false data and try to make sure it's not detected so nobody applies a local override.

You mean, like an FBI domain seizure on the basis of a US court order? Realistically, it doesn't matter a whole lot if the occasional network here or there applies a local override. If their upstream transit provider isn't carrying the prefix (on the basis of similar simultaneous court orders), it's game over for that prefix. Nick

On 28/04/2012 14:04, Alex Band wrote:

At RIPE 63, six months ago, the RIPE NCC membership got a chance to vote on RPKI at the general meeting. The result was that the RIPE NCC has the green light to continue offering the Resource Certification service, including all BGP Origin Validation related functionality. It's correct that concerns were raised in the area of security, resilience and operator autonomy, as you mention. These concerns are continuously being evaluated and addressed. The response to the update that was given at RIPE 64 two weeks ago indicated that the membership and Community are happy with the approach the RIPE NCC is taking in this regard. Of course I realize that some people will never be convinced, no matter which steps are taken…

Alex, I have to take exception with your statement that people in the RIPE region are generally happy about RPKI and the RIPE NCC RPKI project. They aren't. On the basis of some initial interest in the RIPE community several years ago, the RIPE NCC embarked on a certification + rpki project. By way of clarification for other readers of this mailing list, the RIPE NCC is a Dutch company constituted to carry out the policy requirements of the RIPE community. The way this is supposed to work is that the RIPE community puts forward policy proposals, and the RIPE NCC carries these policies out. Some time after the certification project was started in the NCC, a policy proposal (2008-08) was floated in the RIPE community in order to turn this into official RIPE policy, so that it could be formally carried out by the RIPE NCC. Mid last year, after extensive and heated discussion on the address policy working group mailing list, that policy proposal was withdrawn from the RIPE policy development process because it was clear that a large number of people in the RIPE community were deeply uneasy about a variety of implications. It is true that some of these concerns have been addressed to some extent by the NCC, but the core issues of concern are fundamental to RPKI. Later that year, several potential proposals were put forward by the RIPE NCC board at the Nov 2011 general meeting concerning the future of the RIPE NCC certification project. The RIPE NCC members - who are a fee-paying subset of the RIPE community - voted by 52% to 48% to keep funding the project. By any objective measure, this is an alarmingly slim majority. In short: - a substantial number of people, both within the RIPE community and within the RIPE NCC membership have serious concerns about the long-term legal consequences of this project which have not (in their opinion) been addressed adequately. - the RIPE NCC is now funding a project for which there is no consensus policy supported by the RIPE community, and is doing this on the basis of a hair's breath majority vote amongst its membership. Nick

On Sun, 2012-04-29 at 21:50 +0100, Nick Hilliard wrote:

- the RIPE NCC is now funding a project for which there is no consensus policy supported by the RIPE community, and is doing this on the basis of a hair's breath majority vote amongst its membership.

Not only were the vote extremely narrow, a whopping ~97% of the voters did not vote at all. If we incorporate the no-shows, the vote statistics becomes something like: 120 Yes 114 No 26 Abstain ~7400 No-shows The membership got a chance to speak on the topic and largely didn't. Best, Martin

Danny, just one more comment. So named vendor's support can be the worst case when there are no practical ways to deploy and it is absolutely not clear - should we follow this hierarchical model - I think it is the key point as we pushed ourselves by inertia to this way of thinking. Imho - it is way to nowhere in such form We need more flexible, distributed architecture behind - no matter - which interests will be lobbied as we have got already. On Apr 30, 2012, at 6:53 PM, Danny McPherson wrote:

On Apr 28, 2012, at 6:34 AM, Alex Band wrote:

...

All in all, RPKI has really good traction and with native router support in Cisco, Juniper and Quagga, this is only getting better.

We should be more careful with statements such as this, they're conflating important things that add to the confusion in this area.

None of these implementations support "RPKI" today. What they support is a new protocol for onboarding routing policy data (some call this a [VRP], essentially prefix,origin bindings) into soft state in a router.

-danny

[VRP] https://ripe64.ripe.net/presentations/74-120417.sidr-origin.pdf

Personally I find the BitTorrent approach interesting. Jared Mauch On Apr 30, 2012, at 11:46 AM, Randy Bush <randy@psg.com> wrote:

...

We need more flexible, distributed architecture behind - no matter - which interests will be lobbied as we have got already.

as i agree that there is a problem, i *very* eagerly await your proposal

randy

Randy - you know that I'm enough stupid- means straightforward - may be the way is not only technical (recomendations design) - but also to combine with some policy changes as splitting allocations and assignments (may be changing who is responsible for what?) Or we follow the traditional way(means hierarchy) or we are capable to introduce one more level for flexebility - we should be honest that all techinical design just follows some political or quasi-political decisions. But I think it can be changed. Dima On Apr 30, 2012, at 7:46 PM, Randy Bush wrote:

...

We need more flexible, distributed architecture behind - no matter - which interests will be lobbied as we have got already.

as i agree that there is a problem, i *very* eagerly await your proposal

randy

On Mon, 30 Apr 2012 11:46:06 -0400 Randy Bush <randy@psg.com> wrote:

...

We need more flexible, distributed architecture behind - no matter - which interests will be lobbied as we have got already.

as i agree that there is a problem, i *very* eagerly await your proposal

As Radia says in her book, we're probably stuck with BGP forever, but I frequently wonder if she is right in suggesting we could have done better by having a link state protocol instead. It trades some set of problems for another, but I don't find the dread this might instill reason enough to avoid putting some research effort into it. John

Yes, recursive dependencies are an issue. I'm really surprised that folks are even seriously considering something like this, but OTOH, this sort of thing keeps cropping up in various contexts from time to time, sigh.

There are only a couple of ways to get past recursive dependencies. You could simply carry everything in one protocol. This really isn't practical. You could develop an overlay protocol that carries the additional information, so that internal routing is all that's needed to get to the information you need to build external routing. We already have this, to some degree today, with IGP/BGP. You could design a system where most service providers who are likely to be an upstream would be able to hold the information to kick start a peer or customer's external routing, so the peer or customer only needs a default to the upstream to get what they need. #2 is the most desirable overall, but #3 is what we're most likely to wind up with in the real world, for various reasons. And I don't know that #3 is a bad result. There are situations where it won't work (mostly thinking high mobility environments, or complete system failures), but these don't seem to be big "stoppers," to me.... But again, here is something that should be brought into the requirements process in the IETF and discussed as fully as possible, and then that discussion recorded in a requirements document. AFAIK, it's never really been discussed seriously, with all the options, advantages, and disadvantages, enumerated and considered. Russ -- <>< riwhite@verisign.com russw@riw.us

more "threads from the crypt" as i catch up to 6000 missed nanog posts. "Dobbins, Roland" <rdobbins@arbor.net> writes:

On Apr 28, 2012, at 5:17 PM, Saku Ytti wrote:

...

People might scared to rely on DNS on accepting routes, but is this really an issue?

Yes, recursive dependencies are an issue. I'm really surprised that folks are even seriously considering something like this, but OTOH, this sort of thing keeps cropping up in various contexts from time to time, sigh.

so, first, i think you mean circular dependencies not recursive dependencies. second, i'd agree that that's probably bad engineering. third, rsync's dependencies on routing (as in the RPKI+ROA case) are not circular (which i think was david conrad's point but i'll drag it to here.) my reason for not taking ROVER seriously is that route filter preparation is an essentially offline activity -- you do it from a cron job not "live". and to do this you have to know in advance what policy data is available which may or may not have the same coverage as "the routes you will receive between one cron job and the next". we could in other words use DNS to store route policy data if we wanted to use a recursive zone transfer of all policy zones, as a replacement for rsync. (but why would we do this? we have rsync, which worked for IRR data for many years.) ROVER expects that we will query for policy at the instant of need. that's nuts for a lot of reasons, one of which is its potentially and unmanageably circular dependency on the acceptance of a route you don't know how to accept or reject yet. my take-away from this thread is: very few people take RPKI seriously, but even fewer take ROVER seriously. -- Paul Vixie KI6YSY

On 5/28/2012 9:42 PM, David Conrad wrote:

On May 28, 2012, at 1:59 PM, Paul Vixie wrote:

...

third, rsync's dependencies on routing (as in the RPKI+ROA case) are not circular (which i think was david conrad's point but i'll drag it to here.) Nope. My point was that anything that uses the Internet to fetch the data (including rsync) has a circular dependency on routing. It's just a question of timing.

when you say it's a question of timing, i agree, but then i think you won't agree again. in batch mode i can express a policy that's true from that moment forward until removed. in real time mode i have to be able to express a policy which is both valid and reachable at the moment of validation. that's a question of timing but the word "just" as in "just a question of timing" trivializes a galaxy-sized problem space.

...

ROVER expects that we will query for policy at the instant of need. Might want to review https://ripe64.ripe.net/presentations/57-ROVER_RIPE_Apr_2012.pdf, particularly the slide entitled "Avoid a Cyclic Dependency".

i read it. this is also what draft-gersch-grow-revdns-bpg says. this makes for a "fail open" design -- the only thing the system can reliably tell you is "reject". this precludes islands of, or a mode of, "fail closed". while i don't consider a mode of "fail closed" to be practically likely, i'd like to preserve the fig leaf of theoretical possibility. (and the more likely possibility that islands of "fail closed" could be sewn in.)

As far as I can tell, ROVER is simply Yet Another RPKI Access Method like rsync and bittorrent with its own positives and negatives.

i can tell more than that. rover is a system that only works at all when everything everywhere is working well, and when changes always come in perfect time-order, where that order is nowhere defined, and is in any event uncontrollable. rsync's punt of the ordering problem is batch mode with policy start times rather than policy valid instants. to my mind anyone who doesn't punt the ordering problem has to instead solve it. rover does neither. paul

On 5/29/2012 10:27 AM, Stephane Bortzmeyer wrote:

On Mon, May 28, 2012 at 10:01:59PM +0000, paul vixie <vixie@isc.org> wrote a message of 37 lines which said:

...

i can tell more than that. rover is a system that only works at all when everything everywhere is working well, and when changes always come in perfect time-order, Exactly like DNSSEC.

no. dnssec for a response only needs that response's delegation and signing path to work, not "everything everywhere".

So, DNSSEC is doomed :-)

i hope not. if we had to start over on something that can protect the cache against trivial pollution and also enable new applications like DANE, we'd be ten years from first prototype instead of ten years from ubiquity. paul

On 29 May 2012, at 16:21, David Conrad wrote:

On May 29, 2012, at 4:02 AM, paul vixie wrote:

...

...

...

i can tell more than that. rover is a system that only works at all when everything everywhere is working well, and when changes always come in perfect time-order, Exactly like DNSSEC.

no. dnssec for a response only needs that response's delegation and signing path to work, not "everything everywhere".

My impression was that ROVER does not need "everything, everywhere" to work to fetch the routing information for a particular prefix -- it merely needs sufficient routing information to follow the delegation and signing path for the prefix it is looking up. However, I'll admit I haven't looked into this in any particular depth so I'm probably wrong.

RPKI needs the full data set to determine if a BGP prefix has the status 'valid', 'invalid' or 'unknown'. It can't work with partial data. For example, if you are the holder of 10.0.0.0/16 and you originate the full aggregate from AS123 and a more specific such as 10.0.1.0/24 from AS456, then you will need a ROA for both to make them both 'valid'. If you only authorize 10.0.0.0/16 with AS123, then the announcement from AS456 will be 'invalid'. If you only authorize 10.0.1.0/24 from AS456, the announcement from AS123 will remain 'unknown'. So in RPKI, partial data – so you failed to fetch one of the ROAs in the set – can make something 'invalid' or 'unknown' that should actually be 'valid'. http://tools.ietf.org/html/rfc6483#page-3 As far as I know, ROVER doesn't work like that. You can make a positive statement about a Prefix+AS combination, but that doesn't mark the origination from another AS 'unauthorized' or 'invalid', there merely isn't a statement for it. (Someone please confirm. I may be wrong.) -Alex

On 29 May 2012, at 18:33, Richard Barnes wrote:

...

...

...

...

...

i can tell more than that. rover is a system that only works at all when everything everywhere is working well, and when changes always come in perfect time-order, Exactly like DNSSEC.

no. dnssec for a response only needs that response's delegation and signing path to work, not "everything everywhere".

My impression was that ROVER does not need "everything, everywhere" to work to fetch the routing information for a particular prefix -- it merely needs sufficient routing information to follow the delegation and signing path for the prefix it is looking up. However, I'll admit I haven't looked into this in any particular depth so I'm probably wrong.

RPKI needs the full data set to determine if a BGP prefix has the status 'valid', 'invalid' or 'unknown'. It can't work with partial data. For example, if you are the holder of 10.0.0.0/16 and you originate the full aggregate from AS123 and a more specific such as 10.0.1.0/24 from AS456, then you will need a ROA for both to make them both 'valid'. If you only authorize 10.0.0.0/16 with AS123, then the announcement from AS456 will be 'invalid'. If you only authorize 10.0.1.0/24 from AS456, the announcement from AS123 will remain 'unknown'.

So in RPKI, partial data – so you failed to fetch one of the ROAs in the set – can make something 'invalid' or 'unknown' that should actually be 'valid'. http://tools.ietf.org/html/rfc6483#page-3

I wouldn't read that as saying that the RPKI requires you to have full data in order to provide any benefit. Where sufficient certs and ROAs exist to validate an announcement, you can mark it valid/invalid -- just like ROVER, but with a harder failure case.

I don't mean that you need ROAs describing every route announcement in existence for it to be useful. What I mean is for an operator to determine if a route announcement is RPKI valid, invalid or unknown, they will need *all* ROAs that *have been created*. If they miss a ROA in the data set during the fetching process, a route can end up with the incorrect validity state. See my example.

...

As far as I know, ROVER doesn't work like that. You can make a positive statement about a Prefix+AS combination, but that doesn't mark the origination from another AS 'unauthorized' or 'invalid', there merely isn't a statement for it. (Someone please confirm. I may be wrong.)

Of course, there's a reason that an announcement that contradicts a ROA is marked as invalid [RFC6483]. Such announcements are hijacks, the attacks that the RPKI is designed to prevent. If ROVER doesn't provide a hard fail here, then it would seem to not be providing much security benefit.

That does seem the case. I don't think ROVER provides a hard fail. Can someone confirm?

I agree with the person higher up the thread that ROVER seems like just another distribution mechanism for what is essentially RPKI data.

But does that distribution method easily allow you to get the full set of available data? -Alex

On 2012-05-29 5:37 PM, Richard Barnes wrote:

...

...

I agree with the person higher up the thread that ROVER seems like just another distribution mechanism for what is essentially RPKI data.

noting, that up-thread person also said "i havn't studied this in detail so i'm probably wrong."

...

But does that distribution method easily allow you to get the full set of available data? From what little I know, it seems to me that ROVER is optimized for point queries, rather than bulk data access. Which is the opposite of making it easy to get full data :)

that's close to the problem but it is not the problem. RPKI is a catalogue. it's possible to fetch all of the data you could need, before starting what's basically the "batch job" of computing the filters you will use at BGP-reception-time to either accept or ignore an incoming route. if your "fetch and recompute" steps don't work, then you'll have to continue filtering using stale data. if that data becomes too stale you're likely to have to turn off the filtering until you can resynchronize. ROVER is not a catalogue. it's impossible to know what data you could need to precompute any route filters, and it's impossible to know what 'all possible rover data' is -- in fact that would be a nonsequitur. you could i suppose query for every possible netblock (of every possible size) but that's an awful lot of queries and you'd have to do it every day in order to see new stuff or to know when to forget old stuff. the problem is in time domain bounding of data validity and data reachability. ROVER expects you to be able to query for the information about a route at the time you receive that route. that's point-in-time validity and reachability, which you might not have depending on where the DNS servers are and what order you're receiving routes in. RPKI+ROA expects you to have periodic but complete access to a catalogue, and then your future use of the data you fetched has only the risk of staleness or invalidity, but never reachability. as others have stated, there is no reference collection of bad ideas. otherwise we would have written this one up in 1996 when a couple of dns people looked at the routing system and said 'hey what about something like [ROVER]?' and the routing people explained in detail why it wouldn't work. paul

http://www.cafepress.com/nxdomain/8592477 randy, who will be wearing his at nanog

oops! should acknowledge that it was a gracious gift from geoff, to whom i had introduced http://sugru.com/ the hacker's playdough randy

On May 29, 2012, at 8:23 AM, Alex Band wrote:

RPKI needs the full data set to determine if a BGP prefix has the status 'valid', 'invalid' or 'unknown'. It can't work with partial data.

I think I now understand concerns about scaling... :-) Regards, -drc

"ah, the force is strong in this one." On 2012-05-30 3:52 AM, Shane Amante wrote:

On May 29, 2012, at 9:23 AM, Alex Band wrote:

...

...

As far as I know, ROVER doesn't work like that. You can make a positive statement about a Prefix+AS combination, but that doesn't mark the origination from another AS 'unauthorized' or 'invalid', there merely isn't a statement for it. (Someone please confirm. I may be wrong.) Actually, I believe it does. Specifically, there are two types of DNS RR's: a) RLOCK: Route Lock b) SRO: Secure Route Origin Please refer to the following URL for definitions of each: <http://tools.ietf.org/html/draft-gersch-grow-revdns-bgp-00#section-3>.

as dns is an unreliable protocol, and is not atomic across multiple questions, what is the effect of seeing one of those rrsets but not the other? (here again we see the disadvantage of starting from incomplete information.) On 2012-05-30 4:24 AM, Shane Amante wrote:

On May 29, 2012, at 8:44 PM, Paul Vixie wrote:

...

...

the problem is in time domain bounding of data validity and data reachability. ROVER expects you to be able to query for the information about a route at the time you receive that route. that's point-in-time validity and reachability, which you might not have depending on where the DNS servers are and what order you're receiving routes in. RPKI+ROA expects you to have periodic but complete access to a catalogue, and then your future use of the data you fetched has only the risk of staleness or invalidity, but never reachability.

as others have stated, there is no reference collection of bad ideas. otherwise we would have written this one up in 1996 when a couple of dns people looked at the routing system and said 'hey what about something like [ROVER]?' and the routing people explained in detail why it wouldn't work. Just one correction to the above. As pointed out in Section 4 of draft-gersch-grow-revdns-bgp-00 "near-real-time route origin verification" is merely one instantiation of the "ROVER concept". Please refer to that section for other potential uses of such published data.

my comment on that draft was (on the dnsop mailing list, march 10, 2012):

your draft-gersch-dnsop-revdns-cidr-01 is very clean and simple; the draft and the design are of admirable quality. as a co-author of RFC 2317 i agree that it does not suit the needs of bgp security since it seeks only to provide a method of fully naming hosts, not networks.

importantly, i see no reference to RFC 1101 in your draft. RFC 1101 describes a way to name networks, and while at first it did not seem to be compatible with CIDR, implementation (in "netstat -r" back in BSD/OS 3.1) showed that RFC 1101 was in fact not as classful as it appeared. ... you may find that some of your work has already been done for you, or, you may find that this is related work that should be referenced in your draft along with the reasons why your proposed method is necessary.

joe and dan (authors of this draft) responded:

thanks for your comments and support. We will definitely reference RFC draft 1101 in our next version.

and indeed this was done, but weakly:

Changes from version 01 to 02 ... Expanded the related work discussion to include RFC 1101.

looking at draft -02 we see:

4.1. Naming via RFC 1101

The problem of associating records with network names dates back to at least [RFC1101]. This work coincides with some of the early development of DNS and discusses issues regarding hosts.txt files. The RFC observation makes a key observation that one should provide "mappings for subnets, even when nested".

The approach taken here clearly states how to map an IPv4 prefix that is on an octet boundary. The RFC maps "10.IN-ADDR.ARPA for class A net 10, 2.128.IN-ADDR.ARPA for class B net 128.2, etc." This is essentially the same as the approach proposed here, although we append an "m" label (discussed later in this document).

[RFC1101] also mentions more specific subnets, but the details are limited. We believe the approach proposed here builds on the best ideas from this RFC and expands on the details of how the naming convention would work.

in other words no explaination for why the existing RFC 1101 encoding will not serve, even though RFC 1101 encoding been used for network naming in the CIDR era, without limitation. this reader is left wondering, what's the real impetus here?

I would also ask people to expand their minds beyond the "it must have a (near-)real-time mechanism" directly coupled to the Control Plane" for a variety of reasons. Such a tight coupling of /any/ two systems inevitably, and unfortunately, will only fail at scale in ways that likely would never have been predicted a priori[1] --

i think you're paying insufficient attention to this discussion, if you think that failure predictions have not already been well made with respect to the rover approach to routing security.

...

[1] FWIW, Dave Meyer has been doing some thinking about "complexity" for a while now, drawing analogies from outside of networking/computing, and has some fascinating insight. I'm sure if there's enough interest, he'd be willing to discuss it. Who knows, we may even learn something. :-)

see also <http://queue.acm.org/detail.cfm?id=1242499>. paul

Another difference between RPKI and ROVER which hasn't come up much: RPKI incorporates a lot of pre-existing machinery from X.509 et al. This drags in some tedious detail which makes people's eyes cross, but it gives us some tools which simply aren't available in DNS at present. In particular, X.509's CRL mechanism combined with the way that RPKI uses CMS messages with single-use EE certificates means that in RPKI we have a way to revoke individual objects (eg, ROAs) at will. DNSSEC only just barely has revocation at all, and that only for DNSKEYs. The nearest equivalent to per-object revocation one could do in DNSSEC would be either: - generate a new ZSK, re-sign everything in the zone with the new ZSK except for the RRsets you want to get rid of, and revoke the old ZSK, or - keep as many distinct ZSKs in the zone as you intend to have distinctly revocable groups of objects in the zone, and make sure you sign the right objects with the right ZSKs. Neither of these solutions is very good: the first may involve re-signing a lot of data every time you change anything, while the latter is complex and tends to bloat the zone's apex DNSKEY RRset. I suppose a third option would be to make every DNS owner name in the reverse tree be a separate zone. Doesn't seem like an improvement. Summarizing a few other things other people have mentioned: - The normal operating mode with RPKI is to fetch everything rather than do a point query. We've spent the last decade or so making that harder to do with DNS (blocking AXFR/IXFR, using NSEC3 instead of NSEC, etc). This makes it fairly difficult to know in advance what queries one should be asking ROVER (as Paul Vixie puts it, ROVER isn't a catalogue). When I pressed the ROVER folks about this at the Paris IETF meeting, they mumbled something about maybe walking the IRR or other external databases as a way of knowing what DNS queries to issue. - Circular dependencies are a problem. Helical dependencies can be made to work, but this says that one probably should not be depending on routing to make a point query to make decisions about routing. If you look at the architecture of the existing RPKI validators (well, mine and BBN's, anyway, not sure about RIPE's but suspect they took the same approach), we've gone to some trouble to make sure that the validator will continue to work across network outages as long as the collected data haven't expired or been revoked. In theory one could do the same thing with bulk transfers of DNS (whether AXFR/IXFR or NSEC walking, if they worked) but it would not work well with point queries. - ROVER gives us no traction on path validation (BGPSEC), it's limited to origin validation. RPKI can certify both prefixes and ASNs, which gives it the basics needed to support path validation as well as origin validation. ASNs have no hierarchical structure, thus would be a very poor match for encoding as DNS names. - Some of the DNS aspects of ROVER are a little strange. In particular, as currently specified ROVER requires the relying party to pay attention to DNS zone cuts, which is not normal in DNS (the basic DNS model since RFC 883 has been that zones are something for the zone administrator to worry about, resolvers mostly just see a tree of RRsets). ROVER requires the relying party to check for the same data in multiple zones and pay close attention to zone cuts. While it is certainly possible to do all this, it is not a matter of issuing a simple DNS query and you're done. DNS caching effects can also complicate matters here if the zone structure is changing: think about what happens if you have cached responses to some (but not all) of the queries you need to make to figure out whether to allow a more specific route punched out of a larger prefix block. - The reuse of existing infrastructure argument for ROVER is somewhat disingenuous -- it's only partial reuse of existing infrastructure. ROVER's new encoding of prefixes as DNS names means that a lot of new stuff would need to be deployed, and attempting to be backwards compatible with the existing DNS reverse tree adds some complexity to ROVER's architecture (conflicting data for same prefix can appear in multiple zones, relying party has to sort this out, yum). As far as I can tell, ROVER doesn't solve any of the hard problems in RPKI. It's a different encoding of a partial subset of the data, with some of the features removed.

On Mon, May 28, 2012 at 08:59:28PM +0000, Paul Vixie <vixie@isc.org> wrote a message of 43 lines which said:

ROVER expects that we will query for policy at the instant of need. that's nuts for a lot of reasons, one of which is its potentially and unmanageably circular dependency on the acceptance of a route you don't know how to accept or reject yet.

If someone starts to announce 2001:db8:f00::/48 *and* all the name servers for 0.0.f.0.8.b.d.0.1.0.0.2.ip6.arpa are in 2001:db8:f00::/48, then I suggest that he is wrong, not Rover...

On May 1, 2012, at 4:34 AM, Dobbins, Roland wrote:

On Apr 28, 2012, at 5:05 AM, Paul Vixie wrote:

...

is anybody taking it seriously? It's hard to take seriously any proposal which is predicated upon recursive dependencies.

Do you mean the need to be able to use rsync to fetch the data to enable you to use rsync? Or the need to be able to use bittorrent to fetch the data to enable you to use bittorrent? Or the need to be able to use the DNS to fetch the data to enable you to use the DNS? Regards, -drc

Roland, On May 1, 2012, at 8:49 AM, Dobbins, Roland wrote:

On May 1, 2012, at 8:18 PM, David Conrad wrote:

...

...

It's hard to take seriously any proposal which is predicated upon recursive dependencies. Do you mean the need to be able to use [X] to fetch the data to enable you to use [X]? A lot more than just [X] is necessary in order to allow [X] transactions to work. ... - in this context, I'm specifically referring to routing.

So, you're saying that the entire RPKI+BGPSEC effort is hard for you to take seriously. OK. Regards, -drc