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

[Danny McPherson]

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

[John Curran]

On Mar 20, 2013, at 6:50 AM, Danny McPherson <***@tcb.net> wrote:

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

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

[Danny McPherson]

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

I said BGPSEC...

-danny

[Danny McPherson]

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

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

-danny

[John Curran]

On Mar 20, 2013, at 7:21 AM, Danny McPherson <***@tcb.net> wrote:

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

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

[Carlos M. Martinez]

<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




On 3/20/13 10:17 AM, John Curran wrote:
> On Mar 20, 2013, at 6:50 AM, Danny McPherson <***@tcb.net> wrote:
>
>> 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...
>
> 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
>
> _______________________________________________
> sidr mailing list
> ***@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr
>

[Russ White]

> I agree with John's observations. We need to stop making the statement
> "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

[Jakob Heitz]

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'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?

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


--
Jakob Heitz.

[Russ White]

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

Yes, I know that --but when someone says this:

> I agree with John's observations. We need to stop making the
> 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

[John Curran]

On Mar 20, 2013, at 1:10 PM, Russ White <***@riw.us> wrote:

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

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

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

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

[Russ White]

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

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

[John Curran]

On Mar 20, 2013, at 1:51 PM, Russ White <***@riw.us> wrote:

> How often do you think an attacker would bother with taking out a ROA
> 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
> --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.

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

[Russ White]

>> 1. Removing the ROAs is a problem in terms of increased risk, which is a
>> problem which needs to be addressed.
>
> 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.

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

[Murphy, Sandra]

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.

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

--Sandy

[Shane Amante]

On Mar 20, 2013, at 2:35 PM, "Murphy, Sandra" <***@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
> ***@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr
>

[John Curran]

On Mar 20, 2013, at 2:26 PM, Russ White <***@riw.us> wrote:

>> 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.
>
> That all depends on the policy undertaken by each specific provider,
> 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
> because the registry has decertified, and a route with no ROA simply
> because one hasn't ever been created?

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

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

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

[Randy Bush]

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

[Shane Amante]

On Mar 21, 2013, at 8:36 AM, Randy Bush <***@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

[Randy Bush]

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

[Murphy, Sandra]

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

[Sharon Goldberg]

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

[John Curran]

On Mar 21, 2013, at 12:48 PM, Sharon Goldberg <***@cs.bu.edu> wrote:

> 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

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

[Stephen Kent]

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

[Randy Bush]

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

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.

> As above, the actions described in these sections are all easily
> detectable by the targeted entity.

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

randy

[Sharon Goldberg]

Steve,

Thanks for your careful reading of our report. We have some questions for
you inline:

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

Yes, exactly. We should change all our reports to say "whacked" :)

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

We agree that monitoring is important and in fact we are working on such a
monitor right now.

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

To clarify, which 3 approaches do you mean?

In 2.2.1 we consider an org B who has its own ASN but chooses not to have
its own resource cert; instead, it has org A issue its ROA. (This is one
of two recommendations in RFC6480 Section 7.3.2 first paragraph.) In this
case, the parent org A can whack org B's ROA in surreptitious ways, without
explicitly using revocation lists.

In the case where org B has its own resource cert, ROA whacking is more
detectable, because it might involve issuing new ROA, grandparenting, etc.
We discuss that in Sections 2.2.2-2.2.3, 2.3-2.5.

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

We'll look forward to this -- more information about legal remedies
will be useful to inform further investigations on our end.

We are particularly curious about how legal recourse would play out in
cases where the targeted party is in a different country than the party
that whacked its ROA. For example, what if an American organization whacks
a ROA for an AS in a different country (or vice versa)?

We did some analysis of when a subject in one country can whack a ROA for
an AS in another country. See the heatmaps on slide 10-11 of the slide
deck:

http://www.cs.bu.edu/~goldbe/papers/Cooper_RPKI_BFOC.pdf
To get these, we took data on the direct-allocations from each RIR, and
then used routeviews and RIPE RIS data to determine for each
directly-allocated prefix, how many different ASes originate the prefix or
any of its subprefixes. We show this in slide 10. To get slide 11, we
then use the AS-to-country mappings provided by the RIRs to determine the
number of countries that have ASes who originate prefixes that are covered
by the directly allocated prefix. (Note we are in the midst of writing up
a full report of these results, that I'll share with the list in a month or
two.)

So, if we suppose that prefixes directly allocated by the RIRs are given
their own resource certs, we see that these resource certs can whack ROAs
for ASes in multiple countries. (Look at 8/8 or 12/8, for example.) How
would takedowns play out if they cross national borders?

Sharon

--
Sharon Goldberg
Computer Science, Boston University
http://www.cs.bu.edu/~goldbe

[Danny McPherson]

On 2013-04-01 10:17, Sharon Goldberg wrote:

> So, if we suppose that prefixes directly allocated by the RIRs are
> given their own resource certs, we see that these resource certs can
> whack ROAs for ASes in multiple countries. (Look at 8/8 or 12/8, for
> example.)  How would takedowns play out if they cross national
> borders?

Various flavors of this "whacking" happens a *great deal* today in the
DNS operations space, where LEOs engage with registries or registrars
because they have operations within direct or MLAT reach, as opposed
engaging directly with a registrar, registrant, or the transacting
systems / operators themselves. Certainly, RPKI will help some with the
latter of these (i.e., whack transacting systems rather than enablers).

-danny

[John Curran]

On Apr 1, 2013, at 2:03 PM, Danny McPherson <***@tcb.net> wrote:

> On 2013-04-01 10:17, Sharon Goldberg wrote:
>
>> So, if we suppose that prefixes directly allocated by the RIRs are
>> given their own resource certs, we see that these resource certs can
>> whack ROAs for ASes in multiple countries. (Look at 8/8 or 12/8, for
>> example.) How would takedowns play out if they cross national
>> borders?
>
> Various flavors of this "whacking" happens a *great deal* today in the DNS operations space, where LEOs engage with registries or registrars because they have operations within direct or MLAT reach, as opposed engaging directly with a registrar, registrant, or the transacting systems / operators themselves. Certainly, RPKI will help some with the latter of these (i.e., whack transacting systems rather than enablers).

The present equivalent for the RIRs would be LEO's engaging in orders
to change the address holder associated with an IP block, and I am
happy to say that (at least in ARIN's case) that we have not seen any
such requests to date. We do work extremely well with law enforcement,
but relations are predominantly focused on obtaining information for
various investigations. ARIN serves more than 25 different countries,
and as much as possible expects to see LEO requests to involve LEA in
the country of the resource holder except in extremis cases. An actual
uncoordinated LEO order to change a registrant on an IP block could be
rather problematic; there is some chance that I would end up needing a
toothbrush and good reading material depending on the country of the
registrant & nature of the circumstances.

FYI,
/John

John Curran
President and CEO
ARIN

[Danny McPherson]

On 2013-04-01 14:37, John Curran wrote:

> The present equivalent for the RIRs would be LEO's engaging in orders
> to change the address holder associated with an IP block, and I am
> happy to say that (at least in ARIN's case) that we have not seen any
> such requests to date.

That's intuitive given that RIRs don't have an operational role in
connectivity today. E.g., you can do whatever you want, operators don't
need you to route stuff. The crux is that RPKI will change that.

> We do work extremely well with law enforcement,
> but relations are predominantly focused on obtaining information for
> various investigations. ARIN serves more than 25 different
> countries,
> and as much as possible expects to see LEO requests to involve LEA in
> the country of the resource holder except in extremis cases. An
> actual
> uncoordinated LEO order to change a registrant on an IP block could
> be
> rather problematic; there is some chance that I would end up needing
> a
> toothbrush and good reading material depending on the country of the
> registrant & nature of the circumstances.

Heh.. We receive hundreds of court orders (many sealed) a year
involving literally thousands of domain names (and varying actions) and
the registrars, registrants, and resources to which they map are all
over the globe. It's not something we're particularly fond of for an
array of reasons, as you can imagine, but we usually don't have any
choice. Fortunately, RPKI will provide them a more effective
alternative ;-)

-danny


>
> FYI,
> /John
>
> John Curran
> President and CEO
> ARIN

[John Curran]

On Apr 1, 2013, at 7:24 PM, Danny McPherson <***@tcb.net> wrote:

> On 2013-04-01 14:37, John Curran wrote:
>
>> The present equivalent for the RIRs would be LEO's engaging in orders
>> to change the address holder associated with an IP block, and I am
>> happy to say that (at least in ARIN's case) that we have not seen any
>> such requests to date.
>
> That's intuitive given that RIRs don't have an operational role in connectivity today. E.g., you can do whatever you want, operators don't need you to route stuff. The crux is that RPKI will change that.

I'm not certain its all that different (particularly not in the early
stages of RPKI deployment)... In theory, we could receive an order to
reassign an address block to another party (with similar consequences
today for those following whois and or irr data.)

[Danny McPherson]

On 2013-04-01 20:31, John Curran wrote:

>
> Indeed, there will be some that see RPKI as a possible new approach
> for such matters. The registry needs to be consistent (i.e. across
> registration data, Whois publication, and RPKI publication) and we'll
> certainly seek to prevent RPKI-specific actions as inconsistent with
> our mission.

Speaking of inconsistencies in the RPKI, what's ARIN and the NRO's
status on getting to a single trust anchor?

> Also, we have some past success dealing with non-sensical
> directives, e.g. an order to reassign a single IP address from the
> midst of a ISP's IP block to another party, but to the extent we get
> a lawful order to change the address block registered to a party in
> their jurisdiction, it's going to be fairly challenging situation.

Yeah, they were nonsensical in the past and present role of ARIN, not
in an RPKI-enabled world where revocation or transfer or inaccessibility
will have some impacted on the routability of the address block in
question.

> Our best bet may be simply continuing to educate law enforcement
> about
> the difficulty of attempting granular actions on an IP address block
> basis (as contrasted to the DNS layer);

I suspect they long ago realized RIRs have traditionally had little to
no role in this, and they reach out to ISPs where possible. Again, I'd
wager this will change, but alas, only time will tell.

> from your report, it seems that they've gotten the message so far...
> ;-)

I doubt your messaging has impacted this, but if so, you might tell
them all the reasons it's stupid as well, and simply forces diffusion,
etc..

Actually, does ARIN have a public statement on this "message" you're
talking about - i.e., apparently why DNS takedowns are a good idea and
effective and LEOs should go that route v. contacting ISPs or hosting
providers, etc..? I'd like to pass that along to our compliance and
abuse office for inclusive in their LEO package (and selfishly,
understand the logic)?

Thanks John,

-danny

-danny

[John Curran]

On Apr 2, 2013, at 9:53 AM, Danny McPherson <***@tcb.net> wrote:
>
> Speaking of inconsistencies in the RPKI, what's ARIN and the NRO's status on getting to a single trust anchor?

I believe that ICANN and the RIR technical staffs are busy trying to
document a proposed structure and operation to bring to the IETF (e.g.
how does one provide for transfers between regions without having an
an impact at 0/0 each time...)

However, that's somewhat independent of your question... Do you see
inconsistent data right now from following the RIR CA trees? A single
trust anchor is going to point to the same data, so if you see any
issues, please speak up.

> Yeah, they were nonsensical in the past and present role of ARIN, not in an RPKI-enabled world where revocation or transfer or inaccessibility will have some impacted on the routability of the address block in question.

You keep repeating that assertion, but note that even in today's world
we could be ordered to reclaim and reassign a block with similar effect.
It may not be "real time" but there are plenty of folks who follow both
the daily issued files as well as derivative filter lists. It is also
true of various routing registries. Even after deployment of RPKI, there
will be some fairly long period where loss of the covering ROA _alone_ is
likely to have little impact since the routing is still there, and we don't
seem to have any documentation suggesting to _only_ listen to routes that
are known valid. Loss of ROA coverage exposes one to further exploits,
but per existing guidance it should not result in connectivity impacts
(just as leaving one's seatbelt off doesn't generate an auto accident...)

> Actually, does ARIN have a public statement on this "message" you're talking about - i.e., apparently why DNS takedowns are a good idea and effective and LEOs should go that route v. contacting ISPs or hosting providers, etc..? I'd like to pass that along to our compliance and abuse office for inclusive in their LEO package (and selfishly, understand the logic)?


Danny, I never said "DNS takedowns are a good idea"; I said we "educate
law enforcement about the difficulty of attempting granular actions on
an IP address block basis." To the extent that one accepts that LEA folks
are going to sometimes impact the network for their purposes, it is better
if they use the most focused tools available. If that turns out to be the
DNS system, then I imagine that's where they turn next; the fact that one
can impact connectivity via orders against the DNS infrastructure does not
automatically mean we shouldn't deploy DNS, only that we should do so with
understanding of that potential (and the same could be said for RPKI...)

Thanks!
/John

John Curran
President and CEO
ARIN

[Danny McPherson]

On 2013-04-02 08:26, John Curran wrote:
> On Apr 2, 2013, at 9:53 AM, Danny McPherson <***@tcb.net> wrote:
>>
>> Speaking of inconsistencies in the RPKI, what's ARIN and the NRO's
>> status on getting to a single trust anchor?
>
> I believe that ICANN and the RIR technical staffs are busy trying to
> document a proposed structure and operation to bring to the IETF
> (e.g.
> how does one provide for transfers between regions without having an
> an impact at 0/0 each time...)
>
> However, that's somewhat independent of your question...

No, that was precisely what my question was. As for today, the
architecture permits such collisions, which I think is the issue most
agree is, err.. suboptimal.

-danny

[Stephen Kent]

Danny,

The architecture permits overlapping allocations to accommodate
transfers that involve address space that
is in use. I've been told by several operators that, for this sort of
transfer, such overlap
is required.

Steve
On 4/2/13 12:02 PM, Danny McPherson wrote:
> ...
> As for today, the architecture permits such collisions, which I think
> is the issue most agree is, err.. suboptimal.
>
> -danny
>
> _______________________________________________
> sidr mailing list
> ***@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr
>

[Christopher Morrow]

On Tue, Apr 2, 2013 at 1:59 PM, Stephen Kent <***@bbn.com> wrote:

> Danny,
>
> The architecture permits overlapping allocations to accommodate transfers
> that involve address space that
> is in use. I've been told by several operators that, for this sort of
> transfer, such overlap
> is required.
>
>
overlap with respect to:
ADDRESSBLOCK + ASN

right? so initially:
128.2.35.0/24 + AS28

In the near-future as 128.2.35.0/24 moves from AS28 -> AS22224:
128.2.35.0/24 + AS28
128.2.35.0/24 + AS22224

and at some point in the further future:
128.2.35.0/24 + AS22224

(and ideally the initial ROA ends up on a CRL...)

right? Enable /make before break/ for customers moving from attachment
point to attachment point.

-chris


> Steve
> On 4/2/13 12:02 PM, Danny McPherson wrote:
>
>> ...
>>
>> As for today, the architecture permits such collisions, which I think is
>> the issue most agree is, err.. suboptimal.
>>
>> -danny
>>
>> ______________________________**_________________
>> sidr mailing list
>> ***@ietf.org
>> https://www.ietf.org/mailman/**listinfo/sidr<https://www.ietf.org/mailman/listinfo/sidr>
>>
>>
> ______________________________**_________________
> sidr mailing list
> ***@ietf.org
> https://www.ietf.org/mailman/**listinfo/sidr<https://www.ietf.org/mailman/listinfo/sidr>
>

[Stephen Kent]

Chris,

Yes, the example you provided matches what I had in mind.

Steve
-

> On Tue, Apr 2, 2013 at 1:59 PM, Stephen Kent <***@bbn.com
> <mailto:***@bbn.com>> wrote:
>
> Danny,
>
> The architecture permits overlapping allocations to accommodate
> transfers that involve address space that
> is in use. I've been told by several operators that, for this sort
> of transfer, such overlap
> is required.
>
>
> overlap with respect to:
> ADDRESSBLOCK + ASN
>
> right? so initially:
> 128.2.35.0/24 <http://128.2.35.0/24> + AS28
>
> In the near-future as 128.2.35.0/24 <http://128.2.35.0/24> moves from
> AS28 -> AS22224:
> 128.2.35.0/24 <http://128.2.35.0/24> + AS28
> 128.2.35.0/24 <http://128.2.35.0/24> + AS22224
>
> and at some point in the further future:
> 128.2.35.0/24 <http://128.2.35.0/24> + AS22224
>
> (and ideally the initial ROA ends up on a CRL...)
>
> right? Enable /make before break/ for customers moving from attachment
> point to attachment point.
>
> -chris
>
> Steve
> On 4/2/13 12:02 PM, Danny McPherson wrote:
>
> ...
>
> As for today, the architecture permits such collisions, which
> I think is the issue most agree is, err.. suboptimal.
>
> -danny
>
> _______________________________________________
> sidr mailing list
> ***@ietf.org <mailto:***@ietf.org>
> https://www.ietf.org/mailman/listinfo/sidr
>
>
> _______________________________________________
> sidr mailing list
> ***@ietf.org <mailto:***@ietf.org>
> https://www.ietf.org/mailman/listinfo/sidr
>
>

[Danny McPherson]

On 2013-04-02 11:59, Stephen Kent wrote:
> Danny,
>
> The architecture permits overlapping allocations to accommodate
> transfers that involve address space that
> is in use. I've been told by several operators that, for this sort of
> transfer, such overlap is required.

Yes, I understand that.

I was referring to the multi-root TA, as I suspect you were aware.

-danny

[Stephen Kent]

Danny,

No, I didn't realize you were referring to the current multi-TA environment.

I thought that John Curran was alluding to plans to create an ICANN-managed
"global TA", which is why I didn't realize the context you had in mind.

Steve
------
On 4/2/13 3:20 PM, Danny McPherson wrote:
> On 2013-04-02 11:59, Stephen Kent wrote:
>> Danny,
>>
>> The architecture permits overlapping allocations to accommodate
>> transfers that involve address space that
>> is in use. I've been told by several operators that, for this sort of
>> transfer, such overlap is required.
>
> Yes, I understand that.
>
> I was referring to the multi-root TA, as I suspect you were aware.
>
> -danny
>
>
>
>

[Shane Amante]

John,

See below.

On Apr 2, 2013, at 8:26 AM, John Curran <***@arin.net> wrote:
> On Apr 2, 2013, at 9:53 AM, Danny McPherson <***@tcb.net> wrote:
[--snip--]
>> Yeah, they were nonsensical in the past and present role of ARIN, not in an RPKI-enabled world where revocation or transfer or inaccessibility will have some impacted on the routability of the address block in question.
>
> You keep repeating that assertion, but note that even in today's world
> we could be ordered to reclaim and reassign a block with similar effect.
> It may not be "real time" but there are plenty of folks who follow both
> the daily issued files as well as derivative filter lists. It is also
> true of various routing registries. Even after deployment of RPKI, there
> will be some fairly long period where loss of the covering ROA _alone_ is
> likely to have little impact since the routing is still there, and we don't
> seem to have any documentation suggesting to _only_ listen to routes that
> are known valid. Loss of ROA coverage exposes one to further exploits,
> but per existing guidance it should not result in connectivity impacts
> (just as leaving one's seatbelt off doesn't generate an auto accident...)

Personally, I think there's a significant difference in "today's world" vs. a "RPKI-enabled world". Specifically, in today's world, it's typically only upstream SP's that are using such information as a means to apply prefix+Origin_AS filters against their directly attached customers (and, customers of customers). In my understanding of the future promise-land that is the RPKI, ROA information will *not only* be used by SP's to filter against directly attached customers (and, customers of customers) like it is today ... but *also* on all interconnect (peering) circuits and even by third-party SP's who have no direct and, likely, no indirect relationship with the resource-holder in the first place. Thus, what Danny speaks of (and, I share a similar concern) is that either an operational mistake/bug in the RPKI and/or law-enforcement action against the RPKI /will/ result in a much, much larger denial-of-service, perhaps denying that resource holder an ability to receive packets on the Internet for a substantial portion of time. That's a /substantially/ different operating model from today's world where, more often than not, it's typically only the customer's upstream SP's to modify/update a filter-list, which can be done in *minutes* vs. how long in the RPKI ... including time for third-parties to fetch and update and make state changes in the network?

-shane

[John Curran]

On Apr 2, 2013, at 10:53 AM, Shane Amante <***@castlepoint.net>
wrote:
>> You keep repeating that assertion, but note that even in today's world
>> we could be ordered to reclaim and reassign a block with similar effect.
>> It may not be "real time" but there are plenty of folks who follow both
>> the daily issued files as well as derivative filter lists. It is also
>> true of various routing registries. Even after deployment of RPKI, there
>> will be some fairly long period where loss of the covering ROA _alone_ is
>> likely to have little impact since the routing is still there, and we don't
>> seem to have any documentation suggesting to _only_ listen to routes that
>> are known valid. Loss of ROA coverage exposes one to further exploits,
>> but per existing guidance it should not result in connectivity impacts
>> (just as leaving one's seatbelt off doesn't generate an auto accident...)
>
> Personally, I think there's a significant difference in "today's world" vs. a "RPKI-enabled world". Specifically, in today's world, it's typically only upstream SP's that are using such information as a means to apply prefix+Origin_AS filters against their directly attached customers (and, customers of customers). In my understanding of the future promise-land that is the RPKI, ROA information will *not only* be used by SP's to filter against directly attached customers (and, customers of customers) like it is today ... but *also* on all interconnect (peering) circuits and even by third-party SP's who have no direct and, likely, no indirect relationship with the resource-holder in the first place.

That's definitely a possible long-term outcome.

> Thus, what Danny speaks of (and, I share a similar concern) is that either an operational mistake/bug in the RPKI and/or law-enforcement action against the RPKI /will/ result in a much, much larger denial-of-service, perhaps denying that resource holder an ability to receive packets on the Internet for a substantial portion of time.

Indeed. Of course, that same outcome can effectively be had today (for any
given IP address block) via one handful of court orders directed to the larger
ISP backbones.

FYI,
/John

[Danny McPherson]

On 2013-04-02 09:30, John Curran wrote:

> Indeed. Of course, that same outcome can effectively be had today
> (for any
> given IP address block) via one handful of court orders directed to
> the larger
> ISP backbones.

Assuming those backbones operate within jurisdictional or MLAT reach,
as opposed to where an RIR falls jurisdictional.

But yes, this was indeed part of my earlier point.

-danny

[Shane Amante]

On Apr 2, 2013, at 9:58 AM, Danny McPherson <***@tcb.net> wrote:
> On 2013-04-02 09:30, John Curran wrote:
>
>> Indeed. Of course, that same outcome can effectively be had today (for any
>> given IP address block) via one handful of court orders directed to the larger
>> ISP backbones.
>
> Assuming those backbones operate within jurisdictional or MLAT reach, as opposed to where an RIR falls jurisdictional.
>
> But yes, this was indeed part of my earlier point.

IMO, there is still one key difference. ISP's are _directly_ involved in receiving such orders, evaluating them for validity, applicability and then carrying them out. This can also include providing a heads-up to operations teams, in that SP, that a change in configuration to effect it was "purposeful", thus saving substantial time + OpEx not trying to track down a "general connectivity issue" that a customer calls in and reports to the SP.

OTOH, with the RPKI ... the actions carried out by, for example, an RIR will have to be without consultation of the ISP(s) with the directly attached customer, in the case of sealed orders. How does the SP know that a certificate was revoked due: a) a bug; b) lack of payment to their RIR; or, c) a lawful order? And, more importantly, could/should/would ISP's act differently, in terms of routing on their networks in any of those cases?

It's one thing for an operator to have direct influence/knowledge re: actions it takes on their own network, it's another matter entirely when third-parties have that control over your operations, particularly without any recourse.

-shane

[John Curran]

On Apr 2, 2013, at 12:27 PM, Shane Amante <***@castlepoint.net> wrote:

> IMO, there is still one key difference. ISP's are _directly_ involved in receiving such orders, evaluating them for validity, applicability and then carrying them out. This can also include providing a heads-up to operations teams, in that SP, that a change in configuration to effect it was "purposeful", thus saving substantial time + OpEx not trying to track down a "general connectivity issue" that a customer calls in and reports to the SP.
>
> OTOH, with the RPKI ... the actions carried out by, for example, an RIR will have to be without consultation of the ISP(s) with the directly attached customer, in the case of sealed orders. How does the SP know that a certificate was revoked due: a) a bug; b) lack of payment to their RIR; or, c) a lawful order? And, more importantly, could/should/would ISP's act differently, in terms of routing on their networks in any of those cases?

That would suggest that monitoring and alerting aspects of these services
are indeed important, but that doesn't appear to be materially different
than the risks associated with relying on third-party filter lists, anti-
spam blocklists, or IRR data for delivering reliable services today.

/John

[Shane Amante]

John,

On Apr 2, 2013, at 11:22 AM, John Curran <***@arin.net> wrote:
> On Apr 2, 2013, at 12:27 PM, Shane Amante <***@castlepoint.net> wrote:
>> IMO, there is still one key difference. ISP's are _directly_ involved in receiving such orders, evaluating them for validity, applicability and then carrying them out. This can also include providing a heads-up to operations teams, in that SP, that a change in configuration to effect it was "purposeful", thus saving substantial time + OpEx not trying to track down a "general connectivity issue" that a customer calls in and reports to the SP.
>>
>> OTOH, with the RPKI ... the actions carried out by, for example, an RIR will have to be without consultation of the ISP(s) with the directly attached customer, in the case of sealed orders. How does the SP know that a certificate was revoked due: a) a bug; b) lack of payment to their RIR; or, c) a lawful order? And, more importantly, could/should/would ISP's act differently, in terms of routing on their networks in any of those cases?
>
> That would suggest that monitoring and alerting aspects of these services
> are indeed important, but that doesn't appear to be materially different
> than the risks associated with relying on third-party filter lists, anti-
> spam blocklists, or IRR data for delivering reliable services today.

In today's world, if a resource holder doesn't "like" the services provided by an IRR (perhaps, the IRR is unreliable, not cost-effective, etc.), then there's very low-bar for that resource-holder to register their resources in one or more third-party IRR's they consider "better", for some value of better. I think we would agree that the advantage here is a resource-holder gets to "shop around" for Routing Registry Services based on what attributes in a registry the resource holder considers important, (price, availability, susceptibility to LEA), etc. The one, not insignificant, downside is that those (third-party) registries do not, at the moment, provide rigorous authentication of the resources that are registered, (but clearly that's a known risk that exists and is "accepted" today -- whether that continues to be true and/or less acceptable in the future is clearly unknown).

So, in the future of the RPKI, as a resource holder, how am I able to "shop around" as per the above, to mitigate one or more of the concerns that I've illustrated above? Hint: given the, at present, limited number of RIR's near the top of the allocation hierarchy, there would appear to be little choice.

-shane

[John Curran]

On Apr 2, 2013, at 2:59 PM, Shane Amante <***@castlepoint.net> wrote:

> So, in the future of the RPKI, as a resource holder, how am I able to "shop around" as per the above, to mitigate one or more of the concerns that I've illustrated above? Hint: given the, at present, limited number of RIR's near the top of the allocation hierarchy, there would appear to be little choice.

I'm not certain you are describing a problem in RPKI architecture for
the working group: while there is ability to have overlap in RPKI
(as noted for purposes such as transfers and moves), there are still
assumptions regarding regions and hierarchy in the Internet Registry
system that make your perceived problem difficult to solve in the
general case. One approach (if it were really an issue) would be to
handle it similar to the DNS with shared registry/multiple registrars
(and the registrars providing the RPKI services you seek), but that
would not likely be a sidr (or IETF) scope work item in any case...

/John

[Shane Amante]

On Apr 2, 2013, at 2:45 PM, John Curran <***@arin.net> wrote:
> On Apr 2, 2013, at 2:59 PM, Shane Amante <***@castlepoint.net> wrote:
>
>> So, in the future of the RPKI, as a resource holder, how am I able to "shop around" as per the above, to mitigate one or more of the concerns that I've illustrated above? Hint: given the, at present, limited number of RIR's near the top of the allocation hierarchy, there would appear to be little choice.
>
> I'm not certain you are describing a problem in RPKI architecture for
> the working group: while there is ability to have overlap in RPKI
> (as noted for purposes such as transfers and moves), there are still
> assumptions regarding regions and hierarchy in the Internet Registry
> system that make your perceived problem difficult to solve in the
> general case.

Given the RPKI architecture has been based around the "assumptions" you quote above and, to my knowledge, no one has questioned/challenged those assumptions, you may be right. But, if not now, when?


> One approach (if it were really an issue) would be to
> handle it similar to the DNS with shared registry/multiple registrars
> (and the registrars providing the RPKI services you seek), but that
> would not likely be a sidr (or IETF) scope work item in any case...

Although, if the registry function remains "constrained", as it is today, then I'm not sure that meaningfully solves any concerns, given that function still remains an attractive 'target' for outside parties to (try to) exert pressure and/or operational problems to manifest themself with the potential for very noticeable and widespread impacts.

-shane

[John Curran]

On Apr 2, 2013, at 5:59 PM, Shane Amante <***@castlepoint.net> wrote:

> Although, if the registry function remains "constrained", as it is today, then I'm not sure that meaningfully solves any concerns, given that function still remains an attractive 'target' for outside parties to (try to) exert pressure and/or operational problems to manifest themself with the potential for very noticeable and widespread impacts.

With the net result being that those who share those concerns
are likely t decide not to make use of it and continue as today,
and those who are worried more about the possibility of easy
route hijacking will use it... (like many other security-related
capabilities in the Internet, the deployment choice is left to
each network.)

/John

[Stephen Kent]

Shane,
> IMO, there is still one key difference. ISP's are _directly_ involved in receiving such orders, evaluating them for validity, applicability and then carrying them out. This can also include providing a heads-up to operations teams, in that SP, that a change in configuration to effect it was "purposeful", thus saving substantial time + OpEx not trying to track down a "general connectivity issue" that a customer calls in and reports to the SP.
>
> OTOH, with the RPKI ... the actions carried out by, for example, an RIR will have to be without consultation of the ISP(s) with the directly attached customer, in the case of sealed orders. How does the SP know that a certificate was revoked due: a) a bug; b) lack of payment to their RIR; or, c) a lawful order? And, more importantly, could/should/would ISP's act differently, in terms of routing on their networks in any of those cases?
As I mentioned in my message to Sharon last week, each resource holder
can detect any action by any party that renders ROAs for the resource
holder invalid. This sort of self-monitoring can be performed as a side
effect of normal RPKI processing. The next step is for the affected
party to notify other ISPs of the action, which, I
suspect, can be done in a variety of ways. How ISPs cosoe to use this
info is still a local decision, as it
is today.
> It's one thing for an operator to have direct influence/knowledge re: actions it takes on their own network, it's another matter entirely when third-parties have that control over your operations, particularly without any recourse.
I don't think the RPKI results in the change you suggest above. It is
still up to each ISP to decide how
to make use of the data acquired via the RPKI. The LTAM mechanism
provides a specific way for an ISP to
override most of the sorts of changes that have been described. For
example, if a country elects to
maintain RPKI data for ISPs that operate there (exclusively), the
country could publish a contsriants
file in the LTAM-specified format, as a way of "protecting" the
resources for these ISPs. Other ISPs,
outside of the country, can elect to make use of this data if they worry
that an LEO outside of the
geopolitical jurisdiction tries to use the RPKI to whack resources
within the country. In the end, it
is still up to each ISP to decide how to make use of RPKI data.

Steve

[Osterweil, Eric]

On Apr 1, 2013, at 12:17 PM, Sharon Goldberg <***@cs.bu.edu> wrote:

<snip>

> > 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.
>
> We agree that monitoring is important and in fact we are working on such a monitor right now.

Yeah, actually, we've had RPKISpider up and running for several months:
http://rpkispider.verisignlabs.com/
and @RPKIUpdateBot tweeting all global repo changes for longer:
https://twitter.com/RPKIUpdateBot

Tweets show resource holders how they can view their own delegations and watch in real time _today_. For example,
http://rpkispider.verisignlabs.com/rpki-rescert-chain.cgi?p=194.126.136.0/21-24&r=6254

Its metrics also serve as a pretty good detection mechanisms for outages. ;)

We're a little behind on a writeup, but we've been known to be active on email. ;)

Eric

[Shane Amante]

On Apr 1, 2013, at 10:17 AM, Sharon Goldberg <***@cs.bu.edu> wrote:
[--snip--]
> > 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.
>
> We'll look forward to this -- more information about legal remedies will be useful to inform further investigations on our end.
>
> We are particularly curious about how legal recourse would play out in cases where the targeted party is in a different country than the party that whacked its ROA. For example, what if an American organization whacks a ROA for an AS in a different country (or vice versa)?
>
> We did some analysis of when a subject in one country can whack a ROA for an AS in another country. See the heatmaps on slide 10-11 of the slide deck:
>
> http://www.cs.bu.edu/~goldbe/papers/Cooper_RPKI_BFOC.pdf
>
> To get these, we took data on the direct-allocations from each RIR, and then used routeviews and RIPE RIS data to determine for each directly-allocated prefix, how many different ASes originate the prefix or any of its subprefixes. We show this in slide 10. To get slide 11, we then use the AS-to-country mappings provided by the RIRs to determine the number of countries that have ASes who originate prefixes that are covered by the directly allocated prefix. (Note we are in the midst of writing up a full report of these results, that I'll share with the list in a month or two.)
>
> So, if we suppose that prefixes directly allocated by the RIRs are given their own resource certs, we see that these resource certs can whack ROAs for ASes in multiple countries. (Look at 8/8 or 12/8, for example.) How would takedowns play out if they cross national borders?

As one operator whose worldwide routing/operations could be negatively impacted by the above, it would be nice to have a concise statement about what is/was the original intent of the design of the RPKI with respect to the above. In addition, it would be useful to see if any potential remedies/solutions may be employed (and, any associated overhead/delays/*costs*/etc. they incur) that may be used to mitigate them /before/ they manifest themself in the network, at which point operators will be obligated to stop using those 'trusted information repositories' to directly inform routing.

Regardless ... good work, Sharon & Co.

-shane

[Stephen Kent]

Shane,
> As one operator whose worldwide routing/operations could be negatively
> impacted by the above, it would be nice to have a concise statement
> about what is/was the original intent of the design of the RPKI with
> respect to the above. In addition, it would be useful to see if any
> potential remedies/solutions may be employed (and, any associated
> overhead/delays/*costs*/etc. they incur) that may be used to mitigate
> them /before/ they manifest themself in the network, at which point
> operators will be obligated to stop using those 'trusted information
> repositories' to directly inform routing.
The intent of the RPKI has always been to create a PKI that parallels
the allocation hierarchy. The downside of
this is that errors, or malicious actions, by orgs at higher tiers have
the potential to adversely impact
resource holders at lower tiers. At certain tiers in the allocation
hierarchy this is true irrespective of the
use of the RPKI. For example, if a targeted entity receives an PA
allocation from an ISP and that ISP is forced
by a LEO to suspend service for that entity, but to still advertise the
sub-allocated prefix, the target has
a problem. if an RIR accidentally allocated the same prefix to two
different entities, there would be a problem
for one or both of them when they tried to advertise the twice-allocated
space. I am working on a doc, to which
I alluded in my reply to Sharon last week, that examines a wide range of
cases in which an organization
in the allocation hierarchy makes an error, or is forced to whack an
allocation. The doc describes ways
that such activity can be detected, and remediation options.

Steve

[Shane Amante]

Steve,

Thanks for your response. Please see below.

On Apr 2, 2013, at 12:08 PM, Stephen Kent <***@bbn.com> wrote:
> Shane,
>> As one operator whose worldwide routing/operations could be negatively impacted by the above, it would be nice to have a concise statement about what is/was the original intent of the design of the RPKI with respect to the above. In addition, it would be useful to see if any potential remedies/solutions may be employed (and, any associated overhead/delays/*costs*/etc. they incur) that may be used to mitigate them /before/ they manifest themself in the network, at which point operators will be obligated to stop using those 'trusted information repositories' to directly inform routing.
> The intent of the RPKI has always been to create a PKI that parallels the allocation hierarchy. The downside of
> this is that errors, or malicious actions, by orgs at higher tiers have the potential to adversely impact
> resource holders at lower tiers. At certain tiers in the allocation hierarchy this is true irrespective of the
> use of the RPKI. For example, if a targeted entity receives an PA allocation from an ISP and that ISP is forced
> by a LEO to suspend service for that entity, but to still advertise the sub-allocated prefix, the target has
> a problem.

That is true. However, I feel the need to point a subtle, yet important difference from today's environment.

First, today, the ISP has direct knowledge prior to this 'event' occurring and given the direct contractual relationship they have with the customer the ISP would (IMO) be more likely to have a significant business interest (i.e.: get paid) to ensure the order was valid, applicable, etc. /before/ it was carried out. IOW, if the ISP is not providing service to the customer, then the ISP may be unable to bill for all or part of that service provided, (one, simple example: usage-based billing). OTOH, if a third-party (RIR?) higher up the allocation hierarchy were to "whack" a cert, thus making a cert for a resource invalid can the same be said?

Second, consider the 'scope' of where such a change will be propagated and a time-to-restore back to "normalcy" after the matter is rectified. Today -- for better or worse -- it's the immediate upstream ISP(s) of the targeted entity that, in your example, would be curtailing the propagation of routes and/or forwarding to the 'targeted entity' to/from the rest of the Internet. IOW, if (or, when) the matter is appropriately resolved, then (I suspect) the restoration times to get the customer back online are minimal today given we are largely talking about BGP propagation times, i.e.: likely minutes. Ultimately, it's just those immediate upstream ISP's that need to 'act' in order to propagate that route to the entire Internet. OTOH, in a fully RPKI-enabled world, SP's the world over are performing origin filtering using information from the RPKI at all of their customer and peering interconnections ... this could make for some rather long 'restoration' times for the 'targeted entity' based on several of the models I've seen tossed around in SIDR. And, the longer the restoration times, again, the more noticeable the impact it could have on the ISP's who provide service to/from the 'targeted entity', (again: usage-based billing).

Nonetheless, I will be interested to see if the paper you are writing will include these types of detail.


> if an RIR accidentally allocated the same prefix to two different entities, there would be a problem
> for one or both of them when they tried to advertise the twice-allocated space.

While theoretically a possibility, I'd be curious to know if the above is a common occurrence? If the RIR were concerned about this, one quick way to ensure this did not happen would be for the RIR to consult a "live" routing table to see if the space they are (re-)allocating is already being announced somewhere. In fact, I'd be surprised if they did not do this already. (Granted, this does not prevent the same space from ever being twice allocated, because the first allocation was sitting dormant/not-announced at that moment).


> I am working on a doc, to which
> I alluded in my reply to Sharon last week, that examines a wide range of cases in which an organization
> in the allocation hierarchy makes an error, or is forced to whack an allocation. The doc describes ways
> that such activity can be detected, and remediation options.

I look forward to reading that document when it's published.

-shane

[Christopher Morrow]

On Tue, Apr 2, 2013 at 10:25 PM, Shane Amante <***@castlepoint.net> wrote:

> IOW, if (or, when) the matter is appropriately resolved, then (I suspect)
> the restoration times to get the customer back online are minimal today
> given we are largely talking about BGP propagation times, i.e.: likely
> minutes. Ultimately, it's just those immediate upstream ISP's that need to
> 'act' in order to propagate that route to the entire Internet. OTOH, in a
> fully RPKI-enabled world, SP's the world over are performing origin
> filtering using information from the RPKI at all of their customer and
> peering interconnections ... this could make for some rather long
> 'restoration' times


so.. a few times now we've cycled around the time to get objects splayed
out across the rpki/cache/router system. I think we agreed ~3months ago
(?perhaps longer, someone can search the mail archive if interested) that
timelines for publication -> all RP's have data was expected to be on the
order of 10 minutes. I think danny handwaved that 5-10 minutes would be
acceptable in his world.

I also think that today (and for the next while) this timeline isn't
important because folk mostly will be monitoring/marking and not dropping
'invalid' or 'unknown' routes. we could cycle around a few more times if
it's of interest, but it seems to me... this is already solved, no?

[Stephen Kent]

Shane,

> That is true. However, I feel the need to point a subtle, yet
> important difference from today's environment.
>
> First, today, the ISP has direct knowledge prior to this 'event'
> occurring and given the direct contractual relationship they have with
> the customer the ISP would (IMO) be more likely to have a significant
> business interest (i.e.: get paid) to ensure the order was valid,
> applicable, etc. /before/ it was carried out. IOW, if the ISP is not
> providing service to the customer, then the ISP may be unable to bill
> for all or part of that service provided, (one, simple example:
> usage-based billing). OTOH, if a third-party (RIR?) higher up the
> allocation hierarchy were to "whack" a cert, thus making a cert for a
> resource invalid can the same be said?
Fair question. In the case of RIPE, where there was a LEO action that
was somewhat analogous to ROA
whacking, RIPE fought the action (in court). Only time will tell if
other RIRs adopt a similar approach.
> Second, consider the 'scope' of where such a change will be propagated
> and a time-to-restore back to "normalcy" after the matter is
> rectified. Today -- for better or worse -- it's the immediate
> upstream ISP(s) of the targeted entity that, in your example, would be
> curtailing the propagation of routes and/or forwarding to the
> 'targeted entity' to/from the rest of the Internet. IOW, if (or,
> when) the matter is appropriately resolved, then (I suspect) the
> restoration times to get the customer back online are minimal today
> given we are largely talking about BGP propagation times, i.e.: likely
> minutes. Ultimately, it's just those immediate upstream ISP's that
> need to 'act' in order to propagate that route to the entire Internet.
I think that's a fair characterization of an example that I gave.
> OTOH, in a fully RPKI-enabled world, SP's the world over are
> performing origin filtering using information from the RPKI at all of
> their customer and peering interconnections ... this could make for
> some rather long 'restoration' times for the 'targeted entity' based
> on several of the models I've seen tossed around in SIDR. And, the
> longer the restoration times, again, the more noticeable the impact it
> could have on the ISP's who provide service to/from the 'targeted
> entity', (again: usage-based billing).
When a targeted entity detects that it's ROA has been whacked, it can
try to notify RPs (via out of band means).
The easiest action for RPs to take if they choose to not act on the
whacking is to retain the old data that
they have cached. So, the time it would take to deal the whacking is
determined by the time it takes to
get the word out to RPs (after detection of the whacking.
> Nonetheless, I will be interested to see if the paper you are writing
> will include these types of detail.
yes, it does.
>
>> if an RIR accidentally allocated the same prefix to two different
>> entities, there would be a problem
>> for one or both of them when they tried to advertise the
>> twice-allocated space.
>
> While theoretically a possibility, I'd be curious to know if the above
> is a common occurrence? If the RIR were concerned about this, one
> quick way to ensure this did not happen would be for the RIR to
> consult a "live" routing table to see if the space they are
> (re-)allocating is already being announced somewhere. In fact, I'd be
> surprised if they did not do this already. (Granted, this does not
> prevent the same space from ever being twice allocated, because the
> first allocation was sitting dormant/not-announced at that moment).
I think this is a very, very unlikely failure case. I just mentioned it
because others have cited this as a
concern.

Steve

[Stephen Kent]

Sharon,

...
>
> > 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.
>
> We agree that monitoring is important and in fact we are working on
> such a monitor right now.
>
Great. I think we'll include this feature in future RPSRIR releases too.
The important point,
IMHO, is that this sort of monitoring is easiest if performed by
resource holders themselves.
>
> > 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.
>
> To clarify, which 3 approaches do you mean?
>
In 7.3.2 of RFC 6480 the two RECOMMENDED approaches are for a subscriber
to receive a CA cert from the ISP from which the address space
allocation was received, or for the subscriber to have the ISP that is
the allocation source issue a ROA for the subscriber. I consider the
second one to be less preferred than the first. the third approach
applies only if the subscriber does not have it's own ASN, and that
approach is NOT RECOMMENDED.

I misspoke when I said that your analysis, in 2.2.1 focused on the third
of three approaches applicable in
this case. You looked at the second of three, and the third approach is
no applicable because you did assume
that the subscriber had it's own ASN.
>
> In 2.2.1 we consider an org B who has its own ASN but chooses not to
> have its own resource cert; instead, it has org A issue its ROA.
> (This is one of two recommendations in RFC6480 Section 7.3.2 first
> paragraph.) In this case, the parent org A can whack org B's ROA in
> surreptitious ways, without explicitly using revocation lists.
>
Yes, the ROA can be whacked this way.
>
> In the case where org B has its own resource cert, ROA whacking is
> more detectable, because it might involve issuing new ROA,
> grandparenting, etc. We discuss that in Sections 2.2.2-2.2.3, 2.3-2.5.
>
I believe that ROA whacking is always detectable by the whackee. It's
harder for 3rd parties to detect,
because there might be legitimate reasons for other actions. I suggest
that we not consider grand parenting
in this discussion. There is no RFC that allows grand parenting. More
importantly it runs counter to the CP and the architecture, which call
for entities acting as CA to issue certs based on the databases that
they operate
to track the allocations that they made.

> We are particularly curious about how legal recourse would play out in
> cases where the targeted party is in a different country than the
> party that whacked its ROA. For example, what if an American
> organization whacks a ROA for an AS in a different country (or vice
> versa)?
>
> We did some analysis of when a subject in one country can whack a ROA
> for an AS in another country. See the heatmaps on slide 10-11 of the
> slide deck:
>
> http://www.cs.bu.edu/~goldbe/papers/Cooper_RPKI_BFOC.pdf
> <http://www.cs.bu.edu/%7Egoldbe/papers/Cooper_RPKI_BFOC.pdf>
>
> To get these, we took data on the direct-allocations from each RIR,
> and then used routeviews and RIPE RIS data to determine for each
> directly-allocated prefix, how many different ASes originate the
> prefix or any of its subprefixes. We show this in slide 10. To get
> slide 11, we then use the AS-to-country mappings provided by the RIRs
> to determine the number of countries that have ASes who originate
> prefixes that are covered by the directly allocated prefix. (Note we
> are in the midst of writing up a full report of these results, that
> I'll share with the list in a month or two.)
> So, if we suppose that prefixes directly allocated by the RIRs are
> given their own resource certs, we see that these resource certs can
> whack ROAs for ASes in multiple countries. (Look at 8/8 or 12/8, for
> example.) How would takedowns play out if they cross national borders?
It is often possible for a ROA representing resources in country X to be
whacked by an org in country Z, because the allocation hierarchy is not
aligned along country boundaries, and because some ISPs operate across
country boundaries.

One way to mitigate these concerns, if they become significant, is for a
country to operate a service where it tracks allocations to ISPs that
operate within its borders. It can publish an LTAM constraints file that
tracks the allocations, and ISPs that wish to check that file against
data returned by the RPKI repository system can use this mechanism to
detect anomalies. ISPs can then decide which source to believe. I know
of one country that is already considering this model. It is not clear
whether many countries will decide that this approach is worth the effort.

Another way to tackle the LEO-based aspect of this concern is to
persuade LEOs to not view ROA whacking as a good tool. I've had this
discussion with FBI cyber crime folks. I also note that there is an
ongoing IAB effort to produce a position statement on the broader topic
(encompassing both the DNS and the RPKI).

Steve

[Murphy, Sandra]

Speaking as a regular ol' member

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

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.

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

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

[Russ White]

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

[Arturo Servin]

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

On 3/20/13 5:20 PM, Russ White wrote:
>
>>> 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."
>>
>> 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
>
>
> _______________________________________________
> sidr mailing list
> ***@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr
>

[Russ White]

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

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

:-)

Russ

[Arturo Servin]

On 20/03/2013 17:41, Russ White wrote:
>
>> 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.
>
> That is probably a good idea... But since the ROAs are time based
> 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

[Borchert, Oliver]

> On 20/03/2013 17:41, Russ White wrote:
> >
> >> 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.
> >
> > That is probably a good idea... But since the ROAs are time based
> > 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

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

[Arturo Servin]

On 20/03/2013 20:00, Borchert, Oliver wrote:
>> On 20/03/2013 17:41, Russ White wrote:
>>>
>>>> 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.
>>>
>>> That is probably a good idea... But since the ROAs are time based
>>> 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
>
> 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

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


>
> _______________________________________________
> sidr mailing list
> ***@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr
>

[Osterweil, Eric]

On Mar 20, 2013, at 7:32 PM, Arturo Servin <***@gmail.com> wrote:

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

<snip>

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

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

[Arturo Servin]

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:
>
> 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
>
> _______________________________________________
> sidr mailing list
> ***@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr

[Roque Gagliano (rogaglia)]

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


On Mar 20, 2013, at 1:50 PM, Danny McPherson <***@tcb.net> wrote:

>
> 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
>
> _______________________________________________
> sidr mailing list
> ***@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr

[Danny McPherson]

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.
>
> What specific finding(s) concerns you?

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

[Roque Gagliano (rogaglia)]

inline.

On Mar 20, 2013, at 4:21 PM, Danny McPherson <***@tcb.net> wrote:

> 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.
>>
>> What specific finding(s) concerns you?
>
> 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

> -danny
>
>
>
>

[Richard Barnes]

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 <***@tcb.net> wrote:

>
> Interesting presentation here:
>
> http://www.cs.bu.edu/~goldbe/**papers/Cooper_RPKI_BFOC.pdf<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
>
> ______________________________**_________________
> sidr mailing list
> ***@ietf.org
> https://www.ietf.org/mailman/**listinfo/sidr<https://www.ietf.org/mailman/listinfo/sidr>
>

[Danny McPherson]

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

[Montgomery, Douglas]

On 3/20/13 4:41 PM, "Russ White" <***@riw.us> wrote:

>
>> 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.
>
>That is probably a good idea... But since the ROAs are time based
>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