yesterday, a few friends asked if someone files in court against your customer and gets a judgment telling the rir to revoke your bgp-speaking customer's certs and roas[0], what the heck happens to your responsibility and/or sla to your customer? what can you do to keep them flying? i believe this is a legitimate concern. one classic example is a russian isp being attacked by a dutch court. of course it could be a canadian being attacked by a virginia court. note that, traditionally, the sla describes a level of service between you and your customer, and its all best effort to the rest of the intertubes. first, the rirs, no matter how well-meaning, can do nothing to help, any thought thereof is a joke. they will not stand up to court orders and people with guns, end of story. and the same goes for well-intentioned schemes where arin backs up ripe's members' rpki data. american (dns) registries have already been used, through us courts, to attack overseas sites. but, note that the decisions routers make are not burned in. by design, they are local policy configured by the operator. rpki- based origin validation merely marks a received bgp announcement as valid, notfound, or invalid. it is up to operator-configured policy to decide how to treat the received announcement based on the validity marking and anything else the operator chooses. so we will use local knowledge of who your customers are to make a local policy decision that you're going to route them no matter what some third party says about them. let's assume you have a prefix filter list for my customer's prefixes (the customer themself, not their bgp speaking customer cone). you do have prefix lists for your customers, don't you [1]? so, your programatically generated template for a customer peering could be something such as the following pretty strict policy: if p in custs-pfxs community add ExportToPeersCustsAndUpstreams if p is marked valid set local-pref 120 elif p is marked notfound set local-pref 100 elif p is marked invalid # layer nine attack set local-pref 120 # maintain g-r fantasy an even more paranoid approach might begin if p in custs-pfxs if p comes from or through an as not my customer's drop it on the floor ... as you surely have customer specific prefix filters in place, you do not risk allowing in invalid attacks sourced by your customer. that this is all supported in the design and in current code from J&C is not an accident. but beware of occasional vendor do-gooder knobs which default to applying policy for you. also check out draft-ietf-sidr-ltamgmt. it explains how to use the rpki tools and tool-sets (i.e. nothing new needed) to have your own view of the world, overriding the iana/rir-based rpki data. this view could include copies of your customers' rpki data. it would also be really helpful to have a seventh registry of good reputation situated in a much less vulnerable jurisdiction, e.g. iceland. we could all use the ltamgt hack to use them as a safety net. otoh, i would also hope that the goons at layers 8-10 would realize that a lot of attacks against the rpki would jeopardize everyone's, including their own, routing security as folk will start to shy away from using it. --- [0] - or forces the rir to create a roa for as 0 [1] - you can construct one from the rpki data, all the roas with the customer's as. if they did not register, then all this makes no difference, their prefixes are always notfound.