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

[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:


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


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


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


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


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


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


Oleg