Subject: Re: [quicwg/base-drafts] Be more conservative about migration? (#2143)

From: Eric Kinnear <[email-masked]>
Date: Fri, 12 Jul 2019 15:46:35 -0700

Just to clarify what text I'm adding here, this is documenting our security stance towards attacks against migration, which things we think should be possible and which things we think should not be possible. (Which ekr can continue on into a section for QUIC in general.)

-- 
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/2143#issuecomment-511055734

---

From: Eric Kinnear <[email-masked]>
Date: Mon, 22 Jul 2019 22:08:28 -0700

The PR (so far) establishes the following definitions and guarantees:

### On-Path Attacker
An on-path attacker can:
- Inspect packets
- Modify unencrypted packet headers
- Inject new packets
- Delay packets
- Drop packets

An on-path attacker cannot:
- Modify encrypted packet payloads

### Off-Path Attacker
An off-path attacker can:
- Inspect packets
- Inject new packets

An off-path attacker cannot:
- Modify any part of a packet
- Delay packets
- Drop packets

### Limited Off-Path Attacker
A limited on-path attacker can:
- Inspect packets
- Inject new packets
- Modify unencrypted packet headers

A limited on-path attacker cannot:
- Delay packets beyond the original packet duration
- Drop packets
- Modify encrypted packet payloads

## Guarantees
### On-Path Attacker
1. An on-path attacker can interrupt a QUIC connection, causing it to fail if it cannot migrate to a new path that does not contain the attacker. This can be achieved by dropping all packets, modifying them so that they fail to decrypt, or other methods.
2. An on-path attacker can prevent migration to a new path for which the attacker is also on-path by causing path validation to fail on the new path.
3. An on-path attacker cannot prevent a client from migrating to a path for which the attacker is not on-path.
4. An on-path attacker can reduce the throughput of a connection by delaying packets or dropping them.

### Off-Path Attacker
1. An off-path attacker can race packets and attempt to become a “limited” on-path attacker.
2. An off-path attacker can cause path validation to succeed for forwarded packets with the source address listed as the off-path attacker as long as it can provide improved connectivity between the client and the server.
3. An off-path attacker cannot cause a connection to close.
4. An off-path attacker cannot cause migration to a new path to fail if it cannot observe the new path.
5. An off-path attacker can become a limited on-path attacker during migration to a new path for which it is also an off-path attacker.
6. An off-path attacker can become a limited on-path attacker by affecting shared NAT state such that it sends packets to the server from the same IP address and port that the client originally used.

### Limited Off-Path Attacker
1. A limited on-path attacker cannot cause an active connection to close.
2. A limited on-path attacker cannot cause an idle connection to close if the client is first to resume activity.
3. A limited on-path attacker can cause an idle connection to be deemed lost if the server is the first to resume activity.

There's more descriptive text in the PR, as well, covering in a bit more detail our expectations about capabilities of the attackers, pathologically worst-case behaviors they may engage in, etc.

-- 
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/2143#issuecomment-514055926

---

From: MikkelFJ <[email-masked]>
Date: Tue, 23 Jul 2019 03:47:46 -0700

I think there needs to be a distinction between observing off-path attackers and blind off-path attackers. A blind attacker can inject packets and for example try to force close a connection even if the traffic flow is not visible. Such an attacker is probably the most common.

-- 
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/2143#issuecomment-514158030

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 23 Jul 2019 08:45:21 -0700

Can we be careful with how we sue "off path" - I think this uses the term assuming some visibility of the packets. In many transport documents, we assume that an off-path attacker does not have a way to see the packets.

-- 
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/2143#issuecomment-514268056

---

From: Eric Kinnear <[email-masked]>
Date: Tue, 23 Jul 2019 08:54:28 -0700

Yes, sorry @gorryfair, I've got a reference to RFC 3552 in there but haven't updated to fully use the correct terminology yet. Will do, and I'll ping you to take another look to make sure I get the right ones in the right places. :)

-- 
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/2143#issuecomment-514271725