Subject: draft-tiesel-quic-unreliable-streams-01 - comments

From: Roni Even <[email-masked]>
Date: Wed, 1 Nov 2017 13:03:54 +0000

Hi,

I think support for unreliable streams is important for unidirectional and bi-directional streams and even if it is V2 we still need to take support for it into account. One use case is RTP over QUIC.

Small comments:

In section 4.2 " The loss of such a frame does not introduce state at the perceived receiver". If new streams are opened with higher stream ID,  it implicitly opens this one frame stream that was lost in the receiver. I think it still requires the sender to send a reliable FIN to close this stream.

In the security section " An active, on path attacker can drop selected frames " . What does it mean selected frames, the whole payload is encrypted.

Roni

________________________________

---

From: "Philipp S. Tiesel" <[email-masked]>
Date: Thu, 2 Nov 2017 21:49:50 +0100

Hi

> On 1. Nov 2017, at 14:03, Roni Even <[email-masked]> wrote:
> 
> Hi,
>  
> In section 4.2 “ The loss of such a frame does not introduce state at the perceived receiver”. If new streams are opened with higher stream ID,  it implicitly opens this one frame stream that was lost in the receiver. I think it still requires the sender to send a reliable FIN to close this stream.

You’re right. I overlooked this. – The draft says:
  Streams MUST be created in sequential order. Open streams can be used in
  any order. Streams that are used out of order result in lower-numbered
  streams in the same direction being counted as open.

I don’t know the rational behind this, but I think this is, besides the
complications for unreliable streams, unfortunate:
 - with unidirectional streams, this looks a little ambiguous.
 - it prevents the application in encode its own flags within the stream ID.

Can anyone tell me the reason for this MUST? 

I Put it on the ToDo-List for -02

> In the security section “ An active, on path attacker can drop selected frames “ . What does it mean selected frames, the whole payload is encrypted.

This is a little complicated:
 - Assume having “stream-as-a-message” streams with two different kins of messages sized A,B
 - Assume each message fits into one packet, but two messages will not fit
 - Assume one doesn't want to split packets to fill packets to MTU due to latency constrains
 => If an attacker know the inside protocol, the attacker can distinguish from the packet length wether it is an A or B kind message

To avoid this, one has to pad all packets… I should clarify this.

AVE!
  Philipp S. Tiesel / phils…
-- 
   {phils}--->---([email-masked])--->---(http://phils.in-panik.de)----,
      wenn w eine   aube ist dn      man au dran dre en                   |
           o     Schr        an muss     hc         h   (Kurt Schwitters) |
:wq!  <----(phone: +49-179-6737439)---<---(jabber: [email-masked])----'

---

From: Roni Even <[email-masked]>
Date: Sun, 5 Nov 2017 07:32:27 +0000

> -----Original Message-----
> From: Philipp S. Tiesel [mailto:[email-masked]]
> Sent: יום ה 02 נובמבר 2017 22:50
> To: Roni Even
> Cc: QUIC WG
> Subject: Re: draft-tiesel-quic-unreliable-streams-01 - comments
> 
> Hi
> 
> > I think support for unreliable streams is important for unidirectional and bi-
> directional streams and even if it is V2 we still need to take support for it into
> account. One use case is RTP over QUIC.
> >
> > Small comments:
> >
> > In section 4.2 “ The loss of such a frame does not introduce state at the
> perceived receiver”. If new streams are opened with higher stream ID,  it
> implicitly opens this one frame stream that was lost in the receiver. I think it
> still requires the sender to send a reliable FIN to close this stream.
> 
> > In the security section “ An active, on path attacker can drop selected
> frames “ . What does it mean selected frames, the whole payload is
> encrypted.
> 
>  - Assume one doesn't want to split packets to fill packets to MTU due to
> latency constrains  => If an attacker know the inside protocol, the attacker
> can distinguish from the packet length wether it is an A or B kind message
> 
[Roni Even] I understand this case but what does selected frames mean, I assume that the attacker does not know what is in each stream in order to select a specific one, so why will he just drop one and not the other or why not both?

---

From: "Philipp S. Tiesel" <[email-masked]>
Date: Mon, 6 Nov 2017 10:14:49 +0100

> On 5. Nov 2017, at 08:32, Roni Even <[email-masked]> wrote:

Assuming the attacker _knows the protocol_, the attacker would also know the sizes of all kinds of messages and may use this knowledge to recover protocol state or selectively drop messages.

For a protocol like HTTP, the attack vector is rather small.
If one uses this against video conferencing applications, an attacker could prevent rate adaption  by dropping reception reports (larger than a pure QUIC ACK, smaller than a video frame).
If one uses this on IoT control stuff, an attacker might be able to learn a lot about the system state by observing sizes and timings.

This is nothing we can fix within QUIC without massive scarifies, but application developers must keep in mind.

AVE!

---

From: Ingemar Johansson S <[email-masked]>
Date: Tue, 7 Nov 2017 07:40:43 +0000

Hi Philip and Roni

I assume that by reception reports is meant the RTCP CCM messages such as TMMBR or ?

So.. unless I misunderstood it completely.
I am not at all convinced that media rate/congestion control in QUIC should rely on TMMBR.
SCReAM for instance, specified in the RMCAT WG for instance does not depend on TMMBR as it is ACK clocked, the media transmission is reduced to a very low rate if the ACKs are discarded by an attacker.

I would say that it is more straightforward to use a multipurpose congestion control in QUIC, this is perhaps based on BBR, but SCReAM style is not excluded. In any case this means that it is not possible to prevent rate adaptation.

/Ingemar

From: Philipp S. Tiesel [mailto:[email-masked]]
Sent: den 6 november 2017 10:15
To: Roni Even <[email-masked]>
Cc: QUIC WG <[email-masked]>
Subject: Re: draft-tiesel-quic-unreliable-streams-01 - comments

On 5. Nov 2017, at 08:32, Roni Even <[email-masked]<mailto:[email-masked]>> wrote:
From: Philipp S. Tiesel [mailto:[email-masked]]

On 1. Nov 2017, at 14:03, Roni Even <[email-masked]<mailto:[email-masked]>> wrote:
In the security section “ An active, on path attacker can drop selected
frames “ . What does it mean selected frames, the whole payload is
encrypted.
This is a little complicated:
- Assume having “stream-as-a-message” streams with two different kins of
messages sized A,B
- Assume each message fits into one packet, but two messages will not fit
- Assume one doesn't want to split packets to fill packets to MTU due to
latency constrains  => If an attacker know the inside protocol, the attacker
can distinguish from the packet length wether it is an A or B kind message

AVE!
  Philipp S. Tiesel / phils…
--
   {phils}--->---([email-masked]<mailto:[email-masked]>)--->---(http://phils.in-panik.de)----,
      wenn w eine   aube ist dn      man au dran dre en                   |
           o     Schr        an muss     hc         h   (Kurt Schwitters) |
:wq!  <----(phone: +49-179-6737439)---<---(jabber: [email-masked]<mailto:[email-masked]>)----'

---

From: Roni Even <[email-masked]>
Date: Tue, 7 Nov 2017 11:50:12 +0000

Hi Ingemar,
It is not CCM the attacker just does heuristics to understand that this is not media but report (RTCP or ACK frames) and drops it, BTW: audio packets may also be small.
This is an example. The claim is that you can use heuristics to drop “selected” frames even though you do not know what is in the packet.
Roni

From: Ingemar Johansson S [mailto:[email-masked]]
Sent: יום ג 07 נובמבר 2017 09:41
To: Philipp S. Tiesel; Roni Even
Cc: QUIC WG
Subject: RE: draft-tiesel-quic-unreliable-streams-01 - comments

Hi Philip and Roni

/Ingemar

From: Philipp S. Tiesel [mailto:[email-masked]]
Sent: den 6 november 2017 10:15
To: Roni Even <[email-masked]<mailto:[email-masked]>>
Cc: QUIC WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: draft-tiesel-quic-unreliable-streams-01 - comments

AVE!

---

From: Ingemar Johansson S <[email-masked]>
Date: Tue, 7 Nov 2017 14:47:57 +0000

Hi

OK, then I understand, maybe.. Still don’t get it, sorry. If you are about to selectively discard ACK packets, then the ACK spacing will become larger and the ACK clocking will be degraded. The end effect is that also the media (or whatever) that constitute the large packets will also get a degraded performance ?

I assume that we will still be running one congestion control for the connection ?

/Ingemar

From: Roni Even [mailto:[email-masked]]
Sent: den 7 november 2017 12:50
To: Ingemar Johansson S <[email-masked]>; Philipp S. Tiesel <[email-masked]>
Cc: QUIC WG <[email-masked]>
Subject: RE: draft-tiesel-quic-unreliable-streams-01 - comments

Hi Ingemar,

Hi Philip and Roni

/Ingemar

AVE!

---

From: "Philipp S. Tiesel" <[email-masked]>
Date: Tue, 7 Nov 2017 17:48:25 +0100

Hi,

the whole point came up in the security considerations of the draft:

	If one uses unreliable streams as-a-message to cut down
	delay, it is also necessary to send them out right away
	and don’t wait unit a MTU-sized packet is full.

	Despite encryption, this allows an attacker to learn about message
 	sizes and, assuming the protocol within the QUIC connection is known,
	might allow guessing what messages were used.
 
	One _example_ for such an attack was an hypothetical streaming protocol
	which an attacker can drop delivery reports for and thus could influence
	rate adaption.

I came to the conclusion this was not the best example for the message guessing attack.

> On 7. Nov 2017, at 15:47, Ingemar Johansson S <[email-masked]> wrote:
> 
> Hi
>  
> From: Ingemar Johansson S [mailto:[email-masked] <mailto:[email-masked]>] 
> From: Philipp S. Tiesel [mailto:[email-masked] <mailto:[email-masked]>] 
> To: Roni Even <[email-masked] <mailto:[email-masked]>>
> Cc: QUIC WG <[email-masked] <mailto:[email-masked]>>
> On 5. Nov 2017, at 08:32, Roni Even <[email-masked] <mailto:[email-masked]>> wrote:
> From: Philipp S. Tiesel [mailto:[email-masked] <mailto:[email-masked]>]
> 
> On 1. Nov 2017, at 14:03, Roni Even <[email-masked] <mailto:[email-masked]>> wrote:
> 
>    {phils}--->---([email-masked] <mailto:[email-masked]>)--->---(http://phils.in-panik.de <http://phils.in-panik.de/>)----,
> :wq!  <----(phone: +49-179-6737439)---<---(jabber: [email-masked] <mailto:[email-masked]>)----'

AVE!

---

From: Christian Huitema <[email-masked]>
Date: Tue, 7 Nov 2017 14:34:53 -0800

On 11/1/2017 6:03 AM, Roni Even wrote:

> Hi,
>
>  
>
> I think support for unreliable streams is important for unidirectional
> and bi-directional streams and even if it is V2 we still need to take
> support for it into account. One use case is RTP over QUIC.
>

I used to think that too, but I wonder whether something like RTP in
QUIC is best achieved by overloading the concept of streams, or by
defining a completely independent system, maybe using RTP and RTCP frame
types instead of regular streams types.

My main reason to say that is that regular stream data is more or less
treated as a byte stream, and RTP is not. The transport is free to send
stream data segments containing some of the stream's bytes, depending on
flow control, multiplexing conditions, packet size, etc. In contrast,
RTP data is sent as series of well delimited packets, each packet
corresponding to some well defined time slice of the media. Whatever
framing we use in QUIC will have to respect these packet boundaries.

Another reason has to do with forward error correction, which is
commonly applied to large video frames sent over several packets. Many
systems use packet-erasure-correction schemes, which rely on correctly
identifying which packet was lost -- or, in QUIC, which of the
video-carrying frames was lost. That would require some frame numbering
scheme. Some of that is probably best left to the application, but at a
minimum QUIC shall be able to respect frame boundaries. And that's
probably easier if the data is sent in some specialized RTP framing,
rather than as regular STREAM DATA frames.

>  
>
> Small comments:
>
>  
>
> In section 4.2 “ The loss of such a frame does not introduce state at
> the perceived receiver”. If new streams are opened with higher stream
> ID,  it implicitly opens this one frame stream that was lost in the
> receiver. I think it still requires the sender to send a reliable FIN
> to close this stream.
>
>  
>
> In the security section “ An active, on path attacker can drop
> selected frames“ . What does it mean selected frames, the whole
> payload is encrypted.
>

We probably need to assume that real time stream will be set up by the
application, using something like SIP or RTSP in conjunction with SDP.
The end of the real time stream could also be signaled by the
application in pretty much the same way.

Frankly, I don't think that we are ready to define RTP over QUIC right
now, as the priority is to finish the base spec. But what we can do is
experiment with extension mechanism. For example, define an experiment
in which QUIC that can carry RTP, and verify that we can use the various
extension mechanisms to field that. We might learn something about these
extension tools: version numbers, transport parameter negotiation, maybe
experimental frame types.

-- Christian Huitema

---

From: "Lubashev, Igor" <[email-masked]>
Date: Tue, 7 Nov 2017 23:34:59 +0000

I think an alternative to supporting a new packet transport within QUIC could be a new "MIN_STREAM_DATA" frame.  This frame indicates that nothing below this stream data offset will be retransmitted.

The application can periodically call setMinStreamData(offset), respecting any in-stream message boundaries that makes sense for the application.  If all data up to the offset has been acked, this is a noop. Otherwise, the transport drops any unacked bytes up to offset and sends MIN_STREAM_DATA.  This way, an application does not need to create a stream-per-message, paying no penalty in the usual case of all data delivered in time.

  *   Igor

From: Christian Huitema [mailto:[email-masked]]
Sent: Tuesday, November 07, 2017 5:35 PM
To: Roni Even <[email-masked]>; QUIC WG <[email-masked]>
Subject: Re: draft-tiesel-quic-unreliable-streams-01 - comments

I used to think that too, but I wonder whether something like RTP in QUIC is best achieved by overloading the concept of streams, or by defining a completely independent system, maybe using RTP and RTCP frame types instead of regular streams types.

My main reason to say that is that regular stream data is more or less treated as a byte stream, and RTP is not. The transport is free to send stream data segments containing some of the stream's bytes, depending on flow control, multiplexing conditions, packet size, etc. In contrast, RTP data is sent as series of well delimited packets, each packet corresponding to some well defined time slice of the media. Whatever framing we use in QUIC will have to respect these packet boundaries.

Another reason has to do with forward error correction, which is commonly applied to large video frames sent over several packets. Many systems use packet-erasure-correction schemes, which rely on correctly identifying which packet was lost -- or, in QUIC, which of the video-carrying frames was lost. That would require some frame numbering scheme. Some of that is probably best left to the application, but at a minimum QUIC shall be able to respect frame boundaries. And that's probably easier if the data is sent in some specialized RTP framing, rather than as regular STREAM DATA frames.

Small comments:

We probably need to assume that real time stream will be set up by the application, using something like SIP or RTSP in conjunction with SDP. The end of the real time stream could also be signaled by the application in pretty much the same way.

Frankly, I don't think that we are ready to define RTP over QUIC right now, as the priority is to finish the base spec. But what we can do is experiment with extension mechanism. For example, define an experiment in which QUIC that can carry RTP, and verify that we can use the various extension mechanisms to field that. We might learn something about these extension tools: version numbers, transport parameter negotiation, maybe experimental frame types.

-- Christian Huitema

---

From: Ingemar Johansson S <[email-masked]>
Date: Wed, 8 Nov 2017 07:14:42 +0000

OK, then I understand.
Another example of a possible attack vector is needed then, if there is any credible example.

/Ingemar

From: Philipp S. Tiesel [mailto:[email-masked]]
Sent: den 7 november 2017 17:48
To: Ingemar Johansson S <[email-masked]>
Cc: Roni Even <[email-masked]>; QUIC WG <[email-masked]>
Subject: Re: draft-tiesel-quic-unreliable-streams-01 - comments

Hi,

On 7. Nov 2017, at 15:47, Ingemar Johansson S <[email-masked]<mailto:[email-masked]>> wrote:

Hi

/Ingemar

To: Ingemar Johansson S <[email-masked]<mailto:[email-masked]>>; Philipp S. Tiesel <[email-masked]<mailto:[email-masked]>>

Hi Ingemar,

Hi Philip and Roni

/Ingemar

AVE!
   {phils}--->---([email-masked]<mailto:[email-masked]>)--->---(http://phils.in-panik.de<http://phils.in-panik.de/>)----,

AVE!