Subject: Re: [Sidrops] nlnet rp and rsync

From: Randy Bush <[email-masked]>
Date: Mon, 11 May 2020 04:17:16 -0700

turning a private discussion public, with consent of course

it turns out that, to quote tim

> Routinator has had support for RRDP since version 0.6.0, released in
> September 2019.
> 
> If it finds an RRDP SIA and successfully synchronizes the publication
> point once, it will whitelist the RRDP SIA URI and it will no longer
> fall back to rsync where this URI occurs on CA certificates. As long
> as the synchronization has not been successful it will fall back to
> rsync.

to which i then said

> that seem a potential violation of spec.  if the PP RRDP service then
> fails, it really MUST fall back to the mandatory to implement rsync.
> 
>> As long as the synchronization has not been successful it will fall
>> back to rsync.
> 
> s/As long as/If/

to which martin said

> Can you point me to where it says that? Section 3.4.5 of RFC 8182 is
> pretty indifferent about it.

to which i said

> among other places, 6481 s3
> 
>      *  The publication repository MUST be available using rsync
>         [RFC5781] [RSYNC].  Support of additional retrieval mechanisms
>         is the choice of the repository operator.  The supported
>         retrieval mechanisms MUST be consistent with the accessMethod
>         element value(s) specified in the SIA of the associated CA or
>         EE certificate.

to which martin responded

> This talks about what the publication point has to offer, not what a
> cache has to use. In particular, it says that the publication point
> musn’t advertise RRDP unless it actually offers RRDP. Which means that
> as a cache I can rely on RRDP being available.
> 
> Forcing a cache to use rsync instead of RRDP is a downgrade attack and
> should be handled accordingly.

at which point i said it is time to take this to the wg.  so here we go.

imiho, 6481 makes it very clear that rsync is currently the mandatory to
implement protocol (yes i am a coauthor of a draft trying to eventially
change that).  i contend that this is MTI by both the publisher and by
the client.

randy

---

From: Russ Housley <[email-masked]>
Date: Mon, 11 May 2020 10:44:01 -0400

The repository MUST be available by rsync, and it MAY also be available using other protocols.

A client can use any of the protocols that it wants, but it seems like unnecessary fragility to pick an alternate and then refuse to consider rsync.  This seem counter to a graceful transition, especially if there is a transition from RRDP to RRDP2 in the distant future.

Russ

> On May 11, 2020, at 7:17 AM, Randy Bush <[email-masked]> wrote:
> 
> _______________________________________________
> Sidrops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidrops

---

From: Randy Bush <[email-masked]>
Date: Mon, 11 May 2020 10:33:20 -0700

rrdp is more fragile.  e.g. the nlnet labs client (rightly, imiho)
checks the full certificate chain.  if any piece of the chain expires,
is CRLed, ... the client does not go to rsync.  bam!

falling back to rsync is not a 'downgrade' in that the rpki uses an
object, not transport, security model.  well, until the last hop to the
router, and you can see the transport security section from hell in rfc
8210.

the goal in rrdp was to make the rpki more, not less reliable.  we found
the nllnet labs misfeature in the wild when CA data were no longer
fetched.  imiho not good.

randy

---

From: George Michaelson <[email-masked]>
Date: Tue, 12 May 2020 08:19:46 +1000

I agree in the current spec, its MTI.

I also believe the intent of the deprecate-rsync draft remains: Remove
this dependency.

If this means we need to discuss the implications of channel security
and TLS on deployment, and specify the certificate chain validation
requirements on publication points and clients, thats what we need to
do.

But, until deprecate-rsync is adopted and published, the current
specification I feel is clear: you must support rsync, both sides of
the equation.

All the discussions on validation clarifications go to 'removing
objects' -What is the nature of transport security failings, if not to
permit removal of objects? And, if an object can be occluded or
removed because of a lack of channel security, what does this mean in
terms of denial of service attacks?

-George

---

From: Martin Hoffmann <[email-masked]>
Date: Tue, 12 May 2020 11:45:21 +0200

Russ Housley wrote:
> 
> A client can use any of the protocols that it wants, but it seems
> like unnecessary fragility to pick an alternate and then refuse to
> consider rsync.  This seem counter to a graceful transition,
> especially if there is a transition from RRDP to RRDP2 in the distant
> future.

The decision to not fall back to rsync if RRDP succeeded once was
actually made with publication point operators in mind. With most
relying party software now supporting RRDP and preferring it over
rsync, an operator will see most traffic via RRDP and only very small
amounts on rsync. Given that unlike with HTTP where lots of tooling and
services for reliable, scalable operation exist, you are basically on
your own with rsync, they are likely to only provide a minimum service.
Now, if the RRDP service becomes unavailable for whatever reason, all
relying parties hitting the rsync service is not going to end well.

Since the absolute majority of these RRDP failures are of a transient
nature and will be resolved by the next validation run, just skipping
the publication point this time seems a reasonable choice. This could
probably be improved by remember how many times it failed and switching
back to rsync after, say, five failures, but I am not sure this is
worth the effort.

As an aside, switching between rsync and RRDP isn’t free. Because an
RRDP server can essentially publish objects for any rsync URI it wants,
you have to keep separate trees for rsync and each and every RRDP
server. So falling back to rsync actually means either downloading the
full copy or updating a severely outdated copy. It’s not that big a
deal in the grand scheme of things but worth noting.

Kind regards,
Martin

---

From: Martin Hoffmann <[email-masked]>
Date: Tue, 12 May 2020 11:53:06 +0200

> is CRLed, ... the client does not go to rsync.  bam!

I would argue that operating an rsync server is much more fragile in
practice, simply because operators have much less experience with it.
As opposed to keeping an HTTPS server up and running which is absolutely
essential to each and every Internet operation now. 

If a certificate appears on a CRL, there is probably a good reason for
it and perhaps the service shouldn’t be trusted anymore.

> object, not transport, security model.

It has been demonstrated that by maliciously withholding RPKI objects
you can cause damage to the routing system, so we should perhaps
revisit the choice of not relying on transport security.

> the goal in rrdp was to make the rpki more, not less reliable.  we
> found the nllnet labs misfeature in the wild when CA data were no
> longer fetched.  imiho not good.

Was that a permanent issue or did the CA in question fix their RRDP
service in due time? From what I am seeing, the current shift to reject
stale manifests and CRLs will cause much more issue.

Kind regards,
Martin

---

From: Stephen Kent <[email-masked]>
Date: Tue, 12 May 2020 09:08:20 -0400

Randy,

Another observation on this topic: the current, posted versions of the 
CPS for RIPE, APNIC, ARIN, LACNICand AFRINIC refer only to rsync, not RRDP.

Steve

---

From: Russ Housley <[email-masked]>
Date: Tue, 12 May 2020 10:06:21 -0400

> back to rsync after, say, five failures, but I am not sure this is

That seems like a desirable improvement.

> deal in the grand scheme of things but worth noting.

I understand that rsync and RRDP offer a very different interface; however, rsync is still the mandatory-to-implement protocol.  And, you clearly already have the code in place to support it.

Russ

---

From: Rob Austein <[email-masked]>
Date: Tue, 12 May 2020 16:41:26 -0400

FWIW: I believe that the intent of the WG at the time we wrote the
current specification was that rsync be mandatory to implement for
both CA and RP.  As others have noted, the somewhat misnamed
"deprecate-rsync" draft is about changing that, which is fine if
that's the direction we want to go, but for now I think an RP is
required at least to attempt to fall back to rsync when RRDP fails.

---

From: Martin Hoffmann <[email-masked]>
Date: Wed, 13 May 2020 12:53:41 +0200

> required at least to attempt to fall back to rsync when RRDP fails.

This particular case has its very own section in RFC 8182, section
3.4.5. This section does explicitly not require to fall back to rsync
and leaves it to the relying party software whether it wants to try any
other method or not. My, purely subjective, reading of its tone is
that it even suggests not to bother.

Kind regards,
Martin