IETF Logo Mail Archive

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

"Philipp S. Tiesel" <phils@in-panik.de> Thu, 02 November 2017 20:50 UTC

Return-Path: <phils@in-panik.de>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74F1F13F95E for <quic@ietfa.amsl.com>; Thu, 2 Nov 2017 13:50:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ABM9aXead7UA for <quic@ietfa.amsl.com>; Thu, 2 Nov 2017 13:50:36 -0700 (PDT)
Received: from einhorn-mail.in-berlin.de (einhorn.in-berlin.de [192.109.42.8]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4755513F95F for <quic@ietf.org>; Thu, 2 Nov 2017 13:50:35 -0700 (PDT)
X-Envelope-From: phils@in-panik.de
Received: from x-berg.in-berlin.de (x-change.in-berlin.de [217.197.86.40]) by einhorn.in-berlin.de (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id vA2KnrDs022466 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 2 Nov 2017 21:49:53 +0100
Received: from [2001:bf0:c801:101:c821:9806:c083:513a] by x-berg.in-berlin.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <phils@in-panik.de>) id 1eAMQX-0004Ge-DY; Thu, 02 Nov 2017 21:49:25 +0100
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\))
Subject: Re: draft-tiesel-quic-unreliable-streams-01 - comments
From: "Philipp S. Tiesel" <phils@in-panik.de>
In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD82A735@DGGEMM506-MBS.china.huawei.com>
Date: Thu, 02 Nov 2017 21:49:50 +0100
Cc: QUIC WG <quic@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <FBF9665E-15CE-437B-A575-25AEA7C88073@in-panik.de>
References: <6E58094ECC8D8344914996DAD28F1CCD82A735@DGGEMM506-MBS.china.huawei.com>
To: Roni Even <roni.even@huawei.com>
X-Mailer: Apple Mail (2.3445.4.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/TBEXYUzlfFZvAYzGIJ_LaU5Ku1w>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Nov 2017 20:50:38 -0000

Hi

> On 1. Nov 2017, at 14:03, Roni Even <roni.even@huawei.com> 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.
>  
> 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.

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}--->---(phils@in-panik.de)--->---(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: phils@in-panik.de)----'

v2.23.0 | Report a Bug | By Email