Re: [sipcore] Websocket is a new transport or new URI?

Iñaki Baz Castillo <ibc@aliax.net> Wed, 25 April 2012 17:25 UTC

Return-Path: <ibc@aliax.net>
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C3EA21F8817 for <sipcore@ietfa.amsl.com>; Wed, 25 Apr 2012 10:25:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.628
X-Spam-Level:
X-Spam-Status: No, score=-2.628 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f1skHXHRb6dk for <sipcore@ietfa.amsl.com>; Wed, 25 Apr 2012 10:25:35 -0700 (PDT)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5283321F880E for <sipcore@ietf.org>; Wed, 25 Apr 2012 10:25:35 -0700 (PDT)
Received: by yhkk25 with SMTP id k25so378796yhk.31 for <sipcore@ietf.org>; Wed, 25 Apr 2012 10:25:35 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=oX9udNNUtH+LG3Fswo8b+E7Tisx8n82Zf28KdNMJd6w=; b=N0fY/fo6RPmF1vFL3V9t/LcWHYBXC9Q69Zn7VKr9Q5qG1agORq7y8SGWLpJIrAHeUQ BGTn/Y1nc/PZekgnZR4e7G8yfELvC+WF6K30s7Ejbyz2cA4bw9H3XSMZJFHwt7SB/z61 /Z8YT6Kgg3y4jQr060JOdvstmTvPhPrODZDbrgAaNrMTYmdO5tIzWH/4SKqWtPWrm7HN VoCSWmGUBFne7yNZN49PKXQRmQD6LKCrXcNUCrB6rxSpzmuSCN4g2yRC4VeEozflBBon pJAkNDc3rZRhPM8sXCwRz4voMsq8S8PPwFSzTvE4qO0lDj7eZAy6kKfaOEEZsVoMYUvi 319g==
Received: by 10.236.176.167 with SMTP id b27mr3257423yhm.55.1335374734819; Wed, 25 Apr 2012 10:25:34 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.216.8 with HTTP; Wed, 25 Apr 2012 10:25:14 -0700 (PDT)
In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E239306@inba-mail01.sonusnet.com>
References: <CALiegfmw+ouWqoVbsiMuq2CJ4TxkeREVVbw308FzwKpUUrw7tw@mail.gmail.com> <CALiegfkNBi7guNML-oAF5-OUAo2ZXAjXYDo_MShLc4SiOW_wOA@mail.gmail.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228035@inba-mail01.sonusnet.com> <52EA773E-0FA0-4625-8E1F-6D10E543137A@ag-projects.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228062@inba-mail01.sonusnet.com> <FA41E993-B940-4FE6-9352-E9539E56A971@ag-projects.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228098@inba-mail01.sonusnet.com> <CALiegf=q1HE4bn1dgDz7RqKFe3NCDxr3vOWtR5DTevWAo0rK6A@mail.gmail.com> <7F2072F1E0DE894DA4B517B93C6A05852C42DF5E46@ESESSCMS0356.eemea.ericsson.se> <4F8ECB82.7070805@ericsson.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228C1B@inba-mail01.sonusnet.com> <4F9460AC.2080605@alum.mit.edu> <387F9047F55E8C42850AD6B3A7A03C6C0E231B57@inba-mail01.sonusnet.com> <4F956931.7090404@alum.mit.edu> <387F9047F55E8C42850AD6B3A7A03C6C0E2380B2@inba-mail01.sonusnet.com> <4F969C7E.3070107@digium.com> <4F970097.5020002@alum.mit.edu> <387F9047F55E8C42850AD6B3A7A03C6C0E239306@inba-mail01.sonusnet.com>
From: Iñaki Baz Castillo <ibc@aliax.net>
Date: Wed, 25 Apr 2012 19:25:14 +0200
Message-ID: <CALiegf=6Q1L-wboU6MLKZAEXgP+hUCbQh6YHU1XkTE3wFZzXAg@mail.gmail.com>
To: "Ravindran, Parthasarathi" <pravindran@sonusnet.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQmiYH/NJwH89mphYExugRVHLwKPIkmp/YwbH3housqrW8o9GopJ9iUL/kAvja6E/jOo+XQx
Cc: "sipcore@ietf.org" <sipcore@ietf.org>
Subject: Re: [sipcore] Websocket is a new transport or new URI?
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipcore>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Apr 2012 17:25:36 -0000

Hi Partha,


2012/4/25 Ravindran, Parthasarathi <pravindran@sonusnet.com>:
> So IMO, it is more appropriate to define new URI
> scheme like SIPWS rather than defining websocket as a transport.


The SIP transport defined by this draft is WebSocket, instead of TCP.
WebSocket (RFC 6455) is defined to work on top of TCP but, even if a
future spec defines WebSocket to run over SCTP, the SIP transport
would still be "WebSocket" (or perhaps "WebSocket-SCTP" but that
something in which I won't waste time now given the fact that RFC 6455
*mandates* TCP layer-3 transport and does not leave the door open for
other layer-3 transports).

WebSocket is, indeed, a layer on top of a network transport (layer 3)
but it's designed to work as a *transport* layer since it defines a
framing mechanism to send application messages and control mesages in
both directions. Applications (i.e. JavaScript scripts, PHP/Java web
apps) use WebSocket as a transport layer.

You can find lot of cases in which a transport runs on top of other
transports. For example, in the recent IETF #83 the RTCWEB WG approved
(or discussed) SCTP-over-DTLS-over-ICE-over-UDP as the transport for
the WebRTC Data-Channel mechanism. A "transport" does not necessarily
mean "layer 3 network transport".



About SIPS, the last S in SIPS stands for "secure" regardless of the
undelying SIP transport used. AFAIK it does not necessarily mean
"TLS". Take for example draft-jennings-sip-dtls-05 [1] which defines
SIP over DTLS over UDP. The draf is expired, but anyhow, it defines a
secure SIP transport which does not use TLS but DTLS (which is similar
but NOT the same). The draft also allows SIPS messages through DTLS
over UDP.

[1] http://tools.ietf.org/html/draft-jennings-sip-dtls-05


When a SIPS message is carried on top of a secure WebSocket connection
(which means SIP over WebSocket over TLS over TCP) the security level
is basically the same as if it was SIP over TLS over TCP. Therefore I
consider that a secure WebSocket connection fits the requirements of
the SIPS mechanism, thus secure WebSocket should be considered as a
secure SIP transport.



About the SIPWS and SIPWSS schemas you propose, don't take me wrong
but I consider that the worst possible idea. First of all because I
don't agree with your rationale (I insist that, from the point of view
of a SIP stack, WebSocket is the ***SIP transport***, instead of TCP).
Secondly, because adding new URI schemas would just break the existing
SIP world (there are still some SIP entities that don't understand
SIPS schema and you are proposing two new ones?).


Thanks a lot for your comments.


-- 
Iñaki Baz Castillo
<ibc@aliax.net>