Subject: Re: [quicwg/base-drafts] ICMP and ICMPv6 PMTUD with asymmetric connection-ids (#1243)

From: Martin Thomson <[email-masked]>
Date: Mon, 04 Jun 2018 08:22:34 -0700

@enygren, @igorlord, the solutions that you are contemplating here are fairly disruptive to the design.  If you feel strongly about this, you should take it to the list and get the attention of the working group.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1243#issuecomment-394394203

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 04 Jun 2018 21:44:44 -0700

FWIW, let me point out that under the current draft it is possible for an endpoint to send a long header packet at any time it wants to observe the MTU, even after the handshake is complete. It's just that the long header packet will be ignored by the client in case it reaches the client.

And with the introduction of coalesced packets, the cost of doing this type of PMTUD has become small.

Whenever an endpoint wants to do PMTUD and it has some outstanding data, is creates a datagram that consists of the following two QUIC packets:
* a long header packet with zero-length payload that contains the server CID (or some other payload that is sufficient to route the ICMP response back to the origin server)
* a short header packet carrying outstanding data

This type of datagram never harms the conncection, because the draft requires the receiver to process each QUIC packet as if it was received as a separate datagram.

Assuming that the server will be performing PMTUD and assuming that the client's CID is zero-sized, the overhead of the long header packet is: 1 (type) + 4 (version) + 1 (cidl) + len(server_CID) + 1 (payload-length).

Actually, this approach (i.e. sending a compound datagram to contain arbitrary information) is flexible enough to carry any data that needs to be exposed to an on-path device. We could use it to expose packet drop rate for example.

I'm not saying we should support these kinds of exposures, but we cannot prohibit such thing to happen, because the receiver cannot determine if an incoming packet was sent from the peer (to expose signal to on-path devices) or from an attacker (to disrupt connection).

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1243#issuecomment-394580024

---

From: MikkelFJ <[email-masked]>
Date: Tue, 05 Jun 2018 00:08:06 -0700

> This type of datagram never harms the conncection, because the draft requires the receiver to process each QUIC packet as if it was received as a separate datagram.

That is not necessarily true because that is under a cooperative assumption. Any party that keeps dumping invalid packets might be flagged, also otherwise competent QUIC peers. Seeing something suspect in a packet is reasonable cause for rejecting the entire transmission.

Hence, if this is considered a good idea, both endpoints should understand  and agree  on this and avoid confusing each other.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1243#issuecomment-394604499

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 05 Jun 2018 00:19:49 -0700

> Any party that keeps dumping invalid packets might be flagged, also otherwise competent QUIC peers. Seeing something suspect in a packet is reasonable cause for rejecting the entire transmission.

I disagree. As stated in my comment above, terminating the connection due to seeing suspicious QUIC packets is equal to allowing attackers reset the connection. That goes against our principal of having "authenticated reset."

I believe that the same holds for coalesced packets. An attacker can break the packet by modifying it. But that should not lead to the connection being terminated.

FWIW, section 4.6 of the transport draft says: "The receiver of coalesced QUIC packets MUST individually process each QUIC packet and separately acknowledge them, as if they were received as the payload of different UDP datagrams."

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1243#issuecomment-394607390

---

From: MikkelFJ <[email-masked]>
Date: Tue, 05 Jun 2018 00:39:26 -0700

I didn't mean to say dump the connection. By dump transmission I meant the single UDP datagram - either someone messed with it, or the peer is misbehaving. In that case it makes limited sense to further process the datagram since it is obviously not up to specs.

This opens up to an on-path attack where a third party can attach content to a datagram and here you are right, but compound packets are only used during the early handshake, no? And here the best approach is to reject as much nonsense as possible.

If the peer volunteers to sign a packet that makes non sense it becomes suspecious and repeat offences might lead to disconnection and black listing. Therefore it is IMO not a good idea to use invalid packets for path discovery or any other purpose.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1243#issuecomment-394612529

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 05 Jun 2018 07:53:29 -0700

> This opens up to an on-path attack where a third party can attach content to a datagram and here you are right, but compound packets are only used during the early handshake, no? And here the best…

It is true that compound packets are only used during the handshake. OTOH I do not see why we should reject compound packets after the handshake even though we agree that doing so creates an attack vector.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1243#issuecomment-394740045

---

From: Gorry Fairhurst <[email-masked]>
Date: Sun, 17 Jun 2018 03:40:45 -0700

Maybe it is worth identifying this design consideration in  dplpmtud - some of this is generic to working with icmp with any cooperating middle-boxes

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1243#issuecomment-397869951

---

From: martinduke <[email-masked]>
Date: Mon, 18 Jun 2018 13:47:00 -0700

I agree with @gorryfair -- this is a generic problem with load balancers and ICMP, and there are several workarounds which are outside the scope of QUIC itself.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1243#issuecomment-398190157

---

From: Igor Lubashev <[email-masked]>
Date: Fri, 29 Jun 2018 13:15:49 -0700

ICMP and Load Balancers is a generic problem, but QUIC has some protocol elements specifically designed to help load balancers (Server CID).  It stands to reason that enable those protocol elements to help with ICMP processing in QUIC context.

@martinduke, which workarounds do you have in mind (unless it is PLPMTUD)?  PLPMTUD, for example, specifically states that it works most efficiently with ICMP.  So this issue is about enabling ICMP to for for PMTU in the presence of load balancers.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1243#issuecomment-401462472

---

From: Gorry Fairhurst <[email-masked]>
Date: Sat, 30 Jun 2018 01:10:28 -0700

Just to be sure myself ..  how does that help a QUIC sender to process a PTB ICMP message?

Gorry 

> On 29 Jun 2018, at 21:15, Igor Lubashev <[email-masked]> wrote:
> 
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub, or mute the thread.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1243#issuecomment-401525861

---

From: Igor Lubashev <[email-masked]>
Date: Sat, 30 Jun 2018 05:49:05 -0700

All ICMPv6 and a growing number of ICMPv4 packets include a few hundred octets of the packet that triggered that ICMP.

A QUIC sender can be behind a load balancer that requires a Server CID to route packets to that server (this is what we designed Server CID for). However, short header packets do not contain Server CID. Hence, when doing a PMTUD probe, such servers may need to use something that would ensure the presence of Server CID in the UDP datagram. (I.e. they may want to use this method when sending packets larger than any packet for which they had received an ACK from this path before.)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1243#issuecomment-401539218

---

From: Gorry Fairhurst <[email-masked]>
Date: Sat, 30 Jun 2018 06:26:02 -0700

I see, I think this use of the Server CID seems to provide what is 
described as the "protocol information in the quoted payload"  in 4.3  
(Verification and Use of PTB Messages) of the dplpmtud draft.

Gorry

On 30/06/2018, 13:49, Igor Lubashev wrote:
>
> All ICMPv6 and a growing number of ICMPv4 packets include a few 
> hundred octets of the packet that triggered that ICMP.
>
> A QUIC sender can be behind a load balancer that requires a Server CID 
> to route packets to that server (this is what we designed Server CID 
> for). However, short header packets do not contain Server CID. Hence, 
> when doing a PMTUD probe, such servers may need to use something that 
> would ensure the presence of Server CID in the UDP datagram. (I.e. 
> they may want to use this method when sending packets larger than any 
> packet for which they had received an ACK from this path before.)
>
> —
> Reply to this email directly, view it on GitHub 
> <https://github.com/quicwg/base-drafts/issues/1243#issuecomment-401539218>, 
> or mute the thread 
> <https://github.com/notifications/unsubscribe-auth/AHC1kp4A2Lo6ljq1l6k7sYZ7szsMwP0Hks5uB3PBgaJpZM4Sw_fz>.
>

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1243#issuecomment-401541163