IETF Logo Mail Archive

Re: [rtcweb] UDP transport problem

Cb B <cb.list6@gmail.com> Thu, 13 February 2014 22:37 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 657A21A0005 for <rtcweb@ietfa.amsl.com>; Thu, 13 Feb 2014 14:37:46 -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 EowOpfoEVhaj for <rtcweb@ietfa.amsl.com>; Thu, 13 Feb 2014 14:37:45 -0800 (PST)
Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 2FF461A04D8 for <rtcweb@ietf.org>; Thu, 13 Feb 2014 14:37:41 -0800 (PST)
Received: by mail-we0-f179.google.com with SMTP id q58so8256351wes.10 for <rtcweb@ietf.org>; Thu, 13 Feb 2014 14:37:39 -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=+IDnECUCma9D4Fo6f83SSkpnhw885JxuAtIzLR83a7c=; b=of5dmsASXOsd/i0XQ80pP4ALdJyKGxBRwvFX2xmBxzT53tM55zGAUrdiUzmrDOaQm9 IsXAzlh7QJGpDE1NYMnwqikwhaEsv/C+3AG2NpLH6FJBg9oadxcc3bwGJdZr7L2xzipP pakpncWAzHDiWGzccEv5MSx55kZAuP/ONMDYI+24zwNGZarAucFy/0NAWvfA7v46K3NE zZBOA5PZzXwxTABTbxWdU6inLf7DoOYvt7ywHpeTkHBVDKeHs+JhwycwU8x/OBGyXgM5 ksG5TlwyfgvxI86bNcDetE9240CL713XhyXiM4LD2170TuWWL2fWV/VwKZazhqJA7uCD te4w==
MIME-Version: 1.0
X-Received: by 10.180.13.5 with SMTP id d5mr4439124wic.54.1392331059506; Thu, 13 Feb 2014 14:37:39 -0800 (PST)
Received: by 10.194.133.169 with HTTP; Thu, 13 Feb 2014 14:37:39 -0800 (PST)
In-Reply-To: <CA+9kkMCjvBoMK2X6wE332Oe32v44K-hNgJC18yCXqgXEo7=cGw@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>
Date: Thu, 13 Feb 2014 14:37:39 -0800
Message-ID: <CAD6AjGSdQzG+PxiaVfHrkPmgKbgUzQW+XATAPZhHpckwpn5X_g@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/9Bqygv8qPMU4yLr1PuU4xsIq_-U
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:37:46 -0000

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.

CB

v2.23.0 | Report a Bug | By Email