Re: [Sidrops] I-D Action: draft-ietf-sidrops-prefer-rrdp-01.txt

[Koen van Hove <[e-mail]>]

Dear Tim, all,

I have looked at your motivation, particularly:
>    *  rsync is CPU and memory heavy on the server side, and easy to DoS

I decided to test your hypothesis, as RFC 6480 says otherwise, and created a
small program that aims to DoS an rsync daemon using many simultaneous
connections from different IP addresses (but the same machine). My
conclusion is the same as yours - with the old computer (4 cores, 16 GB of
RAM, home fiber connection) underneath my desk I can currently take down my
own test rsync server (8 cores, 16 GB RAM, 1 Gbps connection, different
network). Discussions with operators from RIRs seem to show that this would
also work for their rsync servers.  I believe this would even allow one to
take down all rsync servers currently running in the RPKI with a handful of
computers, but I have not tested that as I do not want to disrupt actual
operations. For this reason, running only rsync strikes me as problematic,
especially if one wishes to adhere to "The publication repository SHOULD be
hosted on a highly available service and high-capacity publication
platform." from RFC 6481, and thus believe that making RRDP a MUST is a good
idea. Of course, one can block the IP addresses used for the DoS attack, but
that turns into a cat and mouse game, where the rsync server operator has a
serious disadvantage (especially compared to RRDP).

What I further want to draw the attention to, and I did not see mentioned in
the draft, is that apart from rsync being an extra protocol that can be used
to receive data (which is useful if RRDP fails), it is also an additional
attack vector. I am thus opposed to the addition of: 
>    Relying Parties MUST attempt to use alternative repository access
mechanisms, if they are available, according to the accessMethod element
value(s) specified in the SIA of the associated certificate (see Section
4.8.8 of [RFC6487]).

Rsync was not created to be used with a possibly malicious server.
Therefore, there are currently simple things everyone could do that would
disrupt a relying party over rsync, which are difficult to solve:
1. One can set a motd file that is several gigabytes in size. Rsync will
wait until this is received (the --no-motd switch only hides it on the
client) and the timeout set in rsync does not affect the maximum time this
may take.
2. One can create an rsync repository with many folders (I tested it with 27
million folders). This fills up the maximum amount of inodes on most Linux
and *BSD filesystems within minutes whilst bypassing any size limits or
--includes and --excludes, as a folder has a size of 0, and folders are used
in non-malicious repositories. 
Both can be done when one is part of an RPKI tree, or using MITM, or a DNS
hijack - serving the actual files as well is not a problem, and you do not
need to sign anything new. Solving the first one can probably be easily done
by setting a timeout outside the rsync program, but the second one seems
more difficult to solve. I believe the impact could be quite substantial.
There is probably more an attacker can do - I did not look extensively into
it.

As both the server and the client can easily be attacked, I believe that in
this case "less is more", and to re-evaluate whether rsync support is an
asset or a burden. I believe availability of the RPKI ecosystem can be
better guaranteed without rsync, and believe a post-rsync section is
justified.

Koen van Hove

-----Oorspronkelijk bericht-----
Van: Tim Bruijnzeels <[e-mail]> 
Verzonden: vrijdag 22 oktober 2021 11:03
Aan: SIDR Operations WG <[e-mail]>
Onderwerp: Re: [Sidrops] I-D Action: draft-ietf-sidrops-prefer-rrdp-01.txt

Dear working group,

We just uploaded a new version of the prefer-rrdp draft.

The document has had some updates based on working group member comments and
discussion between the co-authors. The uploaded version still lacks final
review by my co-authors, but.. after discussing we decided that it would be
good to replace the now expired -00 with this. This also makes it easier for
WG members to comment.

This version is not intended to be final. It's intended to support further
discussion. So feel free!

Important changes compared to -00:
- We no longer talk about post-rsync in this document
   (this can be done as a later and separate exercise)
- We included some more text on rsync fallback

I would like to ask you all to give it a read provide feedback.

Kind regards
Tim




> On 22 Oct 2021, at 10:53, [e-mail] wrote:
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
directories.
> This draft is a work item of the SIDR Operations WG of the IETF.
> 
>        Title           : Resource Public Key Infrastructure (RPKI)
Repository Requirements
>        Authors         : Tim Bruijnzeels
>                          Randy Bush
>                          George Michaelson
> 	Filename        : draft-ietf-sidrops-prefer-rrdp-01.txt
> 	Pages           : 10
> 	Date            : 2021-10-22
> 
> Abstract:
>   This document formulates a plan of a phased transition to a state
>   where RPKI repositories and Relying Party software performing RPKI
>   Validation will use the RPKI Repository Delta Protocol (RRDP)
>   [RFC8182] as the preferred access protocol, and require rsync as a
>   fallback option only.
> 
>   In phase 0, today's deployment, RRDP is supported by most, but not
>   all Repositories, and most but not all RP software.
> 
>   In the proposed phase 1 RRDP will become mandatory to implement for
>   Repositories, in addition to rsync.  This phase can start as soon as
>   this document is published.
> 
>   Phase 2 will start once the proposed updates are implemented by all
>   compliant Repositories.  In this phase RRDP will become mandatory to
>   implement for all compliant RP software, and rsync will be required
>   as a fallback option only.
> 
>   It should be noted that although this document currently includes
>   descriptions and updates to RFCs for each of these phases, we may
>   find that it will be beneficial to have one or more separate
>   documents for these phases, so that it might be more clear to all
>   when the updates to RFCs take effect.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-sidrops-prefer-rrdp/
> 
> There is also an htmlized version available at:
> https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-prefer-rrdp-0
> 1
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-sidrops-prefer-rrdp-01
> 
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> 
> _______________________________________________
> Sidrops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sidrops