Re: [rtcweb] Last Call: <draft-ietf-rtcweb-data-channel-12.txt> (WebRTC Data Channels) to Proposed Standard

Michael Tuexen <Michael.Tuexen@lurchi.franken.de> Sun, 12 October 2014 19:50 UTC

Return-Path: <Michael.Tuexen@lurchi.franken.de>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 761801A873B for <rtcweb@ietfa.amsl.com>; Sun, 12 Oct 2014 12:50:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.337
X-Spam-Level:
X-Spam-Status: No, score=-2.337 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001] autolearn=ham
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 k6u5a0A1abFS for <rtcweb@ietfa.amsl.com>; Sun, 12 Oct 2014 12:50:19 -0700 (PDT)
Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 883981A8730 for <rtcweb@ietf.org>; Sun, 12 Oct 2014 12:50:19 -0700 (PDT)
Received: from [192.168.1.200] (p508F1AC6.dip0.t-ipconnect.de [80.143.26.198]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 36B721C1050E4; Sun, 12 Oct 2014 21:50:17 +0200 (CEST)
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
In-Reply-To: <543ABE69.8030104@alvestrand.no>
Date: Sun, 12 Oct 2014 21:50:16 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <99078EA5-5FE7-431F-9C70-EEA882F4C3C6@lurchi.franken.de>
References: <20141010004836.12666.88765.idtracker@ietfa.amsl.com> <91953101b2634ec69d14e120ea62d929@CY1PR0501MB1579.namprd05.prod.outlook.com> <CABkgnnWE7czWqi4vQRb5d50N2k95joc_Zcvw6w6g7SOjU9b+9g@mail.gmail.com> <03a3bbbc282b4e6d88d587931b46b5f8@CY1PR0501MB1579.namprd05.prod.outlook.com> <57B40110-2F21-4893-B77C-54F46D18567F@lurchi.franken.de> <1DE35922-E890-40C2-87E9-C8C12235920E@phonefromhere.com> <E53B9B7E-37F0-495C-B1BA-DE0A48AC6D73@lurchi.franken.de> <abdfd3ef58dd40028e8d5e2248b5a995@CY1PR0501MB1579.namprd05.prod.outlook.com> <543A5570.7060208@alvestrand.no> <B53499C4-6B51-4E8E-87C2-C8E5C10DBC34@lurchi.franken.de> <543A9E11.2030605@alvestrand.no> <F5C54F5E-C301-4EC7-9536-E43EA3A16863@lurchi.franken.de> <543ABE69.8030104@alvestrand.no>
To: Harald Alvestrand <harald@alvestrand.no>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/uXR5n2GFK_gYtPyrSzCw3QudkIo
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Last Call: <draft-ietf-rtcweb-data-channel-12.txt> (WebRTC Data Channels) to Proposed Standard
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 12 Oct 2014 19:50:23 -0000

On 12 Oct 2014, at 19:46, Harald Alvestrand <harald@alvestrand.no> wrote:

> On 10/12/2014 06:50 PM, Michael Tuexen wrote:
>> On 12 Oct 2014, at 17:28, Harald Alvestrand <harald@alvestrand.no> wrote:
>> 
>>> On 10/12/2014 03:30 PM, Michael Tuexen wrote:
>>>> On 12 Oct 2014, at 12:18, Harald Alvestrand <harald@alvestrand.no> wrote:
>>>> 
>>>>> Given that the middle box has to:
>>>>> 
>>>>> - decrypt and encrypt all packets (because the keys are different)
>>>>> - assert its own identity towards both endpoints (because otherwise DTLS
>>>>> doesn't work)
>>>>> - be trusted by both endpoints (otherwise it's a MITM attack by definition)
>>>>> - manage SCTP congestion control independently on the two legs (because
>>>>> that's how SCTP works)
>>>>> 
>>>>> I don't see the reshuffling of packets between channel numbers to be an
>>>>> excessive *additional* burden.
>>>> I agree CPU wise. But I have a question: Don't expect both endpoints of a
>>>> data channel to see the same "id" attribute? And isn't this attribute
>>>> the stream ID? So can conceptually a middlebox map the streams IDs?
>>> The two ends don't see the same identity either, so the middle box is not transparent.
>> OK. So this means that the ID defined in 
>> http://w3c.github.io/webrtc-pc/#widl-RTCDataChannel-id
>> doesn't have to be the same on both ends, right?
> 
> It has to be the same on both ends of the SCTP connection.
This means you can't remap the streams. Or am I missing something?

Best regards
Michael
> 
> It's just that (I think) you can't splice SCTP connections together;
> either you terminate them, or you don't.
> 
> That's my understanding - YMMV.
> 
>> It would be useful
>> to make that clear in the document. I always assumed that they are the same
>> on both ends...
>> 
>> Best regards
>> Michael
>>> The application has to know the middle box is there. So it has to be written to deal with differing numbers at the two ends too.
>>> 
>>> 
>>> 
> 
> 
> -- 
> Surveillance is pervasive. Go Dark.
> 
>