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

From: Chris Morrow <[email-masked]>
Date: Sun, 17 Mar 2019 01:42:15 -0700

Howdy WG Folken,
The authors of:
  draft-ietf-sidrops-rp

are interested in moving their document forward, the abstract of this
document:

  "This document provides a single reference point for requirements for
   Relying Party (RP) software for use in the Resource Public Key
   Infrastructure (RPKI) in the context of securing Internet routing.
   It cites requirements that appear in several RPKI RFCs, making it
   easier for implementers to become aware of these requirements that
   are segmented with orthogonal functionalities."

Please have a read through this document, comment/complain/etc as
appropriate. The decision on forward progress or necessary edits ends
Mar 07, 2019.

Thanks!
-chris
(co-chair)

---

From: Nick Hilliard <[email-masked]>
Date: Sun, 17 Mar 2019 11:15:42 +0000

> appropriate. The decision on forward progress or necessary edits ends

Mar 7?  That doesn't leave much time.

Overall this looks like a useful summary for RP implementers, but care 
will need to be taken in future to ensure that the doc is kept current.

Is the draft missing a reference to rfc 8416?

The document needs a multiple-pass edit for both style and grammar 
before it can be handed off to the RFC Editor.  I had a look at this 
earlier today, but there's too much to handle in an email - it needs 
someone to sit down with the xml source and spend a couple of hours 
hacking at it.

Nick

---

From: Chris Morrow <[email-masked]>
Date: Sun, 17 Mar 2019 06:22:30 -0700

On Sun, 17 Mar 2019 04:15:42 -0700,
> Mar 7?  That doesn't leave much time.

darned calendars :(
April 7 !! :)

---

From: Di Ma <[email-masked]>
Date: Mon, 18 Mar 2019 20:41:00 +0800

Nick,

> 在 2019年3月17日，19:15，Nick Hilliard <[email-masked]> 写道：
> 
> Overall this looks like a useful summary for RP implementers, but care will need to be taken in future to ensure that the doc is kept current.

You are making sense here in terms of keeping it current.

We authors don’t think this will be a big issue for this draft is an informational document intended to provide readers a single point of learning about the ‘fundamental' functions that an RP should have in the context of routing. 

Since SIDR WG has been concluded, we don’t expect many/frequent changes regarding ‘protocol' that an RP should handle will take place. 

Granted, if there is going to be a fundamental change, this document will be updated by the RFC that brings about the change as we see many RFCs are being updated today.

> Is the draft missing a reference to rfc 8416?

Good point.

We don’t see RFC 8416 is a necessary functionality that an RP MUST support since we expect draft-ietf-sidrops-rp  is to gather basic/necessary functions. 

Yet  we might as well mentioned RFC 8416 in case the reader wants to acquire local control by using RFC 8416. 

I am one of the co-authors of RFC 8416, happy to add it in :-)

> 
> The document needs a multiple-pass edit for both style and grammar before it can be handed off to the RFC Editor.  I had a look at this earlier today, but there's too much to handle in an email - it needs someone to sit down with the xml source and spend a couple of hours hacking at it.

We authors would appreciate very much if you may bother to help polish this draft. 

Thanks.

Di

> 
> Nick
> 
> _______________________________________________
> Sidrops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidrops

---

From: Zhuangshunwan <[email-masked]>
Date: Tue, 19 Mar 2019 03:40:19 +0000

Support.

As a developer of the routing device using the data from RP, 
I think this is a very useful reference document. 
It lets us know how RP works.

Thanks,
Shunwan

-----Original Message-----
From: Sidrops [mailto:[email-masked]] On Behalf Of Chris Morrow
Sent: Sunday, March 17, 2019 4:42 PM
To: [email-masked]; [email-masked]; [email-masked]
Subject: [Sidrops] [WGLC] draft-ietf-sidrops-rp - ENDS: Mar 7, 2019

Howdy WG Folken,
The authors of:
  draft-ietf-sidrops-rp

Please have a read through this document, comment/complain/etc as appropriate. The decision on forward progress or necessary edits ends Mar 07, 2019.

Thanks!
-chris
(co-chair)

---

From: Oleg Muravskiy <[email-masked]>
Date: Sun, 24 Mar 2019 18:11:42 +0100

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

---

From: Di Ma <[email-masked]>
Date: Mon, 25 Mar 2019 12:48:18 +0100

Oleg,

> 在 2019年3月24日，18:11，Oleg Muravskiy <[email-masked]> 写道：
> 

Thanks very much for your detailed review. 

And sorry for forgetting taking your feedback into updating. 
 
> 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. 

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

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

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

We haven’t thought of this implication. 

Thanks for your consideration. 

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

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

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

---

From: George Michaelson <[email-masked]>
Date: Mon, 25 Mar 2019 13:20:35 +0100

I don't think rfc6846 Section 6.5 is overly informal. it says its a
matter of local policy,  and you should issue a warning.

I don't think this needs refinement.

If you want this document to change that, I think thats something we'd
want to discuss more widely.

I think adopting the RP document is a good idea so we *can* discuss
these things.

This specific point I would tend to argue doesn't need work, but the
general sense is that people need guidance. It is useful to have a
document which issues some guidance for RPs.

-G

---

From: Stephen Kent <[email-masked]>
Date: Mon, 25 Mar 2019 09:07:29 -0400

Oleg & Di Ma,

Sorry I missed the use of normative language in my earlier review of 
this doc.
> Thanks for your consideration.
I believe that all of the other RPKI signed objects are intended as 
mandatory for applicable entities (e.g., TAs, CAs, or EEs).  There are 
some fields in those objects that are optional, but not the objects 
themselves. The GB object is purely optional, so the cited statement 
seems apporpriate.
> How about crossing out 'However, most RP software ignores such objects and this document recommends that this behavior be adopted uniformly.’

To avoid what might be construed as standards-like language, how about:

"... this document recommends that..." -> "... the authors of this document suggest that ..."

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

As Di notes, the language in 6486 is thus very squishy, because it's 
hard to decide, in general, whether a hard-line approach to Mainfest 
info may be more helpful than harmful. I think a discussion of the pros 
and cons of using Manifest data can be useful, but it also must be 
carefully worded.

Steve