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

From: Di Ma <[email-masked]>
Date: Tue, 17 Nov 2020 16:21:05 +0800

Chris,

We authors have removed AS0 usecase for RUSH re Job’s concern.

And we also made some editorial change to articulate HTTPs as transport where needed, re Yunan’s suggestion.

Please consider whether it is ready to be adopted.

Thanks.

Di

> 2020年10月22日 22:42，Christopher Morrow <[email-masked]> 写道：
> 
> 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
> 
> On Fri, Oct 9, 2020 at 6:51 AM Di Ma <[email-masked]> wrote:
>> 
>> Yunan,
>> 
>>> 2020年10月9日 14:41，Guyunan <[email-masked]> 写道：
>>> 
>>> 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.
>> 
>> 
>> 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
>> 
>>> 
>>> 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]> 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]
>>> https://www.ietf.org/mailman/listinfo/sidrops
>>> _______________________________________________
>>> Sidrops mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/sidrops
>> 
>> _______________________________________________
>> Sidrops mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/sidrops
> 
> _______________________________________________
> Sidrops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidrops

---

From: Chris Morrow <[email-masked]>
Date: Tue, 17 Nov 2020 11:59:13 +0000

On Tue, 17 Nov 2020 08:21:05 +0000,
> Please consider whether it is ready to be adopted.

ok, awesome.

Can yunan/job speak up if their concerns are NOT met at this time?

If they don't speak up in an hour I think we can consider this adopted
and ask the authors to submit the appropriately re-named draft :)

-chris

---

From: Job Snijders <[email-masked]>
Date: Tue, 17 Nov 2020 14:05:17 +0000

On Tue, Nov 17, 2020 at 11:59:13AM +0000, Chris Morrow wrote:
> Can job speak up if their concerns are NOT met at this time?
> 

Eh.... a new IETF rule? :-)

I am not a fan of adopting this draft, I think the working this working
group's sparse resources should be allocated towards other work. In the
operational field, people have been transporting SLURM files for years
over HTTPS, SSH, whatever is suitable. It seems awkward to describe that
a SLURM file can be transported over HTTPS... it seems ...  obvious?

The security section of RFC 8416 already establishes "Additionally, each
RP using SLURM MUST ensure the authenticity and integrity of any SLURM
file that it uses." The described use-cases erode potential security,
specifically:

    "A small site or enterprise network MAY also use RUSH by
    synchronizing with a third-party RPKI cache provider over external
    networks."

Who are those small networks? Are the authors attempting to speak for a
silent majority? As far as I know small networks have just as much
access to tools to validate RPKI data as big networks. What even *is* a
'small' network? Seems pedantic to a-priori diminish/downgrade a small
network's access to secure routing by suggesting they should use an
inferior substitute instead of the real thing, when everyone knows you
can run a RPKI validator on a raspberry pi or smaller.

Furthermore I do not believe that the SLURM format is optimal to
distribute Validated RPKI cache data. It is inefficient from a size
perspective. The SLURM format makes a lot of sense for describing 'Local
RPKI exceptions', but the datastructure seems less suitable as the RPKI
grows in size.

Many operators *already today* are using different formats, so why not
either look to standardize the format that actually is in use in the
wild, or optimize towards something that is better than what is already
used in the wild?

summary:

    1) SLURM RFC already covers important aspects of SLURM, no novelty
    2) SLURM format seems less suitable than already-deployed JSON formats
    3) Suggestion to research the already-deployed-formats and
       standardize those, or optimize those formats to improve RPKI
       cache distribution.

Kind regards,

Job

---

From: Di Ma <[email-masked]>
Date: Wed, 18 Nov 2020 14:48:33 +0800

Job,

> 2020年11月17日 22:05，Job Snijders <[email-masked]> 写道：
> 

Happy to know people have been transporting SLURM files, which makes it necessary to standardize RUSH for inter-operation.

I think this argument of yours is a kinda support for adoption of RUSH not the other way around.

> can run a RPKI validator on a raspberry pi or smaller.

We don’t make decision for operators but offer them a choice that they can outsource valiation if they have no problem with this fashion.

> RPKI exceptions', but the datastructure seems less suitable as the RPKI

I don’t agree in terms of SIZE.

The beauty of SLURM file is that it naturally supports incremental update.

> wild, or optimize towards something that is better than what is already

I am pleased to know those operators have *already today* used some other formats that works for their networking condition.

If they want a standardized format, it is fine and good.  But this won’t necessarily stop RUSH from being a WG item.  

Di

---

From: Jared Mauch <[email-masked]>
Date: Wed, 18 Nov 2020 01:54:14 -0500

> On Nov 18, 2020, at 1:48 AM, Di Ma <[email-masked]> wrote:
> 

Is it perhaps better to think about offering validation as a service to people who can’t or are unable to run their own validators?

(Thinking of how people may decide to use an off-network DNS resolver so they don’t need to operate one themselves).

Perhaps this is something larger networks may want to offer to their customers, similar to how they may offer NTP, DNS and other services?

- Jared

---

From: Di Ma <[email-masked]>
Date: Wed, 18 Nov 2020 15:02:44 +0800

Jared,

Thanks for your suggestion.

> 2020年11月18日 14:54，Jared Mauch <[email-masked]> 写道：
> 
> 
> 

I think this is a reasonable usecase which can be added into RUSH document.

And RUSH can also be used within a large ISP to distribute cache to RTR servers deployed in different ASes.

Di

---

From: Jared Mauch <[email-masked]>
Date: Wed, 18 Nov 2020 02:49:10 -0500

> And RUSH can also be used within a large ISP to distribute cache to RTR servers deployed in different ASes.

	While an idea, how i copy data internally between my infrastructure
doesn't always need to become a standard.  In that regard I tend to lean
towards the comments from Job.

	I may clone VMs, use rsync, ftp, scp, webdav, SMB to copy data
around internally.  My [dirty] incantations don't need to be all standards
based.

	- Jared

-- 
Jared Mauch  | pgp key available via finger from [email-masked]
clue++;      | http://puck.nether.net/~jared/  My statements are only mine.

---

From: Tim Bruijnzeels <[email-masked]>
Date: Wed, 18 Nov 2020 09:04:06 +0100

Hi,

> On 18 Nov 2020, at 08:02, Di Ma <[email-masked]> wrote:
> 
> Jared,
> 

I believe that for this use case it would be better to standardise the (signed) json emitted by validators so that it can be used by rpki-rtr implementations (go-rtr, and the one we are building rtrtr).

That way people can have interchangeable validators and RTR implementations. With signing one can distribute the data safely even over public internet which can help centralised *own* management.

I believe that outsourcing the validation and using someone else's RP feed for their RTR is ill advised, yet it may be something that people choose to do regardless.

As far as RUSH is concerned I am still on the fence about it, but I see a possible use case in having an API to push updated SLURM settings in a local RP, more finegrained, e.g. allow listing things, adding/removing one or more exceptions as a delta, rather than just giving the RP a complete new file. But.. that would be a different thing altogether, and I don't really want to invent this for the sake of it - I would ask operators here if they have that use case first.

As written the document seems to say: there are SLURM files and you can transport them over HTTPS, possibly implying that RP software will actively fetch these files. I lean towards not standardising this, as it's something that people can already do today. A simple script that fetches a file and feeds it to an RP would already work, if that's the way one chooses to operate.

Tim

---

From: Claudio Jeker <[email-masked]>
Date: Wed, 18 Nov 2020 09:19:36 +0100

> I think this argument of yours is a kinda support for adoption of RUSH not the other way around.

Why is file transport an inter-op problem. If the file is copied with scp,
sftp, rcp, rsync, https, http, ftp, USB stick, floppy disk, or using any
combination of those methods is up to the operator and there is no need to
write an RFC about this. Especially since RUSH is not on the same level as
RPKI regarding authenticity validation.

> We don’t make decision for operators but offer them a choice that they can outsource valiation if they have no problem with this fashion.

This is a very bad choice. There is no cryptographic signature in RUSH
that ensures that the provided data is actually authentic and unaltered.
There is no way to verify the data. All the trust is put in HTTPS.
A secure transport layer does not ensure that the file served was
not altered. 

I think this WG is responsible in helping operators to take the right
decision and to make sure that the promise of validated resource
authorization is not watered down.  Because of this I agree with Job that
this draft should not be adopted by this WG.

People should better spend the effort in making the rpki validators as
easy to use and deploy as possible.

> I am pleased to know those operators have *already today* used some
> other formats that works for their networking condition.
> 
> If they want a standardized format, it is fine and good.  But this won’t
> necessarily stop RUSH from being a WG item.  

-- 
:wq Claudio

---

From: Job Snijders <[email-masked]>
Date: Wed, 18 Nov 2020 12:27:42 +0000

On Wed, Nov 18, 2020 at 02:48:33PM +0800, Di Ma wrote:
> > perspective. The SLURM format makes a lot of sense for describing
> > 'Local RPKI exceptions', but the datastructure seems less suitable
> > as the RPKI grows in size.
> 

Hmmm, when analyzing the SIZE difference:

    $ du -sh slurm.json rpki-client.json
    16.3M   rpki-client.json
    20.3M   slurm.json

The size difference can be explained because the non-standard format
uses 'maxLength' as key, and SLURM uses 'maxPrefixLength' (which is more
bytes).

Furthermore, the SLURM format does not have a "ta" (Trust Anchor) key,
so the SLURM format offers *less* detail than the non-standard format.
The SLURM format also does not have the "metadata" key, which contains
valuable metadata about the set of VRPs the JSON object describes.

> The beauty of SLURM file is that it naturally supports incremental

As far as I can see SLURM does not 'naturally support incremental
updates'. Can you please elaborate on this 'natural' property?

Reading the SLURM RFC it has a section on "atomicity", making it clear
that a partial SLURM file is problematic, and further more it specifies
how to deal with multiple SLURM files, which is not the same as
'naturally supporting incremental updates'.

> > Many operators *already today* are using different formats, so why
> > not either look to standardize the format that actually is in use in
> > the wild, or optimize towards something that is better than what is
> > already used in the wild?
> 
> If they want a standardized format, it is fine and good.  But this
> won’t necessarily stop RUSH from being a WG item.  

I would encourage you to not ignore feedback from operators such as
myself. It seems the authors are ignoring the lessons learned from
existing solutions.

Operators (like myself) have experience with large-scale Route Origin
Validation designs where RPKI Cache Validators and RTR servers are
separate network elements. This experience must not be ignored.

There are 5 (!!!!) validator implementations which support a common
(not-yet-standardized) format used in many real-world deployments. From
this tangible experience we know some of the good and bad sides of the
particular format.

SIDROPS can choose between 3 options: do nothing; or standardize the
existing commonly used format; or improve the existing deployed format.

Investing working group time in a *WORSE* format is not an option.

Kind regards,

Job