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

[Di Ma <[e-mail]>]

Job,

> 2020年10月23日 00:17，Job Snijders <[e-mail]> 写道：
> 
> Hi all,
> 
> 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.

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. 

I think we authors have articulated the essential usecase.

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

> 
> If RUSH is positioned akin to IBGP, RTR or IGP (OSPF/ISIS) - something
> that in the general Internet routing use case is *not* something you'd
> set up with a third party (like an RIR), the specification can perhaps
> be morphed into something that is useful.

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

> 
> However, if we zoom in on the contents of the draft, it really is just
> "SLURM over HTTP" ... and I am not sure whether it is worth
> standardizing that a RFC 8416 file can be put on a HTTP server. Will the
> next Internet-Draft be that a SLURM file can also be transported over
> SSH? This Internet-Draft (to me) doesn't read as a novel specification,
> and given the use cases that it includes (which I find problematic) I am
> lacking convinction this is the right path forward.

I don’t see the reason we would come up with SLURM over SSH. 

If you find it, I am okay with that.

> 
> RUSH is not an alternative to signed object security. Object security
> based on X.509 (which some painstakingly worked on for a decade!) is a
> corner stone of the routing system, we have to be very careful when
> specifying things that water it down.

We indeed realize that RUSH is not an alternative to signed object security as we state in Security Consideration.

That’s why we iterate RUSH is intended to for TRUST.

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

Di and Melchior