Re: [Sidrops] [WGLC] draft-ietf-sidrops-rp - ENDS: Mar 7, 2019

[Di Ma <[e-mail]>]

Oleg,


> 在 2019年3月24日，18:11，Oleg Muravskiy <[e-mail]> 写道：
> 
> Here are my comments on this document. Most of them I already submitted back in 2016 (https://mailarchive.ietf.org/arch/msg/sidr/ThyvBuWdCnv2t9u86sOjwdV4xKc), and authors seem to agreed to update the document, but that didn’t happen:

Thanks very much for your detailed review. 

And sorry for forgetting taking your feedback into updating. 
 
> 
> 
>> 3.2.  Certificate Path Validation
>> 
>>   In the RPKI, issuer can only assign and/or allocate public INRs
>>   belong to it,
> 
> 
> Assignment / allocation of INRs does not happen in RPKI.


Yes, it is not an accurate description, which I see an unnecessary statement by far.

I will cross it out. 

> 
> 
>> 3.3.  CRL Processing
>> 
>>   The CRL processing requirements imposed on CAs and RP are described
>>   in Section 5 of [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 RPKI MUST be
>>   verified using the public key from the certificate of the CA that
>>   issued the CRL.
> 
> 
> The normative language is used in an Informational document.


Good catch.

We authors were eliminating normative language in this document, this is a missed one:-)


> 
> 
>> 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].
> 
> 
> Section 2 of RFC6482 defines the ROA content-type, not the validation.

Yes. It might be a typo. 

We should have referred to Section 4 of  [RFC6482]

> 
> 
>> 4.2.3.  Ghostbusters
>> 
>> 
>>   The Ghostbusters Record is optional; a publication point in the RPKI
>>   can have zero or more associated Ghostbuster Records.
> 
> 
> Since no other CMS object description in this document mentions object’s optionality, this sentence may be understood as that the Ghostbusters Record is the only type of object which is optional. This is not the case.

We haven’t thought of this implication. 

Thanks for your consideration. 

> 
> 
>> 4.3.  How to Make Use of Manifest Data
>> 
>>   For a given publication point, the RP ought to perform tests, as
>>   specified in Section 6.1 of [RFC6486], 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.
> 
> 
> To my knowledge, most RP software notifies operator about presence of such objects, not just ignores them.
> 
> Also, I’m not sure how to treat “recommends” in an informational document.


Since you and I can neither know how other  RP software would behave in terms of this issue.

How about crossing out 'However, most RP software ignores such objects and this document recommends that this behavior be adopted uniformly.’


> 
> 
>>   In the absence of a Manifest, an RP is expected to accept all valid
>>   signed objects present in the publication point.  
> 
> 
> RFC6486 says that all such objects "SHOULD be viewed as suspect, but MAY be used by the RP, as per local policy”. This is quite different to “RP is expected to accept”.
> 
> 
> 
> And again, in general, I do not quite understand how authors chose to describe in detail some validation steps, and completely omit other steps, which makes the overall value of this document unclear to me.


You are touching the key point. 

We authors were bothered  by RFC 6486 which is squishy in how RPs would use Manifest, but find it hard to improve it.

That’s why we tried to go into detail of this issue instead of just referring to Section 6 of RFC 6486 but leave TBD in early version. 

If the WG has no more better idea, we authors will consider to adjust this section regarding 'How to Make Use of Manifest Data’ .


Di