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

[Sandra Murphy <[e-mail]>]

Speaking as regular ol’ member:

> On Jul 15, 2016, at 1:28 PM, Stephen Kent <[e-mail]> 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 :
> 
>    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.

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:
> 
>    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 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sidr