Re: [rtcweb] Resolving RTP/SDES question in Paris

Hadriel Kaplan <HKaplan@acmepacket.com> Sat, 24 March 2012 03:19 UTC

Return-Path: <HKaplan@acmepacket.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 7A47121E8018 for <rtcweb@ietfa.amsl.com>; Fri, 23 Mar 2012 20:19:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.504
X-Spam-Level:
X-Spam-Status: No, score=-2.504 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 14E6RMSMI0XO for <rtcweb@ietfa.amsl.com>; Fri, 23 Mar 2012 20:19:29 -0700 (PDT)
Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 8018621E800F for <rtcweb@ietf.org>; Fri, 23 Mar 2012 20:19:29 -0700 (PDT)
Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 23 Mar 2012 23:19:24 -0400
Received: from MAIL1.acmepacket.com ([169.254.1.170]) by Mail2.acmepacket.com ([169.254.2.166]) with mapi id 14.02.0283.003; Fri, 23 Mar 2012 23:19:24 -0400
From: Hadriel Kaplan <HKaplan@acmepacket.com>
To: Roman Shpount <roman@telurix.com>
Thread-Topic: [rtcweb] Resolving RTP/SDES question in Paris
Thread-Index: AQHNCWzpAfjutPOyGkap6/qZ4J174g==
Date: Sat, 24 Mar 2012 03:19:24 +0000
Message-ID: <86CD9009-0557-4F94-9E9F-89DAD2D80FF1@acmepacket.com>
References: <4F4759DC.7060303@ericsson.com> <387F9047F55E8C42850AD6B3A7A03C6C0E1FEB69@inba-mail01.sonusnet.com> <CALiegfnkYVEpmPV-zSL_4wOY-HiFZN-qJCQCiioaS=5NaqhLZw@mail.gmail.com> <CAD5OKxvtOAxMBx6xDnyfTnEq76oDEm6uj1xL6wGjjrtKUAHy3g@mail.gmail.com> <CABcZeBNZiotPmCfT53uEo+O0xw4xv6tXW1M_G-3A5BHuncsduA@mail.gmail.com> <CAD5OKxvYOY5JZ2mYNGiH1poUBQkyOOycePFijH5H+SxtcdqujQ@mail.gmail.com> <CABkgnnVe-b6Sv=R67bMJk_NQqQwdrRUn6rBm7Gu_CMcfPQwtEg@mail.gmail.com> <4F64FE98.3070605@alcatel-lucent.com> <4F685ED9.2050109@alvestrand.no> <CAD5OKxsVp7px9bHAgxgdqPMxRgppcVUDKt8JHBhyq9qqW3pAMg@mail.gmail.com> <B60F5A76-8ADB-4A55-8F1C-0438F7D7EA80@acmepacket.com> <CAD5OKxv4t-5LS3u=u7SnaLwnmFnE2uCSQ6D06tYqgp8g-oBPYQ@mail.gmail.com>
In-Reply-To: <CAD5OKxv4t-5LS3u=u7SnaLwnmFnE2uCSQ6D06tYqgp8g-oBPYQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [216.41.24.34]
Content-Type: multipart/alternative; boundary="_000_86CD900905574F949E9F89DAD2D80FF1acmepacketcom_"
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAQAAAWE=
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Resolving RTP/SDES question in Paris
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: Sat, 24 Mar 2012 03:19:30 -0000

On Mar 23, 2012, at 1:45 PM, Roman Shpount wrote:

Personally, if I were running such an org, and I don't know if it's possible, but I'd go get some form of rootkit/kernel-mod to intercept audio/video/keystrokes well below the user layer, so that you wouldn't have to worry what application was running - just intercept the audio/screen/keyboard somewhere near the drivers.  Presumably some companies make such things, for just such organizations? (sort of like the equivalent of CarrierIQ)  That way it doesn't matter whether it's WebRTC, Flash, or native apps.


Unfortunately this does not always work. What you are looking for is a way to enforceme that all the devices on the organizational network either confirms to organization communication policy or not allowed to communicate. This also applies to other devices that are being brought to your organization (ie lawyer laptop in prison). Organization cannot force everybody to install a key logger to their computers that they bring in, but they can force all the communications coming from within the organization to go through some sort of proxy or not to be allowed to communicate.

But that *is* their policy, and it *is* being followed: as you said, their policy is "all the devices on the organizational network either confirms to organization communication policy or not allowed to communicate".  That is being followed, because all web communications go through the Organization's proxy, and if a lawyer comes in his/her web traffic goes through the proxy…  but the lawyer can't use it for WebRTC-created media - which is exactly matching the Organization's policy, because the lawyer's laptop must not and will not work for WebRTC communications.

I'm not trying to be pedantic or difficult here, or trying to dismiss the use-case.  I know there are many such "super-tight" networks, but I just don't see how we can reasonably accommodate their use-case in this WG.  And I'm pointing out that we really are following their policies, inasmuch as WebRTC media will fail to escape their network - I would be far more worried if we somehow bypassed their policies instead.  At least this way it's similar behavior they get for unknown/unauthorized applications, which is arguably what going to random websites and running downloaded javascript is equivalent to.

-hadriel