Subject: [Sidrops] Interim Meeting Follow-up Mail

From: Chris Morrow <[email-masked]>
Date: Thu, 22 Oct 2020 17:32:10 +0000

First, apologies for this being so tardy :(
Second, thanks for attending the interim on 10/01/2020 (Oct 1st) and
bearing with me/us in the conversation.

Now, at the end of the meeting (which I thought was 1hr in, but was
really 2hr in) I said I'd send out a mail to discuss two items:

  1) Being clear about impacts/repercussions related to the
     decision process being put forth for 6486bis:
       a) There will be repositories that disappear when they can't
          get their content straight at publication time.
	  
       b) Repeated failures at a CA/PublicationPoint(PP) will
          eventually lead to that CA/PP's routing intent falling back
	  to 'not found'.
	  
       c) In some circumstances (tim pointed these out I believe)
          if the CA/PP is a leaf below another CA/PP which publishes
	  ROA for covering routes, the leaf CA/PP's routing intent
	  may change to INVALID.
	  
	  ie: RIR -> LIR -> end-user
	    if the LIR publises 8.0.0.0/8 - AS64600
	    if the end-user publishes 8.8.0.0/16 AS64601
            if the end-user CA/PP expires
	      (for any reason, but specifically collection problems)
            the end-user prefixes will become invalid.

       d) There are some ordering/rollout/planning concerns related
          to new object types in the repository which either need
	  to be worked out in the bis OR noted and pushed to the next
	  new object proposal.
	  I think the authors are clear that: "for next proposal"
	  I think the meeting participants seemed split, but that at least:
	    "Hey, note that adding new objects will be different... pay attention!"
	  should end up in the bis document.

  2) Closing up the -bis conversation/document prior to december
     The current author set has an expiry timer, we can either finish up 'now'
     or hand-over reins at/after the F2F meeting + edit time.

I'd like to get some closure on these, ideally, before the f2f in ~3wks time.

-chris
co-chair-persona

---

From: Tim Bruijnzeels <[email-masked]>
Date: Fri, 23 Oct 2020 16:33:32 +0200

Hi,

> On 22 Oct 2020, at 19:32, Chris Morrow <[email-masked]> wrote:
> 

Thank you.

>          get their content straight at publication time.

I pointed out there is a failure scenario that cannot be avoided, where a child CA produces delegated CA certificates or ROAs containing over-claims, i.e. referencing resources not on its own CA certificate as currently published by its parent.

As a child CA using RFC 6492 (provisioning) I learn entitlements from my parent (section 3.3.2), but the response lacks the context to know:
- when a current resource will disappear
- when a new resource will be safe to use, ie. when my *parent* published my certificate, and it's picked up by RPs

I am happy to try discuss preventing over-claims as a separate issue, but in the context of this document I believe we should assume that they will happen.

This means that CAs will be temporarily rejected at times. This includes the case where an RIR (eg Lacnic), issues a certificate with extra resources to an NIR (eg nic.br), and the NIR issues and publishes a delegated certificate to one of its members, before the extended certificate is published by the RIR.

FWIW, for the time being I can build a safeguard into the next version of Krill to refrain from using new resources for some time, but any time chosen is of course arbitrary.

I think there are two options here:

1) accept that CAs will be temporarily rejected, even NIR level CAs
2) make an exception for overclaiming, but otherwise valid, objects

I can see how #2 would be hard to swallow for some, but then at least consciously accept and acknowledge that #1 will happen, and it's not the rejected CA's fault.

>            the end-user prefixes will become invalid.

Indeed, so the landing is not always soft.

There was a beginning of a discussion here:
https://mailarchive.ietf.org/arch/msg/sidrops/pi9v6RNA2kMvEOY9BfOD9VHGJtc/

The bottom line is that one might want to filter out VRPs for the resources on the CA certificate for the child CA. Except in cases where the child has *all* resources (e.g. it is the online CA under a TA), because then this could invalidate all objects in the RPKI.

Two options wrt VRP filtering:
1) Doing this adds complexity, and possibly brittleness in software as a result.
2) Not doing this means the WG must accept that the landing is not always soft, and may result in brittleness in routing. A child CA can end up with invalid routes.

To me the most important question is how routing security is best served, by #1 or #2. I can live with either choice, as long as it's consciously accepted and acknowledged.

> 	  should end up in the bis document.

Observe the word 'valid' in this sentence in section 6.7 (Failed Fetches):

   "or does not acquire current valid instances of all of the objects enumerated"

As written this implies that unknown object types are not considered valid, and therefore RPs MUST reject *all* objects for a CA if they are encountered.

This means that new object types can only be published safely when, some arbitrary value of, enough RPs have been upgraded to support it. And even then those operators who did not upgrade will be left behind. By this (arbitrary) time the burden may be on them, rather than the publishing CA.

I, and some others I believe, suggested that unknown objects could be considered 'valid' in this context if they are present and match the hash in the manifest (i.e. the PP is complete and unaltered). One could even go further, and as long as the new object is a form of RPKI signed object (RFC6488) one could validate the outer object, but not its content.

Or to make it more tangible in text:

CURRENT:
   If an RP does not acquire a current valid manifest, or does not
   acquire current valid instances of all of the objects enumerated in a
   current valid manifest as a result of a fetch, then processing of the
   signed objects associated with the CA instance has failed for this
   fetch cycle.

PROPOSED:
   Processing of the signed objects associated with the CA instance MUST
   be considered as failed for this etch cycle, if:

   o current instances of objects matching the names and hashes in a
     current valid manifest could not be retreived
   o any current object for a supported object type is considered
     invalid
   o any current object, of an unknown object type, which is found to
     be a form of an RPKI Signed Object, fails the validation outlined
     in section 3 of RFC 6488, with the exception that further validation
     of the eContent (section 2.1.3.2) is not performed.

This would allow for new objects to be introduced, without causing existing - not updated - RPs to reject the publication point altogether. I believe that this is safe as long as a new type is orthogonal in its semantics to existing types - and it does not change their meaning. For example: ASPA objects do not change how ROAs work or should be validated.

If new objects are not safe in this way, eg imagine that ASPA objects would change the meaning of ROAs, then we could just introduce two new object types instead: ASPA and ROAv2. CAs which would choose to do ASPA then, could just publish ASPA and ROAv2 objects and stop doing ROAs(v1).

Steve Kent suggested a different approach where new SIA entries are used instead, so that new objects can introduced in a new -presumably parallel - PP context. Theoretically this is indeed possible, and it could be specified in a "next proposal". However, this approach introduces a lot of new complexity for all parties involved. It will take significant time to be specified, and it will then take more time to be implemented. Until such time new object types could not be safely introduced. So, I am not convinced about this approach at all. Then I would prefer that we expect people to 'just upgrade their RPs', and clearly document this in a considerations section.

> I'd like to get some closure on these, ideally, before the f2f in ~3wks time.

I am all for resolving this timely if we can. I would also really like to hear from other WG participants besides myself and Steve Kent.

Tim

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

---

From: Stephen Kent <[email-masked]>
Date: Fri, 23 Oct 2020 11:33:27 -0400

Tim,
> ...
Why should a parent push a new cert to a child without waiting a 
suitable interval to allow RPs to learn of changes? Such behavior seems 
a bit careless by the parent.
> ...
VRP filtering seems to add considerable complexity. If CAs can't manage 
to do a better job when changing resource allocations, why should we 
expect the RP side of  a child CA to do the right thing re filtering?
> I, and some others I believe, suggested that unknown objects could be considered 'valid' in this context if they are present and match the hash in the manifest (i.e. the PP is complete and unaltere…
Your suggestion would avoid the problem you describe, but it also means 
that publishers of such objects have no idea whether any RPs know what 
to do with them. Is the plan to allow publication of arbitrary new 
objects (so long as the outer wrapping meets the 6488 syntax), and to 
address the transition to use of new objects in the RFCs that define the 
semantics of those objects?
> ...

I find the wording above very confusing; the term "supported" is not 
defined, and  the last bullet is very, very convoluted, ...

How about:

    Processing of the signed objects associated with the CA instance MUST
    be considered as failed for this etch cycle, if

    o current instances of all the objects matching the names and hashes in a
      current valid manifest could not be retrieved
    o any of the retrieved objects fails the Signed Object validation process
      described in Section 3 of RFC 6488
    o any retrieved object, of a type that the RP is prepared to process,
      fails validation of the eContent as described in Section 2.1.3.2 above

> This would allow for new objects to be introduced, without causing existing - not updated - RPs to reject the publication point altogether. I believe that this is safe as long as a new type is orth…
I agree that new objects that are independent of semantics of existing 
object types could be tolerated under these revised processing rules.
> If new objects are not safe in this way, eg imagine that ASPA objects would change the meaning of ROAs, then we could just introduce two new object types instead: ASPA and ROAv2. CAs which would ch…

Easily said, in a casual fashion, but if one examines the transition 
processes already defined for alg transition etc., this will entail a 
complex description. Still, I suspect your principal goal is allowing 
near-term publication of ASPA objects, without having to deal with 
description of a transition process, so for that concern the revised 
Manifest processing changes would suffice.

Steve

---

From: Tim Bruijnzeels <[email-masked]>
Date: Fri, 23 Oct 2020 21:14:59 +0200

Steve,

Thank you for your quick reply.

> On 23 Oct 2020, at 17:33, Stephen Kent <stkent=[email-masked]> wrote:
> 
> Tim,
>> ...
> Why should a parent push a new cert to a child without waiting a suitable interval to allow RPs to learn of changes? Such behavior seems a bit careless by the parent.

Part of the issue - I believe - is that the parent can pro-actively issue a shrunk certificate to the child *before* they learn about the shrunk resource set, and send a new CSR for the reduced set. This may seem careless, but the parent may not have a choice if their own certificate is shrunk.

But, I think I should start a separate thread on this and explore the problem statement before suggesting solutions. I don't think this can be solved as part of the bis work.

> VRP filtering seems to add considerable complexity. If CAs can't manage to do a better job when changing resource allocations, why should we expect the RP side of  a child CA to do the right thing re filtering?

Note that this VRP filtering is very similar to the SLURM prefix based filtering already implemented by many RPs (Section 3.3.1 of RFC 8416). The key difference would be that in this case covering VRPs would need to be filtered as well (I am not sure now why this was not done in SLURM).

I don't deny that it adds complexity, and I can understand if the WG prefers the simpler validation model, but there is some prior art.

> Your suggestion would avoid the problem you describe, but it also means that publishers of such objects have no idea whether any RPs know what to do with them. Is the plan to allow publication of arbitrary new objects (so long as the outer wrapping meets the 6488 syntax), and to address the transition to use of new objects in the RFCs that define the semantics of those objects?
>> ...
>> 
>> PROPOSED:
> I find the wording above very confusing; the term "supported" is not defined, and  the last bullet is very, very convoluted, ...
> 
> How about:
> 

I like your text better!

> I agree that new objects that are independent of semantics of existing object types could be tolerated under these revised processing rules.
> Easily said, in a casual fashion, but if one examines the transition processes already defined for alg transition etc., this will entail a complex description. Still, I suspect your principal goal is allowing near-term publication of ASPA objects, without having to deal with description of a transition process, so for that concern the revised Manifest processing changes would suffice.

Indeed that is my principal goal and this works for me.

I can also see how for the class of new object types which are not orthogonal to existing types the transition process needs to be clearly defined as part of their definition.

Tim

---

From: Stephen Kent <[email-masked]>
Date: Wed, 28 Oct 2020 12:02:56 -0400

Tim,

I looked at the revised bullet points we agreed upon and crafted a new 
Section 6.4 to reflect the last point. (The first three were already 
covered in this or other sub-sections of Section 6.) The proposed, 
revised text is below. If you concur, I'll ask that 6486-bis be revised 
accordingly.

6.4.Acquiring Files Referenced by a Manifest

The RP MUST acquire all of the files enumerated in the manifest
(fileList) from the publication point.If there are files listed in the
manifest that cannot be retrieved from the publication point, or if
they fail the validity tests specified in [RFC6488], the fetch has
failed and the RP MUST proceed to Section 6.7; otherwise, proceed to
Section 6.5. Note that the set of retrieved objects may include types that

    the PR is not prepared to process, e.g., objects other than CRLs, 
certificates,

    and Ghostbuster records (all of which MUST be processed by an RP, if 
present).

    When such objects are encountered by an RP, the RP MUST NOT attempt 
to validate

    the eContent (as described in Section 2.1.3.2 above) of such objects;

    encountering such objects does not, per se, result in a failed fetch.

---

From: Russ Housley <[email-masked]>
Date: Wed, 28 Oct 2020 12:16:04 -0400

In one place "PR" should be "RP"

Russ

> On Oct 28, 2020, at 12:02 PM, Stephen Kent <stkent=[email-masked]> wrote:
> 
> Tim,
> 
> I looked at the revised bullet points we agreed upon and crafted a new Section 6.4 to reflect the last point. (The first three were already covered in this or other sub-sections of Section 6.) The proposed, revised text is below. If you concur, I'll ask that 6486-bis be revised accordingly.
> 
> 
> 
> 
> 6.4.  Acquiring Files Referenced by a Manifest
> 
>    (fileList) from the publication point. If there are files listed in the
>    the PR is not prepared to process, e.g., objects other than CRLs, certificates, 
>    and Ghostbuster records (all of which MUST be processed by an RP, if present). 
>    When such objects are encountered by an RP, the RP MUST NOT attempt to validate 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/sidrops <https://www.ietf.org/mailman/listinfo/sidrops>

---

From: Stephen Kent <[email-masked]>
Date: Wed, 28 Oct 2020 13:10:26 -0400

Russ,
> In one place "PR" should be "RP"

thanks, fixed.

Steve

---

From: Tim Bruijnzeels <[email-masked]>
Date: Thu, 29 Oct 2020 13:56:25 +0100

Hi Steve,

> On 28 Oct 2020, at 17:02, Stephen Kent <stkent=[email-masked]> wrote:
> 
> Tim,
> 

Right, indeed it's section 6.4 that needs the update. I was a bit confused by the repeated text in 6.7 (Failed Fetches). Maybe this first sentence could be dropped?

To me this reads like these checks are done as part of 6.7, whereas actually these checks to determine that a fetch failed were all done in earlier sections and that is why implementers were directed to proceed to 6.7, right?

>    encountering such objects does not, per se, result in a failed fetch.

I see you use "e.g." when enumerating types which MUST be processed. But I think it would be better to either enumerate all object types explicitly, or have no enumeration and leave the choice which types MUST be supported out of this context.

If you go for explicit enumeration, then it will most likely need updating by future RFCs. E.g. the ASPA RFC when it comes out could update the list. How about something like this:

   Note that the following objects MUST all be fully validated if present:
    * Manifests (this document)
    * CRLs [RFC6487]
    * Resource Certificates [RFC6487]
    * BGPsec Router Certificates [RFC8209]
    * Ghostbuster Records [RFC6493]
    * Route Origin Authorizations [RFC6482]

   However, the publication point MAY include other object types
   that the RP is not prepared to process. When such objects are encountered
   by an RP, the RP MUST NOT attempt to validate the eContent (as described
   in Section 2.1.3.2 above) of such objects; encountering such objects
   does not, per se, result in a failed fetch.  

As a note to implementers: there is little (inter-)operational experience in producing and validating BGPsec Router Certificates and Ghostbuster Records. I am okay with including them in a list, but I would advise that CAs test with known RP software and collaborate, before deploying these objects in production environments.

Tim

---

From: Stephen Kent <[email-masked]>
Date: Thu, 29 Oct 2020 11:37:30 -0400

Tim,

I revised the text of 6.4 and 6.7 to address the issues you cited. See 
below:

(fileList) from the publication point. If there are files listed in

the manifest that cannot be retrieved from the publication point, or

if they fail the validity tests specified in [RFC6488], the fetch has

Section 6.5. Note that all RPs MUST be able to process Manifests,

CRLs and Resource Certificates [RFC6487], BGPsec Router Certificates

{RFC8209], Ghostbuster Records [RFC6493], and ROAs [RFC6482]. The

set of retrieved objects may include other RPKI object types that the

    RPis not prepared to process. When such objects are encountered by an

RP, the RP MUST NOT attempt to validate the eContent (as described in

Section 2.1.3.2 above) of such objects; encountering such objects does

not, per se, result in a failed fetch.

6.7.Failed Fetches

If a fetch fails for any of the reasons cited in 6.2-6.6, the RP MUST

issue a warning indicating the reason(s)for termination of processing

with regard to this CA instance.It is RECOMMENDED that a human

operator be notified of this warning.

Termination of processing means that the RP SHOULD continue to use

cached versions of the objects associated with this CA instance,

until such time as they become stale or they can be replaced by

objects from a successful fetch.This implies that the RP MUST not

try to acquire and validate subordinate signed objects, e.g.,

subordinate CA certificates, until the next interval when the RP is

scheduled to fetch and process data for this CA instance.

---

From: Tim Bruijnzeels <[email-masked]>
Date: Fri, 30 Oct 2020 13:52:48 +0100

Hi Steve,

Thank you. That text works for me.

Tim

> On 29 Oct 2020, at 16:37, Stephen Kent <stkent=[email-masked]> wrote:
> 
> Tim,
> 
> I revised the text of 6.4 and 6.7 to address the issues you cited. See below:
> 
>    RP is not prepared to process. When such objects are encountered by an
> 6.7.  Failed Fetches
>    with regard to this CA instance.  It is RECOMMENDED that a human 
>    objects from a successful fetch.  This implies that the RP MUST not