Re: [quicwg/base-drafts] WIP: Begin lightly abstracting over the use of UDP as the underlying transport (#4043)

[Mike Bishop <[e-mail]>]

@MikeBishop commented on this pull request.

An interesting foray.  I think this generalizes some pieces that really are UDP-specific, and would need to be redefined (or at least reconsidered) in other aspects.

> @@ -1902,10 +1917,12 @@ that are uniquely attributed to a single connection. This includes datagrams
 that contain packets that are successfully processed and datagrams that contain
 packets that are all discarded.
 
-Clients MUST ensure that UDP datagrams containing Initial packets have UDP
-payloads of at least 1200 bytes, adding padding to packets in the datagram as
-necessary. A client that sends padded datagrams allows the server to send more
-data prior to completing address validation.
+Clients MUST ensure that underlying transports datagrams containing Initial
+packets have payloads of at least 1200 bytes, adding padding to packets in the
+datagram as necessary. (The payload is the assembled QUIC packets, and does not
+include any headers associated with the underlying protocol that are also part
+of the datagram.) A client that sends padded datagrams allows the server to send
+more data prior to completing address validation.

I feel like the anti-amplification features -- minimum initial size, the 3x limit, etc. -- really are UDP-focused because they mitigate attacks we know are common with UDP.  A different transport might have such concerns, or might not.  Perhaps, rather than generalizing these requirements, we should instead condition them on UDP.

> @@ -2526,13 +2543,16 @@ routing of packets across multiple network paths will also allow activity on
 those paths to be linked by entities other than the peer.
 
 A client might wish to reduce linkability by employing a new connection ID and
-source UDP port when sending traffic after a period of inactivity.  Changing the
-UDP port from which it sends packets at the same time might cause the packet to
-appear as a connection migration. This ensures that the mechanisms that support
-migration are exercised even for clients that do not experience NAT rebindings
-or genuine migrations.  Changing port number can cause a peer to reset its
-congestion state (see {{migration-cc}}), so the port SHOULD only be changed
-infrequently.
+source address when sending traffic after a period of inactivity.  (In
+conventional situations using UDP, the client cannot freely vary the IP address,

With IPv6 privacy addresses, this might not be true.

> +conventional situations using UDP, the client cannot freely vary the IP address,
+but can much more readily change the UDP port.  Since an address for QUIC when
+using UDP is the tuple of the IP address and UDP port, changing the source port
+along constitutes changing the QUIC address.) So changing the address from which
+it sends packets at the same time might cause the packet to appear as a
+connection migration.  This ensures that the mechanisms that support migration

This seems really wordy explaining why this is useful for UDP while still trying to generalize.  You already changed the specific of UDP port to "source address"; probably all you need to add is that "When the underlying transport protocol is UDP, changing the source port is sufficient."

It might also be the case that changing the source address isn't possible with the alternate transport, so this is an "if supported by the underlying protocol" thing.  (For that matter, the CID itself might be irrelevant on a transport where addresses can't change.)

> @@ -3205,6 +3230,29 @@ Packets with the short header are designed for minimal overhead and are used
 after a connection is established and 1-RTT keys are available; see
 {{short-header}}.
 
+## Underlying Transport Protocol {#underlying-transport-protocol}
+
+The underlying protocol is the protocol with which QUIC packet are sent.

```suggestion
The underlying protocol is the protocol over which QUIC packets are sent.
```

> +The underlying protocol MUST contain both a source and destination address:
+while the underlying protocol is free to route datagrams by whichever means it
+chooses, and futhermore a source address isn't strictly necessary to route a
+datagram, the QUIC implementation needs to be able to inspect both addresses for
+to implement connection migration.

```suggestion
The underlying protocol MUST contain both a source and destination address,
as the QUIC implementation needs to be able to inspect both addresses in
order to support connection migration.
```

> +An underlying datagram MUST correspond to a single IP packet, if it is sent over
+IP.  That means IP fragmentation MUST NOT be used.  When using IPv4
+({{!IPv4=RFC0791}}), the DF bit MUST be set to prevent fragmentation on the
+path.

I'm not certain QUIC generically has this requirement across all underlying transports.  The requirement is that datagrams be delivered whole to QUIC; if they were fragmented and reassembled along the way, that's irrelevant.  For UDP, we don't fragment because we want to be able to assess the maximum packet size; for some other transport, we might be able to query the maximum size directly or have effectively-infinite maximum size.

In fact, given the way encryption overhead decreases with larger units of encryption, we might find that very large datagrams perform really well in certain environments with certain transports, even in the presence of fragmentation.

> +The QUIC packet size is just the total size of the QUIC header and protected
+payload. It follows that the sizes of any other headers that are part of the
+underlying datagram and associated with underlying protocols are not counted.

```suggestion
The QUIC packet size includes the QUIC header and protected payload, but not the
headers of any underlying protocol.
```

> @@ -4030,12 +4086,16 @@ address of the client; see {{address-validation}}.
 
 ## Path Maximum Transmission Unit

Much of the work referenced here is specific to UDP.  I'd leave this as UDP-specific and merely note that a QUIC implementation on a different transport might need to use similar techniques to learn the properties of the path.

>  : The maximum UDP payload size parameter is an integer value that limits the
-  size of UDP payloads that the endpoint is willing to receive.  UDP packets
-  with payloads larger than this limit are not likely to be processed by the
-  receiver.
+  size of underlying datagram payloads that the endpoint is willing to receive.
+  Datagrams with payloads larger than this limit are not likely to be processed

A parameter that's specifically named UDP doesn't tell you anything about other underlying protocols.  Either the parameter becomes generic (i.e. renamed, perhaps `max_datagram_size`) or it remains specific to UDP and other parameters might be defined for other contexts.

> @@ -6669,7 +6736,7 @@ attacker to establish connectivity on a given path.
 An on-path attacker can:
 
 - Inspect packets
-- Modify IP and UDP packet headers
+- Modify underlying transport headers (e.g. UDP and IP headers)

Here again, it's really going to depend on what that underlying transport is.  This security analysis assumes UDP/IP; I think the safest statement is that QUIC over another transport needs its own security analysis to see what attackers might be able to do.

> @@ -3205,6 +3230,29 @@ Packets with the short header are designed for minimal overhead and are used
 after a connection is established and 1-RTT keys are available; see
 {{short-header}}.
 
+## Underlying Transport Protocol {#underlying-transport-protocol}
+
+The underlying protocol is the protocol with which QUIC packet are sent.
+
+This protocol SHOULD NOT have automatic retransmission, ordering, congestion
+control, or other such mechanisms that would overlap with those provided by QUIC
+and therefore not actually enhance the overall quality of service.  This
+protocol SHOULD be message-oriented.

Personally, I'm reviewing this through the mental model of two additional transports:
- Message-based Websockets across an HTTP proxy
- Local datagram sockets for IPC

Websockets are clearly going to provide all those services which an underlying transport SHOULD NOT have, but that's just the suck you live with if that's your only way to speak QUIC to an endpoint.  Local sockets, on the other hand, mean that a lot of the machinery within QUIC simply won't be needed -- but if you're porting over a protocol that's already built atop QUIC, that might be okay.

-- 
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/pull/4043#pullrequestreview-472519287