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

From: [email-masked]
Date: Fri, 08 Jul 2016 02:19:43 -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 of the IETF.

        Title           : RPKI Validation Reconsidered
        Authors         : Geoff Huston
                          George Michaelson
                          Carlos M. Martinez
                          Tim Bruijnzeels
                          Andrew Lee Newton
                          Daniel Shaw
	Filename        : draft-ietf-sidr-rpki-validation-reconsidered-06.txt
	Pages           : 12
	Date            : 2016-07-08

Abstract:
   This document proposes an update to the certificate validation
   procedure specified in RFC 6487 that reduces aspects of operational
   fragility in the management of certificates in the RPKI, while
   retaining essential security features.

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:
https://tools.ietf.org/html/draft-ietf-sidr-rpki-validation-reconsidered-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-rpki-validation-reconsidered-06

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: Tim Bruijnzeels <[email-masked]>
Date: Fri, 8 Jul 2016 11:35:30 +0200

Dear WG,

After receiving some feedback on the previous version and discussion with co-authors, this version:
- Does not reject 'over-claiming' EE certificates, but uses VRS-IP/AS there as well
- Includes text to update ROA validation (in short requires that all prefixes are in VRS-IP of the EE)
- Includes a request to the authors of the bgpsec-rpki-profile document.

The reason why the change that I proposed to reject EE certificates has been reverted is that:
- This way the validation algorithm is consistent between CA and EE certificates
- Even though ROAs still require that *all* prefixes are contained in the VRS-IP, there may be other future use cases of EE certificates where a VRS-IP/AS that is smaller than the resources contained in the extensions.

Stephen Kent comment on -04 of this document saying that it should not attempt to update the BGPSec Router Certificate I-D because it's not an RFC, just yet. It's currently in IESG Processing. The current document therefore has a request and some suggestion to the authors to change the document (in which case the section can be deleted in the next (hopefully final) version of this document.

I don't mind either way. Maybe the chairs have an idea about what the best process is. But in either case we would like to ask the BGPSec Router Certificate authors to review the included text.

Thanks,

Tim

> On 08 Jul 2016, at 11:19, [email-masked] wrote:
> 
> 
> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr

---

From: Sean Turner <[email-masked]>
Date: Fri, 8 Jul 2016 09:00:34 -0400

> On Jul 08, 2016, at 05:35, Tim Bruijnzeels <[email-masked]> wrote:
> 

Tim,

Just so I’m following along:

- This draft replaces the text in RFC 6487 s7.2 so should rpki-validation-reconsidered draft include the “Updates: 6487 (if approved)” header?  My understanding is that the proposal is that all RPKI validators follow these new steps so that would make sense process wise.

- bgpsec-pki-profiles s3.3 currently refers to RFC 6487 s7 for validation procedures and technically if rpki-validation-reconsidered updates RFC 6487 when bgpsec-pki-profiles refers to RFC 6487 it includes those references so I wouldn’t necessarily have to add a explicit reference to rpki-validation-reconsidered … but people will forget this and miss the update and I know Wes hates chasing references ;)  So, to drive this point home we could do the following tweak in addition to adding your suggested bullet and separate-certificate per ASN suggestion:

OLD:

  The validation procedure used for BGPsec Router Certificates is
  identical to the validation procedure described in Section 7 of
  [RFC6487], but using the constraints applied come from this
  specification.

NEW:

  The validation procedure used for BGPsec Router Certificates is
  identical to the validation procedure described in Section 7 of
  [ID.sidr-rpki-validation-reconsidered], but using the constraints
  applied come from this specification.

Note I’d probably also add ID.idr-rpki-validation-reconsidered to the required reading list in the terminology section :/

spt

---

From: Stephen Kent <[email-masked]>
Date: Sat, 9 Jul 2016 18:12:28 -0400

Tim,

I have not yet read the -06 version, but I did notice a couple of issues 
in the 7.2 text I provided, most of which you adopted. Specifically, I 
think it useful to refer to 3779 in Section 2 in the 2nd paragraph, and 
at the end:

These criteria require, in particular, that the Internet Number

Resources (INRs) of each certificate in the validation path are

"encompassed" by INRs on the issuing certificate.(This criteria

    is derived from [RFC3779], which defines the certificate extensions

    used to represent INRs.) The first

certificate in the path is required to be a trust anchor, and its

resources are considered valid by definition.

All certificates in this scenario are considered valid (relative to 
[RFC3779] since the INRs in each certificate are encompassed by

those of the issuingcertificate.ROA1 is valid because the specified 
prefix isencompassed by the embedded EE certificate, as required by 
[RFC6482].

I copied text that was OK when it appeared in 6487, but now needs to 
refer to 6487:

     3.The Version, Issuer, and Subject fields of certificate x satisfy

the constraints established in Section 4.1-4.7 of [RFC6487].

4.Certificate x contains all the extensions that MUST be present,

as defined in Section 4.8 of [RFC6487].The value(s)

for each of these extensions MUST be satisfy the constraints

established for each extension in the respective sections.Any

extension not identified in Section 4.8 MUST NOT appear in

certificate x.

step 6 could be a bit be clearer with a minor edit:

6.If certificate x is an EE certificate, then the INRs of this

certificate MUST be "encompassed" by the values of VRS-IP and

VRS-AS computed for certificate x-1.

also, the loop sentence disappeared, so I added it after the last bullet 
in step 7:

Otherwise, return to step 1 and continue path validation.

---

From: Stephen Kent <[email-masked]>
Date: Fri, 15 Jul 2016 13:28:30 -0400

Tim,

I reviewed the -06 version and am attaching a pdf of the MS Word file 
with suggested edits. I can send you the word file itself if you wish.

I have provided text to my co-author, Sean, to include in the 
bgpsec-pki-profile doc to address your concern. I suggested the 
following text at the beginning of section 3 :

    The validation procedure used for BGPsec Router Certificates is
    identical to the validation procedure described in Section 7 of
    [RFC6487](and any RFC that updates this procedure), but using the
    constraints applied come from this specification.

Sean added an implementation considerations section which I suggest will 
say:

    Operators MAY choose to issue separate BGPsec Router Certificates for
    different ASNs. Doing so may prevent a BGPsec Router Certificate from
    becoming invalid if one of the ASNs is removed from any superior CA certificate
    along the path to a trust anchor.

I hope these changes avoid the need to say anything about router certs 
in your doc.

I'm not sure there is a need to change the ROA spec. If we agree that 
all prefixes in the ROA MUST be contained in the EE cert for that ROA, 
then the current text in the ROA spec does not need to change.

Steve

---

From: Sean Turner <[email-masked]>
Date: Sat, 16 Jul 2016 19:02:53 -0400

> On Jul 08, 2016, at 09:00, Sean Turner <[email-masked]> wrote:
> 
> 

I would like to propose that sidr-rpki-validation-reconsidered include an updates header, i.e., “Updates: 6487 (if approved)”, be included on the 1st page of the draft in the appropriate location.

Of the options presented in the change below for sidr-bgpsec-pki-profiles, I’d like to rely on the change proposed above and not make the OLD/NEW changes I proposed below, i.e., I am suggesting making no changes to the introductory text in s3.3 of sidr-bgpsec-pki-profiles to refer to sidr-rpki-validation-reconsidered because it’s an unnecessary change.

Steve’s suggested some other edits a a result of this thread and rpki-validation-reconsidered, so if the chairs direct me I can upload a new version of sidr-bgpsec-pki-profiles.  Since AD review hasn’t really happened yet, maybe we can treat these as late, but timely WGLC comments?

spt

---

From: Sandra Murphy <[email-masked]>
Date: Tue, 19 Jul 2016 12:32:43 -0400

Speaking as regular ol’ member:

> On Jul 15, 2016, at 1:28 PM, Stephen Kent <[email-masked]> wrote:
> 
> Tim,
> 
> I reviewed the -06 version and am attaching a pdf of the MS Word file with suggested edits. I can send you the word file itself if you wish.
> 
> I have provided text to my co-author, Sean, to include in the bgpsec-pki-profile doc to address your concern. I suggested the following text at the beginning of section 3 :
> 
>    [RFC6487]
> (and any RFC that updates this procedure)
> , but using the

I can’t parse “but using the constraints applied come from this specification”.  Can you clarify?

> 
> 
> Sean added an implementation considerations section which I suggest will say:
> 

I quibble about this wording.  why do you say “may”?  Is it because if the ASN in one of the separate router certificates is one of the ASNs that is removed, then it still becomes invalid?

I think you mean:

This document permits the operator to include a list of ASNs in a BGPsec Router Certificate.
In that case, the router certificate would become invalid if any one of the ASNs is removed
from any superior CA certificate along the path to a trust anchor.  Operators MAY choose
to avoid this possibility by issuing a separate BGPsec Router Certificate for each distinct
ASN, so that the router certificates for ASNs that are retained in the superior CA certificate
would remain valid.

I’m not sure you meant a normative “MAY choose” ("there are reasons, <listed here,> to make this choice”) or “could possibly choose”

> 
> 
> I hope these changes avoid the need to say anything about router certs in your doc.
> 
> I'm not sure there is a need to change the ROA spec. If we agree that all prefixes in the ROA MUST be contained in the EE cert for that ROA, then the current text in the ROA spec does not need to change.

Well……

The ROA RFC says validation of the ROA must satisfy:

   o  The IP address delegation extension [RFC3779] is present in the
      end-entity (EE) certificate (contained within the ROA), and each
      IP address prefix(es) in the ROA is contained within the set of IP
      addresses specified by the EE certificate's IP address delegation
      extension.

If the EE certificate and the ROA mention a /18, and a /19 is removed from a “superior CA certificate”, then there is/are only a /19 of the EE certificate that is/are VRP.  And every prefix in the ROA is still contained in the EE cert, so this validation step is satisfied.  What does this ROA now authorized?  How would it be applied in BGP route validation?

—Sandy, speaking as regular ol’ member

> 
> Steve
> 
> <draft-ietf-sidr-rpki-validation-reconsidered-06.pdf>_______________________________________________
> sidr mailing list
> [email-masked]

---

From: Stephen Kent <[email-masked]>
Date: Wed, 20 Jul 2016 10:42:36 -0400

Sandy,

> I can’t parse “but using the constraints applied come from this specification”.  Can you clarify?
The text I supplied for the replacement validation alg were based on the 
original text, whenever possible. Unfortunately, the original text 
refers to sections of 6487 implicitly as "this specification". Thus, in 
the new document we need to explicitly note that the indicated 
constraints on certs (e.g., required/prohibited extensions, etc.) are in 
the relevant parts of 6487.
> ASN, so that the router certificates for ASNs that are retained in the superior CA certificate
I prefer your text. Nice job.
> I’m not sure you meant a normative “MAY choose” ("there are reasons, <listed here,> to make this choice”) or “could possibly choose”
I'm not picky about the case of the MAY here.
> If the EE certificate and the ROA mention a /18, and a /19 is removed from a “superior CA certificate”, then there is/are only a /19 of the EE certificate that is/are VRP.  And every prefix in the…
I see your point. yes, the ROA spec does need to be modified.

Steve