Subject: [Sidrops] RTR over QUIC

From: Di Ma <[email-masked]>
Date: Wed, 4 Aug 2021 16:47:04 +0800

Hi, folks,

I am recently exploring to improve RTR.

As we test our RP implementation, RTR would start over in case of just one piece of wrong PDU, which is more remarkably observed when a router is downloading the full copy from RTR server. I think this could be a problem since there is an increasing both number and type of RPKI data.

Since QUIC can tolerate packet loss to some extent, I am trying to let RPSTIR call QUIC for transport. 

Besides, QUIC has got intrinsic support of TLS which is another feature that RTR could benefit from.
 
Any big idea or practice on this point? Shall this WG consider standardizing RTR over QUIC?

Di

---

From: Claudio Jeker <[email-masked]>
Date: Wed, 4 Aug 2021 11:15:58 +0200

> standardizing RTR over QUIC?

What does QUIC solve that TCP does not that is relevant for RTR?
I really see no point in pushing for QUIC for something that works
perfectly over TCP and has no need to work around TCP window scaling.
TCP stacks are widely available whereas QUIC is not.

-- 
:wq Claudio

---

From: Chenshuanglong <[email-masked]>
Date: Wed, 4 Aug 2021 09:22:32 +0000

Hi Di，

We are also exploring the feasibility of BGP over QUIC, and I think both BGP over QUIC and RTR over QUIC are technically feasible. 

In addition, QUIC's weak network tolerance, short latency performance, and inherent support for TLS may benefit protocols.

BestRegards
Shuanglong

-----Original Message-----
From: Sidrops [mailto:[email-masked]] On Behalf Of Di Ma
Sent: Wednesday, August 4, 2021 4:47 PM
To: SIDR Operations WG <[email-masked]>
Subject: [Sidrops] RTR over QUIC

Hi, folks,

 

Di

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

---

From: Job Snijders <[email-masked]>
Date: Wed, 4 Aug 2021 12:01:22 +0200

On Wed, Aug 04, 2021 at 04:47:04PM +0800, Di Ma wrote:
> As we test our RP implementation, RTR would start over in case of just
> one piece of wrong PDU, which is more remarkably observed when a
> router is downloading the full copy from RTR server. I think this
> could be a problem since there is an increasing both number and type
> of RPKI data.

RTR clients are fully expected to terminate the RTR session when a
corrupted PDU is received from the server.

> RPSTIR call QUIC for transport. 

But TCP (and SSH) can also tolerate packet loss?

> standardizing RTR over QUIC?

There already is:

	* RTR over SSH
	* RTR over TLS
	* RTR over TCP-MD5
	* RTR over TCP-AO

I am not sure how adding QUIC to the list will materially improve
things. It would introduce additional fragmentation in the ecosystem.
With this many RTR transport options available, it appears the industry
is not converging on a single mechanism, which harms interopability.

The table overview at https://datatracker.ietf.org/doc/html/rfc7128#section-5
is an indication there already are too many standards.

Promoting "RTR over SSH" to be the default transport, supported by all
platforms would be my preference.

Kind regards,

Job

---

From: Di Ma <[email-masked]>
Date: Wed, 4 Aug 2021 19:48:28 +0800

Shuanglong,

> 2021年8月4日 17:22，Chenshuanglong <[email-masked]> 写道：
> 
> Hi Di，
> 

Glad to know Huawei as a vendor’s interest in QUIC support for routers.

Should Huawei's router has got support of QUIC, then we would have chance to have a test of RTR over QUIC.

Di

---

From: Di Ma <[email-masked]>
Date: Wed, 4 Aug 2021 20:06:50 +0800

Job,

> 2021年8月4日 18:01，Job Snijders <job=[email-masked]> 写道：
> 

Yes. 

Granted, the RTR client has to start over for all the PDUs, instead of pursuing an incremental from where it finds this corrupted one.

Di

---

From: Ties de Kock <[email-masked]>
Date: Wed, 4 Aug 2021 14:09:26 +0200

Di,

> On 4 Aug 2021, at 14:06, Di Ma <[email-masked]> wrote:
> 
> Job,
> 

How would you inject an invalid PDU in a TCP, RTR-over-TLS or RTR-over-SSH stream?

I think that an on-path attacker can always force the connection to reset - even with QUIC.

Kind regards,
Ties