Re: [Sidrops] Interim Meeting Follow-up Mail

[Tim Bruijnzeels <[e-mail]>]

Hi,


> On 22 Oct 2020, at 19:32, Chris Morrow <[e-mail]> wrote:
> 
> 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:

Thank you.

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

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.



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

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.


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

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.

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

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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sidrops