Re: [MMUSIC] ICE and RTCP host components

Roman Shpount <roman@telurix.com> Fri, 23 October 2015 18:30 UTC

Return-Path: <roman@telurix.com>
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 E8B7B1A897E for <mmusic@ietfa.amsl.com>; Fri, 23 Oct 2015 11:30:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level:
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_LOW=-0.7, 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 QFAP99U9MzHj for <mmusic@ietfa.amsl.com>; Fri, 23 Oct 2015 11:30:22 -0700 (PDT)
Received: from mail-ig0-f196.google.com (mail-ig0-f196.google.com [209.85.213.196]) (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 48BC01A8960 for <mmusic@ietf.org>; Fri, 23 Oct 2015 11:29:57 -0700 (PDT)
Received: by igbfs6 with SMTP id fs6so3082438igb.3 for <mmusic@ietf.org>; Fri, 23 Oct 2015 11:29:56 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Y165DSEtxY3aQStKpXbgbEW0Of2gelSnf+1Mn6R3uDE=; b=RpUdsYO8UHtblknLFMMj76oK3o38FlhO9BIKt8cE8zV2hz3u0f0nLqw9S26zoypflb LbgqdSyo97mPWjxZ0jJyS9SJSTCaRhy1m3r/Xv3RplxlS7fJXhfJOcp9ObQiQI0zX5O8 BED+k2DFhxF/wvmqVggsoWYRCHOKON/iN4rC1sNH533uI9Jk0RDxjvzsRFBHVS3g6Cnb ihefBE7mGiCPfFMWWj4IQZ62SaBmzrggEMjiI6H0Omm1gKKq6HN0VpVjfZzC8KQkYxvO 9H/pofD/y7TlgKT8iaA4r6+wQ8hDYvAFVRtoy8DUNqv3rnglZkhquK7LmrzDqd9XZBq1 UwcA==
X-Gm-Message-State: ALoCoQli5QJslKIXwqkzTP4EhgoRSMo3LiZ6NjOoZxgApCwL9CBEbOgZcAMATEjL9eNJ/8VYvtf6
X-Received: by 10.50.155.33 with SMTP id vt1mr6500842igb.92.1445624996469; Fri, 23 Oct 2015 11:29:56 -0700 (PDT)
Received: from mail-ig0-f171.google.com (mail-ig0-f171.google.com. [209.85.213.171]) by smtp.gmail.com with ESMTPSA id w71sm8297459ioi.29.2015.10.23.11.29.54 for <mmusic@ietf.org> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 23 Oct 2015 11:29:55 -0700 (PDT)
Received: by igbkq10 with SMTP id kq10so22246790igb.0 for <mmusic@ietf.org>; Fri, 23 Oct 2015 11:29:54 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.50.87.69 with SMTP id v5mr6373697igz.2.1445624994545; Fri, 23 Oct 2015 11:29:54 -0700 (PDT)
Received: by 10.36.205.67 with HTTP; Fri, 23 Oct 2015 11:29:54 -0700 (PDT)
Received: by 10.36.205.67 with HTTP; Fri, 23 Oct 2015 11:29:54 -0700 (PDT)
In-Reply-To: <562A72E2.7090400@alum.mit.edu>
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>
Date: Fri, 23 Oct 2015 14:29:54 -0400
Message-ID: <CAD5OKxv3F8MxK-YUDjHkhSpTf4Bm7LvfO4rsOEOiwpipfatKhg@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
Content-Type: multipart/alternative; boundary="047d7bf17eea478e2e0522c9cc54"
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/63htqARVww7j6z44KF64wnxNN0Y>
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 18:30:24 -0000

The normal use case for ICE are large numbers of end points deployed behind
NAT sending media directly to each other. 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.

Roman Shpount
On Oct 23, 2015 1:48 PM, "Paul Kyzivat" <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>> 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
>> https://www.ietf.org/mailman/listinfo/mmusic
>>
>>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>