Subject: [quicwg/base-drafts] Recommend discarding bad, unauthentication packets (#2141)

From: Martin Thomson <[email-masked]>
Date: Wed, 12 Dec 2018 22:57:11 -0800

We already have piecemeal recommendations for discarding in certain circumstances, but a blanket allowance for dropping packets will allow endpoints to do all sorts of nice things if they want better DoS resilience.

This leaves the existing requirements in place.  Some of those are more directly the result of stronger requirements (like the ones against off-path attacks).  This is just a license to back out changes that are made as a result of bad packets.

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

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

-- Commit Summary --

  * Recommend discarding bad, unauthentication packets

-- File Changes --

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

-- Patch Links --

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

---

From: Marten Seemann <[email-masked]>
Date: Wed, 12 Dec 2018 23:02:26 -0800

marten-seemann approved this pull request.

Do we need to describe what we mean by "invalid 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/pull/2141#pullrequestreview-184523169

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 12 Dec 2018 23:34:55 -0800

kazuho commented on this pull request.

> @@ -1000,6 +1000,12 @@ to more quickly identify when a connection becomes unusable.
 Packets that are matched to an existing connection, but for which the endpoint
 cannot remove packet protection, are discarded.
 
+Invalid packets without packet protection, such as Initial, Retry, or Version
+Negotiation, SHOULD be discarded without altering connection state.  An endpoint

I tend to agree with @marten-seemann. I wonder if we might rather say MAY here (or "can"), because people might wonder what the anticipated behavior is, without the definition of what "invalid" means (does it mean a packet with a broken encoding? or does it mean a frame containing a semantically invalid frame; i.e. ACK containing a PN that was never used); and my understanding is that we do not want to define "invalid."

-- 
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/2141#pullrequestreview-184530534

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 12 Dec 2018 23:36:59 -0800

I tend to agree with @marten-seemann. I wonder if we might rather say MAY here (or "can"), because people might wonder what the anticipated behavior is, without the definition of what "invalid" means.

Does it mean a packet with a broken encoding? Or does it mean a frame containing a semantically invalid frame; i.e. ACK containing a PN that was never used?

My understanding is that we do not want to define "invalid", hence the suggestion to use a weaker word.

-- 
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/2141#pullrequestreview-184531046

---

From: MikkelFJ <[email-masked]>
Date: Thu, 13 Dec 2018 01:37:04 -0800

> Do we need to describe what we mean by "invalid packets"?

No, the spec defines expected behaviour and deviations from that would be invalid. We are not trying to make partial recovery and we are not trying to convey information in error messages.

-- 
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/2141#issuecomment-446902909

---

From: ekr <[email-masked]>
Date: Thu, 13 Dec 2018 03:56:44 -0800

ekr commented on this pull request.

I'm not sure this is generally a good idea. Consider the case where we have a packet with two frames. (1) a perfectly legitimate stream frame (2) a frame that is misformatted but generally parseable and doesn't otherwise require connection termination. Why is the sensible procedure here to (a) keep the connection alive but (b) ignore the stream data?

-- 
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/2141#discussion_r241372642

---

From: ianswett <[email-masked]>
Date: Thu, 13 Dec 2018 06:44:41 -0800

ianswett commented on this pull request.

Initials are the only packets on the list with multiple frames, and they are AES-GCM encrypted, so an invalid frame indicates a buggy peer or an injection attack.  In both cases parsing part of the packet seems unwise.

Also, if you only process one frame, do you ACK that packet?

-- 
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/2141#discussion_r241425018

---

From: ekr <[email-masked]>
Date: Thu, 13 Dec 2018 07:05:43 -0800

@ianswett what's our rule here for the same defective packet if it were received protected? 

-- 
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/2141#discussion_r241433699

---

From: MikkelFJ <[email-masked]>
Date: Thu, 13 Dec 2018 07:49:16 -0800

mikkelfj commented on this pull request.

I'm not Ian ... but you can't close a connection on valid AEAD but i'll formatted content unless you have advanced the handshake sufficiently due to injection attacks. There is explicit text for a variety of cases already. The current PR covers the rest.

-- 
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/2141#discussion_r241452961

---

From: ekr <[email-masked]>
Date: Thu, 13 Dec 2018 07:55:55 -0800

@mikkelfj well, that's exactly what we're discussing. And given that we don't have a threat model for this class of attack, I'm not sure that that's true 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/2141#discussion_r241455987

---

From: MikkelFJ <[email-masked]>
Date: Thu, 13 Dec 2018 08:02:25 -0800

When I say can't close, I mean you should drop packets. Or close if you already affected state as the PR says - even if injection because you can no longer trust yourself - therefore you need to validate carefully before applying state, especially during handshake. You definitely shouldn't try to recover.

That said, perhaps we need to clarify exactly when we switch from dropping to closing. You need to have established a secure line of communication. Bogus TLS can be injection attacks as well as endpoint sourced nonsense.

-- 
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/2141#discussion_r241458778

---

From: ianswett <[email-masked]>
Date: Thu, 13 Dec 2018 13:12:12 -0800

If it was protected, we'd close the connection.

-- 
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/2141#discussion_r241562773