Re: [sidr] New Version Notification for draft-madi-sidr-rp-00.txt

[Di Ma <[e-mail]>]

Oleg,

Thanks very much for your comments.

See my responses in lines. 

> 在 2016年7月13日，17:05，Oleg Muravskiy <[e-mail]> 写道：
> 
> Hi Di,
> 
>> On 27 Apr 2016, at 03:46, Declan Ma <[e-mail]> wrote:
>> 
>> Hi, folks,
>> 
>> Steve Kent and I have generated this document to try to consolidate RP requirements in one document, with pointers to all the relevant RFCs. 
> 
> I read the document, and I appreciate you putting it together, but I can't say I support this effort.
> 
> As you state in Section 1:
> 
>   The follow sections present requirements imposed on RPs as defined in
>   the following RFCs:
> 
>   RFC 6480 (RPKI Architecture)
>   RFC 6481 (Repository Structure)
>   RFC 6482 (ROA format)
>   RFC 6485 (Algorithms)
>   RFC 6486 (Manifests)
>   RFC 6487 (Certificate and CRL profile)
>   RFC 6488 (RPKI Signed Objects)
>   RFC 6489 (Key Rollover)
>   RFC 6810 (RPKI to Router Protocol)
>   RFC 6916 (Algorithm Agility)
>   RFC 7730 (Trust Anchor Locator)
>   RFC XXXX (Router Certificates)
> 
>   This document will be update to reflect new or changed requirements
>   as these RFCs are updated, or new RFCs are written.
> 
> I agree that there are many documents that one has to consult on order to make or verify an implementation of RPKI validation, but this document will *add* to that number!
> 
> Once this document is out, someone will have to keep it up to date (and not conflicting) with all those other documents. This could create more problems than it could solve.
> 
> My following comments basically show why it is difficult to keep this document in a state that would not create more problems.

I understand your concerns but I do think this document deserves our efforts. 

It’s not in state of art at present yet I hope it would be adopted to move along with help from the WG. 

> 
> 
>> As I mentioned in IETF 95 meeting, there is no standards language (e.g., MUST, SHOULD, MAY, ...) in this doc, as it is just POINTING to the docs that have the real requirements. 
> 
> Well, actually there is normative language:
> 
>   3.3.  CRL Processing
> 
>   The CRL processing requirements imposed on CAs and RP are described
>   in [RFC6487].  CRLs in the RPKI are tightly constrained; only the
>   AuthorityKeyIndetifier and CRLNumber extensions are allowed, and they
>   MUST be present.  No other CRL extensions are allowed, and no
>  ^^^^^^
>   CRLEntry extensions are permitted.  RPs are required to verify that
>   these constraints have been met.  Each CRL in the RPI MUST be
>                                                        ^^^^^^
>   verified using the public key from the certificate of the CA that
>   issued the CRL.
> 
> And there are several other places where the normative language is not used, but implied.

Thanks for catching the typos. 

We will change ‘MUST’ into ‘must’.

As for the implication stuff, the text is just paraphrasing the requirements from RFCs which I don’t think is sort of inappropriate. 


> 
> 
>> This doc outlines the RP functions, summarizes them and then gives reference to those precise sections or paragraphs, in order to make life easier for implementers to make sure he/she has addressed all of these requirements.
> 
> I have two comments for this paragraph.
> 
> First, it might seem appealing to create a document that will give a "reference to those precise sections or paragraphs", so that the implementer could skip reading those long RFCs in full.  But I do not think it is possible or advisable. Even in your draft you say:
> 
>   An RP is required
>   to verify that a resource certificate adheres to the profile
>   established by [RFC6487].  This means that all extensions mandated by
>   [RFC6487] must be present and value of each extension must be within
>   the range specified by this RFC.  Moreover, any extension excluded by
>   [RFC6487] must be omitted.
> 
> or
> 
>   To determine whether a manifest is valid, the RP is required to
>   perform manifest-specific checks in addition to those specified in
>   [RFC6488].
> 
> So very often it is more practical to refer to the whole RFCs, because an implementer has to implement all of it, not just specific paragraphs.
> 

We are not suggesting that implementers skip reading those RFCs in full.

This draft is born to be a guide to help implementers get the essentials of RP functionalities scattered in different RFCs. Anyone who wants to comprehend RPKI cannot be exempted from reading all the RPKI RFCs, let alone the implementers.

One might see the RP requirements document as a“Manifest” for all necessary RP functions. 

> 
> Second, what if, for whatever reason, this document will not list *all* of the requirements?  Will it be OK for the implementer to say "I did everything specified there", or will (s)he be required to double-check with other RFCs you refer to?  Or even with those you do not refer to?
> 
> I’m not sure how to define the applicability of such document.

This is document is intended to be Informational, which is going to help implementers to find what they want. The tricky part is the your concerns are of different granularity!

This document tell readers an RP system is supposed to contain these categories:

--Fetching and Caching RPKI Repository Objects

-- Processing Certificate and CRL

--Processing RPKI Repository Signed Objects

--Delivering Validated Cache Data to BGP Speakers

But for whether an implementer did everything specified “there”, they should double check “there” which is specific paragraph in the referenced RFCs. 


Once again, we are not suggesting that implementers skip reading those RFCs in full.

IF they want to do double-check, they are encouraged to know the breakdown of every categories in terms RP requirements. 

> 
> 
>> Any comments and feedbacks are appreciated.
> 
> Here are my comments for some specific sections:
> 
>   3.1.  Verifying Resource Certificate and Syntax
> 
>   Certificates in the RPKI are called resource certificates, and they
>   are required to conform to the profile [RFC6487].  An RP is required
>   to verify that a resource certificate adheres to the profile
>   established by [RFC6487].  This means that all extensions mandated by
>   [RFC6487] must be present and value of each extension must be within
>   the range specified by this RFC.  Moreover, any extension excluded by
>   [RFC6487] must be omitted.
> 
> I think you should not repeat the text of other RFCs, otherwise you risk of being incomplete or going out of sync with referenced RFC.

Good suggestion. 

We authors will see how to address issues.

And I would appreciate your help. 


> 
> 
>   3.2.  Certificate Path Validation
> 
>   In the RPKI, issuer can only assign and/or allocate public INRs
>   belong to it, ...
> 
> I don’t think assignment or allocation of INR happens in RPKI.

Agreed.

It should have been expressed like:  In the RPKI, issuer can only authorize the custodianship of public INR belonging to it, …

> 
> 
>   3.3.  CRL Processing
> 
>   The CRL processing requirements imposed on CAs and RP are described
>   in [RFC6487].  CRLs in the RPKI are tightly constrained; only the
>   AuthorityKeyIndetifier and CRLNumber extensions are allowed, and they
>   MUST be present.  No other CRL extensions are allowed, and no
>   CRLEntry extensions are permitted.  RPs are required to verify that
>   these constraints have been met.  Each CRL in the RPI MUST be
>   verified using the public key from the certificate of the CA that
>   issued the CRL.
> 
> 
> Apart from using normative language mentioned above, you seem to repeat the text of other RFC.
> Is it the only bit of RFC6487 that is applicable to CRL processing in RPKI validation?
> Aren’t any CRL validation (not only in RPKI) requires that CRL must be verified using the public key of it's issuer?

We will be considering adding text in terms of generalized CRL specification.


> 
> 
>   4.2.1.  Manifest
> 
>   To determine whether a manifest is valid, the RP is required to
>   perform manifest-specific checks in addition to those specified in
>   [RFC6488].
> 
>   Specific checks for a Manifest are described in section 4 of
>   [RFC6486].  If any of these checks fails, indicating that the
>   manifest is invalid, then the manifest will be discarded and treated
>   as though no manifest were present.
> 
> This description is quite incomplete. Perhaps you should merge the content of section "4.3.  How to Make Use of Manifest Data” in here, but even there I do not see a reference to section 6 (Relying Party Use of Manifests) of RFC6486, which is quite a big omission.

Manifest has been a tricky part. 

Manifest processing has proven to be significantly more complicated that initially anticipated. 

I hope SIDROPS WG to take the chance to give an operational advice along with this draft. 

> 
> 
>   4.2.2.  ROA
> 
>   To validate a ROA, the RP is required perform all the checks
>   specified in [RFC6488] as well as the additional ROA-specific
>   validation steps.  The IP address delegation extension [RFC3779]
>   present in the end-entity (EE) certificate (contained within the
>   ROA), must encompass each of the IP address prefix(es) in the ROA.
>   More details for ROA validation are specified in section 2 of
>   [RFC6482].
> 
> The second sentence is almost a 1-to-1 copy of Section 4 of 6482. What’s the point of copying it instead of referencing?


For smooth reading, in some cases, the text of this draft paraphrases the requirements, and in other cases it may merely restate them.

> 
> Section 2 of RFC6482 defines the ROA content-type, not the validation.
> 
> 
>   4.2.3.  Ghostbusters
> 
>   The Ghostbusters Record is optional; a publication point in the RPKI
>   can have zero or more associated Ghostbuster Records.  
> 
> This is true for all objects except manifest and CRL.
> 
>   If a CA has at
>   least one Ghostbuster Record, RP is required to verify that this
>   Ghostbusters Record conforms to the syntax of signed object defined
>   in [RFC6488].
> 
> And this is also true for any signed object.
> 
>   The payload of this signed object is a (severely) profiled vCard.  An
>   RP is required to verify that the payload of Ghostbusters conforms to
>   format as profiled in [RFC6493].
> 
> I'm mentioning it here, but it applies to many places in this document: the validation section of RFC6493 already references RFC6488. So why duplicate it here?
> 

They are not duplicate.

RFC6488 is for generalized validity check in terms of syntax yet RFC6493 is for syntax check especial for Ghostbusters. 


> 
>   4.3.  How to Make Use of Manifest Data
> 
>   For a given publication point, the RP ought to perform tests to
>   determine the state of the Manifest at the publication point.  A
>   Manifest can be classified as either valid or invalid, and a valid
>   Manifest is either current and stale.  An RP decides how to make use
>   of a Manifest based on its state, according to local (RP) policy.
> 
>   If there are valid objects in a publication point that are not
>   present on a Manifest, [RFC6486] does not mandate specific RP
>   behavior with respect to such objects.  However, most RP software
>   ignores such objects and this document recommends that this behavior
>   be adopted uniformly.
> 
> Instead of “recommending" it in this document, maybe we should review and change 6486?
> 
>   In the absence of a Manifest, an RP is expected to accept all valid
>   signed objects present in the publication point.  
> 
> Actually, 6486 says that all such objects "SHOULD be viewed as suspect, but MAY be used by the RP, as per local policy", which has subtle difference.
> 

As I mentioned above, Manifest has been a tricky part. Manifest processing has proven to be significantly more complicated that initially anticipated. 

We might as well considering to update RFC 6486. 


> 
> 
> I think this confirms that keeping such document up to date and consistent with other documents is not an easy task, and having this document will not relieve the implementer from studying deeply all the documents it refers.


As far I responded to you above, I think this document is worth efforts as a WG item though it is not in state of art at present. 

I would appreciate help and contributions from the WG, especially guys in charge of RP software. 


Di