Re: [Sidrops] 6486bis: referenced object validation

[Job Snijders <[e-mail]>]

On Fri, Dec 04, 2020 at 02:13:40PM +0100, Benno Overeinder wrote:
> Not looking back, but looking ahead, I want to focus on how we solve
> issues and discuss them in sidrops.  And indeed, if there is an
> impasse, organise a virtual meeting and discuss the matter to make
> progress.

Yes, I took it as a sign of convergent thinking. Progress indeed.

However, my question remains, looking forward, what can be done
differently in the future?

Some suggestions from my side:

    - SIDROPS must require multiple implementations before sending an
      Internet-Draft towards the IESG. To meet this requirement,
      Implementers should write an implementation report and share it
      with the group, at least detailing the behavior for each normative
      term.

    - Please listen to operators who report (hard to troubleshoot, hard
      to explain) network outages which resulted from RPKI processing.
      RPKI ROV is supposed to be an incrementally deployable 'fail open'
      mechanism.

    - Implementers should more often share/construct the actual X.509
      files rather than attempting to document the hypothetical states
      of the RPKI in natural language (avoid English or Dutch). We can
      all load X.509 files into our implementations, set currenttime to
      the test case at hand, and discuss results.

    - Implementers should feel empowered to make improvements to their
      software (for the benefit of their users), especially if there is
      perceived ambiguity in RFC texts. An implementer doesn't need the
      blessing of the whole IETF before making a change.

    - Sometimes RFCs are wrong, or worse: the then-WG kicked the ball
      down the road and state 'up to the implementer' (aka 'local
      policy'); in which case the implementer will have to weigh the
      advantages of perceived 'RFC compliance' vs the effects of the
      behavior in the BGP Default-Free Zone. See the previous point.

    - The RPKI is a system that has been deployed on the Internet, this
      sometimes means operators need to quickly deploy fixes to address
      ongoing issues. Time is of the essence when it comes to security
      or reliability issues. So 'code first, RFC later', which goes well
      with point 1: 'implementations first, then publish RFC'.

You mentioned some kind of testbed, indeed it would be wonderful if we
can easily reproduce states of the RPKI and allow implementers to
provide annotations on why software (versions) behaves in a certain
way. The December 1st, 2020 case is definitely one I'd add to the
testbed archive.

> > The real goal is to keep the network running, where in this context
> > our role is to create software for network operators for them to
> > securely validate the wishes of the Internet number resource
> > holders.
> 
> Agree to that!
> 
> Let's keep the good spirit of collaboration and learning together.

For sure!

Kind regards,

Job