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

[Stephen Kent <[e-mail]>]

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.
>
>>
>> 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 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.
>
>>
>> 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?
I see your point. yes, the ROA spec does need to be modified.

Steve