Re: [MMUSIC] ICE and RTCP host components

Paul Kyzivat <pkyzivat@alum.mit.edu> Fri, 23 October 2015 19:01 UTC

Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FA221A8823 for <mmusic@ietfa.amsl.com>; Fri, 23 Oct 2015 12:01:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.635
X-Spam-Level:
X-Spam-Status: No, score=-0.635 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_64=0.6, SPF_SOFTFAIL=0.665] 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 OATx0SAIpfS8 for <mmusic@ietfa.amsl.com>; Fri, 23 Oct 2015 12:01:01 -0700 (PDT)
Received: from resqmta-ch2-03v.sys.comcast.net (resqmta-ch2-03v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:35]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E33101A87D5 for <mmusic@ietf.org>; Fri, 23 Oct 2015 12:00:48 -0700 (PDT)
Received: from resomta-ch2-11v.sys.comcast.net ([69.252.207.107]) by resqmta-ch2-03v.sys.comcast.net with comcast id Yiz11r0012Ka2Q501j0omX; Fri, 23 Oct 2015 19:00:48 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-11v.sys.comcast.net with comcast id Yj0n1r00Y3Ge9ey01j0nRT; Fri, 23 Oct 2015 19:00:48 +0000
To: Roman Shpount <rshpount@gmail.com>
References: <7594FB04B1934943A5C02806D1A2204B37B7AC27@ESESSMB209.ericsson.se> <56266954.3080206@alum.mit.edu> <CAD5OKxtxHwjdaDnmK9LORM9M0YqQQb+-h66dV8C8Lgy8a6WYiA@mail.gmail.com> <56271989.5010509@alum.mit.edu> <CAD5OKxtW_3Ucq4X=wjhkT17tsxedc1JjEC2KYCchQF=_3uDX7g@mail.gmail.com> <562A64CF.200@alvestrand.no> <CAD5OKxvVDRFOSHB1S3Qodtqvm1Y4nSAMo41JmmsBTWw5CP=FpA@mail.gmail.com> <562A72E2.7090400@alum.mit.edu> <CAD5OKxuitU1paSGPn=wFmYG7+rWoY_tnG=u8hN7OjGnQEaVemg@mail.gmail.com>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <562A83DE.4040602@alum.mit.edu>
Date: Fri, 23 Oct 2015 15:00:46 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <CAD5OKxuitU1paSGPn=wFmYG7+rWoY_tnG=u8hN7OjGnQEaVemg@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1445626848; bh=zO4YmPtg8+DTDFK0U+xoeaz1TbB0Sxf4ZM5cTtGQkwA=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=BmvabY5YCjb+zZjrrkSOWz6Mdb9SWz63FPZyBTY+HDRhLUtM2SIyelyAhaDpQekFo Ni5H7gjWoxtlF1UeIR9DayBtcls/kLPKUSDahrupyCw7fc8r8FqH/wxGfCfuCdp0ef K0F7uyqAieIVP715gl2xWL2xCUW14Ol/02vtAnmIrdCFVFYt+F1iuCtXje8na0bzsw BYA/xchvwguQb/JGDIVnGRtmb9u9lm9q9iaM9DbseRiXjQWgHFsrHneGAOLZaXuZIk laEArgP8toC+o2Ebeb2wWglcgscWpNsitf0BXmgGHOATcRE4+rgQdQXrG8qWXnrANV WXF5tao8pDDMA==
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/q0ZWGTnpJ5CjxWt1HVJH_bPd4BI>
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] ICE and RTCP host components
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 23 Oct 2015 19:01:02 -0000

On 10/23/15 2:25 PM, Roman Shpount wrote:
> The normal use case for ICE are large numbers of end points deployed
> behind NAT sending media directly to each other.

"Normal" changes over time. I think what you mean here is "current".

As ICE becomes more mature and people understand it better, it will be 
used more broadly, for things that have legacy components.

In any case, I think there will be much use of webrtc as one end of a 
session with the other end being a legacy sip device.

> Deploying a lot of end
> points without some sort of consent to send media mechanism creates a
> perfect platform for denial of service attacks. ICE solves this issue if
> legacy support is disabled. Furthermore, legacy end points without SDP
> rtcp attribute support end up sending RTCP to completely wrong place.
> Best solution for anything ICE enabled is to set c= line address to IP4
> 0.0.0.0 and provide real RTP and RTCP in ICE candidates. Legacy will not
> work, but no traffic to unexpected destinations will be generated.

Don't break interworking. Certainly this will require at least a 
signaling gateway. In general that will require a media gateway too. But 
anything that can be done to reduce the load on such a media gateway is 
good. It may need to do ICE. It may need to do the consent on behalf of 
the ultimate device.

	Thanks,
	Paul

> On Oct 23, 2015 1:48 PM, "Paul Kyzivat" <pkyzivat@alum.mit.edu
> <mailto:pkyzivat@alum.mit.edu>> wrote:
>
>     Ignoring legacy is a bad idea. It takes a long time for all of it to
>     go away. In the meantime there must be some way of interworking with it.
>
>              Thanks,
>              Paul
>
>     On 10/23/15 1:18 PM, Roman Shpount wrote:
>
>         On Fri, Oct 23, 2015 at 12:48 PM, Harald Alvestrand
>         <harald@alvestrand.no <mailto:harald@alvestrand.no>
>         <mailto:harald@alvestrand.no <mailto:harald@alvestrand.no>>> wrote:
>
>              On 10/22/2015 07:22 AM, Roman Shpount wrote:
>
>                  Basically, end points must implement ICE and be
>             deployed with TURN
>                  servers to play well with other end points. If you
>             implement ICE
>                  with STUN servers only, one would need to make sure to
>             set up
>                  connections only to end points they control, which
>             implement ICE
>                  or at least SDP rtcp attribute. Everything else breaks in
>                  interesting and unpleasant ways. Building anything new
>             now without
>                  ICE, and consent to send traffic which is part of ICE,
>             would be
>                  highly dangerous and can be used for DOS attacks. So, I
>             think it
>                  might be safer to remove interop with legacy.from
>             anything that
>                  supports ICE, and require that remote party implements
>             at least
>                  ice-lite, or no media flow will be established.
>
>
>              RTCP/RTP multiplexing works for all cases where anything
>         works at all.
>
>              Legacy (RTCP port = RTP port + 1) doesn't.
>
>              Time to give up on legacy.
>
>
>         Can we also give up on legacy interop for ICE? Let's make ICE
>         work iwth
>         ICE enabled end points only and stop worrying what goes into c= line
>         address, m= line port, and SDP rtcp attribute. If anybody needs to
>         support legacy, put the media proxy on the RTP path.
>         _____________
>         Roman Shpount
>
>
>         _______________________________________________
>         mmusic mailing list
>         mmusic@ietf.org <mailto:mmusic@ietf.org>
>         https://www.ietf.org/mailman/listinfo/mmusic
>
>
>     _______________________________________________
>     mmusic mailing list
>     mmusic@ietf.org <mailto:mmusic@ietf.org>
>     https://www.ietf.org/mailman/listinfo/mmusic
>