Subject: [sidr] I-D Action: draft-ietf-sidr-rpki-validation-reconsidered-00.txt

From: [email-masked]
Date: Tue, 01 Jul 2014 18:27:17 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF.

        Title           : RPKI Validation Reconsidered
        Authors         : Geoff Huston
                          George Michaelson
                          Carlos M. Martinez
                          Tim Bruijnzeels
                          Andrew Lee Newton
                          Alain Aina
	Filename        : draft-ietf-sidr-rpki-validation-reconsidered-00.txt
	Pages           : 10
	Date            : 2014-07-01

Abstract:
   This document reviews the certificate validation procedure specified
   in RFC6487 and highlights aspects of potentially acute operational
   fragility in the management of certificates in the RPKI in response
   to the movement of resources across registries, and the associated
   actions of Certification Authorities to maintain continuity of
   validation of certification of resources during this movement.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-validation-reconsidered/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-sidr-rpki-validation-reconsidered-00

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Byron Ellacott <[email-masked]>
Date: Mon, 7 Jul 2014 03:54:09 +0000

I have read and reviewed this document.

The problem described is one that concerns me greatly as the operator of a
near-apex CA and repository.  While all due care is taken to ensure
correctness of action, good engineering practice is to identify risks
through frequency and impact and take steps to mitigate those risks.  In
this case, the frequency is low but the current impact is extremely high.
With solutions to mitigate the impact at hand, it seems straightforward to
me that those solutions should be pursued: removing the occurrence of
events of this nature altogether is impractical.

Regarding the content of the document, the last paragraph of section 2
offers a very clear description of the problem: a technical choice, not
driven by any system requirements, is imposing a significant consequence
on operations.

Section 3 covers scenarios related to movement of resources between CAs,
but does not consider the additional impact of cache refresh cycles.  Each
CA in a chain must wait until it is confident that all clients have
refreshed, which introduces at least 24 hours delay at each tier in the
hierarchy.  This cascade of delays up and down the hierarchy, plus
coordination lag across timezones, is likely to extend the time it takes
to move resources within the RPKI by days at best.  Perhaps the document
should make some reference to this issue?

And one minor typo at the top of page 4 with the resources listed as
".../24/24".  Fortunately this typo doesn't invalidate the rest of the
document :-)

  Byron

On 2/07/2014 11:27 am, "[email-masked]"
<[email-masked]> wrote:

>_______________________________________________
>sidr mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/sidr

---

From: Tim Bruijnzeels <[email-masked]>
Date: Thu, 10 Jul 2014 14:53:45 +0200

Hi,

As you may have noticed my name was added to the author list, so it will come as no surprise that I read this document and agree with its content.

I believe that all RIRs share both operational concerns outlined in section 3: (1) Operational fragility, and (2) resource transfers. One thing to note about the second case is that we don't have this problem right now because we only offer a hosted service where our members cannot create delegated certificates. However, this will change when we enable the provisioning (up-down) system and support non-hosted CAs that may delegate further.

Section 4 describes, in very general terms, two alternative approaches to counter these concerns.

The first approach has my strong preference. I believe it's simple to explain and implement, effective against both concerns, and I do not see any security issues with it. The change boils down to this: when doing top-down validation, just accept the *intersection* of resources listed on a certificate, and its parent. The idea of keeping track of resources explicitly is not new: we already have this when using 'inherit'. We have running code in our validator for this. It took us a day to implement this. The feature is off by default of course, but it's enabled without problems on a public instance that we're running: http://localcert.ripe.net:8088/

The second approach in section 4 was presented at the last IETF (draft-barnes-sidr-tao). Essentially it allows for transfer signalling through an up-down like protocol. Technically this approach can help to deal with transfer issues (2). The 'happy case' scenarios assume though that all involved parties play nice - and keep playing nice. There are many moving parts here, and it's not clear to me what happens when one party walks away (e.g. goes offline permanently). Additionally the timing of certificate shrinking in case of a cancel is not clear to me and introduces complexity: live transfer or not?, who signals the transfer?, when is it canceled, before or after shrinking and/or swinging? Can a cancel be canceled? But, more importantly, this approach offers no protection against the operational fragility case (1). Furthermore it adds a lot of complexity and this has huge costs in development (many months) and maintenance and introduces more operational fragility and potential interop issues between implementations.

Tim

---

From: "Carlos M. Martinez" <[email-masked]>
Date: Thu, 10 Jul 2014 15:23:40 -0300

As newly-added co-author of this document, I obviously share the
concerns expressed in Section 3.

Although it can be argued that these issues could be worked around by
careful coordination among all involved CAs when any change is to be
performed on resource sets included in CA certificates, these
coordination steps are only viable when only few CAs are involved.

Moreover, I believe that in an escenario where the Internet comes to see
any signficant deployment of the RPKI Provisioning Protocol this
coordination becomes more and more difficult and the chances for
possible brokenness in some limbs of the RPKI tree at a a particular
point in time will be rather high.

This is clearly not acceptable, and I believe the SIDR standards need to
be engineered for resiliency as much as for security.

In Section 4 two possible paths forward are proposed. The first option
presents a simple, understandable and workable alternative that, as Tim
has already mentioned, can be implemented by relying parties in a short
period of time.

Warm regards,

-Carlos

---

From: Stephen Kent <[email-masked]>
Date: Wed, 23 Jul 2014 14:30:20 -0400

Tim,

> Hi,
>
> As you may have noticed my name was added to the author list, so it 
> will come as no surprise that I read this document and agree with its 
> content.
>
> I believe that all RIRs share both operational concerns outlined in 
> section 3: (1) Operational fragility, and (2) resource transfers. One 
> thing to note about the second case is that we don't have this problem 
> right now because we only offer a hosted service where our members 
> cannot create delegated certificates. However, this will change when 
> we enable the provisioning (up-down) system and support non-hosted CAs 
> that may delegate further.
>
> The first approach has my strong preference. I believe it's simple to 
> explain and implement, effective against both concerns, and I do not 
> see any security issues with it. The change boils down to this: when 
> doing top-down validation, just accept the *intersection* of resources 
> listed on a certificate, and its parent. The idea of keeping track of 
> resources explicitly is not new: we already have this when using 
> 'inherit'. We have running code in our validator for this. It took us 
> a day to implement this. The feature is off by default of course, but 
> it's enabled without problems on a public instance that we're running: 
> http://localcert.ripe.net:8088/
Since you implemented this capability based on what we all agree is a 
rough description of the
intended functionality, can you be very confident that it is "correct"?

More to the point, we all agree that it is very bad for an RIR or NIR to 
issue a cert
that would break the current validation algoroithm. In a prior message I 
suggested several
checks that I thought every CA operating should perform to detect and 
avoid such errors.
Has RIPE been performing check such as these? Might adoption of relaxed 
validation rules
minimize the perceived need to perform such checks, i.e., encourage 
sloppiness?
> The second approach in section 4 was presented at the last IETF 
> (draft-barnes-sidr-tao). Essentially it allows for transfer signalling 
> through an up-down like protocol. Technically this approach can help 
> to deal with transfer issues (2).
The cited approach approach is designed expressly to deal with transfer 
issues, not with the
more general problem of errors by CAs. One ought not conflate these two 
issues.
> The 'happy case' scenarios assume though that all involved parties 
> play nice - and keep playing nice. There are many moving parts here, 
> and it's not clear to me what happens when one party walks away (e.g. 
> goes offline permanently). Additionally the timing of certificate 
> shrinking in case of a cancel is not clear to me and introduces 
> complexity: live transfer or not?, who signals the transfer?, when is 
> it canceled, before or after shrinking and/or swinging? Can a cancel 
> be canceled? But, more importantly, this approach offers no protection 
> against the operational fragility case (1). Furthermore it adds a lot 
> of complexity and this has huge costs in development (many months) 
> and maintenance and introduces more operational fragility and 
> potential interop issues between implementations.
Since we have NO description of resource transfer at the level of detail 
provided in the TAO I-D, it seems a bit premature to describe it as 
being more complex than the suggested alternative.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 23 Jul 2014 14:37:49 -0400

Carols,

> coordination steps are only viable when only few CAs are involved.
Section 3 addresses two distinct topics: errors by high tier CAs and
INR xfers. The former, and arguably the more serious of the two topics,
involves one CA making a mistake. The latter may involve 3 or more CAs.
Let's try to be precise in our comments.
> point in time will be rather high.
This is a very vague comment.
> be engineered for resiliency as much as for security.
Both are important.
> has already mentioned, can be implemented by relying parties in a short
Section 4 conflates two related, but distinct, issues. A method for INR
transfer, by itself, is not going to deal with errors by high tier CAs.

Tim is one developer of RP software. We ought to hear from the other two
RP software developers before judging how easy or hard it may be to adopt
a change that is not fully specified yet.

Steve

---

From: Russ Housley <[email-masked]>
Date: Thu, 24 Jul 2014 10:37:12 -0400

The Introduction says:

When this working group was developing the RPKI specifications, the RIRs essentially asked us not to specify how the "movement of resources across registries" would take place.  I for one accepted this at the time because it looked like an issue between RIRs.  This document is calling for a make-before-break certificate issuance capability.  Maybe there are other motives too.

RFC 3779 has been implemented.  For example, OpenSSL implements RFC 3779, and others make use of this certificate handling software.  We are not talking about a little tweak to such a library.  Implementation would require a path validation parameter to pass the content of the ROA.

As I understand the situation, the existing specification works, but it imposes some restrictions on the order that certificates that must be issued and distributed.

I really want to see the RPKI deployed, and deployed really soon.  I worry greatly that this proposed change will result in a very significant delay.

To change my mind, I'd need to see a serious impact on operators by the current specification. Can it be demonstrated with the various implementations that we already have in front of us?

Russ

---

From: Sandra Murphy <[email-masked]>
Date: Thu, 24 Jul 2014 11:30:52 -0400

> When this working group was developing the RPKI specifications, the RIRs essentially asked us not to specify how the "movement of resources across registries" would take place.  I for one accepted…

There are two cases.

One is the transfer case and the need to revise certs upward on the giving side and downward on the receiving side.  That's the make-before-break part.
The other is the problem of removing resources from certs - one CA reissues a "smaller" cert, and reissuing has to take place down the chain for the resources that are retained, in order to keep the encompassing rules valid.  The pain is felt in the CA's descendants until other CAs get their re-issuance done.

> RFC 3779 has been implemented.  For example, OpenSSL implements RFC 3779, and others make use of this certificate handling software.  We are not talking about a little tweak to such a library.  Imp…

Not sure that's the case.  I think all RPKI recipients now need to do a computation of which of a cert's resources are valid, which are not.  The *recipients* decide what the certificate says.  This will impact interpretation of a ROA but I don't think it requires something that has to get passed around with the ROA.

> As I understand the situation, the existing specification works, but it imposes some restrictions on the order that certificates that must be issued and distributed.

There's a order problem in the transfer case and a timing problem in the reduction case.

> To change my mind, I'd need to see a serious impact on operators by the current specification. Can it be demonstrated with the various implementations that we already have in front of us?

I think the case they point to can occur - but it is a matter of timing.  It will be a problem until the CA who needs to reissue does the reissue, and then the world picks that up.

---

From: Tim Bruijnzeels <[email-masked]>
Date: Thu, 24 Jul 2014 11:40:48 -0400

Steve, all,

>> The first approach has my strong preference. I believe it's simple to explain and implement, effective against both concerns, and I do not see any security issues with it. The change boils down to…

What I forgot to mention above is that we do issue warnings on over claiming certificates. So this is visible, although so-far we have not seen these warnings in the RIR production repositories.

> Since you implemented this capability based on what we all agree is a rough description of the

It's a beta feature for a reason. But I do believe there is value in running code and getting experience with this.

That said I think the approach safe. And what we implemented is my, quite specific, understanding of the intended approach. I tried to explain it in brief above, but if this is not clear enough and the WG prefers, I would be happy to provide more formal text for this.

> More to the point, we all agree that it is very bad for an RIR or NIR to issue a cert
> that would break the current validation algoroithm. In a prior message I suggested several
> checks that I thought every CA operating should perform to detect and avoid such errors.
> Has RIPE been performing check such as these? Might adoption of relaxed validation rules
> minimize the perceived need to perform such checks, i.e., encourage sloppiness?

It is not my intention, and I believe it's safe to say that it's not the intention of others, to encourage sloppiness, but to minimise impact and improve resiliency if an error does occur.

Speaking for our own CA implementation. We have code in place to ensure that we cannot create over-claiming certificates. We also have code to re-issue products as needed when resources are shrunk (e.g. omitting certain ROA prefixes when the resources are no longer held by the CA). However, there are a lot of moving parts here, and no software is without bugs. This problem gets worse when certificates are received from, or issued to third parties. In our current software we manage all CAs in our hierarchy locally, so we *know* when something changes and we can do the above. When dealing with 3rd parties there may be a significant time that parent and child are out of sync about the resources held by the child.

>> The second approach in section 4 was presented at the last IETF (draft-barnes-sidr-tao). Essentially it allows for transfer signalling through an up-down like protocol. Technically this approach can help to deal with transfer issues (2).
> The cited approach approach is designed expressly to deal with transfer issues, not with the
> more general problem of errors by CAs. One ought not conflate these two issues.

Okay, fair enough. As long as it's clear that this is the scope.

>> The 'happy case' scenarios assume though that all involved parties play nice - and keep playing nice. There are many moving parts here, and it's not clear to me what happens when one party walks away (e.g. goes offline permanently). Additionally the timing of certificate shrinking in case of a cancel is not clear to me and introduces complexity: live transfer or not?, who signals the transfer?, when is it canceled, before or after shrinking and/or swinging? Can a cancel be canceled? But, more importantly, this approach offers no protection against the operational fragility case (1). Furthermore it adds a lot of complexity and this has huge costs in development (many months) and maintenance and introduces more operational fragility and potential interop issues between implementations.
> Since we have NO description of resource transfer at the level of detail provided in the TAO I-D, it seems a bit premature to describe it as being more complex than the suggested alternative.

Okay, fair enough as well. I will maintain that in my opinion the TAO introduces a lot of complexity (and open questions above), but my belief that it's more complicated than the alternative is based on implicit interpretation and informal discussions about this, and not on a detailed document.

---

From: Tim Bruijnzeels <[email-masked]>
Date: Thu, 24 Jul 2014 12:09:30 -0400

On Jul 24, 2014, at 11:30 AM, Sandra Murphy <[email-masked]> wrote:
> …

> Not sure that's the case.  I think all RPKI recipients now need to do a computation of which of a cert's resources are valid, which are not.  The *recipients* decide what the certificate says.  Thi…

Okay, let me elaborate a bit on how we do this..

We don't use openssl for this. We have our own implementation and the way we do this is fully top-down. We don't pass the content of the ROA we are interested in around at all. We just keep track of the resources we *accept* at each stage in the top-down validation. We then insist (as know) that the ROA EE certificate has the resources (we accepted) for all the prefixes mentioned on it, and if not we reject it.

Resource certificates can already have the inherit flag in RFC3779. In such cases we already implicitly copy the parent resources, rather than reading them from the certificate itself. So we are already keeping a set of validated resources for each step in the chain in the context of a top-down validation.

The change is that rather than rejecting an over-claiming cert and everything below, we will only accept the intersection of resources mentioned on an otherwise valid child certificate and its parent certificate. And this is applied recursively down the chain. In other words: we don't necessarily believe what the certificate says, but we always evaluate this in the context of a top-down walk.

The main idea here is that these certificates do nothing more than tying a set of validated resources to validated keys. Whether over-claiming actually is a problem is only relevant when we look at other statements about these resources, such as ROAs, router certificates etc. If they refer to a resource that was over-claimed, they are rejected.

As mentioned before this change was actually trivial to implement for us as a beta feature.

Tim

---

From: Stephen Kent <[email-masked]>
Date: Thu, 24 Jul 2014 12:38:57 -0400

Sandy,

> ...
The second case merits further analysis, I think.

If the INRs being removed are not in use at lower tier CAs, then maybe 
they are not allocated
in certs issued to those CAs, and the process is trivial. If the INRs 
have been allocated
to lower tier CAs, and thus they are represented in the certs of the 
CAs, then one would not
expect to remove the INRs in a top down basis anyway, right? One would 
expect the lowest tier
CA holding the INRs that are to be returned to be the fist to relinquish 
them. Then this would
propagate up the chain, consistent with each CA updating its databases 
to reflect the new
allocation status. RPKI docs consistently state that certs are issued ti 
reflect the INR
databases of the entities acting as CAs. These databases ought not be 
updated to reflect a
return of INRs until that return has taken place. So, it seems that the 
only artificial timing
issue is the lag one has to accept in terms of RPKI repository (and 
cache) propagation. But,
we already know that such lags are intrinsic in the RPKI. Also, what are 
the requirements,
vis-a-vis timing, for completing INR removal? How man tiers of CAs are 
involved?
> Not sure that's the case.  I think all RPKI recipients now need to do a computation of which of a cert's resources are valid, which are not.  The *recipients* decide what the certificate says.  Thi…
Having looked at our RP software, I believe the revised vaidation 
approach (based on the current,
informal spec)  would require that we compute the intersection of parent 
and child CA certs along each
cert path and store the result.  This is independent of whether one is 
later using the path to
validate a ROA (with it's embedded EE cert) or a router cert (in 
BGPSEC). Maybe Russ was alluding
to the need to pass that intersection of INR sets to the ROA validation 
process.
> There's a order problem in the transfer case and a timing problem in the reduction case.
This seems like a good characterization, but I question whether the 
timing restrictions
are really important. Also, in the INR transfer case, I've seen detailed 
slides at APNIC
meetings showing how inter-RIR xfers work today. It is a process with a 
number of steps,
and some, limited parallelism. It's not clear how much additional 
parallelism one can
achieve with the proposed validation procedure, without violating the 
CP. We have a spec
of the details of INR xfer in TAO. We don't yet have an analogous spec 
for the proposed
validation model. Until we do, we can't accurately compare the proposed 
scenario vs. the
existing one.

Steve

---

From: Sandra Murphy <[email-masked]>
Date: Thu, 24 Jul 2014 13:25:25 -0400

speaking as regular ol' member

>> Not sure that's the case.  I think all RPKI recipients now need to do a computation of which of a cert's resources are valid, which are not.  The *recipients* decide what the certificate says.  Th…

I may have misread what Russ meant.  When I said "passed around", I meant passed with the ROA to someone downloading the RPKI data.

--Sandy

---

From: Stephen Kent <[email-masked]>
Date: Thu, 24 Jul 2014 13:31:21 -0400

Tim,

Thanks for providing the description of the processing you employ in 
your RP software.

> We don't use openssl for this. We have our own implementation and the way we do this is fully top-down. We don't pass the content of the ROA we are interested in around at all. We just keep track o…
In the 3779 spec, it is not necessary to maintain a list of valid INRs 
at each tier, so long as one
caches only valid certs. It suffices to compare the INRs in a 
subordinate cert against those in
the parent.
> Resource certificates can already have the inherit flag in RFC3779. In such cases we already implicitly copy the parent resources, rather than reading them from the certificate itself. So we are al…
Yes, the inherit flag does require creating a list of INRs for a cert 
that contains such a flag.
> The main idea here is that these certificates do nothing more than tying a set of validated resources to validated keys. Whether over-claiming actually is a problem is only relevant when we look at…
 From an operational perspective I agree that over claiming is a problem 
when an EE cert
for a ROA (or a Manifest, or a GB record, etc.) includes the INRs in 
question. But, a CA
that issues a cert containing resources that have not been allocated to 
it by its parent is
violating the CP. That bothers me, as it undermines a fundamental tenet 
of the RPKI.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Thu, 24 Jul 2014 13:53:04 -0400

Sandy,

> I may have misread what Russ meant.  When I said "passed around", I meant passed with the ROA to someone downloading the RPKI data.
For that interpretation of "passed around" I agree that this is not the 
case, i.e., no added
data need be downloaded from a repository or cache.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Thu, 24 Jul 2014 14:35:28 -0400

Tim,

> ...
>>>
>>> The first approach has my strong preference. I believe it's simple 
>>> to explain and implement, effective against both concerns, and I do 
>>> not see any security issues with it. The change boils down to this: 
>>> when doing top-down validation, just accept the *intersection* of 
>>> resources listed on a certificate, and its parent. The idea of 
>>> keeping track of resources explicitly is not new: we already have 
>>> this when using 'inherit'. We have running code in our validator for 
>>> this. It took us a day to implement this. The feature is off by 
>>> default of course, but it's enabled without problems on a public 
>>> instance that we're running: http://localcert.ripe.net:8088/
>
> What I forgot to mention above is that we do issue warnings on over 
> claiming certificates. So this is visible, although so-far we have not 
> seen these warnings in the RIR production repositories.
Can you says what tests you perform and how will they change if we adopt 
a relaxed path validation alg?
> It is not my intention, and I believe it's safe to say that it's not 
> the intention of others, to encourage sloppiness, but to minimise 
> impact and improve resiliency if an error does occur.
I understand this motive, but we have seen many examples over time where 
accepting non-conforming
data results in progressive degradation of implementations. This is why 
the RPKI specs mandate
RP enforcement of the criteria that CAs are supposed to follow in 
issuing certs.  This is in
contrast to the normal PKI specs which mandate CA cert generation rules, 
but do no generally
require RPs to check that certs have been generated consistent with 
these rules. In the Web PKI
context, this has resulted in a lot of "broken" certs being issued, and 
then accepted by RPs,
with not so great results. So, I think it is hard to increase resilience 
yet maintain sufficient
feedback to CAs to help encourage standards compliance.
> Speaking for our own CA implementation. We have code in place to 
> ensure that we cannot create over-claiming certificates. We also have 
> code to re-issue products as needed when resources are shrunk (e.g. 
> omitting certain ROA prefixes when the resources are no longer held by 
> the CA). However, there are a lot of moving parts here, and no 
> software is without bugs. This problem gets worse when certificates 
> are received from, or issued to third parties. In our current software 
> we manage all CAs in our hierarchy locally, so we *know* when 
> something changes and we can do the above. When dealing with 3rd 
> parties there may be a significant time that parent and child are out 
> of sync about the resources held by the child.
see my question above about how you ensure that certs don't over-claim 
and how the mechanisms
would change if path validation were relaxed.
>>> (draft-barnes-sidr-tao). Essentially it allows for transfer 
>>> signalling through an up-down like protocol. Technically this 
>>> approach can help to deal with transfer issues (2).
The first sentence of the Abstract for TAO says:

    This document defines an extension to the rpki-updown protocol to

provide support for transferring Internet Number Resources from one

INR holder to another.

That seems pretty clear.

Steve

---

From: Rob Austein <[email-masked]>
Date: Thu, 24 Jul 2014 15:35:50 -0400

I don't have much to add to the current discussion that I haven't
already said in previous discussion, but do have one additional datum:

A few months ago I said that it seemed possible that the
validation-reconsidered approach would alleviate some potential race
conditions involved in the loosely consistent database model.  For
what it's worth, I would like to report that in the one timing-related
corner case we managed to explore all the way down to the end of the
rat hole, it turned out that validation-reconsidered was irrelevant,
because the normal certificate revocation process during a resource
reduction produced the same effect regardless of the order in which
the RP saw the RPKI objects in question.

In other words: no smoking gun found.

---

From: Tim Bruijnzeels <[email-masked]>
Date: Thu, 24 Jul 2014 16:14:40 -0400

Hi,

a few more comments.. after this I think it's better (from my end) to discuss tomorrow in the working group.

On Jul 24, 2014, at 2:35 PM, Stephen Kent <[email-masked]> wrote:

> Can you says what tests you perform and how will they change if we adopt a relaxed path validation alg?

pseudo code:

Strict:
  parentresources = parentcertificate.getresources
  childresources = certificate.getresources
  if (parentresources contain childresources) {
     accept childresources
  } else {
     reject
  }

Relaxed:
  parentresources = parentcertificate.getAcceptedResources
  CLAIMED_childresources = certificate.getresources
  if (parentresources contain CLAIMED_childresources) {
     accept CLAIMED_childresources
  } else {
     warn about over-claimed resources
     accept remaining
  }

As mentioned in the other part of this thread: this applies to accepting resources on a certificate, i.e. in connection to a key. For ROAs we do insist that *all* resources that appear in ROA prefixes are accepted on the EE certificate used to sign the ROA. For MFT inherit is mandatory so it's irrelevant. For GBs also use inherit, so here the contact would only be accepted for remaining resources. For router certificates the router key would only be associated with accepted ASNs.

> I understand this motive, but we have seen many examples over time where accepting non-conforming
> data results in progressive degradation of implementations. This is why the RPKI specs mandate
> RP enforcement of the criteria that CAs are supposed to follow in issuing certs.  This is in
> contrast to the normal PKI specs which mandate CA cert generation rules, but do no generally
> require RPs to check that certs have been generated consistent with these rules. In the Web PKI 
> context, this has resulted in a lot of "broken" certs being issued, and then accepted by RPs, 
> with not so great results. So, I think it is hard to increase resilience yet maintain sufficient

And I understand that a whole tree being invalidated is a pretty strong motivator for fixing stuff. But I find the operational impact and liability of this happening at the top of the hierarchy disproportionate. Therefore I am advocating a model where the impact is limited to INRs in question. In my opinion that is still bad enough to motivate fixing things.

Very practical example: if we stuff up our TA certificate now we invalidate 2000+ members. With relaxed validation we would only affect a few. And yes, this is still bad enough that we would want to fix it ASAP.

> see my question above about how you ensure that certs don't over-claim and how the mechanisms

We currently rely on *pro-active* rules in our software that prevent this. But I have no issues with setting up *re-active* self-monitoring on top of this. And I have no problems with appropriate text instructing CAs that they SHOULD or even MUST do the latter.

>    provide support for transferring Internet Number Resources from one

That is indeed pretty clear. It is cited under 'alternative approaches' though, so maybe we would do well to make it clear here that this approach is designed to address one specific set of problems (i.e. transfers), or leave it out.

---

From: Stephen Kent <[email-masked]>
Date: Thu, 24 Jul 2014 17:20:38 -0400

Tim,

I think I was not clear in requesting clarification for your tests. I 
didn't mean to
ask what your RP code does. I was asking what your CA code does to 
detect and reject
over-claiming, and what it will do under relaxed validation rules. I ask 
because it
may be harder to perform such checks when there is an explicit intent to 
issue a CA cert
that contains INRs not present in the parent cert.

>  ....
>
> And I understand that a whole tree being invalidated is a pretty 
> strong motivator for fixing stuff. But I find the operational impact 
> and liability of this happening at the top of the hierarchy 
> disproportionate. Therefore I am advocating a model where the impact 
> is limited to INRs in question. In my opinion that is still bad enough 
> to motivate fixing things.
maybe.
> Very practical example: if we stuff up our TA certificate now we 
> invalidate 2000+ members. With relaxed validation we would only affect 
> a few. And yes, this is still bad enough that we would want to fix it 
> ASAP.
With relaxed validation a CA can make a mistake that erroneously 
allocates INRs to a child,
and there is no validation failure if the child and its descendents 
don't use the INRs in question.
So feedback may not be as forthcoming.
> That is indeed pretty clear. It is cited under 'alternative 
> approaches' though, so maybe we would do well to make it clear here 
> that this approach is designed to address one specific set of problems 
> (i.e. transfers), or leave it out.
You mean that the doc of which you are a coauthor mischaracterized TAO :-).

Steve

---

From: Byron Ellacott <[email-masked]>
Date: Fri, 25 Jul 2014 13:09:39 +0000

Hi,

From: Stephen Kent <[email-masked]<mailto:[email-masked]>>
Date: Thursday, 24 July 2014 5:20 pm
To: Tim Bruijnzeels <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rpki-validation-reconsidered-00.txt

Tim,

I think I was not clear in requesting clarification for your tests. I didn't mean to
ask what your RP code does. I was asking what your CA code does to detect and reject
over-claiming, and what it will do under relaxed validation rules. I ask because it
may be harder to perform such checks when there is an explicit intent to issue a CA cert
that contains INRs not present in the parent cert.

I can't speak for RIPE, but at APNIC when a child requests a certificate for us, we intersect it with our registry data, and our own CA certificate.  What we cannot do is confirm that our own parent hasn't in the meantime published a new certificate for us with some resource removed: we can only detect that after it has happened, and it would be preferable that detection leads to correction without an intermediate step of total invalidation of a region.

In a perfect world, of course, no process would ever lead to a parent shrinking their child's certificate without adequate communication and preparation, but if we were in a perfect world, a large part of the use case for SIDR would be gone, because no router operator would ever make an erroneous BGP announcement.

  Byron

---

From: Stephen Kent <[email-masked]>
Date: Fri, 25 Jul 2014 12:20:49 -0400

Byron,

Thanks for providing the details of what APNIC does.  Those are 
precisely the sort of
checks I would hope for.

I agree that if APNIC had IANA as its parent, then the issue you cited 
would be relevant, i.e.,
you can't know if IANA issued a new cert that removed an INR from your 
cert, which could result
in invalidating the whole APNIC cert. Of course, today, this is not an 
issue, because all RIRs
represent themselves as trust anchors.

Steve

---

From: Tim Bruijnzeels <[email-masked]>
Date: Fri, 25 Jul 2014 13:19:27 -0400

Hi,

On Jul 25, 2014, at 9:09 AM, Byron Ellacott <[email-masked]> wrote:

> Hi,
> 
> From: Stephen Kent <[email-masked]>
> To: Tim Bruijnzeels <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> I can't speak for RIPE, but at APNIC when a child requests a certificate for us, we intersect it with our registry data, and our own CA certificate.

Same here.

In addition: we include all resources explicitly in our certificate sign requests from our *online* CA to the offline TA that we manage. This TA will re-issue the TA certificate itself if needed, to include all requested resources. I need to double check our code but I am pretty certain that our online CA also shrinks its own understanding of which resources it has as soon as it issues a request - i.e. it does not wait to receive the shrunk certificate before we stop issuing these resources to child certificates, but we *do* wait until we received the certificate before we issue from *new* resources. Any modifications to the TA certificate and online certificates are printed to the console and the operator needs to confirm before the certificate is cut. We require 3 out of 10 senior RIPE NCC staff to agree to the transaction (they have a smart card and need to enter their passphrase).

> What we cannot do is confirm that our own parent hasn't in the meantime published a new certificate for us with some resource removed: we can only detect that after it has happened, and it would be preferable that detection leads to correction without an intermediate step of total invalidation of a region.

We will not intentionally break things obviously. And so-far our track record has been flawless on this.

But there are various reasons why, despite our best efforts, our online CA may still be out of sync. A bug can be introduced in our code, or there could be problem in publication and yesterday's TA certificate is not updated but the CA certificate is, and if we would receive a certificate from an upstream that is not managed by us then we have no assurance. And as Byron points out we can only find this out after the fact. We do regularly validate our repository, we don't actively monitor the exact resources on our certificate, but we do monitor for sudden drops in valid objects. By that time damage has been done though.

The same problems apply on a smaller scale to any of our members that run a non-hosted CA. We currently don't support this yet in our production environment, but it's coming.

As I said before I think that invalidating *ALL* resources in this case is disproportionate. I would be much more comfortable with minimising the impact. And still monitor for any overclaiming-warnings, and still deal with them ASAP.

> In a perfect world, of course, no process would ever lead to a parent shrinking their child's certificate without adequate communication and preparation, but if we were in a perfect world, a large…

+1

Tim

---

From: Carlos Martinez-Cagnazzo <[email-masked]>
Date: Fri, 25 Jul 2014 14:45:54 -0400

It is weird that we even need to state here that we the five RIRs are not
going to break things intentionally, but, yeah, LACNIC will not break
things intentionally either.

Engineering for resiliency is as much a necessity as engineering for
security. If the damage caused by the failures of the solution itself
becomes worse than the damage caused by the problem, well, no one is going
to deploy the solution.

regards,

-Carlos

On Fri, Jul 25, 2014 at 1:19 PM, Tim Bruijnzeels <[email-masked]> wrote:

> Subject: Re: [sidr] I-D Action:
> draft-ietf-sidr-rpki-validation-reconsidered-00.txt
>
>   Tim,
>
>  I can't speak for RIPE, but at APNIC when a child requests a certificate
> for us, we intersect it with our registry data, and our own CA certificate.
>
>
> Same here.
>
> In addition: we include all resources explicitly in our certificate sign
> requests from our *online* CA to the offline TA that we manage. This TA
> will re-issue the TA certificate itself if needed, to include all requested
> resources. I need to double check our code but I am pretty certain that our
> online CA also shrinks its own understanding of which resources it has as
> soon as it issues a request - i.e. it does not wait to receive the shrunk
> certificate before we stop issuing these resources to child certificates,
> but we *do* wait until we received the certificate before we issue from
> *new* resources. Any modifications to the TA certificate and online
> certificates are printed to the console and the operator needs to confirm
> before the certificate is cut. We require 3 out of 10 senior RIPE NCC staff
> to agree to the transaction (they have a smart card and need to enter their
> passphrase).
>
> What we cannot do is confirm that our own parent hasn't in the meantime
> published a new certificate for us with some resource removed: we can only
> detect that after it has happened, and it would be preferable that
> detection leads to correction without an intermediate step of total
> invalidation of a region.
>
>
> But there are various reasons why, despite our best efforts, our online CA
> may still be out of sync. A bug can be introduced in our code, or there
> could be problem in publication and yesterday's TA certificate is not
> updated but the CA certificate is, and if we would receive a certificate
> from an upstream that is not managed by us then we have no assurance. And
> as Byron points out we can only find this out after the fact. We do
> regularly validate our repository, we don't actively monitor the exact
> resources on our certificate, but we do monitor for sudden drops in valid
> objects. By that time damage has been done though.
>
> The same problems apply on a smaller scale to any of our members that run
> a non-hosted CA. We currently don't support this yet in our production
> environment, but it's coming.
>
> As I said before I think that invalidating *ALL* resources in this case is
> disproportionate. I would be much more comfortable with minimising the
> impact. And still monitor for any overclaiming-warnings, and still deal
> with them ASAP.
>
>
> In a perfect world, of course, no process would ever lead to a parent
> shrinking their child's certificate without adequate communication and
> preparation, but if we were in a perfect world, a large part of the use
> case for SIDR would be gone, because no router operator would ever make an
> erroneous BGP announcement.
>
>
> +1
>
> Tim
>
>
>    Byron
>
>
>

-- 
--
=========================
Carlos M. Martinez-Cagnazzo
h <http://cagnazzo.name>ttp://cagnazzo.me
=========================

---

From: Stephen Kent <[email-masked]>
Date: Thu, 31 Jul 2014 16:03:13 -0400

Carlos,

> It is weird that we even need to state here that we the five RIRs are 
> not going to break things intentionally, but, yeah, LACNIC will not 
> break things intentionally either.
I don't think anyone requested that each RIR pledge to not try to break 
the RPKI.
I did ask that RIRs describe what measures they take to detect possible 
errors, prior
to issuing certs that might cause subordinate CAs to fail 3779 
validation criteria. I thought
the replies from RIPE and APNIC were very encouraging.
> becomes worse than the damage caused by the problem, well, no one is 
> going to deploy the solution.
Terry has reminded us that, even if such accidents occur, the world does 
not end, at
least wrt origin validation. Thus, for the current set of SIDR RFCs, the 
damage that
would occur is not nearly so great as some have suggested; until the 
error is fixed (which
one would presume would be fairly quickly), origin validation would 
treat the affected
routes as no worse than they are treated today.

Terry's message from 7/25 suggested that we revisit details of BGPSEC to 
see if we might
want to address the the concerns about errors in the RPKI in a more 
accommodating fashion.
I think he has a good point. We are still working on BGPSEC and so we 
have the leeway to
revisit details of this sort.

In the SIDR meeting last week Geoff cited a problem that relaxing the 
3779 validation criteria
was supposed to address (though not explicitly mentioned in his I-D): an 
operator who asserts
that it holds an ASN, at odds with the RIR that is supposed to be 
authoritative for the assignment
of that ASN. This case is illustrative of the concern I tried to raise 
in my comments to Tim, i.e.,
I worried that relaxing 3779 validation rules might encourage sloppiness 
in managing the
RPKI, e.g., causing CAs to violate the CP by not maintaining the RPKI as 
a representation
of their allocation databases. Geoff's example seems to suggest that my 
concern is warranted.
Relaxing 3779 validation "fixes" the cited problem by making the 
deviation from the allocation
hierarchy acceptable, at the expense of the CP.

Finally, the point I tried to make near the end of the session was that 
if we are worrying
about errors by high-tier CAs that break certs (via 3779 validation), 
then that worry also
should extend to errors that revoke certs. Relaxing 3779 validation 
rules will not help
with that problem. The Suspenders proposal does address that, and a 
broader range of behaviors by CAs.
So while Suspenders may not be the answer, I believe that the current 
problem statement in
draft-ietf-sidr-rpki-validation-reconsidered is way too narrow, as it 
fails to address the
wider set of errors (or compelled behavior) by (high tier) CAs in the RPKI.

Steve