Subject: [quicwg/base-drafts] Reliable identification of the initial packet for a connection (#185)

From: Igor Lubashev <[email-masked]>
Date: Fri, 20 Jan 2017 15:57:27 -0800

Some path elements may need to statelessly identify an initial packet of a connection. These path elements could include load balancers and organization's border security systems.  Ability to identify the initial packet may also be required for systems implementing Stateless Rejects #60.

Since QUIC allows for packet number truncation, the most straightforward way to identify the initial packet is by checking for packet number 1 and VERSION flag set.

Hence:

- The language of section 6.1 Version Negotiation would need to change SHOULD to MUST in "All subsequent packets sent by the client SHOULD have the VERSION flag unset".
- Section 6.1 Version Negotiation should also gain language like: "If Version negotiation is not complete in 2^6 packets, any endpoint MAY reset this connection".  (This is a weaker statement than #143.)
- Proposal in issue #35 is not compatible with this issue. If packet numbers are allowed to be deliberately skipped, we should require that packets with VERSION set MUST NOT be skipped.

-- 
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/185

---

From: Mike Bishop <[email-masked]>
Date: Fri, 20 Jan 2017 16:17:15 -0800

You're entirely correct that #35 is not compatible, but it's more fundamental:  This issue suggests that we make it possible to identify and act on a particular packet when you're not a party to the connection; #35 suggests making it more difficult to act on and therefore ossify an exposed protocol element.

I suspect you'll need to back up and motivate why we *want* to allow path elements to identify a particular packet in a connection.  "Some... may need to" isn't a justification.  My gut reaction is that load balancers at least should be statelessly operating on the connection ID itself, whether it's the first packet or the billionth.

-- 
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/185#issuecomment-274213866

---

From: Igor Lubashev <[email-masked]>
Date: Fri, 20 Jan 2017 17:31:49 -0800

> I suspect you'll need to back up and motivate why we want to allow path elements to identify a particular packet in a connection.

Certainly.  Let's take a load balancer system. Think [LVS](http://www.linuxvirtualserver.org/) or [Google Maglev](https://research.google.com/pubs/pub44824.html). These systems consist of multiple machines serving as load balancers, each with imperfect availability, and packets belonging to a single connection may arrive at different load balancer servers.

These load balancers are _not_ proxies. They are more like routers. They do not terminate connections but rather forward packets to the appropriate backend servers.

Load balancer's job is to:
a) For a new connection, select an appropriate server to handle it, and
b) Keep sending all packets that are a part of the connection to the same server, and
c) Keep doing (b) even if the set of machines eligible to serve new connections of this type changes dynamically (say, every second)

To do its job, at a minimum, the load balancer needs to identify new connections (a). Identifying first packet (subject of this issue) is trivial with TCP (SYN). It should be trivial with QUIC, too.

-- 
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/185#issuecomment-274222247

---

From: Igor Lubashev <[email-masked]>
Date: Sun, 22 Jan 2017 13:19:36 -0800

One more reason for changing SHOULD to MUST of section 6.1 Version Negotiation in "All subsequent packets sent by the client SHOULD have the VERSION flag unset".

In draft-ietf-quic-tls-01, _6.1.1. Initial Key Transitions_, we require:

> Packets protected with 1-RTT keys have a KEY_PHASE bit set to 1. These packets also have a VERSION bit set to 0.

If I understand it correctly, TLS 1-RTT keys should be available at the same time as the completion of the Version negotiation. So changing of SHOULD to MUST is mandated by draft-ietf-quic-tls-01 (6.1.1). Right?

-- 
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/185#issuecomment-274360476

---

From: ianswett <[email-masked]>
Date: Sun, 22 Jan 2017 15:54:46 -0800

If we want to make identification easier, I'd suggest when the version bit is set, we also include 4 fixed bytes that identify the protocol as QUIC.  I'd suggest the string QUIC, so it is easy to identify in wireshark as well.

I have mixed feelings on making it easier to identify UDP traffic QUIC, but I think it's going to be a thing people will do, so I'd rather have them latch onto an explicit signal than hardcode the version number or something worse.(public flags anyone...)

Two notes:
1) Initial packets from the client cannot have a truncated connection ID, because the peer has to inform you it's acceptable in the handshake.
2) There are proposals to randomize the initial packet number, so relying on it being packet number 1 would conflict with that.

-- 
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/185#issuecomment-274370899

---

From: Igor Lubashev <[email-masked]>
Date: Sun, 22 Jan 2017 17:04:13 -0800

The issue here is not identifying traffic as QUIC (it could be a different issue).

The issue is being able to identify new client connections statelessly (just by observing the packets).

This is needed for load balancers. As a load balancer I want to know whether I need to:
- pick a backend server for this connection (i.e. processing "TCP SYN" or "QUICK packet 1"), or
- try to identify which backend server is already handling this connection and forward the packet that way ("TCP ACK or RST" or "QUICK packet > 1").

This is especially important, since I would like to keep load balancers stateless and will want to use "Stateless Reject" to encode the load balancing decision for a particular connection. So I need to be able to statelessly identify initial packets and send "Stateless Reject" to them.

draft-ietf-quic-tls-01 already requires (6.1.1. Initial Key Transitions) that packets without 0-RTT protection have KEY_PHASE=0, VERSION=1; with 0-RTT have KEY_PHASE=1, VERSION=1; with 1-RTT have KEY_PHASE=1, VERSION=0.

So I would like to bring draft-ietf-quic-transport-01 is agreement with draft-ietf-quic-tls-01 and make setting VERSION=0 a MUST instead of SHOULD.

If there is a strong desire (for a good reason) to randomize the initial packet number, I think I can live with it, and send "Stateless Rejects" to all packets with KEY_PHASE=0, VERSION=1.

-- 
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/185#issuecomment-274375420

---

From: mirjak <[email-masked]>
Date: Mon, 23 Jan 2017 12:24:38 -0800

I still don't see why you need to identify the first packet. Isn't for a load balancer simply the first packet of a connection the first ones it sees when it doesn't have a mapping yet? And if the load balancers change dynamically, don't you have to sync state anyway all the time?

-- 
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/185#issuecomment-274606112

---

From: Igor Lubashev <[email-masked]>
Date: Mon, 23 Jan 2017 15:06:31 -0800

That would be true for a completely stateful load balancer. And that's exactly the kind of load balancing system I'd like to avoid having to build -- a system that requires all nodes to be completely in sync and aware of all connections real-time.

This system is very expensive (CPU and bandwidth), especially when you think global scale (not just in-datacenter). And it may not work very reliably anyway due to packets for a single connection arriving very quickly, since if packet 1 and 2 arrive at different nodes, there may had been not enough time for all nodes to get in sync.  If you try to fix the previous problem by adding a request-response mechanism for connections you do not know about, you need to worry about your vulnerability to an attack with random packets, all of which may need to go through this expensive request-response. And simply setting up rate limiting on request-response to deal with attacks would not work, since there could be legitimate events that could cause a ton of traffic shifting load balancers all together even in a well-designed system (think BGP change for a global load balancer or a server crash for a local one).

A little more on this in issue #205.

(Our current system for TCP is "mostly stateless".)

-- 
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/185#issuecomment-274646981

---

From: Martin Thomson <[email-masked]>
Date: Mon, 23 Jan 2017 20:29:19 -0800

@ianswett, do you want that four bytes AND #167?

-- 
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/185#issuecomment-274706988

---

From: ianswett <[email-masked]>
Date: Tue, 24 Jan 2017 05:17:27 -0800

I think it was mentioned today that this is no longer an issue, is that correct @igorlord ?

-- 
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/185#issuecomment-274799965

---

From: Igor Lubashev <[email-masked]>
Date: Tue, 24 Jan 2017 16:07:00 -0800

@ianswett Yes. It seems resolved for now, although there are proposals (like #203) that may need reopening this issue.

-- 
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/185#issuecomment-274979887