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

On 2013-02-02 11:31, Harald Alvestrand wrote:
> 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).

OK. Here is a shot at it:

Fnn: The browser MUST be able to send streams and                   data 
to a peer in such a fashion that the peer is not (e.g. by inspection of 
packets belonging to the streams or data or any associated signaling 
messages) able to find out the xxxxx IP address used by the browser

There has been some discussion of xxxxx; is it needed, and if so, what 
should it say? "host"? "local"?

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

Yes, that is simple if we could get Fnn done...

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