Re: [rtcweb] 5G standards advocating WebRTC protocol violations?

Roman Shpount <roman@telurix.com> Tue, 09 November 2021 20:49 UTC

Return-Path: <roman@telurix.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38E3E3A1163 for <rtcweb@ietfa.amsl.com>; Tue, 9 Nov 2021 12:49:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=telurix.com
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 VuEARb49QmhX for <rtcweb@ietfa.amsl.com>; Tue, 9 Nov 2021 12:49:19 -0800 (PST)
Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAD473A112A for <rtcweb@ietf.org>; Tue, 9 Nov 2021 12:49:18 -0800 (PST)
Received: by mail-qt1-x832.google.com with SMTP id a2so85439qtx.11 for <rtcweb@ietf.org>; Tue, 09 Nov 2021 12:49:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5B0FKGPjow4v91chr1Kh3fT++gDkca0u9Fme3KhmBCU=; b=OcvSOaSVpaqK5Mt1d9QhwOr89RIlKv7dcoxCey/G+DbFhqoYwPPRSM89LXi6zR4bZV UhLYCdpvuEUMfiG+wpMACidDTtoVlGME8YXhEqDwZcm6qlXA63w5k/ISUNJ3XQqK6CCY 3mOjtZ6I1b0tt29VQ/YFGhbX1ghXOfZbDf+qI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5B0FKGPjow4v91chr1Kh3fT++gDkca0u9Fme3KhmBCU=; b=cZlcw9OfMDoXGrls+wNCwE4DsIDsetEc6hPwcF3gACpBtbYfg2+akb4aoWVSEYNuXM 6Hdov44Kp7YSbxspCUokl2nLQD+5/DsoUABXzZcdAkKJWPqD+oI1Vhv+aHxWU8NIQU1/ rXcU0x1QiX0NMbldTBNOJbxC6pYx0/qJL2d87puJwvArtmDdEQmML27U9VNfTBZtmQog 0ZjoLbaEGEANmaVvVfOQ5C0hU+l4ROvlRts2bCYibftFpYN0816xBTFmnUCX1WtY8w0b St/9vIGN+D3djo7nBwVey5gCcI/NTra4iJCkjzllQ77W1CRzM3AbawQ6zrvU10LigjM9 S/nQ==
X-Gm-Message-State: AOAM533Wx1ENMnbtIS3tRHhEX5tQT1I9/4rS3kMC53q+csA8dSngNzVm 9Ogss5H+80/3+nz0Cfyy6zpI0FxUuShctA==
X-Google-Smtp-Source: ABdhPJwYyJAmPC6euKeZW7+9iX20pZINXn6EIIl9dNvRc5PelgQitwEnJTz/isXP8Z/2zW63c6SRHQ==
X-Received: by 2002:ac8:56f9:: with SMTP id 25mr11877790qtu.374.1636490954054; Tue, 09 Nov 2021 12:49:14 -0800 (PST)
Received: from mail-yb1-f178.google.com (mail-yb1-f178.google.com. [209.85.219.178]) by smtp.gmail.com with ESMTPSA id h12sm12165612qkp.52.2021.11.09.12.49.13 for <rtcweb@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 09 Nov 2021 12:49:13 -0800 (PST)
Received: by mail-yb1-f178.google.com with SMTP id e136so752168ybc.4 for <rtcweb@ietf.org>; Tue, 09 Nov 2021 12:49:13 -0800 (PST)
X-Received: by 2002:a25:2342:: with SMTP id j63mr11066575ybj.22.1636490952812; Tue, 09 Nov 2021 12:49:12 -0800 (PST)
MIME-Version: 1.0
References: <ca569473-975c-b11d-eaa6-4aa215c8c7c9@alvestrand.no> <CA+9kkMA1GfFY_Uemhvu7PZNj-rJGUMyxYcMbS4_vVu5MTq75Bg@mail.gmail.com> <C1C2D95D-5A5E-4D02-A40D-F525F6A9C957@iii.ca>
In-Reply-To: <C1C2D95D-5A5E-4D02-A40D-F525F6A9C957@iii.ca>
From: Roman Shpount <roman@telurix.com>
Date: Tue, 09 Nov 2021 15:49:01 -0500
X-Gmail-Original-Message-ID: <CAD5OKxv6qjatESJ+-kT36bL3W6HUdd50so2krdr4gOG9+f0UDQ@mail.gmail.com>
Message-ID: <CAD5OKxv6qjatESJ+-kT36bL3W6HUdd50so2krdr4gOG9+f0UDQ@mail.gmail.com>
To: Cullen Jennings <fluffy@iii.ca>
Cc: RTCWeb IETF <rtcweb@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000ebade705d0613d59"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/pjNUi-Uxz2GLAdE4yJnYiaHjy7o>
Subject: Re: [rtcweb] 5G standards advocating WebRTC protocol violations?
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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: Tue, 09 Nov 2021 20:49:30 -0000

I would advise against ICE-lite. One of the things that ICE provides is
consent to send media. ICE-lite does not have this. Getting consent is
important to avoid using endpoints for DDOS attacks, so it is a matter of
security.

If they want to simplify things, they can use host candidates only, which
will make the ICE state machine trivial.
_____________
Roman Shpount


On Tue, Nov 9, 2021 at 3:38 PM Cullen Jennings <fluffy@iii.ca> wrote:

>
> We might want to say if you don’t want to do any of the ICE nightmare, ICE
> Lite is the best way to not do it and still have interoperability.  Do we
> know someone working on this at 5G that can help provide more guidance ?
>
>
>
> On Nov 3, 2021, at 7:10 AM, Ted Hardie <ted.ietf@gmail.com> wrote:
>
> Hi Harald,
>
> It is definitely possible for us to send liaison statements via the
> appropriate channel, but I am missing some context.  Can you provide a
> citation to the document from which the excerpt comes?  (It appears to be
> labeled a white paper, so the first step may be to confirm that its
> description and the underlying specs say the same thing.)
>
> regards,
>
> Ted Hardie
>
> On Wed, Nov 3, 2021 at 11:37 AM Harald Alvestrand <harald@alvestrand.no>
> wrote:
>
>> It's come to my attention that there's apparently some 5G spec that says
>> "Use WebRTC datachannel, but don't bother with this ICE stuff".
>>
>> The exact quote is below.
>>
>> Now I don't mind saying "don't use TURN/STUN servers" - that's a
>> configuration option on the WEBRTC API, and anyone can choose to not do
>> that - but I do mind leaving out ICE. An ICE-supporting implementation
>> won't interwork properly with an implementation that doesn't support ICE.
>>
>> Is it possible for the IETF to say "please don't make incompatible
>> changes to our protocols without asking us"? (that's the version where I
>> try not to use expletives).
>>
>> Or is it possible that this is all a misunderstanding, and the 5G folks
>> actually meant to require peer-to-peer ICE, but just wrote it wrongly?
>>
>> Or did I misunderstand what the WG's intent was, and should just suck it
>> up and interoperate with non-ICE-supporting endpoints?
>>
>> Harald
>>
>> --------- Spec reference quote ----------
>>
>> 1. Spec
>> NG.129 - 5G Data Channel White Paper  (CR1001)
>>
>> 8.2.1Data channel APIs
>> The data channel application consists of the device side logic and the
>> server side logic.
>> Both should use standardized APIs that need to be agreed by the industry.
>> W3C WebRTC1.0 data channel API specification is suggested as the
>> preferred IMS data channel API. RTCPeerConnection ,
>> RTCDataChannel object, the  callbacks need to be supported .
>> Only data channel API related definitions  are used and IMS data channel
>> API is not allowed to use WebRTC media.
>> ICE/STUN/TURN are also not required.
>>
>> # Reference
>> 3GPP TS 26.114 IMS_Multimedia Telephony Media handling and interaction
>> GSMA NG.114 IMS Profile for Voice, Video and Messaging over 5GS
>> GSMA NG.129_5G DATA CHANNEL
>>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>