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 13:30 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 763531A1B7F for <rtcweb@ietfa.amsl.com>; Sun, 12 Oct 2014 06:30:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.737
X-Spam-Level:
X-Spam-Status: No, score=-1.737 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_57=0.6, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001] autolearn=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 erBsVkPOvU2N for <rtcweb@ietfa.amsl.com>; Sun, 12 Oct 2014 06:30:49 -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 008D51A1B80 for <rtcweb@ietf.org>; Sun, 12 Oct 2014 06:30:48 -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 65B891C0B2E31; Sun, 12 Oct 2014 15:30:46 +0200 (CEST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
In-Reply-To: <543A5570.7060208@alvestrand.no>
Date: Sun, 12 Oct 2014 15:30:45 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <B53499C4-6B51-4E8E-87C2-C8E5C10DBC34@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>
To: Harald Alvestrand <harald@alvestrand.no>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/tvGQ8HDMMAHrK8ir1wdOWvJx8eI
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 13:30:51 -0000

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?

Best regards
Michael 
> 
> The kind of "middle box" that "just shuffles bits" while doing something
> to them or with them in addition doesn't exist in the WebRTC context.
> 
> 
> On 10/11/2014 06:58 PM, Wyss, Felix wrote:
>>>> Yes, it does. I think the worry is that the middle box may end up as DTLS server to both legs.
>>> And why can't the middle box avoid this?
>> How can it if it is the offerer on both legs?  From RFC#5763, section 5 (page 10): "The endpoint that is the offerer MUST use the setup attribute value of setup:actpass and be prepared to receive a client_hello before it receives the answer."
>> 
>> The answerer thus gets to pick whether it is the client or server.  As mentioned in my original message, the answerer picking client is desirable as it can speed up the DTLS negotiation.  So almost invariably the middlebox will be DTLS server on both legs.
>> 
>> 
>>>> That leaves both endpoints as DTLS clients. This then breaks the
>>>> odd-even split and risks the endpoints allocating the same stream numbers.
>>> I think "risks" is the wrong term here. I guess they will run into this almost always.
>> Not necessarily if the endpoints draw their IDs at random.  That makes this particularly problematic as everything may appear to work fine but then fail intermittently in the field due to collisions.  
>> 
>> --Felix
>> 
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
> 
> 
> -- 
> Surveillance is pervasive. Go Dark.
> 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>