Content-type: text/plain; charset=gb2312
MIME-version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Di Ma <madihello@icloud.com>
In-reply-to: <F0799243-C489-4BB9-B2C1-FAB115D9536D@ripe.net>
Date: Sun, 16 Jul 2017 23:43:06 +0200
Cc: IETF SIDR <sidr@ietf.org>, sidrops@ietf.org, kent@alum.mit.edu,
 Declan Ma <declan.ma@qq.com>
Content-transfer-encoding: quoted-printable
Message-id: <D96830FA-D423-4831-9FA8-55753C964639@icloud.com>
References: <20160412100344.32250.28492.idtracker@ietfa.amsl.com>
 <E3DE4ED0-1BAE-48EE-849B-E0E0813CE411@icloud.com>
 <F0799243-C489-4BB9-B2C1-FAB115D9536D@ripe.net>
To: Oleg Muravskiy <oleg@ripe.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/w4kMQpDRX6qSafmLGN2hvAHYsc8>
Subject: Re: [sidr] New Version Notification for draft-madi-sidr-rp-00.txt
Precedence: list

Oleg,

Thanks very much for your comments.

See my responses in lines.=20

> =D4=DA 2016=C4=EA7=D4=C213=C8=D5=A3=AC17:05=A3=ACOleg Muravskiy =
<oleg@ripe.net> =D0=B4=B5=C0=A3=BA
>=20
> Hi Di,
>=20
>> On 27 Apr 2016, at 03:46, Declan Ma <madihello@icloud.com> wrote:
>>=20
>> Hi, folks,
>>=20
>> Steve Kent and I have generated this document to try to consolidate =
RP requirements in one document, with pointers to all the relevant RFCs.=20=

>=20
> I read the document, and I appreciate you putting it together, but I =
can't say I support this effort.
>=20
> As you state in Section 1:
>=20
>   The follow sections present requirements imposed on RPs as defined =
in
>   the following RFCs:
>=20
>   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)
>=20
>   This document will be update to reflect new or changed requirements
>   as these RFCs are updated, or new RFCs are written.
>=20
> 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!
>=20
> 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.
>=20
> 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.=20

It=A1=AFs not in state of art at present yet I hope it would be adopted =
to move along with help from the WG.=20

>=20
>=20
>> 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.=20
>=20
> Well, actually there is normative language:
>=20
>   3.3.  CRL Processing
>=20
>   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.
>=20
> And there are several other places where the normative language is not =
used, but implied.

Thanks for catching the typos.=20

We will change =A1=AEMUST=A1=AF into =A1=AEmust=A1=AF.

As for the implication stuff, the text is just paraphrasing the =
requirements from RFCs which I don=A1=AFt think is sort of =
inappropriate.=20


>=20
>=20
>> 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.
>=20
> I have two comments for this paragraph.
>=20
> 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:
>=20
>   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.
>=20
> or
>=20
>   To determine whether a manifest is valid, the RP is required to
>   perform manifest-specific checks in addition to those specified in
>   [RFC6488].
>=20
> 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.
>=20

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=A1=B0Manifest=A1=B1 for =
all necessary RP functions.=20

>=20
> 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?
>=20
> I=A1=AFm 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 =A1=B0there=A1=B1,=
 they should double check =A1=B0there=A1=B1 which is specific paragraph =
in the referenced RFCs.=20


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.=20

>=20
>=20
>> Any comments and feedbacks are appreciated.
>=20
> Here are my comments for some specific sections:
>=20
>   3.1.  Verifying Resource Certificate and Syntax
>=20
>   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.
>=20
> 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.=20

We authors will see how to address issues.

And I would appreciate your help.=20


>=20
>=20
>   3.2.  Certificate Path Validation
>=20
>   In the RPKI, issuer can only assign and/or allocate public INRs
>   belong to it, ...
>=20
> I don=A1=AFt 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, =A1=AD

>=20
>=20
>   3.3.  CRL Processing
>=20
>   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.
>=20
>=20
> 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=A1=AFt 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.


>=20
>=20
>   4.2.1.  Manifest
>=20
>   To determine whether a manifest is valid, the RP is required to
>   perform manifest-specific checks in addition to those specified in
>   [RFC6488].
>=20
>   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.
>=20
> This description is quite incomplete. Perhaps you should merge the =
content of section "4.3.  How to Make Use of Manifest Data=A1=B1 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.=20

Manifest processing has proven to be significantly more complicated that =
initially anticipated.=20

I hope SIDROPS WG to take the chance to give an operational advice along =
with this draft.=20

>=20
>=20
>   4.2.2.  ROA
>=20
>   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].
>=20
> The second sentence is almost a 1-to-1 copy of Section 4 of 6482. =
What=A1=AFs 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.

>=20
> Section 2 of RFC6482 defines the ROA content-type, not the validation.
>=20
>=20
>   4.2.3.  Ghostbusters
>=20
>   The Ghostbusters Record is optional; a publication point in the RPKI
>   can have zero or more associated Ghostbuster Records. =20
>=20
> This is true for all objects except manifest and CRL.
>=20
>   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].
>=20
> And this is also true for any signed object.
>=20
>   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].
>=20
> 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?
>=20

They are not duplicate.

RFC6488 is for generalized validity check in terms of syntax yet RFC6493 =
is for syntax check especial for Ghostbusters.=20


>=20
>   4.3.  How to Make Use of Manifest Data
>=20
>   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.
>=20
>   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.
>=20
> Instead of =A1=B0recommending" it in this document, maybe we should =
review and change 6486?
>=20
>   In the absence of a Manifest, an RP is expected to accept all valid
>   signed objects present in the publication point. =20
>=20
> 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.
>=20

As I mentioned above, Manifest has been a tricky part. Manifest =
processing has proven to be significantly more complicated that =
initially anticipated.=20

We might as well considering to update RFC 6486.=20


>=20
>=20
> 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.=20

I would appreciate help and contributions from the WG, especially guys =
in charge of RP software.=20


Di