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

From: Guyunan <[email-masked]>
Date: Fri, 9 Oct 2020 06:41:39 +0000

Seems quite useful for local management of validated cache. A small suggestion, maybe the authors can further clarify the use of HTTP and HTTPs, whether HTTPs is mandatory, or it’s optional using either HTTP only or HTTPs.

Support adoption.

BR,

Yunan

From: Sidrops [mailto:[email-masked]] On Behalf Of Melchior Aelmans
Sent: Thursday, October 1, 2020 12:51 AM
To: Chris Morrow <[email-masked]>
Cc: SIDROps Chairs <[email-masked]>; SIDR Operations WG <[email-masked]>; [email-masked]
Subject: Re: [Sidrops] WG ADOPTION - draft-madi-sidrops-rush - ENDS 10/12/2020 (Oct 12th)

As a co-author I support adoption by the WG.

THanks!
Melchior

On Mon, Sep 28, 2020 at 6:38 AM Chris Morrow <[email-masked]<mailto:[email-masked]>> wrote:

Howdy,

Please consider this the start of a WG Adoption call for the subject
draft, the abstract of which is:

  "This document defines a method for transferring RPKI validated cache
   update information in JSON object format over HTTPs."

The URL of which is:
  https://datatracker.ietf.org/doc/html/draft-madi-sidrops-rush-02

Please give this a read-through and consider if the work is appropriate
for the WG to work on.

thanks!
-chris
co-chair-persona

_______________________________________________
Sidrops mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sidrops

---

From: Di Ma <[email-masked]>
Date: Fri, 9 Oct 2020 18:50:49 +0800

Yunan,

> 2020年10月9日 14:41，Guyunan <[email-masked]> 写道：
> 

A very good catch.

I think https is default at least as it is used in the name of this draft literally.

But I see a potential that http can work if IPsec has been established between two cache servers.

We can discuss it further if adopted as a WG item.

Di

> On Mon, Sep 28, 2020 at 6:38 AM Chris Morrow <[email-masked]> wrote:
> 
> Howdy,
> 
> [email-masked]
> [email-masked]

---

From: Christopher Morrow <[email-masked]>
Date: Thu, 22 Oct 2020 10:42:29 -0400

Howdy folks,
We had 2 authors and 1 not-author reply here... Are there other folks
interested in moving this forward? or working on this in the WG over
the next few meeting slots/periods?

-chris

---

From: Stephen Kent <[email-masked]>
Date: Thu, 22 Oct 2020 11:37:58 -0400

I support adoption.  SLURM seems to be a potentially very useful mechanism and this proposal is a natural companion  to SLURM,

Steve 

Sent from my iPhone

> On Oct 22, 2020, at 10:42, Christopher Morrow <[email-masked]> wrote:
> 
> Howdy folks,

---

From: Job Snijders <[email-masked]>
Date: Thu, 22 Oct 2020 16:17:40 +0000

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.

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.

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.

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.

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.

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.

In summary:

    * RUSH specifically targets a (IMHO) terrible use case
    * RUSH appears to be "SLURM over HTTP" (doh?)
    * One can argue there is a need to standardize a VRP exchange format
      perhaps based on JSON for archival / intra-domain applications

Kind regards,

Job

---

From: Di Ma <[email-masked]>
Date: Fri, 23 Oct 2020 21:18:21 +0800

Job,

> 2020年10月23日 00:17，Job Snijders <[email-masked]> 写道：
> 
> Hi all,
> 

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.

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

> be morphed into something that is useful.

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

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

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

> 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

---

From: Job Snijders <[email-masked]>
Date: Fri, 23 Oct 2020 13:44:59 +0000

Hi Di,

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

> AS0 is only a potential usecase and it is a policy issue whether the
> community decide to use RUSH to implement AS0. 
> 

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*

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?

> 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

---

From: Di Ma <[email-masked]>
Date: Wed, 28 Oct 2020 14:32:48 +0800

Job,

Sorry for my late response.

> 2020年10月23日 21:44，Job Snijders <[email-masked]> 写道：
> 
> Hi Di,
> 

The trust in the RPKI roots in the public key that an RP uses to validate a X.509 certificate or a signed object. 

The trust in RUSH basically is the key bound to the cache server to do authentication which by the way is out of band of the RPKI.  Or the trust can also be the shared-key pre-configured between cache server and cache client of a RUSH connection in question.

> exaggregation supports the Internet-Draft.

An exaggerated example might not implemented in practice but helps make the statement more straightforward.

> wider (contentious) discussion.

I did note the discussions in RIPE Routing WG where AS0-slurm proposal did not reach consensus.

But I have not got the similar observation in APNIC, LACNIC, ARIN and AfriNIC community. I would like to hear from them.

Anyway, AS0-slurm is just one of the usecases.  Should it not be proper to be a RUSH usecase, RUSH should not be denied on the whole.

> mechanism. Why water that channel down?

I think the first two usecases described in the draft are easy to be implemented in a commonsense trust domain.

o Cache Distribution
   RUSH can be used to distribute a RPKI validated cache within a single
   ASN or network, for example a confederation composed of a number of
   ASes.  A small site or enterprise network MAY also use RUSH by
   synchronizing with a third-party RPKI cache provider over external
   networks.

   o Local Control over Networks
   Network operators MAY want to inject SLURM Assertions/Filters via an
   API offered by RPKI validator/cache.  RUSH is therefore able to carry
   out such local control signals inside an administrative bailiwick in
   a secure manner.

Di

---

From: Di Ma <[email-masked]>
Date: Wed, 28 Oct 2020 20:49:51 +0800

Job,

We authors are fine with removing AS0 usecase in RUSH after some discussions.

Di

> 2020年10月28日 14:32，Di Ma <[email-masked]> 写道：
> 
> Job,
>