Re: [rtcweb] ICE and security

Eric Rescorla <ekr@rtfm.com> Sun, 18 September 2011 04:59 UTC

Return-Path: <ekr@rtfm.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 5FD8921F8663 for <rtcweb@ietfa.amsl.com>; Sat, 17 Sep 2011 21:59:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.605
X-Spam-Level:
X-Spam-Status: No, score=-102.605 tagged_above=-999 required=5 tests=[AWL=-0.228, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 Wb8POPtR3Xj5 for <rtcweb@ietfa.amsl.com>; Sat, 17 Sep 2011 21:59:01 -0700 (PDT)
Received: from mail-wy0-f170.google.com (mail-wy0-f170.google.com [74.125.82.170]) by ietfa.amsl.com (Postfix) with ESMTP id 94E3A21F85FF for <rtcweb@ietf.org>; Sat, 17 Sep 2011 21:59:01 -0700 (PDT)
Received: by wyg8 with SMTP id 8so5396216wyg.15 for <rtcweb@ietf.org>; Sat, 17 Sep 2011 22:01:20 -0700 (PDT)
Received: by 10.227.165.202 with SMTP id j10mr1265382wby.18.1316322080201; Sat, 17 Sep 2011 22:01:20 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.227.38.9 with HTTP; Sat, 17 Sep 2011 22:01:00 -0700 (PDT)
In-Reply-To: <0E6DD5C7-A59F-4C35-9412-780CB19F2DE1@acmepacket.com>
References: <CALiegfnOCxyTo9ffQ272+ncdu5UdgrtDT-dn10BWGTZMEjZoCg@mail.gmail.com> <2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com> <05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com> <16880306-5B3A-4EFD-ADE4-1201138D9182@acmepacket.com> <4E73BA23.6040305@skype.net> <E8DBBD7D-BAD2-43A9-807B-C3663FD31A2B@edvina.net> <0E6DD5C7-A59F-4C35-9412-780CB19F2DE1@acmepacket.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Sat, 17 Sep 2011 22:01:00 -0700
Message-ID: <CABcZeBOPgNASQi5cELnhN+n6=Hi4ehfYoifXv_TMba=Ov-VNCQ@mail.gmail.com>
To: Hadriel Kaplan <HKaplan@acmepacket.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "<rtcweb@ietf.org>" <rtcweb@ietf.org>
Subject: Re: [rtcweb] ICE and security
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
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: Sun, 18 Sep 2011 04:59:02 -0000

On Sat, Sep 17, 2011 at 10:27 AM, Hadriel Kaplan <HKaplan@acmepacket.com>; wrote:
>
> On Sep 17, 2011, at 4:22 AM, Olle E. Johansson wrote:
>
>>
>> 16 sep 2011 kl. 23:05 skrev Matthew Kaufman:
>>>
>>> This, and supports enough security/safety that the library can be trusted to run in the browser environment. (This is where the ICE requirement comes from.)
>>
>> Matt,
>> Can you please elaborate how ice relates to security?
>
> There's a concern that malicious javascript can make your Browser start sending RTP packets at a target, and that enough people running such a javascript would be a nice botnet flooding a target.  For example, there could be some malicious website which has some interesting content on it to draw people to go to it (for example it mirrors real content from somewhere else, or it offers pirated content downloading, or porn, or whatever), and on the same webpage it embeds javascript that makes your Browser start sending RTP packets against root DNS servers or whatever.  IF they got enough browsers viewing their webpage, then it would be a DDoS flood of RTP against the target.  And of course if we have a UDP-based Data channel and the javascript can decide what goes in the data packet, then it could craft something nasty, to either perform a heavier resource exhaustion attack, or whatever.  Ultimately the concern is that UDP has no SYN/SYN-ACK exchange like TCP does, to verify the
>  device you're going to send lots of packets to wants to receive any of them.
>
> So ICE does that for you - it verifies the IP:port you're going to send your RTP packets to is willing to accept your packets. (it has some other security properties too, but I personally find the rest questionable, compared to this one)
> So basically we're stuck with requiring ICE be used for every media/data session, and thus not being able to interop directly with devices which don't do ICE (which is most of the SIP world right now).
>
> One open question is if javascript will even be allowed to open a media channel to a peer without human/user consent.  I thought we were requiring per-site consent.  I guess a malicious site could still offer legitimate media usage, and thus get user's consent, and then sometime in the future the same website could turn evil; or it could offer seemingly legitimate service that works, while in javascript creating a forked stream that is the one attacking someone else.

I don't see any reason not to allow (for instance) a data channel w/o
user consent.


> I wonder though if even requiring ICE is sufficient.  If I'm a malicious javascript, I could add enough ICE candidates against a target that it would be the same as an RTP stream in aggregate (I believe ICE's throttling limit was in fact approximately the rate of RTP by design, if I recall correctly).

At best this would be a DoS attack, however.

-Ekr

> -hadriel
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>