Subject: [Sidrops] Benjamin Kaduk's No Objection on draft-ietf-sidrops-rp-06: (with COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Wed, 08 Apr 2020 23:12:38 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-sidrops-rp-06: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-sidrops-rp/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Section 2

   RP software uses synchronization mechanisms supported by targeted
   repositories (e.g., [rsync], RRDP [RFC8182]) to download all RPKI
   changed data objects in the repository system and cache them locally.

nit(?): perhaps "changed" requires a bit more explanation.

Section 2.1

   TAL acquisition and processing are specified in Section 3 of
   [RFC8630].

I'm not really convinced that the referenced section discusses
specifically TAL *acquisition*.

Section 2.2

   by using the SIA and AIA extensions.  Detailed specifications of SIA
   and AIA extensions in a resource certificate are described in
   Section 4 of [RFC6487].

(Subsections thereof, though I trust that the reader should be able to
figure this out.)

Section 3.1

   established by Section 4 of [RFC6487].  This means that all
   extensions mandated by Section 4.8 of [RFC6487] must be present and
   value of each extension must be within the range specified by this
   RFC.  Moreover, any extension excluded by Section 4.8 of [RFC6487]

nit: s/this/that/ ("this RFC" is the thing that draft-ietf-sidrops-rp
will become, in this context).

   Section 7.1 of [RFC6487] gives the procedure that the RP should
   follow to verify resource certificate and syntax.

"verify resource certificate and syntax" seems a little broad; the
referenced section seems specific to validating the extension defined in
RFC 3779.

Section 3.2

   Certificate Authorities that want to reduce aspects of operational
   fragility will migrate to the new OIDs [RFC8360], informing the RP of
   using an alternative RPKI validation algorithm.  An RP is expected to
   support the amended procedure to handle with accidental over-claim.

nit: I suggest s/with accidental over-claim/accidental overclaim/.

Section 3.3

   Processing of a CRL that is not consistent with a manifest is a
   matter of local policy, as described in the fourth paragraph of
   Section 6.6 of [RFC6486].

Is the fifth paragraph relevant, also?

Section 4.1

   Note that these checks are necessary, but not sufficient.  Additional
   validation checks must be performed based on the specific type of
   signed object.

These additional validations are covered in the following sections, it
seems -- should we mention that here?

Section 4.2.4

   contain an IP Address Delegation extension.  The validation procedure
   used for BGPsec Router Certificates is identical to the validation
   procedure described in Section 7 of [RFC6487], but using the
   constraints applied come from specification of Section 7 of
   [RFC8209].

nit: if it does something differently, it's no longer "identical"; maybe
"analogous" or it's following the validation procedure [...] with
additional constraints"?
That said, Section 7 of RFC 8209 is the IANA considerations, so I'm not
sure what the "constraints applied come from" is intended to say.

Section 7

The validation steps discussed throughout this document are also pretty
important to the security of the system as a whole.

Section 10.1

I'm not sure that RFC 5280 actually is normative here.  (That might be
the first time I've ever said that!)

Section 10.2

I think that RFCs 6489, 6916, and 8634 are probably better as normative.

---

From: Di Ma <[email-masked]>
Date: Thu, 9 Apr 2020 22:54:23 +0800

Benjamin,

Thanks for your review.

Please find our response in lines.

> 2020年4月9日 14:12，Benjamin Kaduk via Datatracker <[email-masked]> 写道：
> 

How about:

RP software uses synchronization mechanisms supported by targeted repositories (e.g., [rsync], RRDP [RFC8182]) to download RPKI data objects in the repository system in order to update the local cache. These mechanisms download only those objects that have been added, or replaced with new versions, since the time when the RP checked the repository. 

> specifically TAL *acquisition*.

Good catch.

"TAL configuration” fits well here. 

> (Subsections thereof, though I trust that the reader should be able to

ACK.

We will add more specific pointers to SIA and AIA extensions.

> will become, in this context).

ACK.

We will use “this document” instead of “this RFC”.

> referenced section seems specific to validating the extension defined in

Yes.

We will say: 

Section 7.1 of [RFC6487] specifies the procedure that the RP should follow to verify the RCF 3779  extension.

> nit: I suggest s/with accidental over-claim/accidental overclaim/.

ACK

> Is the fifth paragraph relevant, also?

Yes. Good catch.

> seems -- should we mention that here?

Note that these checks are necessary, but not sufficient.  Additional validation checks must be performed based on the specific type of signed object as described in Section 4.2. 

> sure what the "constraints applied come from" is intended to say.

proposed new text:
  The validation procedure used for BGPsec Router Certificates is analogous to the validation
  procedure described in Section 7 of [RFC6487], but it uses the constraints defined in Section 3 of  [RFC8209].

> important to the security of the system as a whole.

Good point. We'll add a final sentence:

This document highlights many validation actions applied to RPKI signed objects, an essential element of secure operation of RPKI security.

> the first time I've ever said that!)

We cite 5280 because it  it the IETF profile for X.509; the various RPKI RFCs further profile that RFC.

> I think that RFCs 6489, 6916, and 8634 are probably better as normative.

OK, we'll move them up to 10.1

Di

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 9 Apr 2020 15:16:05 -0700

> RP software uses synchronization mechanisms supported by targeted repositories (e.g., [rsync], RRDP [RFC8182]) to download RPKI data objects in the repository system in order to update the local ca…

Looks good, thanks.

> We will use “this document” instead of “this RFC”.

It's not aquestion of "RFC" vs. "document" but rather "this" vs. "that" --
someone reading the RFC that draft-ietf-sidrops-rp will become is reading
"this RFC", whereas that other RFC (RFC 6487) that we're making a
reference to is "that RFC".

>   procedure described in Section 7 of [RFC6487], but it uses the constraints defined in Section 3 of  [RFC8209].

I think that works.  (Section 3 makes much more sense than Section 7!)

> OK, we'll move them up to 10.1

Thanks for the updates!

-Ben

---

From: Di Ma <[email-masked]>
Date: Fri, 10 Apr 2020 14:20:06 +0800

Benjamin,

> reference to is "that RFC".

Gotcha:-)

We will replace "this RFC" with "RFC 6487". 

Di