Subject: [quicwg/base-drafts] Remove PATH_RESPONSE limits (#2241)

From: Martin Thomson <[email-masked]>
Date: Thu, 20 Dec 2018 21:19:44 -0800

Implementations can do this anyway, so we're not getting much from the
recommendation.  And we already have good limits on what can be sent
(including PATH_RESPONSE) in the migration section.

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

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

-- Commit Summary --

  * Remove PATH_RESPONSE limits

-- File Changes --

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

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/2241.patch
https://github.com/quicwg/base-drafts/pull/2241.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/2241

---

From: MikkelFJ <[email-masked]>
Date: Fri, 21 Dec 2018 01:33:07 -0800

> An endpoint MAY bundle PATH_CHALLENGE and PATH_RESPONSE frames that are used for path validation with other frames. In particular, an endpoint may pad a packet carrying a PATH_CHALLENGE for PMTU discovery, or an endpoint may bundle a PATH_RESPONSE with its own PATH_CHALLENGE.

This can lead to amplification attack if not careful.

-- 
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/2241#issuecomment-449331995

---

From: janaiyengar <[email-masked]>
Date: Fri, 21 Dec 2018 12:37:05 -0800

@mikkelfj: how can this lead to amplification?

-- 
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/2241#issuecomment-449492442

---

From: janaiyengar <[email-masked]>
Date: Fri, 21 Dec 2018 12:37:13 -0800

janaiyengar 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/2241#pullrequestreview-187531611

---

From: MikkelFJ <[email-masked]>
Date: Fri, 21 Dec 2018 12:53:24 -0800

> @mikkelfj: how can this lead to amplification?

If an endpoint seeing a challenge uses the opportunity to discover if its preferred MTU is supported by padding the response (as opposed to the challenge) even if the challenge packet is small. Since this might fail, it like will also send a small response after a delay or after a new challenge if it doesn't get an ACK before that.

A defence could be to ensure that challenges are no larger than, say twice, response.

-- 
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/2241#issuecomment-449495690

---

From: MikkelFJ <[email-masked]>
Date: Fri, 21 Dec 2018 12:55:36 -0800

An endpoint may also optimistically bundle all kinds of other data in a response. Even with 1200 bytes, this can be much larger than a small challenge packet without considering PMTU discovery at all.

-- 
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/2241#issuecomment-449496165

---

From: MikkelFJ <[email-masked]>
Date: Fri, 21 Dec 2018 12:58:28 -0800

I think I raised this issue quite a while ago this is the reason the limit was introduced, although I didn't formulate the exact counter measure.

-- 
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/2241#issuecomment-449496716

---

From: ianswett <[email-masked]>
Date: Fri, 21 Dec 2018 13:17:33 -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/2241#pullrequestreview-187541219

---

From: Martin Thomson <[email-masked]>
Date: Sun, 23 Dec 2018 20:06:27 -0800

The counter measure we have against amplification is the initial congestion window.  We won't send more than that.  That's higher than the x3 we have during the handshake, but I think that's a reasonable balance, considering that the attacker in this context has to spend a considerable amount of effort.

Yes, this is a policy question, but I'm happy with it.  (Though we should probably highlight this when asking for review.)

-- 
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/2241#issuecomment-449683536

---

From: Martin Thomson <[email-masked]>
Date: Sun, 23 Dec 2018 20:06:33 -0800

Merged #2241 into master.

-- 
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/2241#event-2042722004