Re: [rtcweb] ICE and security

"Dan Wing" <dwing@cisco.com> Mon, 19 September 2011 20:31 UTC

Return-Path: <dwing@cisco.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 A93C821F8CFE for <rtcweb@ietfa.amsl.com>; Mon, 19 Sep 2011 13:31:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.458
X-Spam-Level:
X-Spam-Status: No, score=-103.458 tagged_above=-999 required=5 tests=[AWL=-0.859, BAYES_00=-2.599, 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 FhCyFUtzC80i for <rtcweb@ietfa.amsl.com>; Mon, 19 Sep 2011 13:31:05 -0700 (PDT)
Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id E464A21F8CBD for <rtcweb@ietf.org>; Mon, 19 Sep 2011 13:31:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=1675; q=dns/txt; s=iport; t=1316464410; x=1317674010; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=LGH7EFyqM/PaMmASF7d3g6iM7T0iYD+ucNt39Go1fJo=; b=b1EzxFRNqYA++Z/8aJcaHs10TrVAccHOtwNv1oe17FDHPPuxj8Cuez/b eueseNxvNwmMqT8uQOp1I081nLD62z2/OBOrhFpp7d0LnKCQBHX90DwKr lQs35V8D5BGdFQvGi5R9LuMQ90yxjuP44aY9PCFU6gwze0oGFApePa6fY M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAB+md06rRDoH/2dsb2JhbABCmkOMfHeBUwEBAQECAQgKARcQPwUIAwIJDgE3GSMbAgQBHReHVZcDAZ4rhngEh2+dJw
X-IronPort-AV: E=Sophos;i="4.68,407,1312156800"; d="scan'208";a="3044481"
Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 19 Sep 2011 20:33:29 +0000
Received: from dwingWS ([128.107.105.231]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p8JKXTCY007870; Mon, 19 Sep 2011 20:33:29 GMT
From: "Dan Wing" <dwing@cisco.com>
To: "'Hadriel Kaplan'" <HKaplan@acmepacket.com>, "'Olle E. Johansson'" <oej@edvina.net>
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>
In-Reply-To: <0E6DD5C7-A59F-4C35-9412-780CB19F2DE1@acmepacket.com>
Date: Mon, 19 Sep 2011 13:33:29 -0700
Message-ID: <0e7701cc770b$6459bcd0$2d0d3670$@com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AQHMdV8HZnV0C/itdk+1WJWhe7py/pVVKrlg
Content-Language: en-us
Cc: 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: Mon, 19 Sep 2011 20:31:06 -0000

...
> 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).

To work, they "just" need to do ICE-Lite.  ICE-Lite is the ability to 
respond to ICE's media path STUN messages.  ICE-Lite does not require a 
STUN server, does not require a TURN server, and does not require 
gathering IP addresses that everyone finds (oddly) difficult.

Those that don't do ICE-Lite can be front-ended with an SBC that does
ICE-Lite for them.

> One open question is if javascript will even be allowed to open a media
> channel to a peer without human/user consent. 

I'll bet a beer it'll happen without human consent, yes.

> 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 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).

Yep, if you 0wn enough hosts, just their "can I send you a flood of
media packets" requests could, itself, be a flood of traffic.


Let's talk about DNSSEC responses being a source of attack.

-d