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

From: Oleg Muravskiy <[email-masked]>
Date: Wed, 13 Jul 2016 17:05:16 +0200

Hi Di,

> On 27 Apr 2016, at 03:46, Declan Ma <[email-masked]> 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.

> 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.

> 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.

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.

> 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.

   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.

   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?

   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.

   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?

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?

   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.

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.

Oleg

> 
> 
> Di
> 
> ZDNS
> 
> 
>> 下面是被转发的邮件：
>> 
>> 发件人: [email-masked]
>> 主题: New Version Notification for draft-madi-sidr-rp-00.txt
>> 日期: 2016年4月12日 GMT+8 18:03:44
>> 收件人: "Dr. Stephen T. Kent" <[email-masked]>, "Di Ma" <[email-masked]>, "Stephen Kent" <[email-masked]>
>> 
>> 
>> A new version of I-D, draft-madi-sidr-rp-00.txt
>> has been successfully submitted by Di Ma and posted to the
>> IETF repository.
>> 
>> Name:		draft-madi-sidr-rp
>> Revision:	00
>> Title:		Requirements for Resource Public Key Infrastructure (RPKI) Relying Parties
>> Document date:	2016-04-12
>> Group:		Individual Submission
>> Pages:		10
>> URL:            https://www.ietf.org/internet-drafts/draft-madi-sidr-rp-00.txt
>> Status:         https://datatracker.ietf.org/doc/draft-madi-sidr-rp/
>> Htmlized:       https://tools.ietf.org/html/draft-madi-sidr-rp-00
>> 
>> 
>> Abstract:
>>  This document provides a single reference point for requirements for
>>  Relying Party (RP) software for use in the Resource Public Key
>>  Infrastructure (RPKI).  It cites requirements that appear in several
>>  RPKI RFCs, making it easier for implementers to become aware of these
>>  requirements.
>> 
>> 
>> 
>> 
>> 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.
>> 
>> The IETF Secretariat
>> 
> 
> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr

---

From: Declan Ma <[email-masked]>
Date: Fri, 15 Jul 2016 01:07:58 +0800

Oleg,

Thanks for your detailed comments.

> 在 2016年7月13日，23:05，Oleg Muravskiy <[email-masked]> 写道：
> 
> Hi Di,
> 

This document is intended to offer a starting point for searching RP requirements.

Yes. These referenced RFCs would be updated. But it’s the IETF not the implementers who should try to reflect the updates. 

As such, implementers merely need to keep an eye on the RP requirement document, which is going to exempt implementers from watching all the update of all the referenced RFCs. 

> And there are several other places where the normative language is not used, but implied.

Thanks for spotting these MUSTs.  We shall replace them by using different expressions. 

> 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 persuading implementers to skip reading those RFCs in full. Our 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 requirement as Manifest of all necessary RP functions. 

Besides, implementers need know more than what RP requirements are. They need to know how to reflect these functions as they are making software design. 

To that end, this draft has generalized RP requirements segmented with orthogonal functionalities in different sections.

> I’m not sure how to define the applicability of such document.
> 

This document is about to go through discussions in SIDR, merging comments from this WG. 

If a necessary piece of requirement is not included in this draft and the community agree to add it in, we of course would do that. 

> 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.

When we are repeating text, we consider them the best to brief this section, helping people to seize the key point. 

We are open to figure out a better way to do this. 

> Aren’t any CRL validation (not only in RPKI) requires that CRL must be verified using the public key of it's issuer?
> 

Well, CRL is not new. We might need to resort to some other documents, other than RPKI RFCs, to figure how to deal with CRL which all sorts of PKI systems need to handle. 

> 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?

When we are repeating text, we consider them the best to brief this section, helping people to seize the key point. 

We are open to figure out a better way to do this. 

> Section 2 of RFC6482 defines the ROA content-type, not the validation.

Right. We should have referenced section 4 of RFC6482. 

> 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?

The reason is quite straightforward. RFC 6493 is specialized for Ghostbusters. 

> Instead of “recommending" it in this document, maybe we should review and change 6486?

Agreed. 

> 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.

Agreed. We shall consider how to modify this sentence. 

> 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 a…

Maybe not an easy task but it deserves necessity and efforts. 

As I mentioned above,   I would like to reiterate the motivation of this work: 

1) This document is intended to offer a starting point for searching RP requirements.

2 ) These referenced RFCs would be updated. But it’s the IETF not the implementers who should try to reflect the updates. As such, implementers merely need to keep an eye on the RP requirement document, which is going to exempt implementers from watching all the update of all the referenced RFCs. 

3) We are not persuading implementers to skip reading those RFCs in full. Our 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 requirement as Manifest of all necessary RP functions. 

4) Implementers need know more than what RP requirements are. They need to know how to reflect these functions as they are making software design.  To that end, this draft has generalized RP requirements segmented with orthogonal functionalities in different sections.

Anyway, I appreciate your comments, which is going to help shape this draft better in it’s next version. 

Di

---

From: Stephen Kent <[email-masked]>
Date: Wed, 20 Jul 2016 15:28:17 -0400

Oleg,

Thanks for the feedback on our doc.
> Well, actually there is normative language: 
you're right. those instances of MUST will be changed to lowercase, 
since the intent is that this doc be informational.
> And there are several other places where the normative language is not used, but implied.
the doc is re-iterating what requirements doc say, so it is appropriate 
to use language that conveys what the requirements are, but we do try to 
avoid normative language. We'll revise the doc to remove normative 
(uppercase) language, but we will continue to convey what is mandated 
vs. optional, etc.
> 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.
I agree that implementers will have to read the cited RFCs. The goal 
here is to provide an overview of the requirements and to enumerate the 
RFCs that contain such requirements.
> I'm not sure how to define the applicability of such document.
the utility of the doc is that it provides a concise, high level 
description of RP requirements, and pointers to the normative RFCs where 
these requirements are fully specified. The BGPsec overview I-D is 
informational and provides a concise description of what a router needs 
to do to implement BGPsec, but it points to the relevant RFCs that 
provide the full specs for BGPsec, router certs, etc.
> 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.
An informational RFC providing an overview always runs this risk, but 
that doesn't make it a bad idea.
> I don't think assignment or allocation of INR happens in RPKI.
good point. the text will be revised to note that the RPKI _represents_ 
the allocations of INRs.
> Aren't any CRL validation (not only in RPKI) requires that CRL must be verified using the public key of it's issuer?
The cited text notes what CRL processing requirements are unique to the 
RPKI. ALL PKIs require that a CRL be validated using the public key of 
the issuer of the CRL.
> 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…
I agree that this needs more work. Your doc describing what the RIPE RP 
code does include examples where you have made choices that are allowed, 
but not mandated, by RFCs. This text wants to say what is mandated and 
what is allowed. I suspect we may add an implementation guidance section 
that will address issues where implementers have options and what 
experience has taught us about the pros and cons of different options.
> 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?
the goal of this doc is both to point to all of the RFCs that establish 
RP requirements, and to provide an overview of the requirements. In some 
cases, the text here will paraphrase the requirements, in other cases it 
may merely restate them.
> Section 2 of RFC6482 defines the ROA content-type, not the validation.
god catch, we'll fix that.
> This is true for all objects except manifest and CRL.
yes, so what?
> And this is also true for any signed object.
ibid.
> 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?

Oleg, I think we fundamentally disagree about the utility of a doc like 
this. I agree that this initial cut can be improved, but I disagree with 
you sentiment that it is not a worthwhile document. I have provided you 
and Tim with extensive comments on your RIPE validation description doc, 
and these have identified a number of places where the text needed to be 
clarified or fixed, i.e., it was technically incorrect.  In that light I 
think it would be fair to assume that successive versions of this doc 
can improve as well, and thus refusing to consider it is premature.

Steve