Subject: [quicwg/base-drafts] Document request forgery by version negotiation (#4339)

From: Martin Thomson <[email-masked]>
Date: Thu, 05 Nov 2020 15:19:01 -0800

It&#39;s pretty bad.

Personally, I&#39;m still comfortable with it.  Server deployments are far
less likely to made without due consideration to the environment into
which they find themselves.

Closes #4258.
You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/4339

-- Commit Summary --

  * Document request forgery by version negotiation

-- File Changes --

    M draft-ietf-quic-transport.md (24)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/4339.patch
https://github.com/quicwg/base-drafts/pull/4339.diff

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

---

From: Marten Seemann <[email-masked]>
Date: Thu, 05 Nov 2020 19:42:30 -0800

> Server deployments are far less likely to made without due consideration to the environment into which they find themselves.

... unless you start considering p2p deployments.

-- 
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/4339#issuecomment-722792833

---

From: Martin Thomson <[email-masked]>
Date: Thu, 05 Nov 2020 19:49:32 -0800

Fair point; though I would suggest that p2p doesn't need version negotiation.  Once you have to do NAT traversal, you can also ensure that you don't have to ever send Version Negotiation.

-- 
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/4339#issuecomment-722795027

---

From: Marten Seemann <[email-masked]>
Date: Thu, 05 Nov 2020 20:01:23 -0800

I don't think that works in the general case. A node won't know if it's behind a NAT when it's started (it will learn after a while of interacting with other nodes). And even if you solve that problem, you'll need to do some extra work to communicate QUIC versions during hole punching.

-- 
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/4339#issuecomment-722798683

---

From: Martin Thomson <[email-masked]>
Date: Thu, 05 Nov 2020 20:17:27 -0800

@martinthomson commented on this pull request.

 * spoofed connection migrations ({{address-spoofing}}), where a client is able
   to use source address spoofing to select where a server sends subsequent
-  datagrams.
+  datagrams; and
+
+* spoofed packets that cause a server to send a Version Negotiation packet
+  {{vn-spoofing}}.
 
 In all three cases, the attacker can cause its peer to send datagrams to a

```suggestion
In all cases, the attacker can cause its peer to send datagrams to a
```

-- 
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/4339#pullrequestreview-524846324

---

From: Martin Thomson <[email-masked]>
Date: Thu, 05 Nov 2020 20:17:36 -0800

@martinthomson pushed 1 commit.

f4b66322e4fd168a040e3e171d5d8ab75347be5b  Counting

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/4339/files/0922e04f101a8bb3667f3f8c80c6dc0dadcb6011..f4b66322e4fd168a040e3e171d5d8ab75347be5b

---

From: Christian Huitema <[email-masked]>
Date: Fri, 06 Nov 2020 07:30:04 -0800

@huitema approved this pull request.

I agree that documenting the issue is the best we can do at this stage of the process. Short of ditching version negotiation altogether, but that would mean a long delay in delivering QUIC V1, and I don't think we want to go there.

> +### Request Forgery with Version Negotiation {#vn-spoofing}
+
+Clients that are able to present a spoofed source address on a packet can cause
+a server to send a Version Negotiation packet {{packet-version}} to that
+address.
+
+The absence of size restrictions on the connection ID fields for packets of an
+unknown version increases the amount of data that the client controls from the
+resulting datagram.  The first byte of this packet is not under client control
+and the next four bytes are zero, but the client is able to control up to 512
+bytes starting from the fifth byte.
+
+No specific countermeasures are provided for this attack, though generic
+protections {{forgery-generic}} could apply.  In this case, ingress filtering
+{{?BCP38}} is also effective.
+

I have been thinking about potential defenses, and I could not find something obvious there. Rate limiting does not help much, since this is not a volumetric attack. I think this text is about the best we can do.

-- 
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/4339#pullrequestreview-525256807

---

From: ianswett <[email-masked]>
Date: Fri, 06 Nov 2020 11:47:08 -0800

@ianswett approved this pull request.

-- 
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/4339#pullrequestreview-525444332

---

From: Jana Iyengar <[email-masked]>
Date: Fri, 06 Nov 2020 16:50:11 -0800

@janaiyengar approved this pull request.

Ugh. Yeah, this isn't great. I agree that we can lean on servers... but documenting this is super important. This is a pretty big hole... but I think it's ok to leave it as it is in this PR.

Let's leave this open for a while longer to ensure that it gets more visibility, and to see if anyone can come up with any other ideas.

-- 
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/4339#pullrequestreview-525572526