Subject: [sidr] Princeton University:: Impacting IP Address Reachability via RPKI Manipulations

From: Danny McPherson <[email-masked]>
Date: Wed, 20 Mar 2013 06:50:36 -0600

Interesting presentation here:

http://www.cs.bu.edu/~goldbe/papers/Cooper_RPKI_BFOC.pdf

"The RPKI (Resource Public Key Infrastructure) is a new infrastructure 
to secure Internet routing
It’s been in deployment since ~2011 But, it also creates new risks 
(misconfigurations and takedowns)
that could make IP prefixes unreachable"

Given we've been concerned (and vocal) about this from an operational 
perspective since RPKI's proposed "tight coupling" into BGPSEC 
discussions many years ago...

-danny

---

From: John Curran <[email-masked]>
Date: Wed, 20 Mar 2013 07:17:15 -0600

On Mar 20, 2013, at 6:50 AM, Danny McPherson <[email-masked]> wrote:

> "The RPKI (Resource Public Key Infrastructure) is a new infrastructure to secure Internet routing
> It’s been in deployment since ~2011 But, it also creates new risks (misconfigurations and takedowns)
> Given we've been concerned (and vocal) about this from an operational perspective since RPKI's proposed "tight coupling" into BGPSEC discussions many years ago...

So, I'm a little confused...  (wouldn't be the first time :-)

The presentation states "Importantly, RPKI validity must impact routing 
decisions.", which I guess we have to take as a truism if RPKI is to have 
any effect at all on routing security.  It then goes on to equate cert
revocation (and resulting loss of a ROA) with an impact to reachability. 

I don't understand how they conclude that loss of a ROA would be a 
reachability impacting event (on its own), since any party using  
routing policy as outlined in <draft-ietf-sidr-origin-ops-20> is
almost certainly going to end up using an announcement which is 
now NotFound origin instead... 

Danny - Is there really a "tight coupling" if providers are 
following the recommend BGP origin validation best practices?

/John

---

From: Arturo Servin <[email-masked]>
Date: Wed, 20 Mar 2013 10:20:37 -0300

And THE organization can also take down bgp-peers, shutdown interfaces,
etc.

	At the end, it is its space, they can revoke certs.

Cheers,
as

On 3/20/13 9:50 AM, Danny McPherson wrote:
> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr

---

From: Danny McPherson <[email-masked]>
Date: Wed, 20 Mar 2013 09:21:47 -0400

> following the recommend BGP origin validation best practices?

I said BGPSEC...  

-danny

---

From: Danny McPherson <[email-masked]>
Date: Wed, 20 Mar 2013 09:27:33 -0400

>> following the recommend BGP origin validation best practices?

However, my statement does apply to origin validation as well, in some envisaged deployment models...

-danny

---

From: John Curran <[email-masked]>
Date: Wed, 20 Mar 2013 07:33:18 -0600

>> following the recommend BGP origin validation best practices?

Got it - the presentation suggests that RPKI poses risks to network
reachability due to attack vectors on the certificate infrastructure
that impact ROAs, the loss of which may not actually cause reachability
issues if people are following best-practices, but would be true if 
there were a tight-coupling to routing, which there isn't with BGP 
origin preference, but might be with BGPSEC...  

I'm not sure I'd use that particular presentation's logic to try to 
make a point, but it's your example... ;-)

/John

---

From: "Carlos M. Martinez" <[email-masked]>
Date: Wed, 20 Mar 2013 11:17:42 -0300

<disclaimer: i haven't read the paper in full, i've started and so far
it seems more solid than the slide deck>

I agree with John's observations. We need to stop making the statement
"no roa == no route", because it's simply not true.

So far in my reading of the full paper, many of the 'vulnerabilities'
they mention (quotes intended, I'm not sure the word is properly applied
given the context) appear to (1) depend of how RPs handle the 'Unknown'
validity state, and, more deeply, (2) to the very nature of the
tree-based model of trust.

For (1), I believe that we're still a long way from dropping unknowns,
and we're definitely going to 'build the road as we go' (paraphrasing a
very well known Chilean poet). Additional work might be needed in this area.

For (2), I share the misgivings, but, do we have anything better ?
Should we stop using tree-based models of trust until we do? I don't
think so. Until now, this has worked reasonably well. Given the sheer
amount of certification authorities out there, the fiascos like Digi
Notar have not been that many. In the case of the RPKI we are talking
about a more restricted universe that can be audited more easily and
into which other safeguards could be built.

cheers!

~Carlos

---

From: "Roque Gagliano (rogaglia)" <[email-masked]>
Date: Wed, 20 Mar 2013 15:00:43 +0000

Danny,

Thanks for the link. I read the doc.

I do not believe the work has been peer-reviewed and I detected a couple of bizarre statements (such as deleting an object = revocation or the idea of "overwriting" a ROA to replace an existing one).

What I believe it adds to our work are a number of scenarios on how to implement grand-parenting (not all valid) if we ever decide to take that problem.

What specific finding(s) concerns you?

Roque

---

From: Richard Barnes <[email-masked]>
Date: Wed, 20 Mar 2013 11:15:22 -0400

Hey Danny,

I read the paper.  Maybe it's that I'm missing the voice-over for the
slides, but I don't really see anything new here.  Every new security
mechanism creates a new DOS possibility.  If you screw up your HTTPS cert
or your CA revokes it, your website goes down.  This happens because only
hard failures can provide real security guarantees.  As the presentation
notes, soft failure produces vulnerability -- a "depref invalid" policy
allows sub-prefix hijacking.

One other thing to note is that manipulation is indistinguishable from
legitimate revocation, at a technical level.  So the only solution here is
at the human layer, for RPKI relying party software to have operator
overrides.  Randy stated this better than I at a RIPE meeting many moons
ago -- with the RPKI, we're automatically handling a common error (hijacks
and fat-fingers) at the expense of having to deal manually with an uncommon
error (manipulation).

--Richard

On Wed, Mar 20, 2013 at 8:50 AM, Danny McPherson <[email-masked]> wrote:

> http://www.cs.bu.edu/~goldbe/**papers/Cooper_RPKI_BFOC.pdf<http://www.cs.bu.edu/~goldbe/papers/Cooper_RPKI_BFOC.pdf>
>
> perspective since RPKI's proposed "tight coupling" into BGPSEC discussions
> many years ago...
>
> -danny
>
> ______________________________**_________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/sidr<https://www.ietf.org/mailman/listinfo/sidr>
>

---

From: Danny McPherson <[email-masked]>
Date: Wed, 20 Mar 2013 09:21:20 -0600

On 2013-03-20 09:00, Roque Gagliano (rogaglia) wrote:

> I do not believe the work has been peer-reviewed and I detected a
> couple of bizarre statements (such as deleting an object = revocation
> or the idea of "overwriting" a ROA to replace an existing one).

Much of the work presented here is not "peer reviewed'.  Paper is here:

http://www.cs.bu.edu/~goldbe/papers/RPKImanip.html

I'm sure the authors would welcome comments.

> What I believe it adds to our work are a number of scenarios on how
> to implement grand-parenting (not all valid) if we ever decide to 
> take
> that problem.
>

The general observation as an operator that this would potentially 
impact my operations (and reachability to my peers, etc..) but is 
outside of my control, and that sufficient buffers are required here. 
Nothing new, just another datapoint for folks with various 
perspectives..

-danny

---

From: Danny McPherson <[email-masked]>
Date: Wed, 20 Mar 2013 09:24:31 -0600

On 2013-03-20 09:15, Richard Barnes wrote:

>
> One other thing to note is that manipulation is indistinguishable
> from legitimate revocation, at a technical level.  So the only
> solution here is at the human layer, for RPKI relying party software
> to have operator overrides.  Randy stated this better than I at a 
> RIPE
> meeting many moons ago -- with the RPKI, we're automatically handling
> a common error (hijacks and fat-fingers) at the expense of having to
> deal manually with an uncommon error (manipulation).

Yeh, I understand.  I'm saying as an operator this continues to concern 
me.  Just a datapoint for the WG.  Take it or leave it..

-danny

---

From: Russ White <[email-masked]>
Date: Wed, 20 Mar 2013 11:45:38 -0400

> "no roa == no route", because it's simply not true.

There's something I probably don't understand here...

1. SIDR's ROA/RPKI infrastructure is designed to provide security for
route origination.

2. Security for route origination means that you shouldn't be able to
advertise routes unless someone in the infrastructure (other than you)
has stated (publicly through a signed certificate) "this is a valid route."

3. But... If there's no certificate for a route, it's perfectly fine to
advertise it and route to it.

It seems, to me, that if the RPKI can't be used to actually validate who
owns what route with certainty, we're going to a lot of trouble for
nothing... Or maybe folks are trying to have their cake and eat it to.
"We'll provide solid security which you can ignore if you like, no
problem."

I know this goes back to the difference between "unknown," and
"invalid," but if all address space which no-one actually claims is open
for whatever use anyone wants, then are we really making any progress in
any meaningful way?

Just a thought...

:-)

Russ

---

From: "Roque Gagliano (rogaglia)" <[email-masked]>
Date: Wed, 20 Mar 2013 15:58:06 +0000

inline.

On Mar 20, 2013, at 4:21 PM, Danny McPherson <[email-masked]> wrote:

>> to implement grand-parenting (not all valid) if we ever decide to take
>> that problem.
>> 
> The general observation as an operator that this would potentially impact my operations (and reachability to my peers, etc..) but is outside of my control, and that sufficient buffers are required here. Nothing new, just another datapoint for folks with various perspectives..
> 

got it. 

Roque

---

From: Jakob Heitz <[email-masked]>
Date: Wed, 20 Mar 2013 19:01:17 +0000

On , Russ White <> wrote:

>> I agree with John's observations. We need to stop making the
>> statement "no roa == no route", because it's simply not true.
> 

There is a difference.
Invalid: someone is certified to own it and someone ELSE is originating.
Unknown: No one is certified owner.

-- 
Jakob Heitz.

---

From: Russ White <[email-masked]>
Date: Wed, 20 Mar 2013 15:10:04 -0400

> statement "no roa == no route", because it's simply not true.

In response to a paper that says removing ROAs is a form of DoS, or that
there are potential problems in the space of the relationship between
the registry and the address owner, then we've moved from "unknown," to
"contested." The response given essentially says, "don't worry about
attacks, because in the case of attacks, we'll just ignore those ROA
thingies."

If that's the case, then why bother with the ROAs in the first place?

Again, you can't have your cake and eat it too... Either ROAs mean
something, and attacks against the ROA system are a real threat, or the
attacks are not worth worrying about --in which case, the ROAs
themselves don't mean anything from day one.

:-)

Russ

---

From: John Curran <[email-masked]>
Date: Wed, 20 Mar 2013 13:41:51 -0600

> attacks, because in the case of attacks, we'll just ignore those ROA

The problem in the paper was equating removing ROAs with DoS attacks
with actual reachability implications.

> If that's the case, then why bother with the ROAs in the first place?

ROAs provide a method to give your correct routes precedence over other
routes from (hostile) sources.  It is an optional service, and loss of 
the RPKI system is not loss of connectivity. 

The fact that it is optional doesn't mean that it won't be valued by
many folks for its use in routine operations.  (Just as you may value
having an alarm system for your home because of the protection it provides, 
its failure doesn't also automatically unlock your front door...)

> themselves don't mean anything from day one.

Loss of a ROA (e.g. due to an attack on the RPKI system) does not 
cause a _reachability event_ if folks are using best practices for 
route precedence; that's what was implied in the paper and is wrong.  
Successful attacks against the RPKI system do have an impact, but it 
is simply that you are again vulnerable to route hijacking.

FYI,
/John

---

From: Russ White <[email-masked]>
Date: Wed, 20 Mar 2013 15:51:18 -0400

> is simply that you are again vulnerable to route hijacking.

How often do you think an attacker would bother with taking out a ROA
without taking out the route as well? But this misses the larger point
--if the ROAs are supposed to provide security, then either:

1. Removing the ROAs is a problem in terms of increased risk, which is a
problem which needs to be addressed.

-OR-

2. Removing the ROAs isn't a problem, in which case we have to ask --why
bother?

You're trying to have your cake and eat it to. ROAs are important unless
they're not important, and you can't tell the difference by looking at
the RPKI system itself.

:-)

Russ

---

From: "Murphy, Sandra" <[email-masked]>
Date: Wed, 20 Mar 2013 20:14:11 +0000

Speaking as a regular ol' member

>"We'll provide solid security which you can ignore if you like, no

Routing policy has always been left to the local operator.  You suggest a change to a mandated global common policy.  I don't think that could ever fly with the operators.

>for whatever use anyone wants, then are we really making any progress in

So a flag day would be preferable, when everyone would be required to have certified their address space?

If not, incremental deployment requires handling the case of "no-one actually claims" the space.

For the "no-one actually claims" space, that space will be subject to the same attacks as exist now.  Pretty much the same with any new but unused protection system.

--Sandy, speaking as regular ol' member

---

From: John Curran <[email-masked]>
Date: Wed, 20 Mar 2013 14:19:35 -0600

On Mar 20, 2013, at 1:51 PM, Russ White <[email-masked]> wrote:

> without taking out the route as well?

Invert the question... Of the thousands of entities that could today 
inject (hostile) routes and do a hijack today, how many of them will 
be able to also mount an attack against the RPKI infrastructure?

> But this misses the larger point

I never argued with addressing the risks that might be posed; I was pointing 
out that the risk does not equate (on its own) with a reachability event, as 
alluded to by the paper.

/John

---

From: Russ White <[email-masked]>
Date: Wed, 20 Mar 2013 16:20:35 -0400

> Routing policy has always been left to the local operator.  You suggest a change to a mandated global common policy.  I don't think that could ever fly with the operators.

Of course --but clearly there is a difference between "not present," and
"under attack," something the current RPKI codes don't take into account.

> So a flag day would be preferable, when everyone would be required to have certified their address space?

Since it's going to take 20 years to deploy anyway (according to various
comments at the mic over the years, and on this and other lists)...

Or perhaps we need a way of telling whether something should have an
entry or not.

:-)

Russ

---

From: Russ White <[email-masked]>
Date: Wed, 20 Mar 2013 16:26:34 -0400

> out that the risk does not equate (on its own) with a reachability event, as 

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? If the registries issue "negative
ROAs," for all the address space they own, doesn't that immediately
break anyone who doesn't participate?

It seems, to me, that there's a problem in here that's likely to bite
someone in the butt once things really start to deploy (if they ever
really do start to deploy).

But, it's fine, we can put our fingers in our ears, say, "lalalala" as
loud as possible, and hope it's not "me" who gets the first crack as
being bitten by this particular bug.

As Danny said --this is a salient point in the conversation. I'll extend
that to say that if I were a provider, this would be a salient point in
my decision about deploying --or not-- this mechanism.

:-)

Russ

---

From: Arturo Servin <[email-masked]>
Date: Wed, 20 Mar 2013 17:30:05 -0300

That could be attacked as well. Then we will have something to tell
that an entry exists for the table that tells that roas exists.

:)

	What we probably need need is something that flags that a Certificate
or a ROA has disappeared in the last X time. Then as operator we could
take the action to decide if this was an attack or a valid revocation.

Regards,
as

---

From: "Murphy, Sandra" <[email-masked]>
Date: Wed, 20 Mar 2013 20:35:53 +0000

Speaking as regular ol' member

>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.

You certainly would not want to end up with a system that would not allow reclaiming address space.

--Sandy

---

From: Russ White <[email-masked]>
Date: Wed, 20 Mar 2013 16:41:47 -0400

> take the action to decide if this was an attack or a valid revocation.

That is probably a good idea... But since the ROAs are time based
themselves, it might be hard to do (?).

:-)

Russ

---

From: "Montgomery, Douglas" <[email-masked]>
Date: Wed, 20 Mar 2013 17:30:09 -0400

>themselves, it might be hard to do (?).

?

Maybe you mean they are signed by certs that have validity periods?

Monitor and log rpki-rtr protocol - look for ROA withdraws.  Wireshark
module to do that for you is here:
http://www-x.antd.nist.gov/bgpsrx/

Given that the kind of transformations that Sharon's work describes might
be the desirable actions of an ISP reclaiming resources from an
ex-customer, what actions will we take to decide otherwise?  Sandy's point
that such action might be viewed differently looking up the tree, rather
than down.

dougm

---

From: John Curran <[email-masked]>
Date: Wed, 20 Mar 2013 16:16:04 -0600

On Mar 20, 2013, at 2:26 PM, Russ White <[email-masked]> wrote:

> doesn't it?

Correct.  We have an ID which makes recommendations (but it is still
up to each provider what their specific policy will be)

From <draft-ietf-sidr-origin-ops-20> - 

   "Announcements with Valid origins SHOULD be preferred over those with
   NotFound or Invalid origins, if the latter are accepted at all.

   Announcements with NotFound origins SHOULD be preferred over those
   with Invalid origins.

   Announcements with Invalid origins SHOULD NOT be used, but MAY be
   used to meet special operational needs.  In such circumstances, the
   announcement SHOULD have a lower preference than that given to Valid
   or NotFound.

   When first deploying origin validation, it may be prudent to not drop
   announcements with Invalid orgins until inspection of logs, SNMP, or
   other data indicate that the correct result would be obtained."

> How can you tell the difference between a route with no ROA

No ROA is no ROA...  Should give way to routes with Valid origins.

> really do start to deploy).

If that's the case, you might want to make some suggestions of alternative 
text for "Section 5. Routing Policy" of draft-ietf-sidr-origin-ops-20>.  
As it is, it looks fairly solid in describing the situation at initial 
deployment and factors that an operator might want to consider in setting
their local policy.

Thanks!
/John

---

From: Arturo Servin <[email-masked]>
Date: Wed, 20 Mar 2013 19:22:16 -0300

> themselves, it might be hard to do (?).

	Not sure if it is so hard.

	If the ROA expires because of the date is not longer valid, then there
is normal and a high probability that there is no attack.

	Only, if the ROA is valid in the previous state and in the current is
revoked or missing, then you will alert.

> Russ

/as

---

From: "Borchert, Oliver" <[email-masked]>
Date: Wed, 20 Mar 2013 19:00:02 -0400

> >> 	What we probably need need is something that flags that a
> >> Certificate or a ROA has disappeared in the last X time. Then as
> >> operator we could take the action to decide if this was an attack or a valid
> revocation.
> >

But what does the alert tell me? 
What if one is multi homed, uses two ROAs then switches to be single homed and revokes the second ROA. In this case the owner revoked the ROA and this is not an attack - here the alert is not of help at all!

Oliver

---

From: Arturo Servin <[email-masked]>
Date: Wed, 20 Mar 2013 20:32:43 -0300

> What if one is multi homed, uses two ROAs then switches to be single homed and revokes the second ROA. In this case the owner revoked the ROA and this is not an attack - here the alert is not of he…

	That is the problem. It is almost impossible to know when a ROA is
revoked legally or by accident/attack. This would only be a mechanism to
alert when something changes, then you to decide as operator what to do.
But most probably you will end up ignoring all the alerts unless there
is a big fuss about it.

/as

---

From: Shane Amante <[email-masked]>
Date: Thu, 21 Mar 2013 08:25:11 -0600

> 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

---

From: Randy Bush <[email-masked]>
Date: Thu, 21 Mar 2013 16:36:05 +0200

aside from sharon, who is at bu, having gotten her degree at princeton,
how did it get in the $subject?

randy, who is not learning anything else new from this rinse repeat

---

From: Shane Amante <[email-masked]>
Date: Thu, 21 Mar 2013 09:20:02 -0600

> 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

---

From: Randy Bush <[email-masked]>
Date: Thu, 21 Mar 2013 17:22:31 +0200

> 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

---

From: "Murphy, Sandra" <[email-masked]>
Date: Thu, 21 Mar 2013 15:27:07 +0000

>So, you're stating that operator input wrt impacts the RPKI will have on their networks is not useful to 

Randy said "nothing new", not "nothing".

--Sandy, speaking as regular ol' member.

---

From: Sharon Goldberg <[email-masked]>
Date: Thu, 21 Mar 2013 12:48:10 -0400

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

---

From: John Curran <[email-masked]>
Date: Thu, 21 Mar 2013 15:27:46 -0400

> http://www.cs.bu.edu/~goldbe/papers/RPKImanip.pdf

Sharon - 
 
  Thanks for the pointer to the paper - it appears to be a far more 
  complete treatment of the topic than the summary slide deck.

/John

---

From: "Osterweil, Eric" <[email-masked]>
Date: Fri, 22 Mar 2013 10:39:01 -0400

> On 20/03/2013 20:00, Borchert, Oliver wrote:

<snip>

> But most probably you will end up ignoring all the alerts unless there

I think this thread brings up a very important (but subtle point).  Knowing that i) a ROA exists, but is not present is different than ii) a ROA that has been removed by a resource holder, and _that_ is different than iii) the grand-parenting issue… (though that could be a vector to effect case i), above)… For example:
i) An adversary intercepts a TCP session and selectively removes branches of a repo (including some ROAs) during an rsync session so that attestation is affected…  Yes, yes, I know the crypto makes this apparent, but that's at the cache-level… The RP just knows that there ain't no ROA there...
ii) (As mentioned above), resource holder changes their peering…
iii) A resource holder surgically takes a descendant's allocations away…

I think it is very important (as I think Doug M alluded to) that there be an understanding and some expressiveness around these corner cases.  If something is there, if something is validated, if something is not there, if something is missing (i.e. _should_ be there, but isn't) are all different.  With an understanding of these sorts of things, operators might be able to find policy knobs that they can use, and with _that_ maybe we can get some informed requirements…  Well, ideally, anyway… ;)

Eric

---

From: Stephen Kent <[email-masked]>
Date: Mon, 25 Mar 2013 11:19:44 -0400

Sharon,
> through methods other than (the obvious) revocation lists. See Section
The terminology above is not quite correct, since only one of the five
"methods" results in revocation per se. I suggest using the technical
term "whacking" instead. (You're a Princeton grad, so a NJ-inspired term
of this sort seems appropriate :-.)

Nonetheless, all of the methods for whacking a ROA described in the 
paper are detectable
by anyone who monitors the RPKI. One might argue that each resource 
holder should monitor
his/her RPKI pub point to detect any action that causes one's ROA to 
become unverifiable.
That's a very easy check, to perform. Also, the scenario addressed in 
2.2.1 is specific to
a very narrowly-defined class of resource holders who elected the third 
of three approaches
(not the preferred approach) to participating in the RPKI.
> grandparenting. See Sections 2.2.2, 2.2.3, and 2.3 of the report.
As above, the actions described in these sections are all easily 
detectable by
the targeted entity. So, the question is what that entity would/could do 
if it
detects this sort of activity by its parent (or grandparent). Unless the 
parent
was compelled to whack a ROA by a LEO, there is likely to be a legal 
remedy that
can be invoked. if a LEO is involved, then the situation is more 
complex, but I've
been working on a memo that describes remedies for that context as well. 
I'll share
it when it's been vetted by some more folks.

Steve

---

From: Randy Bush <[email-masked]>
Date: Tue, 26 Mar 2013 00:34:03 +0900

> paper are detectable by anyone who monitors the RPKI. One might argue
> that each resource holder should monitor his/her RPKI pub point to
> detect any action that causes one's ROA to become unverifiable.

thanks to shane for whacking me on this general area in taipei.  the
results are in draft-ietf-sidr-origin-ops-20.txt

   Operators should use tools which warn them of any impending ROA or
   certificate expiry which could affect the validity of their own data.
   Ghostbuster Records, see [RFC6493], can be used to facilitate contact
   with upstream CAs to effect repair.

and

   As reliable access to the global RPKI and an operator's caches (and
   possibly other hosts, e.g.  DNS root servers) is important, an
   operator SHOULD take advantage of relying party tools which report
   changes in BGP or RPKI data which would negatively affect validation
   of such prefixes.

> detectable by the targeted entity.

suggestions for strengthening the draft appreciated.  terse, steve,
terse :)

randy