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

[Job Snijders <[e-mail]>]

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?
> 
> 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 :)

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