Subject: Transport Draft Comments, mostly about error handling

From: Martin Duke <[email-masked]>
Date: Fri, 18 Aug 2017 11:37:49 -0700

I'm deep into implementing the handler for a stream frame straight from the
-05 spec, and there seem to be a lot of ambiguities in the errors, as well
as things that should probably be prohibited:

(1) Section 8.14. Stream Frames for Stream 1 and above MUST NOT be in
Cleartext packets of any kind.

(2) Section 12.2 Stream Errors: We need to have some sort of special
considerations for handshake, especially cleartext packets. In particular,
any sort of cleartext packet that triggers an error should be dropped
rather than causing RST_STREAM or CONNECTION_CLOSE. Otherwise it is
trivially easy for a man-on-the-side to abort connections.

I believe, by the same logic, that bad 0RTT packets should simply be
dropped rather than reset.

As I see it, there are two possible responses to problems processing the
stream frame, each appropriate to different situations:
  - Internal error that doesn't break the stream (e.g. failure to allocate
memory for the stream reassembly queue element): drop the packet -- make
the peer retransmit and hope it works next time. Also do this for errors in
cleartext.
  - a stream error that still allows the receiver to find the end of the
frame (e.g. STREAM_STATE_ERROR). Send a RST_STREAM for that stream,but keep
processing the packet.

If this analysis is correct, it would be nice to specify it in the draft
explicity.

(4) Section 12. Error Handling: If a peer initiates an odd stream when it's
supposed to be even, or vice versa, what kind of error is that? Is it a
stream error or connection error?

(5) Section 12.3 Error Codes: For a Frame Error on a STREAM or ACK frame,
is the last two bytes of the error code the whole flags byte of the packet,
or just the mask (0xa0, 0xb0) of the frame type?

If I am not way off base on some or all of these points, I am happy to
create issues or PRs.

Martin Duke

---

From: Ryan Hamilton <[email-masked]>
Date: Fri, 18 Aug 2017 15:22:29 -0700

On Fri, Aug 18, 2017 at 11:37 AM, Martin Duke <[email-masked]>
wrote:

> I'm deep into implementing the handler for a stream frame straight from
> the -05 spec, and there seem to be a lot of ambiguities in the errors, as
> well as things that should probably be prohibited:
>

​While I'm with you in spirit, I'm not sure about this. One downside of
such an approach is it means that if the peer is actually broken, the local
endpoint must keep the connection alive until it finally decides to abort
the handshake. I'm not sure how desirable this as. As for attackers, I
suspect it's just as easy to close the connection will a well-formed packet
than it is with a malformed packet.

> (4) Section 12. Error Handling: If a peer initiates an odd stream when
> it's supposed to be even, or vice versa, what kind of error is that? Is it
> a stream error or connection error?
>

---

From: Martin Thomson <[email-masked]>
Date: Mon, 21 Aug 2017 16:24:19 +1000

On 19 August 2017 at 08:22, Ryan Hamilton <[email-masked]> wrote:
>> any sort of cleartext packet that triggers an error should be dropped rather
>> than causing RST_STREAM or CONNECTION_CLOSE. Otherwise it is trivially easy
>> for a man-on-the-side to abort connections.
>
>
> While I'm with you in spirit, I'm not sure about this. One downside of such
> an approach is it means that if the peer is actually broken, the local

The minutes from the Prague meeting should show that we agreed that we
would rely on protection against off-path attackers only when it came
to disrupting the handshake.

---

From: Martin Thomson <[email-masked]>
Date: Mon, 21 Aug 2017 16:27:31 +1000

> Cleartext packets of any kind.

That should be in the -tls draft (though it will eventually move to -transport).

> stream error or connection error?

Since all stream opening uses authenticated packets, I think that
connection error is appropriate.  Also, I don't know how to recover
from this situation gracefully, particularly if the numbers collide.
That said, it makes the h2 settings situation bad.

> (5) Section 12.3 Error Codes: For a Frame Error on a STREAM or ACK frame, is
> the last two bytes of the error code the whole flags byte of the packet, or
> just the mask (0xa0, 0xb0) of the frame type?

The entire byte.  Thus, there are many error codes that represent
STREAM frame errors.  (I agree that that could be difficult, and it's
something I'd be happy to see someone open an issue on to track.)