Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Tolerate unknown stream types, add greasing #1525

Merged
merged 5 commits into from
Jul 6, 2018
Merged

Tolerate unknown stream types, add greasing #1525

Changes from all commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
e547427
Tolerate unknown stream types
MikeBishop Jul 5, 2018
2cf8b43
Prohibit speculative stream type use that modifies core protocol
MikeBishop Jul 6, 2018
9d5a550
Discuss padding in Security Considerations
MikeBishop Jul 6, 2018
7deb076
Loosen prohibition on unknown stream types further
MikeBishop Jul 6, 2018
4459244
Multiply for IANA
MikeBishop Jul 6, 2018
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
53 changes: 42 additions & 11 deletions draft-ietf-quic-http.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -492,16 +492,32 @@ this header is determined by the stream type.
~~~~~~~~~~
{: #fig-stream-header title="Unidirectional Stream Header"}

Two stream types are defined in this document: control streams
({{control-streams}}) and push streams ({{server-push}}). Other stream types
can be defined by extensions to HTTP/QUIC.
Some stream types are reserved ({{stream-grease}}). Two stream types are
defined in this document: control streams ({{control-streams}}) and push streams
({{server-push}}). Other stream types can be defined by extensions to
HTTP/QUIC.

If the stream header indicates a stream type which is not supported by the
recipient, this SHOULD be treated as a stream error of type
HTTP_UNKNOWN_STREAM_TYPE. The semantics of the remainder of the stream are
unknown. Implementations SHOULD NOT send stream types the peer is not already
known to support, since a stream error can be promoted to a connection error at
the peer's discretion (see {{errors}}).
recipient, the remainder of the stream cannot be consumed as the semantics are
unknown. Recipients of unknown stream types MAY trigger a QUIC STOP_SENDING
frame with an error code of HTTP_UNKNOWN_STREAM_TYPE, but MUST NOT consider such
streams to be an error of any kind.

Implementations MAY send stream types before knowing whether the peer supports
them. However, stream types which could modify the state or semantics of
existing protocol components, including QPACK or other extensions, MUST NOT be
sent until the peer is known to support them.

### Reserved Stream Types {#stream-grease}

Stream types of the format `0x1f * N` are reserved to exercise the requirement
that unknown types be ignored. These streams have no semantic meaning, and can
be sent when application-layer padding is desired. They MAY also be sent on
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What do you mean by application-layer padding in this case? If this is some property of the mapping that can be used to add additional padding to QUIC's PADDING frames then is it worth pointing out in security considerations?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps. HTTP/2 allowed padding on the HEADERS and DATA frames, to make analysis of the traffic more difficult. QUIC can pad individual packets to different / uniform sizes, but I'm assuming that most stacks won't generate traffic where none exists. An application layer can make analysis more difficult by sending traffic even when no requests are happening.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok so I get the problem, this is more like a background level of noise.

I guess I had been expecting transport libraries to handle packing and padding with some influence from the application. It wouldn't be a stretch for them to provide an API that would allow the caller to declare a background level of traffic, however the transport won't have any stream to send this on.

In that case, I like the side effect of this.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added a mention in Security Considerations.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Padding using bogus frames might work, but there are two problems with this:

  1. Not all streams use frames.
  2. Padding that uses bogus unidirectional streams isn't guaranteed to be placed in the same packet as the data that it pads.

connections where no request data is currently being transferred. Endpoints MUST
NOT consider these streams to have any meaning upon receipt.

The payload and length of the stream are selected in any manner the
implementation chooses.

### Control Streams

Expand Down Expand Up @@ -1424,7 +1440,10 @@ Error codes need to be defined for HTTP/2 and HTTP/QUIC separately. See
# Security Considerations

The security considerations of HTTP over QUIC should be comparable to those of
HTTP/2 with TLS.
HTTP/2 with TLS. Note that where HTTP/2 employs PADDING frames to make a
connection more resistant to traffic analysis, HTTP/QUIC can rely on QUIC's own
PADDING frames or employ the reserved frame and stream types discussed in
{{frame-grease}} and {{stream-grease}}.

The modified SETTINGS format contains nested length elements, which could pose
a security risk to an uncautious implementer. A SETTINGS frame parser MUST
Expand Down Expand Up @@ -1508,8 +1527,8 @@ The entries in the following table are registered by this document.
| ---------------- | ------ | -------------------------- |

Additionally, each code of the format `0xb + (0x1f * N)` for values of N in the
range (0..7) (that is, `0xb`, `0x2a`, etc., through `0xe4`), the following
values should be registered:
range (0..7) (that is, `0xb`, `0x2a`, `0x49`, `0x68`, `0x87`, `0xa6`, `0xc5`,
and `0xe4`), the following values should be registered:

Frame Type:
: Reserved - GREASE
Expand Down Expand Up @@ -1651,6 +1670,18 @@ The entries in the following table are registered by this document.
| Push Stream | 0x50 | {{server-push}} | Server |
| ---------------- | ------ | -------------------------- | ------ |

Additionally, for each code of the format `0x1f * N` for values of N in the
range (0..8) (that is, `0x00`, `0x1f`, `0x3e`, `0x5d`, `0x7c`, `0x9b`, `0xba`,
`0xd9`, `0xf8`), the following values should be registered:

Stream Type:
: Reserved - GREASE

Specification:
: {{stream-grease}}

Sender:
: Both

--- back

Expand Down