Re: [rtcweb] UDP transport problem

Cb B <cb.list6@gmail.com> Thu, 13 February 2014 22:47 UTC

Return-Path: <cb.list6@gmail.com>
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 4883A1A04DE for <rtcweb@ietfa.amsl.com>; Thu, 13 Feb 2014 14:47:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.75
X-Spam-Level:
X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_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 51dDDQNna7WJ for <rtcweb@ietfa.amsl.com>; Thu, 13 Feb 2014 14:47:54 -0800 (PST)
Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 85CF61A0481 for <rtcweb@ietf.org>; Thu, 13 Feb 2014 14:47:54 -0800 (PST)
Received: by mail-wi0-f173.google.com with SMTP id hn9so9374495wib.12 for <rtcweb@ietf.org>; Thu, 13 Feb 2014 14:47:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=afpn94pJJ+JiRZObuaNz8CrerxzX9QF+HCU7Rx4/05g=; b=MQt4FOolSuayhdN7xquqWCvWSF8HFR60nP+whpDzrgiJWgRZuFfeZgJCSs6z1vkCMG FNwWc9AO7boMZ4NNyKJ6hQSlJk6fgt1eNx/L/IAGsQvvFj4xOqrRni9oJA2jnWY7FoMY ptwdg9Uq9neEeZFjpOeYdJgpbCMdSIOHi3gzlaX24WfeM0W66B/hMw7MnPJ9krag51KU REeo0iJJW0a9Wd788UfeyL3wFxmDJKee38i7WsxnXu8qbK75qCD+VU6fCcqvvBrTD14p eRSxcdcvIP0zKgPENtcCr4E2wn/jJoaIO1tz94pH5TDbYhjIOVj4yrGuSY/U+Sl5eTUM D7pw==
MIME-Version: 1.0
X-Received: by 10.180.165.15 with SMTP id yu15mr4508699wib.28.1392331672832; Thu, 13 Feb 2014 14:47:52 -0800 (PST)
Received: by 10.194.133.169 with HTTP; Thu, 13 Feb 2014 14:47:52 -0800 (PST)
In-Reply-To: <CA+9kkMC8uMrKk3nRq7OnG1pRmY-oxbveBtaBnvBJ4uTx924oyA@mail.gmail.com>
References: <CAD6AjGRiQ1UF5n3JG9HPRQFM+TD54Xz-dpTn5u9bX+__BMfesQ@mail.gmail.com> <CABkgnnVbZp7yBvpY1ARuaBXS=TOipY=BhXzrd=h5DY-76oF9Pw@mail.gmail.com> <CAD6AjGSxS4jNRGotsE_no0XhewvDqcVZ+Kmx1aMW9qorqSKR+w@mail.gmail.com> <52FD2FA4.8040701@alvestrand.no> <CAD6AjGTbSJEV2cJj5QyLktyZPv8SJa7h-QHKVtdUXnF3K6xwHA@mail.gmail.com> <CA+9kkMCjvBoMK2X6wE332Oe32v44K-hNgJC18yCXqgXEo7=cGw@mail.gmail.com> <CAD6AjGSdQzG+PxiaVfHrkPmgKbgUzQW+XATAPZhHpckwpn5X_g@mail.gmail.com> <CA+9kkMC8uMrKk3nRq7OnG1pRmY-oxbveBtaBnvBJ4uTx924oyA@mail.gmail.com>
Date: Thu, 13 Feb 2014 14:47:52 -0800
Message-ID: <CAD6AjGQz727mkiTh=2dJXRUf3rEMBOLwGtTGz5RkJ96ytTmpDQ@mail.gmail.com>
From: Cb B <cb.list6@gmail.com>
To: Ted Hardie <ted.ietf@gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/f12WMJw2-YbfBnS2Z1Lb-jwpU6g
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] UDP transport problem
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: Thu, 13 Feb 2014 22:47:56 -0000

On Thu, Feb 13, 2014 at 2:45 PM, Ted Hardie <ted.ietf@gmail.com> wrote:
> On Thu, Feb 13, 2014 at 2:37 PM, Cb B <cb.list6@gmail.com> wrote:
>>
>> On Thu, Feb 13, 2014 at 2:32 PM, Ted Hardie <ted.ietf@gmail.com> wrote:
>> > On Thu, Feb 13, 2014 at 1:20 PM, Cb B <cb.list6@gmail.com> wrote:
>> >>
>> >>
>> >> But that's not the point.  The question is can we include native SCTP
>> >> as an option in  draft-ietf-rtcweb-transports?  What is the downside?
>> >>
>> >> CB
>> >
>> >
>> > Howdy,
>> >
>> > Given previous decisions of the working group, you would need to
>> > describe
>> > how to provide confidentiality.  At the moment, I know only of TLS over
>> > SCTP
>> > (which would reverse the current mapping) and SCTP over IPSec (which
>> > would
>> > likely actually be IPSec/UDP); do you know of other methods which would
>> > keep
>> > SCTP at the top layer of the protocol stack and still provide
>> > confidentiality?
>> >
>> > regarsd,
>> >
>> > Ted
>> >
>>
>> I believe the cleanest would be to do TLS over SCTP.  I understand
>> that changes the top of the transport stack, and create variation.
>> But, i don't think current SCTP over DTLS plan has won any beauty
>> prizes.  If this is standards track work that must stand the test of
>> time, TLS over SCTP seems appropriate.
>>
>
> This requires a completely new method for providing channel abstractions.
>
> If you would like the working group to consider a change of that magnitude,
> a worked draft describing a solution that meets all of the use cases set out
> in
> draft-ietf-rtcweb-data-channel-07 seems to me the bare minimum to consider
> overturning the established working group consensus on this point.
>
> Speaking personally, I do not see sufficient SCTP/IP deployment to warrant
> further discussion on this point.  The working group has invested
> considerable
> time and effort on this approach and the likely result of this change seems
> to
> me either a less deployable system or one which will deploy later because of
> the
> need to start discussions over.
>
> regards,
>
> Ted Hardie
>

Acknowledged.  That is approximately the story arc i expected before I
initiated the conversation.

CB

>
>
>>
>> CB
>
>