Re: Transport Draft Comments, mostly about error handling

[Ryan Hamilton <[e-mail]>]

On Fri, Aug 18, 2017 at 11:37 AM, Martin Duke <[e-mail]>
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:
>
> (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.
>

​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.


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