IETF Logo Mail Archive

Re: [rtcweb] Revealing IP addresses (Re: Review of draft-ietf-rtcweb-use-cases-and-requirements-10 (Part II))

Harald Alvestrand <harald@alvestrand.no> Sat, 02 February 2013 10:31 UTC

Return-Path: <harald@alvestrand.no>
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 1309221F907C for <rtcweb@ietfa.amsl.com>; Sat, 2 Feb 2013 02:31:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.424
X-Spam-Level:
X-Spam-Status: No, score=-110.424 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E+Wnc7LKRj9M for <rtcweb@ietfa.amsl.com>; Sat, 2 Feb 2013 02:31:29 -0800 (PST)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 4B1AE21F907A for <rtcweb@ietf.org>; Sat, 2 Feb 2013 02:31:29 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E5E4339E140 for <rtcweb@ietf.org>; Sat, 2 Feb 2013 11:31:26 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dL0St-E2MPH8 for <rtcweb@ietf.org>; Sat, 2 Feb 2013 11:31:26 +0100 (CET)
Received: from [IPv6:2001:470:de0a:27:ed70:e47d:914f:d71e] (unknown [IPv6:2001:470:de0a:27:ed70:e47d:914f:d71e]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id D05F539E04C for <rtcweb@ietf.org>; Sat, 2 Feb 2013 11:31:25 +0100 (CET)
Message-ID: <510CEAF9.6020509@alvestrand.no>
Date: Sat, 02 Feb 2013 11:31:21 +0100
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <50F97303.4070906@ericsson.com>, , , <CABkgnnWcqZ+dU+87djBQ0z47ufB-Go13mWyPi_ZQA8BPinQJEA@mail.gmail.com>, , <BLU002-W1705DC54006131B55B432A931F0@phx.gbl>, <BLU002-W210B8DBB897CAF5BECC501A931F0@phx.gbl>, <5109265F.6040106@ericsson.com> <BLU002-W123BE6BAA58BE0B26DEA28F931E0@phx.gbl> <510B9A41.8000804@ericsson.com> <510B9FD8.6000008@alvestrand.no> <510BB070.9040602@ericsson.com>
In-Reply-To: <510BB070.9040602@ericsson.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
Subject: Re: [rtcweb] Revealing IP addresses (Re: Review of draft-ietf-rtcweb-use-cases-and-requirements-10 (Part II))
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, 02 Feb 2013 10:31:30 -0000

On 02/01/2013 01:09 PM, Stefan Håkansson LK wrote:
> On 2013-02-01 11:58, Harald Alvestrand wrote:
>> On 02/01/2013 11:34 AM, Stefan Håkansson LK wrote:
>>>>
>>>>     A25             It must be possible for the application to
>>>>                     refrain from exposing the IP address
>>>>
>>>> [BA] I am assuming we are talking about exposing the originating IP
>>>> address of media, which can be addressed via TURN.
>>>> If so, this is more of a protocol than an API requirement. Since the
>>>> ICE candidates need to exposed in the API in
>>>> order to allow them to be signaled, I am not sure how we can avoid
>>>> exposing those to the application.  Similarly, the
>>>> HTTP server can obtain the IP address used by the HTTP client. Even
>>>> within SIP, there are VIA headers and contact
>>>> headers, so it is not easy to avoid disclosure of the IP address to
>>>> everyone.  So I think we need to be more clear
>>>> about what we are trying to avoid exposing, and to whom.
>>>
>>> Personally I would like to get rid of this requirement. The
>>> application can always get all candidates. To have a way to let the
>>> application ask for _only_ the TURN candidates does not change this -
>>> that kind of API is more for convenience (so that the app you trust
>>> does not have to remove privacy revealing candidates from the offer,
>>> but can instead ask the browser to deliver an offer without them).
>> I think this requirement is important, but needs reformulation.
>>
>> Should we instead say
>>
>> "It MUST be possible to set up a call between two parties A and B
>> without one party learning the other party's IP address"
>
> This requirement is not on the browser (or its APIs) per se, if we go 
> this path it almost belongs into another category than what we 
> currently have.

I think it is, actually - the A browser has to be able to send media to 
B without sending IP packets to B, which means that it has to use an 
intermediary, and force B to use an intermediary too. TURN does that, we 
could imagine other solutions (the people who made Tor could probably 
think of many more schemes).

The API requirement is that the application should be able to request 
that functionality.

v2.23.0 | Report a Bug | By Email