Subject: Re: [sidr] AD Review of draft-ietf-sidr-rpki-validation-reconsidered-07

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Thu, 15 Jun 2017 15:02:17 +0000

Dear authors:

Hi!

It’s been 3 months since this e-mail, which was the last of the thread started from my review.

I am expecting a revised ID – what are the plans to move forward?

Thanks!

Alvaro.

On 3/15/17, 10:24 AM, "sidr on behalf of Tim Bruijnzeels" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

Hi Chris,

On 13 Mar 2017, at 15:21, Chris Morrow <[email-masked]<mailto:[email-masked]>> wrote:

but, having 2 versions of the validation
algorithm and seeing published data for both OID sets for a single
prefix/publication bundle will be very problematic. There's no
proscribed 'prefer new over old' action here, so a CA must only
publish one version of their data.

Why is this a problem, really?

The OIDs are set on a per certificate basis by the issuing CA. FWIW, in our hosted set up we *will* be able to pro-actively re-issue everything using the new OIDs without user interaction, but there are cases in hosted CA deployments where a hosted CA can automatically re-issue manifests, but ROAs can only be re-issued by explicit user request, one by one.

So we may see hosted CAs with products like this:

1 CRL (validation algorithm does not apply)
1 MFT (new validation, although it won't matter because inherit is used)
1 ROA with new validation (which has been re-issued by the user)
1 ROA with old validation (which has NOT yet been re-issued)

This might seem confusing, but since the OIDs make it very explicit which algorithm the CA intended to use, I really do not see any ambiguity here.

My main concern is that we need to be quite confident that new RP code that understands the new OIDs has been available and is deployed. Because old RPs will reject EVERYTHING once CAs start using the new OIDs.

That is why I would have preferred to not need new OIDs, and just agree on a day that the new algorithm should be preferred. Rob seems adamant that the RFC3779 extension library code does not have access to the context of the full certificate with the RPKI CP OID - so there is no way to have something like:

if (FULL certificate has RPKI CP OID && Date is after 'switch' day) {
  do NEW on RFC3779 extension
} else {
  do OLD on RFC3779 extension
}

The impact of RP software not using the new library on 'switch' day is fairly limited. They would not reject the full repository, but only reject the exceptional cases where certificates ARE over-claiming. And of course the date check can be removed in releases of the library after 'switch' day..

It seems to me that this is a design issue with OpenSSL itself, but be that as it may - it may be unsurmountable. Rob knows this code much better than I do.

Still the consequence of all this is is that we will have to have a mix, and that despite our best efforts to warn everyone to upgrade their RP software I expect that we WILL see a number of operators that suddenly find that their old RP software has reject our full repository when start using the new OIDs.

If it can't be avoided than so be it, but I believe this perspective should be considered as well.

Cheers

Tim

---

From: Tim Bruijnzeels <[email-masked]>
Date: Thu, 22 Jun 2017 10:36:19 +0200

Hi Alvaro, all,

Speaking for myself the reason for the delay is that I underestimated the impact of the new OIDs on deployability of this algorithm. I also meant to talk to all interested parties about this in person in Chicago, but unfortunately my father was hospitalised at the time (all good now!).

All that said I will work on an update of this document following Alvaro’s review. This document will define an additional validation algorithm, but not update the existing one. We can finish this work first and then have a structured discussion about deployment - I propose that we take this work to SIDROPS.

I canceled all my meetings today so I should have updated text to share with my co-authors soon. Will then send a new version to the WG asap.

Tim

> On 15 Jun 2017, at 17:02, Alvaro Retana (aretana) <[email-masked]> wrote:
> 
> Dear authors:
>  
> Hi!
>  
> On 3/15/17, 10:24 AM, "sidr on behalf of Tim Bruijnzeels" <[email-masked] on behalf of [email-masked]> wrote:
>  
> Hi Chris, 
>  
>> On 13 Mar 2017, at 15:21, Chris Morrow <[email-masked]> wrote:
>>

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Thu, 22 Jun 2017 09:24:49 +0000

On 6/22/17, 10:36 AM, "Tim Bruijnzeels" <[email-masked]> wrote:

Tim:

Hi!

> All that said I will work on an update of this document following 
> Alvaro’s review. This document will define an additional validation 
> algorithm, but not update the existing one. We can finish this work 
> first and then have a structured discussion about deployment - I 
> propose that we take this work to SIDROPS.

I’m assuming that you mean: finish draft-ietf-sidr-rpki-validation-reconsidered in sidr (i.e. publish as an RFC) and then further discuss deployment in sidrops, right?

> I canceled all my meetings today so I should have updated text to 
> share with my co-authors soon. Will then send a new version to 
> the WG asap.

Just a procedure note:  Even though there should be a good number of changes, I don’t think we need to run the result through the WG (as in a new WGLC).  I’m happy to allow time for anyone to comment further, either now or during IETF LC.  I just rather not officially send the document back to the WG.

Thanks!

Alvaro.

---

From: Tim Bruijnzeels <[email-masked]>
Date: Thu, 22 Jun 2017 11:26:52 +0200

> On 22 Jun 2017, at 11:24, Alvaro Retana (aretana) <[email-masked]> wrote:
> 

yes

> Just a procedure note:  Even though there should be a good number of changes, I don’t think we need to run the result through the WG (as in a new WGLC).  I’m happy to allow time for anyone to comme…

Works for me

---

From: Tim Bruijnzeels <[email-masked]>
Date: Mon, 26 Jun 2017 12:11:22 +0200

Dear Alvaro,

We have just uploaded a -08 version. See comments in-line below:

> On 9 Mar 2017, at 19:44, Alvaro Retana (aretana) <[email-masked]> wrote:
> 
> Dear authors:
>  
> I just finished reading this document.  My review is predicated on the assumption that the intent of the WG is to define an additional validation process, and not amend/change/update/deprecate the existing one…yet, which is why there are not only process changes specified, but also new OIDs.
>  
> As written, with Updates and text “to be used in place of” existing specifications, the document achieves the deprecation of the current (old) mechanism: simply because procedurally you are replacing the existing/old text with the new one…and the old one would then not be anymore.  The result then is not coherent with the assumption above, and we will need to rewrite (at least from an intent point of view) the document before progressing.
>  
> I think that the easiest way forward would be for this document to say something like: “a new validation mechanism is specified, which uses these new OIDs – the specifications defined in RFCA, RFCB, etc.. apply, except for the following exceptions/changes.”  You should then be able to use most of the substantive text already written.
>  
> Please see below for specific comments – including more on why this document should not Update the existing RFCs.
>  
> Thanks!
>  
> Alvaro.
>  
>  
>  
> Major:
>  
> M1. Section 4.2.1. (Changes to RFC6484).  This document requests an assignment of a new OID (id-cp-ipAddr-asNumber-v2); both the reference and the policy to be followed are contained here, and not in RFC6484.  IOW, this document shouldn’t Update RFC6484.  Instead, it should request the new OID and simply reference RFC6484 when pointing back to id-cp-ipAddr-asNumber.
>  

done, using “alternative to” in lots of places now..

>  
> M2. Section 4.2.2. (Changes to RFC3779).  Same comment: this document requests the assignment of new OIDs….  Note that if the changes in Section 4.2.2.1. (OID for id-pe-ipAddrBlocks-v2) and Section 4.2.2.3. (OID for id-pe-autonomousSysIds-v2) were to be used in place of the text in RFC3779, then id-pe-ipAddrBlocks and id-pe-autonomousSysIds would end up being deprecated.
>  
> M2.1. [minor] The syntax for id-pe-ipAddrBlocks-v2 and id-pe-autonomousSysIds-v2 (4.2.2.2 and 4.2.2.4) use the “v1” names.
>  
> M2.2. For Sections 4.2.2.5 and 4.2.2.6, I think that what you want to say is (something like): “when the OIDs defined in this document are used, the procedures in RFC3779 are followed, except for the certificate path validation (section 2.3), which is specified in Section 4.2.4.4 of this document, and…”  Again, if the text was to replace what is currently in RFC3779, then those procedures would be deprecated.
>  
> M2.3. Same comment for Section 4.2.2.7: amending the specification in RFC3779 results in loosing what is defined there.
>  

done

>  
> M3. Section 4.2.4. (Changes to RFC6487).  Same comments as above: replacing the text (which is what an Update does), would result in the mechanism specified in RFC6487 to be the same as what is specified in this document…which means that the option in the first paragraph (“…MUST issue certificates either as specified in [RFC6487] or with all the amendments specified in the following sections.) would result in the same thing.  As with Section 4.2.2 (above), I think you really should specify what the exceptions are for the extensions defined in this document (and not Update RFC6487).

Presented as an alternative. But note that the validation algorithm proposed here can handle a mix of RFC6487 and ‘reconsidered’ certificates. In a nutshell: it will warn on over-claims if ‘reconsidered’ OIDs are used, and reject otherwise. This allows for a gradual deployment in the RPKI where some issuing CAs opt in to using this, and other don’t (yet).

In other words: RPs that support ‘reconsidered’ should use this approach instead of the algorithm defined in 7.2 of RFC6487. The outcome in a pure RFC6487 world will be unchanged, the only negative effect being that work was spent on calculating “Validated Resource Sets” that was not strictly needed.

>  
>  
> M4. Section 4.2.4.4. (Amended Resource Certificate Path Validation).
>  
> M4.1. [Comment about RFC6487] This document correctly mentions the NotBefore/NotAfter values (which should really be notBefore/notAfter), instead of From/To (in RFC6487).  It seems to me that this is an error in the original text.  Can you please file an Errata against RFC6487?

Focussing on this first, will try to remember!

>  
> M4.2. s/Certificate x contains all the extensions that MUST be present/Certificate x contains all the required extensions    The “MUST” is not normative in this context.

Ok, I think it’s better now. I also made it explicit what to expect when an RFC6487 CP is found, vs a ‘reconsidered’ CP.

>  
> M4.3. [minor] s/MUST be satisfy the constraints/MUST satisfy the constraints
>  
> M4.4. “If IP Address Delegation extension is present, it is replaced with the intersection of the values from that extension and the current value of the VRS-IP.”  What is replaced, the IP Address Delegation extension or the VRS-IP?  If the extension, what does it mean to replace the extension in the certificate?   Note that the text about the AS Identifier Delegation extension is as confusing.
>  
> M4.5. “…these values MAY be stored along with the certificate, to facilitate incremental validation…”  This document (and RFC6487) don’t say anything about where to store anything – I don’t think we need that normative “MAY”.   s/MAY/may

Removed this altogether - not important to specify here.

>  
> M4.6. This text is not needed: “If certificate x uses the original version of [RFC6487], then certificate x MUST be rejected.”

This text is needed but I clarified. The validation algorithm proposed can handle a mix of RFC6487 and ‘reconsidered’ certificates. In a nutshell: it will warn on over-claims if ‘reconsidered’ OIDs are used, and reject otherwise. This allows for a gradual deployment in the RPKI where some issuing CAs opt in to using this, and other don’t (yet).

>  
> M5. Section 4.2.5. (Changes to RFC6482).  Same comment about not needing an Update/replacing the text/…

Done.

However, since all resources on ROA prefixes would need to be part of the VRS-IP for a ROA EE certificate, we might as well say that ROA EE certificates MUST never use the reconsidered profile. It would be pointless to accept the EE certificate with warnings about over-claim, only to reject the ROA itself because it lists prefix that were rejected.

You didn’t mention, but I assume that the same comment applies to section 4.2.6 (router certificates), so updated that as well.

For the moment the document describes validation in case the reconsidered OIDs *are* used for ROAs and Router Certificates - personally I feel this is probably best because it’s explicit. And it leaves the question whether the new OIDs MAY/MUST NOT be used in these cases to the migration discussion we still need to have after this work.

>  
>  
> M6. Section 5. (Deployment Considerations).  The timeline in Table 1 shouldn’t appear in this specification.  Migration is an operational issue that the community should coordinate separately (and not by specifying a normative timeline in an RFC).  What should be included here are any other migration considerations that should be observed when making the transition – if there’s anything beyond what you already wrote.

done 

>  
>  
> M7. Section 6. (Security Considerations). Please point to the security considerations in RFC3779, RFC6482, RFC6484 and RFC6487 as applying here too.  It might be beneficial to include a short discussion of why not immediately rejecting the over-claiming certificates is not a security issue

done 

>  
>  
> M8. IANA Considerations.   TBD4/TBD5 are not for IPAddrAndASCertExtn-*, but for the new id-mod-ip-addr-and-as-ident-*.

done 

>  
> M9. References
> - Please add a reference to RFC2119 and the corresponding boilerplate.

We have this reference, am I am missing something?

> - I don’t think that the reference to RFC6268 needs to me Normative.
> - We don’t need references to RFC3849, RFC5398 or RFC5737.
> - RFC3280 was Obsoleted by RFC5280

done 

>  
>  
>  
> Minor:
>  
> P1.  The example in Section 3 is meant to be a continuation from the example in Section 2 (“Certificate 2 from the previous example was re-issued by TA to CA1 and the prefix 198.51.100.0/24 was removed.  However, CA1 failed to re-issue a new Certificate 3 to CA2.”); but Certificate 3 is not the same as the one shown in Section 2.  I think the example still gets the over-claiming point across, but it is “wrong” in that both Certificate 2 and Certificate 3 (not just Certificate 2) would have to change for the problem to happen.
>  
> P2, Also in the example in Section 3.  It might be beneficial for the reader if the EE certificate was also marked as invalid; the text says so, but the list of certificates doesn’t.
>  
> P3. In several places “[this document]” is used – if the intent is to refer to a specific Section, please indicate which.  If not, then you should get rid of the brackets ([]).
>  
> P4. In 4.3: “ROA1 is considered valid because the prefix matches the Verified Resource Set on the embedded EE certificate, as required by RFC 6482.”  The VRS is introduced in this document, not RFC6482.
>  
>  
>  
> Nits:
>  
> N1. “This document proposes…” and “The changes proposed here…”.  We’re past the proposal phase: “This document specifies…”
>  
> N2. s/ maintaining Verified Resource Set/ maintaining a Verified Resource Set
>  
> N3. s/ the loss of on IP address prefix/ the loss of one IP address prefix
>  
> N4. s/ the 1988 ASN.1 modules for which we provided an update in Section 4.2.2.7 remain the normative version/ the 1988 ASN.1 modules in Section 4.2.2.7 remain the normative version
>  
> N5. s/ Furthermore we wish to note that operators MAY issue separate BGPsec Router Certificates for different ASNs/ Operators MAY issue separate BGPsec Router Certificates for different ASNs

All done

Thanks,

Tim