Re: [Sidrops] 6486bis: Failed Fetches

[Christopher Morrow <[e-mail]>]

 First, thanks! having some tested results on an optional path (for
newly added types) seems cool.
it's at least informed some of the conversation, which seemed to go a
bit outside the original point of order (in my re-re-reading anyway)

I think the salient points in the discussion are really (happy to be
corrected, of course):
  1) the -bis is proposing a simpler handling of publication point collection.
      this simplicity is a bit at odds with some Internet principals
(robustness principal), but
      trades this for very clear behaviors in the RP software.
operations folk (myself, job, mikael though I missed his mail...
others)
      were a bit concerned with the different flavors of 'correct'
that can pop out the RP :( and see that being simpler about
      the flavors/options may make all/MOST RP get the same set of
answers... predictability / consistency are nice.

  2) the CA software and operations have to be very clear now about
what is/not published,
      keeping in mind that mistakes in the CA Publication Point will
have repercussions.
      Perhaps these need to be clearly articulated in the -bis draft?
(more clearly?)
      This will, I think, clearly have impact on both CA / PP software
and on operations of the CA / PP.
      I think this is good, actually as we're (sidrops folks i mean)
attempting to push for:
          o  closer compliance to consistency
          o  more reliance upon the whole system
          o better overall security for the routing system

  3) With the proposed simplicity/strictness comes some potential
problems, at least:
      o problems in a CA / PP mean that CA / PP may not have their
most updated information (routing intent) available
      o continual problems will lead to fallback to 'unknown' in the
routing system
      o adding new object types seems difficult (just my reading so far)
         particularly there's a note about 'people won't upgrade their
RP software'

I think that the simplicity is a goal I would like to see achieved,
specifically because inconsistent results in the RP set is problematic
longer term.
If we can get to more consistency before we roll a bunch more out
we'll be able to course correct better/faster (I think).

I think the idea that people won't upgrade... sure? maybe? Also: "Do
you  like killing kittens? because not managing your business critical
systems a great way to kill kittens." We've been able to push more
people into RPKI and better routing-intent hygiene, I don't see why we
can't keep doing that and get folk to treat part of the routing system
as critical to their business.

We should not shy away from a solution just because we may have to
convince people to upgrade.

I look forward to the discussion tomorrow/thurs.

-chris



On Tue, Sep 29, 2020 at 10:55 AM Tim Bruijnzeels <[e-mail]> wrote:
>
> Hi,
>
> On 7 Sep 2020, at 13:17, Tim Bruijnzeels <[e-mail]> wrote:
> >
> >>>
> >>> If we do go down this road then I think that we should also look at the manifest object itself, and let it convey which object (types) are critical (and while we are at it, we can specify types instead of using filename extensions). That way future object types could introduced more easily perhaps - this obviously needs more discussion but it could even allow for semantics like: 1) new object please test, don't use, 2) new objects, use if you can, 3) new objects, critical - fail if you don't understand.
> >>
> >> One could combine the new SIA URI and a revised manifest, in which the manifest contains the per-object flag, rather than redefining the basic object format to accommodate the flag. That would reduce the number of RFCs that need to change. Good idea.
> >
> > Upon reflection I realised that even the introduction of an SIA in the issuing CA certificate will lead to issues. RPs would reject the CA certificate, and as a result the whole PP of the parent CA. This means that the SIA cannot be deployed without leaving a significant number of RP installations behind. E.g. if I run a delegated CA under an RIR which wants to adopt ASPA, and I get a new CA certificate with the additional SIA from my parent, then 1000s (RIPE NCC >12k) other CAs will also be rejected.
>
>
> I have done some testing on this.
>
> Section 4.8.8.1 of RFC 6487 seems to say that additional SIA OIDs for CA certificates can be expected and can be ignored. And indeed it seems that all current RP software will accept (and ignore) additional SIAs.
>
> At least that's the result from adding an extra SIA in a Krill branch and running the end to end tests using the following validator versions:
>
> fortvalidator 1.4.0
> OctoRPKI v1.1.4 (2019-08-06T16:51:07-0700)
> rcynic version believed to be buildbot-1.0.1544679302
> routinator 0.7.1
> rpkiclient 6.7p1
> rpkivalidator3 3.1-2020.08.06.14.39
>
> I am still not very happy about the overhead that this approach implies:
>
> Additional publication points which need to be maintained, which may be out of sync. What if MFT A has a certain ROA and MFT B doesn't? This can lead to serious operational impact if an announcement would be valid under one, but not the other.
>
> It would also require much more fundamental code changes for producing CAs - one cannot just support a new object type. One has to support an additional publication model. Parent CAs have to be willing to include the new SIAs as well affecting the ability to deploy for delegated CAs.
>
> But, at least it seems that it can be introduced without breaking things immediately for existing deployed validators.
>
> Tim
> _______________________________________________
> Sidrops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sidrops