Mailing List Archive

On Apr 27, 2012 3:05 PM, "Paul Vixie" <vixie@isc.org> wrote:
>
>
http://tech.slashdot.org/story/12/04/27/2039237/engineers-ponder-easier-fix-to-internet-problem
>
> > "The problem: Border Gateway Protocol (BGP) enables routers to
> > communicate about the best path to other networks, but routers don't
> > verify the route 'announcements.' When routing problems erupt, 'it's
> > very difficult to tell if this is fat fingering on a router or
> > malicious
> > <
http://www.itworld.com/security/272320/engineers-ponder-easier-fix-dangerous-internet-problem
>,'
> > said Joe Gersch, chief operating officer for Secure64, a company that
> > makes Domain Name System (DNS) server software. In a well-known
> > incident, Pakistan Telecom made an error with BGP after Pakistan's
> > government ordered in 2008 that ISPs block YouTube, which ended up
> > knocking Google's service offline
> > <
http://slashdot.org/story/08/02/25/1322252/pakistan-youtube-block-breaks-the-world
>.
> > A solution exists, but it's complex, and deployment has been slow. Now
> > experts have found an easier way."
>
> this seems late, compared to the various commitments made to rpki in
> recent years. is anybody taking it seriously?
>

Taking what seriously ? The commitments to rpki you speak off ?

Late is a relative term.

It does not matter if the cat is white or black, as long as it cathes the
rat.

CB

On 04/27/2012 06:05 PM, Paul Vixie wrote:
> this seems late, compared to the various commitments made to rpki in
> recent years. is anybody taking it seriously?

first thing that sprung to mind was this:

http://www.cafepress.com.au/nxdomain

line 408 ff. in the IETF 83 SIDR minutes

* http://www.ietf.org/proceedings/83/minutes/minutes-83-sidr.txt



Cheers
matthias

--
Matthias Waehlisch
. Freie Universitaet Berlin, Inst. fuer Informatik, AG CST
. Takustr. 9, D-14195 Berlin, Germany
.. mailto:waehlisch@ieee.org .. http://www.inf.fu-berlin.de/~waehl
:. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net

On Fri, 27 Apr 2012, Paul Vixie wrote:

> http://tech.slashdot.org/story/12/04/27/2039237/engineers-ponder-easier-fix-to-internet-problem
>
> > "The problem: Border Gateway Protocol (BGP) enables routers to
> > communicate about the best path to other networks, but routers don't
> > verify the route 'announcements.' When routing problems erupt, 'it's
> > very difficult to tell if this is fat fingering on a router or
> > malicious
> > <http://www.itworld.com/security/272320/engineers-ponder-easier-fix-dangerous-internet-problem>,'
> > said Joe Gersch, chief operating officer for Secure64, a company that
> > makes Domain Name System (DNS) server software. In a well-known
> > incident, Pakistan Telecom made an error with BGP after Pakistan's
> > government ordered in 2008 that ISPs block YouTube, which ended up
> > knocking Google's service offline
> > <http://slashdot.org/story/08/02/25/1322252/pakistan-youtube-block-breaks-the-world>.
> > A solution exists, but it's complex, and deployment has been slow. Now
> > experts have found an easier way."
>
> this seems late, compared to the various commitments made to rpki in
> recent years. is anybody taking it seriously?
>
>

* Paul Vixie:

> this seems late, compared to the various commitments made to rpki in
> recent years. is anybody taking it seriously?

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

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

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

draft-bates-bgp4-nlri-orig-verif-00.txt was '98

and we dropped it for good reasons

randy

On (2012-04-27 22:05 +0000), Paul Vixie wrote:

> this seems late, compared to the various commitments made to rpki in
> recent years. is anybody taking it seriously?

(disclaimer I'm almost completely clueless on RPKI).

If two fails don't make win, then I think ROVER is better solution, doesn't
need any changes to BGP just little software magic when accepting routes.

People might scared to rely on DNS on accepting routes, but is this really
an issue? I'd anyhow prefer to run verification in 'relaxed' mode, where
routes which fail authorization are logged but accepted if there wasn't
pre-existing covering route. Only drop routes if they fail authorization
_AND_ there is pre-existing covering route.
Maybe after several more years of experience and working out kinks, I could
dare to try to run verification in 'strict' more. But 'relaxed' more
already would stop the real-life problems we've seen of route-hijackings. I
don't care much about unannounced net used for spamming really.

Nick Hilliard mentioned in other forum to me bootstrapping problem. DNS
would then be inherently part of your NMS, so install DNS in your NMS, and
NMS already exists in IGP. So infra for verification should be up, before
BGP is up.

--
++ytti

On 28 Apr 2012, at 11:56, Florian Weimer wrote:

> * Paul Vixie:
>
>> this seems late, compared to the various commitments made to rpki in
>> recent years. is anybody taking it seriously?
>
> The idea as such isn't new, this has been floating around for four
> years or more, including at least one Internet draft,
> draft-donnerhacke-sidr-bgp-verification-dnssec.
>
> I don't know if we can get RPKI to deployment because RIPE and RIPE
> NCC have rather serious issues with it. On the other hand, there
> doesn't seem to be anything else which keeps RIRs relevant in the
> post-scarcity world, so we'll see what happens.

Could you elaborate on what those issues are?

I can't speak for ROVER, but judging from Gersh's talk at RIPE64 and the discussion afterwards, it looks like it's just an old idea that was brought to the table again, with a few early adopters experimenting.

In the linked article Gersh says that RPKI is complex and deployment has been slow. In reality, since the RIRs launched an RPKI production service on 1 Jan 2011, adoption has been incredibly good (for example compared to IPv6 and DNSSEC). More than 1500 ISPs and large organizations world-wide have opted-in to the system and requested a resource certificate using the hosted service, or running an open source package with their own CA.

But it's not just that, these ISPs didn't just blindly get certificate and walk away. There are over 800 ROAs in the global system, describing more than 2000 prefixes ranging from /24s to /10s, totaling to almost 80 million IPv4 addresses worth of BGP announcements. Data quality is really good. All in all, RPKI has really good traction and with native router support in Cisco, Juniper and Quagga, this is only getting better.

Global deployment statistics can be found here: http://certification-stats.ripe.net/

* Alex Band:

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

A year ago, RIPE NCC received legal advice that RPKI-based takedowns
would not happen under Dutch law because Dutch law lacked any
provisions for that. This was used to deflect criticism that RPKI
deployment would result in too much concentration of power:

<http://www.ripe.net/ripe/mail/archives/address-policy-wg/2011-May/005858.html>

The legal analysis turned out to be incomplete and the results
incorrect---legal counsel failed to consider public order legislation.
The validaty of such an order (issued in the Dnschanger context) is
currently being challenged in a Dutch court.

From the comments on these events, I infer that RIPE NCC still does
not want to exercise this level of control over routing, and the RIPE
community does not want RIPE to have such control. But assuming that
the order stands, RPKI will provide RIPE NCC with a tool that nobody
wants it to have, and RIPE NCC can be forced to use it. Depending on
the seriousness of those concerns, that's the end of RPKI deployment.

(However, the most likely outcome of the current court case is that
this particular police order will be found invalid on a formality,
such as lack of effectiveness, providing little insight on the
validity of future orders which are more carefully crafted.)

Regarding the post-scarcity future, if most address holders never have
to come back to the RIR to request more addresses, the number of
address-related RIR/LIR transactions will decrease. Organizations
have a tendency to resist decreases in business (even non-profits),
and RPKI is an obvious source of future business.

On Sat, Apr 28, 2012 at 03:04:07AM -0700,
Randy Bush <randy@psg.com> wrote
a message of 9 lines which said:

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

Unfortunately, we have RFCs for good ideas but bad ideas never get
documented by the IETF (one of the few exceptions is RFC 3197). So,
bad ideas keep coming back and back again.

Would you explain in a few words why this was a bad idea? I personally
find Rover a very interesting idea, and which seems realistic.

On Sat, Apr 28, 2012 at 12:34:52PM +0200,
Alex Band <alexb@ripe.net> wrote
a message of 41 lines which said:

> In reality, since the RIRs launched an RPKI production service on 1
> Jan 2011, adoption has been incredibly good (for example compared to
> IPv6 and DNSSEC). More than 1500 ISPs and large organizations
> world-wide have opted-in to the system and requested a resource
> certificate using the hosted service, or running an open source
> package with their own CA.

I have an experience with the deployment of DNSSEC and the problem
with DNSSEC was not to have signed zones (many are, now) but to have
people *using* these signatures to check the data (i.e. validating in
a resolver).

RPKI has many ROA (signed objects) but how many operators validate
routes on their production routers? Zero?

> But it's not just that, these ISPs didn't just blindly get
> certificate and walk away.

Most of the ROAs are very recent. Again, the experience with DNSSEC
shows that starting is easy ("DNSSEC in siw minutes"). It's long term
management which is *the* problem. Wait until people start to change
the routing data and watch the ROAs becoming less and less correct...

> Data quality is really good.

It's not what you said:

"It is safe to say that overall data quality is pretty bad"
<https://labs.ripe.net/Members/AlexBand/resource-certification-rpki-in-the-real-world>
(good paper, by the way, thanks)

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

Looking at the bigger picture though, we shouldn't forget that what RPKI, ROVER and the IRR facilitate is merely the ability make a *statement* about routing (with varying degrees of reliability) and doesn't have a direct impact on BGP routing itself. Ultimately, it is up to the network operator to interpret the data that is entered in the system, allow them to make an informed decision and take action they deem appropriate. Everyone has the ability to apply an override on data they do not trust, or have a specific local policy for. In the toolsets for using the RPKI data set for routing decisions, such as the RIPE NCC RPKI Validator, every possible step is taken is taken to ensure that the operator is in the driver's seat.

Have a look here for a public example: http://rpki.netsign.net:8080/
Or install and try it yourself: http://www.ripe.net/certification/tools-and-resources

Cheers,

Alex

On 28 Apr 2012, at 13:35, Florian Weimer wrote:

> * Alex Band:
>
>>> I don't know if we can get RPKI to deployment because RIPE and RIPE
>>> NCC have rather serious issues with it. On the other hand, there
>>> doesn't seem to be anything else which keeps RIRs relevant in the
>>> post-scarcity world, so we'll see what happens.
>>
>> Could you elaborate on what those issues are?
>
> A year ago, RIPE NCC received legal advice that RPKI-based takedowns
> would not happen under Dutch law because Dutch law lacked any
> provisions for that. This was used to deflect criticism that RPKI
> deployment would result in too much concentration of power:
>
> <http://www.ripe.net/ripe/mail/archives/address-policy-wg/2011-May/005858.html>
>
> The legal analysis turned out to be incomplete and the results
> incorrect---legal counsel failed to consider public order legislation.
> The validaty of such an order (issued in the Dnschanger context) is
> currently being challenged in a Dutch court.
>
> From the comments on these events, I infer that RIPE NCC still does
> not want to exercise this level of control over routing, and the RIPE
> community does not want RIPE to have such control. But assuming that
> the order stands, RPKI will provide RIPE NCC with a tool that nobody
> wants it to have, and RIPE NCC can be forced to use it. Depending on
> the seriousness of those concerns, that's the end of RPKI deployment.
>
> (However, the most likely outcome of the current court case is that
> this particular police order will be found invalid on a formality,
> such as lack of effectiveness, providing little insight on the
> validity of future orders which are more carefully crafted.)
>
> Regarding the post-scarcity future, if most address holders never have
> to come back to the RIR to request more addresses, the number of
> address-related RIR/LIR transactions will decrease. Organizations
> have a tendency to resist decreases in business (even non-profits),
> and RPKI is an obvious source of future business.
>

On Sat, Apr 28, 2012 at 01:17:10PM +0300,
Saku Ytti <saku@ytti.fi> wrote
a message of 27 lines which said:

> I think ROVER is better solution, doesn't need any changes to BGP
> just little software magic when accepting routes.

I like Rover but RPKI+ROA does not change BGP either (it will be a
different story with BGPsec).

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

RPKI+ROA depends on DNS too, since rsync://rpki.ripe.net/repository
will work only if DNS works. Not a problem in practice, since route
origins do not change every minute and the validating ROA cache can
work even if it can no longer update its data. Same thing with Rover:
temporary glitches in the DNS are not a practical problem (the router
keeps the old info).

> routes which fail authorization are logged but accepted if there
> wasn't pre-existing covering route. Only drop routes if they fail
> authorization _AND_ there is pre-existing covering route.

It is a bit more complicated: more-specific attacks, and so on. But,
yes, you're right. As Alex Band says, Rover, RPKI and the IRR make
(authenticated) statements about route origins. You then do what you
want (what your boss wants? what the FBI wants?) with these statements
(route-map, etc).

On 28 Apr 2012, at 14:57, Stephane Bortzmeyer wrote:

> On Sat, Apr 28, 2012 at 12:34:52PM +0200,
> Alex Band <alexb@ripe.net> wrote
> a message of 41 lines which said:
>
>> In reality, since the RIRs launched an RPKI production service on 1
>> Jan 2011, adoption has been incredibly good (for example compared to
>> IPv6 and DNSSEC). More than 1500 ISPs and large organizations
>> world-wide have opted-in to the system and requested a resource
>> certificate using the hosted service, or running an open source
>> package with their own CA.
>
> I have an experience with the deployment of DNSSEC and the problem
> with DNSSEC was not to have signed zones (many are, now) but to have
> people *using* these signatures to check the data (i.e. validating in
> a resolver).
>
> RPKI has many ROA (signed objects) but how many operators validate
> routes on their production routers? Zero?

First you need a robust system and reliable data. Native router support is coming along. We could be getting to a stage where people will use the data in production. Time will tell...

>> But it's not just that, these ISPs didn't just blindly get
>> certificate and walk away.
>
> Most of the ROAs are very recent. Again, the experience with DNSSEC
> shows that starting is easy ("DNSSEC in siw minutes"). It's long term
> management which is *the* problem. Wait until people start to change
> the routing data and watch the ROAs becoming less and less correct...
>
>> Data quality is really good.
>
> It's not what you said:
>
> "It is safe to say that overall data quality is pretty bad"
> <https://labs.ripe.net/Members/AlexBand/resource-certification-rpki-in-the-real-world>
> (good paper, by the way, thanks)

A lot has changed since I wrote that. :)

-Alex

[. sorry cameron, trying to keep things down to one message ]

> http://tech.slashdot.org/story/12/04/27/2039237/engineers-ponder-easier-fix-to-internet-problem
> http://www.itworld.com/security/272320/engineers-ponder-easier-fix-dangerous-internet-problem

and don't miss

http://www.theregister.co.uk/2012/04/23/ip_hijack_prevention/

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

someone selling dnssec appliances flew a press release that a few
reporters bought without doing their homework. end of net predicted,
news at eleven.

> Taking what seriously ? The commitments to rpki you speak off ?

a thousand LIRs in the ripe region, 500 elsewhere? cisco code shipping
on a number of platforms, juniper soon. some of us have actually
started validating route origins in the real network using rpki and
cisco and juniper (test) code.

----

Saku Ytti <saku@ytti.fi> wrote:
> If two fails don't make win, then I think ROVER is better solution,
> doesn't need any changes to BGP just little software magic when
> accepting routes.

you are right, you have not done your homework. rpki-based origin
validation asks no changes to bgp.

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

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

----

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

this problem is inherent in any system which uses the address allocation
administrative hierarchy to attest to address space ownership, whether
rpki, dns-based, or hollerith cards.

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

----

randy

> first thing that sprung to mind was this:
> http://www.cafepress.com.au/nxdomain

geoff wore one at ripe64. i was soooooo green with envy that he has
graciously sent one to meet me when i get home from travails.

see http://archive.psg.com/001213.ietf-dns.pdf for my comments on the
subject at an ietf plenary a dozen years ago.

randy

* Alex Band:

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

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

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

I don't think so. Ultimately, it does not seem to be possible to get
this through the PDP.

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

On 28/04/2012 14:04, Alex Band wrote:
> they do not trust, or have a specific local policy for. In the toolsets
> for using the RPKI data set for routing decisions, such as the RIPE NCC
> RPKI Validator, every possible step is taken is taken to ensure that the
> operator is in the driver's seat.

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

It will be difficult for politicians / legislators / LEAs to look at a
technology like this and not see its potential for implementing wide-area
Internet blocking. For sure, the LEAs currently looking at it are
extremely interested.

Nick

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

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

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

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

Or the ITU ? :)

Cheers,
Phil

On 28/04/2012 18:27, Phil Regnauld wrote:
> To me that seems like the most obvious problem, but as Alex put it,
> "Everyone has the ability to apply an override on data they do not trust,
> or have a specific local policy for."

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

Nick

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

> On 28/04/2012 18:27, Phil Regnauld wrote:
>> To me that seems like the most obvious problem, but as Alex put it,
>> "Everyone has the ability to apply an override on data they do not trust,
>> or have a specific local policy for."
>
> So what do you suggest to do with a roa lookup which returns "Invalid"?

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

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

-Alex

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

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




Rubens

Rubens Kuhl (rubensk) writes:
> > In case you feel a BGP announcement should not be "RPKI Invalid" but something else, you do what's described on slide 15-17:
> >
> > https://ripe64.ripe.net/presentations/77-RIPE64-Plenery-RPKI.pdf
>
> The same currently happens with DNSSEC, doing what Comcast calls
> "negative trust anchors":
> http://tools.ietf.org/html/draft-livingood-negative-trust-anchors-01

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

On 28 Apr 2012, at 21:28, Phil Regnauld wrote:

> Rubens Kuhl (rubensk) writes:
>>> In case you feel a BGP announcement should not be "RPKI Invalid" but something else, you do what's described on slide 15-17:
>>>
>>> https://ripe64.ripe.net/presentations/77-RIPE64-Plenery-RPKI.pdf
>>
>> The same currently happens with DNSSEC, doing what Comcast calls
>> "negative trust anchors":
>> http://tools.ietf.org/html/draft-livingood-negative-trust-anchors-01
>
> Yes, NTAs was the comparison that came to my mind as well. Or even
> in classic DNS, overriding with stubs. You will get bitten by a bogus/
> flawed ROA, but you'll have to the chance to mitigate it. Any kind of
> centralized mechanism like this is subject to these risks, no matter
> what the distribution mechanism is.

Now that we have cleared up the fact that any RPKI statement can be overridden, I want to address another tenacious misunderstanding in relation to what Randy said:

On 28 Apr 2012, at 15:58, Randy Bush wrote:

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

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

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

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

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

-Alex

>> the worry in the ripe region and elsewhere is what i call the 'virginia
>> court attack', also called the 'dutch court attack'. some rights holder
>> claims their movie is being hosted in your datacenter and they get the
>> RIR to jerk the attestation to your ownership of the prefix or your ROA.
>
> If a Dutch court would order the RIPE NCC to remove a certificate or ROA from the system, the effect would be that there no longer is an RPKI statement about a BGP route announcement. The result is that the announcement will have the RPKI status *UNKNOWN*. It will be like the organization never used RPKI to make the statement in the first place.
>
> Thus, removing a certificate or ROA *does NOT* result in an RPKI INVALID route announcement; the result is RPKI UNKNOWN.
>
> The only way a court order could make a route announcement get the RPKI status *INVALID* would be to:
> 1: Remove the original, legitimate ROA
> 2: Tamper with the Registry, inject a false ROA authorizing another AS to make the announcement look like a hijack

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

-- Jen