Re: [Sidrops] WG ADOPTION - draft-madi-sidrops-rush - ENDS 10/12/2020 (Oct 12th)

[Job Snijders <[e-mail]>]

Hi Di,

On Fri, Oct 23, 2020 at 09:18:21PM +0800, Di Ma wrote:
> > 2020年10月23日 00:17，Job Snijders <[e-mail]> 写道：
> > I am hesitant to support adoption as I feel this opens yet another
> > not-at-all-validated channel into pandora's box. I don't think this
> > draft in its current form is ready for adoption.
> > 
> > If this work is to proceed, I'd like RUSH to *strictly* limit itself to
> > transportation of VRPs within a *single* trust domain. If you are not
> > willing to give the operator of the RUSH endpoint absolute unrestricted
> > 'enable' access on your BGP routers, they are outside your trust domain
> > and one should not talk RUSH with them.
> 
> You have got the essence of RUSH: TRUST.

RUSH seems the opposite of TRUST. All validation steps from which we can
derive a degree of trust have been removed?

> But, trust is not necessarily limited into the *single* trust domain.
> If I am allowed to exaggerate, RUSH even can used between two tier 1
> ISPs as long as one trusts the other. 

Interesting point, indeed we could iterate over all permutations of
possibilities, but what you mention is simply not how things are done in
practise between tier 1s (or other networks). I fail to see how the
exaggregation supports the Internet-Draft.

> I think we authors have articulated the essential usecase.

Please see below.

> > The offending paragraph is this one:
> > 
> >    "o AS0 SLURM File Delivery The Regional Internet Registries (RIRs)
> >    need to publish assertions with origin AS0 ([RFC6491]) for all the
> >    unallocated and unassigned address space (IPv4 and IPv6) for which
> >    it is the current administrator.  RUSH is able to deliver those
> >    assertions to RPKI relying parties if so called AS0 SLURM file are
> >    generated by the RIR."
> > 
> > Here is an *explicit* example of the detrimental effects of so-called
> > RIR 'AS 0' policies https://www.ripe.net/ripe/mail/archives/routing-wg/2020-June/004131.html
> > Do we really want to create big red buttons that can be pressed to nuke
> > *countries* off the global Internet Routing system? Surely that is not
> > our intention. I'm a pacifist, I do believe that if we don't develop
> > machine guns, machine guns can't be used against other human beings.
> 
> AS0 is only a potential usecase and it is a policy issue whether the
> community decide to use RUSH to implement AS0. 
> 
> But we just want to offer the tool. 

Yes, you want to offer a tool, but as I mentioned the existence of some
tools is not without consequences to the global routing system. When a
big red dangerous button is created, at some point someone somewhere
will want to push it.

I'll note for full transparency to this group that one of the co-authors
of the RUSH Internet-Draft is also the co-author of a "RIR AS0" policy,
which was rejected by the RIR community in which it was submitted.

>From my perspective the many discussions all over the globe (which so
far have taken place in APNIC, AFRINIC, RIPE, and LACNIC), is now just
spilling over to SIDROPS. Just like in all those RIR policy forums, it
should come as no surprise it will meet some resistance in this forum
too. As one of the use cases explicitly references 'AS 0' policies, it
no longer can be positioned as a neutral tool but has become part of a
wider (contentious) discussion.

> As I mentioned,  trust is not necessarily limited into a *single*
> trust domain.

Interesting, I am not sure I understand your definition of trust
domains. I am not even sure what my definition is, but I will point out
that the RIRs generally are *not* considered something to blindly trust.
The channel from RIR to Network Operator for RPKI related data is -
right now - one that strictly flows through a X.509 verifyable chain,
and RUSH is a novel way which sidesteps an existing more secure
mechanism. Why water that channel down?

> > However... there *might* be some work to be done in this area (forgive
> > me for linking to non-IETF resources, this is not to promote or NIH)
> > https://github.com/job/draft-sidrops-rpki-vrp-lorri HTMLized version
> > here
> > https://htmlpreview.github.io/?https://raw.githubusercontent.com/job/draft-sidrops-rpki-vrp-lorri/master/draft-spaghetti-sidrops-rpki-vrp-lorri-00.html
> > 
> > As it currently stands all RPKI validators are able to emit the VRPs in
> > a JSON format. This JSON format has become the defacto standard because
> > each validator blindly copied the other validators. However, the
> > 'commonly used JSON format for VRPs' is not optimal from a data
> > structure perspective, and it is not standardized (unlike SLURM). There
> > is no schema, and thus no validation.
> 
> I go with a standard RFC8416 (SLURM).  Why bother to find an
> unstandardized tool? I am confused.

The OpenBSD rpki-client, NLNet Labs Routinator, RIPE NCC RPKI Validator,
Cloudflare OctoRPKI, NIC.MX FORT, and possibly other validators are all
capable of emitting a specific (quite similar) JSON format.

This (non-standardized) format that is *widely* deployed & used by
operators, and has been for many years. I've uploaded an example JSON
file here: http://sobornost.net/~job/example-rpki-client-json-output.txt
Many network operators use this JSON format -today-.

So on the one hand we have RUSH (SLURM over HTTP), on the other hand we
have a JSON format that is widely used but not standardized. I brought
up the topic of the not-standardized-json because it appears to cover a
similar solution space to what RUSH addresses, and perhaps this working
group has thoughts or ideas on whether this is work suitable for the
working group.

It is also fair to consider my reference to this non-standard JSON as
'thread hijacking', but to me it seems somewhat related.

Kind regards,

Job