Subject: [quicwg/base-drafts] Invalid CONNECTION_CLOSE frames (#2475)

From: martinduke <[email-masked]>
Date: Fri, 15 Feb 2019 09:46:59 -0800

Section 11.1 says:
"An endpoint that receives an invalid CONNECTION_CLOSE frame MUST NOT signal the existence of the error to its peer."

Editorially, it is not clear to me whether I am to suppress the error code in the CONNECTION_CLOSE frame or the error I generate when I receive an invalid frame.

Moreover, I am not sure what constitutes an invalid CONNECTION_CLOSE frame. The words don't occur elsewhere. Section 19.19 doesn't define any fatal errors for this type. I can imagine a Reason Length that overruns the packet, or perhaps an undefined error code? A bogus frame type? We should probably define those in 19.19.

Perhaps this sentence is an artifact from before we were throwing away Initial keys agressively?

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

---

From: MikkelFJ <[email-masked]>
Date: Fri, 15 Feb 2019 09:50:50 -0800

If you suppress the error, does it matter which error you do not send?

-- 
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/2475#issuecomment-464139377

---

From: martinduke <[email-masked]>
Date: Fri, 15 Feb 2019 10:00:39 -0800

I'm not sure what the intent of the sentence is. Do I send PROTOCOL_VIOLATION but not the error code in the frame? Do I send nothing?

-- 
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/2475#issuecomment-464142585

---

From: MikkelFJ <[email-masked]>
Date: Fri, 15 Feb 2019 10:10:44 -0800

As I read it, you should not send anything if you see CONNECTION_CLOSE.

As to the motivation, I'm not quite sure, but if the peer closes but does it badly, chances are that anything you send just results in stateless resets. Maybe there can also be some malicious intend, especially in early handshake, but I don't think that is the reason.

-- 
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/2475#issuecomment-464145642

---

From: Mike Bishop <[email-masked]>
Date: Fri, 15 Feb 2019 10:58:11 -0800

I *think* this is addressing the injected packet case -- if you ignore an injected CONNECTION_CLOSE, you shouldn't send the real peer anything about it, or you've just allowed an attacker to inject authenticated traffic in 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/issues/2475#issuecomment-464160681

---

From: Martin Thomson <[email-masked]>
Date: Sun, 17 Feb 2019 11:33:47 -0800

This is more about the looping case: sending CONNECTION_CLOSE in response to CONNECTION_CLOSE.  But it is badly worded.

-- 
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/2475#issuecomment-464498811

---

From: Roni Even <[email-masked]>
Date: Mon, 18 Feb 2019 06:43:15 -0800

>From the current text in 10.3

After sending a CONNECTION_CLOSE frame, endpoints immediately enter the closing state.  During the closing period, an endpoint that sends a CONNECTION_CLOSE frame SHOULD respond to any packet that it receives with another packet containing a CONNECTION_CLOSE frame.  To minimize the state that an endpoint maintains for a closing  connection, endpoints MAY send the exact same packet.

This will be a loop  since the same invalid packet will be sent again by the sender ....

-- 
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/2475#issuecomment-464756141