Subject: Re: [rtcweb] WG Last Call: draft-ietf-rtcweb-use-cases-and-requirements-10

From: Harald Alvestrand <[email-masked]>
Date: Fri, 01 Feb 2013 10:06:38 +0100

On 02/01/2013 01:16 AM, Martin Thomson wrote:
> On 31 January 2013 21:30, Harald Alvestrand <[email-masked]> wrote:
>> I can think of a reasonably easy test that generates the signal (read a mono
>> sound from a file to a mediastream using the MediaSource interface, feed it
>> to the WebAudio API, apply spatialization effects using the WebAudio API),
>> but I'm not sure how you test whether spatialization is actually performed
>> correctly. But writing that test should be a W3C matter.
> Maybe I'm reading too much into this, but spatialization effects are
> used for several reasons: for arrangements of multiple microphones in
> the same room, they can be necessary to get proper stereo audio.  In
> order to do this based on microphone configuration, you need
> signaling.  If all you are looking for is the ability to spatially
> separate different speakers, that clarification might help.

Aha - I was reading the use case as "you want to place different 
speakers at different positions in the virtual audio space" only - seems 
that the word "spatialization" means more than that. Thanks!

>
>>>>>       F7              The browser MUST support fast stream switches.
> ...
>> Specified further (yes) or removed (yes)?
> Yes.  As in pick one and I care little which that is.
>
>>>> TURN/TLS will satisfy this requirement.
>>> This is not always true :)
>> What's the case when it isn't?
> Some firewalls use traffic analysis to identify real-time data that
> has been tunneled over HTTP CONNECT.

Yes, argh :-( - I could argue that these fall outside the use case, or I 
could argue that the requirement should be described well enough to make 
it not a MUST to be able to avoid these firewalls.

You can't win them all.... and we're not designing the Universal Policy 
Defeater here.

>
>> I don't read "make before break" either, but that's obviously preferable.
>> Now that I dig further back into my memory, I think ICE restart is supposed
>> to support make-before-break; you don't have to turn off the old path before
>> the new has checked out usable.
> ICE restart can do that, but there is no guarantee that triggering a
> restart will result in a change of network interface.  Further clarity
> on the requirement may be necessary to say that it be *possible* to do
> this.
I think the normal case is "this interface stopped working, can you find 
me another one?".
The less normal case is "I know both 3G and WiFi are working, but I 
still want to use 3G".

If you can tell which IP address belongs to which interface, ICE restart 
+ keeping control of which candidates you allow through to the other 
side would enable you to control that (albeit hackishly).

---

From: Stefan Håkansson LK <[email-masked]>
Date: Fri, 1 Feb 2013 11:12:11 +0100

> separate different speakers, that clarification might help.

I agree, we should clarify. But I think many of the requirements are 
similar in this respect: just reading the requirement itself is not 
sufficient, you need to read the use-case from which it was derived to 
get the context and fully understand.

> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Stefan Håkansson LK <[email-masked]>
Date: Fri, 1 Feb 2013 11:19:18 +0100

On 2013-01-30 20:30, Bernard Aboba wrote:
>  > To me it means that the browser should not congest the network (and this
>  > is regardless of what the possibly malicious app does).
>
> [BA]  Today we have three potential approaches that might be relevant to
> this general concern:
>
> a. Consent.  If a receiver is being inundated, they can refuse to
> response to ICE keepalives, thereby causing a compliant sender to stop
> sending.
> b. Circuit breakers.  As I understood it, the goal of this document was
> to prevent congestive collapse in a number of situations.   However,
> circuit breakers aren't a complete solution to congestion control, so
> the resulting behavior might not be considered "fair" and also it wasn't
> clear to me that high packet loss/low throughput would be avoided in all
> situations.
> c. Congestion control (RMCAT).  This is a solution to the congestion
> control problem, not just DDOS or worst-case congestive collapse.  Since
> it covers more ground it is more of a long-term solution than a or b.
>
> I would like the requirement to be a bit more specific so that we can be
> clear which of a, b and/or c address the concern.   Solution a is more
> of a response to DDOS issues than congestion control per se.   Solution
> b is designed to address some worst case outcomes, though not
> necessarily all of them.   Solution c is the long-term solution, but it
> may not be available within the same time frame as a or b.

I agree to the above, but could we not let the requirement remain as is? 
Instead, when we some time in the future compare what the WG has 
specified as solutions with the requirement we can say that this 
requirement is initially met by a. and b., and c. will be added in a 
later release.

I am not very keen on keep updating the requirements based on the 
solutions we discuss/opt for. We then risk to lose sight on the original 
reason for the requirement.

>
>  > > Please note that the requirements specified in this document are to
>  > > be used in evaluating... protocol submissions. As such, the
>  > > requirements language refers to capabilities of these protocols; the
>  > > protocol documents will specify whether these features are required,
>  > > recommended, or optional. For example, requiring that a protocol
>  > > support confidentiality is NOT the same thing as requiring that all
>  > > protocol traffic be encrypted.
>  >
>  > This makes a lot of sense.
>
> [BA] Feel free to tweak the wording above to the needs of RTCWEB.  IETF
> Requirements documents are often used for different purposes, so one
> size doesn't necessarily fit all.  For example, the RFC 2989 language
> above was created to provide guidelines for selection between competing
> protocol proposals.  In that particular situation, meeting more
> requirements was "better" but it wasn't necessarily expected that the
> "winner" would meet all requirements.  Other WGs have created
> requirements documents to guide protocol development and enable
> identification of missing work.  In those situations, it isn't
> necessarily expected that an initial document set will cover all the
> bases, though there may be an expectation that major holes will get
> covered somehow at some point.

OK, thanks for this input - it is helpful.

---

From: Stefan Håkansson LK <[email-masked]>
Date: Fri, 1 Feb 2013 11:34:41 +0100

On 2013-01-30 21:02, Bernard Aboba wrote:
>  > > [BA] Can I assume that the use of the plural implies a requirement
> to be able to support multiple sources?
>  >
>  > Yes. And in the use-case "Hockey Game Viewer" multiple cameras are used.
>
> [BA] OK.  General question:  is this something that needs to be
> supported in v1.0 (e.g. we need to figure out how multiple source
> negotiation works immediately) or can it wait until later?  For me, that
> question is helpful in distinguishing MUSTs (things we need to have to
> either provide basic capabilities, avoid damage to the Internet, or
> attain interoperability) from lesser levels like SHOULD (things it would
> be very useful to have, but perhaps are not needed immediately).

You're right, we should discuss if this is needed for v1 or not. 
Personally I think we should have support for multiple sources from v1.

>
>  > > [BA] I am not sure what this means. Is it implying the need for a
> strategy to deal with loss in the MTI codec?
>  > > For example, is this implying a requirement for codec adaption,
>  > > or FEC or re-transmission? I don't see the purpose of letting the
> TBD remain here.
>  >
>  > The TBD could go; my interpretation is that at the very least there
> should be some PLC implemented.
>
> [BA] OK.  It might be helpful to be a bit more specific about what might
> address this requirement, assuming we can come to agreement on it.

OK.

>
>  > > [BA] What does "graceful" mean?? Is this referring to the
> resilience of the codec and
>  > > loss-strategy (see above), or to enabling the application to adapt
> to loss?
>  >
>  > I agree. This is very vague. I think that what was in mind at the time
>  > was that the browser should not be worse than existing native clients
>  > during bad network conditions (e.g. strange high level audio sounds that
>  > comes from decoding erroneous data should not be played). I think this
>  > req could go.
>
> [BA] I think that this requirement is probably covered adequately by
> other ones so it can be omitted.

I agree.

>
>  > > [BA] I really am not sure what is meant here. Are we talking about
> the ability of a sender to change
>  > > transmission rate quickly (e.g. removing a layer in SVC)? Or about
> adding/removing a stream?
>  >
>  > This requirement is derived from the "Video conferencing system with
>  > central server" use-case. The intention was to say something like "if
>  > the central node asks for an intraframe, the browser should insert it".
>
>  > > [BA] Synchronization is not necessarily possible or even desirable
> in all circumstances.
>  > > For example, if the video experiences substantial loss, do you
> really want to delay the audio to sync
>  > > with it? So I can understand why it is desirable to support the
> capability, but is this
>  > > really a MUST? I would not bother to attempt to answer the
> question; delete it.
>  >
>  > You're right: in some cases it is better to not synchronize. But I still
>  > think the browser MUST support it (even if not used in certain cases).
>
> [BA] I agree with the "MUST support" formulation.

OK.

>
>  > > ----------------------------------------------------------------
>  > > F18 The browser MUST be able to process and mix
>  > > sound objects (media that is retrieved from
>  > > another source than the established media
>  > > stream(s) with the peer(s) with audio streams.
>  > >
>  > > [BA] If this is done, isn't it important to make clear to the user
> (and perhaps the peer) what is happening?
>  > > Confusing live and recorded media seems like a potential vector for
> mischief.
>  >
>  > This is derived from the use-case "Multiparty on-line game with voice
>  > communication". Are you saying that the browser should inform the user
>  > that the "boom" sound comes from the explosion on the game scene, while
>  > the voice comes from his friend that is playing the same game? I don't
>  > see that need.
>
> [BA] I agree that it is silly in a game scenario.  But in an emergency
> call, knowing that the video of a hostage situation isn't live would be
> pretty important.

I agree, but I feel that we're now starting to put requirements on the 
service rather than the browser or its APIs.

>
>  > > [BA] "Wiretapping" is too vague a phrase to be of much use. It
> might make more sense to
>  > > talk about security services that should be provided (e.g.
> confidentiality of media).
>  >
>  > This was discussed a bit, and someone (Harald?) pointed out that
>  > wiretapping is well defined and can be used.
>
> [BA] If we can refer to a definition this would be helpful in clarifying
> the requirement.

I think Harald answered this one; but I agree that we should reference.

>
>  > > ----------------------------------------------------------------
>  > > F26 It MUST be possible to move from one network
>  > > interface to another one
>  > > [BA] Are we talking about the ability of an application to control
> this, or the ability of an application to react to it, or something else?
>  >
>  > It is not split up between application, browser, STUN/TURN server, it is
>  > just a requirement on that it should work.
>
> [BA] My question is whether existing ICE/STUN/TURN RFCs are sufficient
> or whether extensions such as ICE Mobility are required to meet this
> requirement.

Again, I think we should leave the requirement as is (being a bit vague 
and generic), let the WG design a solution (which now seems to be 
ICE/STUN/TURN) and then come back and say that this req is met by that 
solution, and it gives the following characteristics.

>
>  > > ----------------------------------------------------------------
>  > > F35 The browser MUST enable verification, given
>  > > the right circumstances and by use of other
>  > > trusted communication, of that streams and
>  > > data received have not been manipulated by
>  > > any party.
>  > > [BA] I do not see how such a verification is possible.
>  >
>  > I was under the impression that DTLS allowed this.
>
> [BA] DTLS/SRTP can verify that there is no man-in-the-middle.  But it
> doesn't address modification by an endpoint that is a media gateway.

Yes, but the browser will (to my understanding) make the fingerprints 
available to the users (at request), and they can then detect if there 
are other end-points in the path. So it is possible "under the right 
circumstances".

> Also, there is the replay vs. live issue.

Yes, that is one issue.

>
>  > > ----------------------------------------------------------------
>  > > F36 The browser MUST reject incoming media and
>  > > data, either modified, created or injected,
>  > > by any entity not trusted by the site.
>  > >
>  > > [BA] Do we really mean "trusted by the site" or "trusted by the
> browser"?
>  >
>  > I need to think a bit more about this one.
>
> [BA] While the security document advises the use of HTTPS for signaling,
> it doesn't prohibit use of HTTP.  Also, for media there probably will be
> scenarios where the client is unauthenticated, even if the server is
> authenticated (e.g. DTLS/SRTP with asymmetric trust).   My advice is to
> reformulate this as a requirement for support of {media, signaling}
> authentication/integrity protection, rather than use.

We need to look into that.

>
> One last question, about A25:
>
>     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).

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 01 Feb 2013 11:58:32 +0100

On 02/01/2013 11:34 AM, Stefan Håkansson LK wrote:
>> [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
> 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 doesn't place any requirement that the signalling server should be 
kept in the dark.

---

From: Stefan Håkansson LK <[email-masked]>
Date: Fri, 1 Feb 2013 13:09:20 +0100

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

---

From: Emil Ivov <[email-masked]>
Date: Fri, 01 Feb 2013 13:14:09 +0100

> this path it almost belongs into another category than what we currently 

Well, if we agree that we care about the requirement itself, then the
browser has to generate SDP with no host addresses and use 0.0.0.0 instead.

(Unless we are OK with the application parsing and modifying the SDP
before sending it)

Emil

-- 
https://jitsi.org

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 1 Feb 2013 04:25:48 -0800

This reformulation seems closer to what we are trying to do. 

On Feb 1, 2013, at 2:58 AM, "Harald Alvestrand" <[email-masked]> wrote:

>> 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).
> "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 doesn't place any requirement that the signalling server should be kept in the dark.
>

---

From: Barry Dingle <[email-masked]>
Date: Sat, 2 Feb 2013 00:19:42 +1100

Good point Harald regarding F.700 A.3.2.3 calling up "font support for *all
characters* in ISO-10646-1".

I suspect that the reference to F.700 was to the service and performance
requirements of a range of multimedia services. I am not aware of another
'more suitable' set of Service Requirements document that we can reference.
F.700 (and F.703) are frequently referenced - but some people probably
quietly ignore the full implications of A.3.2.3.

So we need to capture the 'general service requirements' but remove any
parts of F.700 (or F.703) that are not applicable.

As the proposed additional use-case just adds RTT to the video+audio, I
suggest that we just add the (selected) RTT Requirements that suit rtcweb
to the use-case and maybe put an informational note to F.700 and F.703.

Cheers,
/Barry Dingle

On Fri, Feb 1, 2013 at 10:07 AM, Harald Alvestrand <[email-masked]>wrote:

>  FWIW, I strongly object to a couple of formalities here:
>
> - I object to making normative reference to F.700 and F.703.
> - I object to requiring interworking with emergency services.
>
> If there's strong support in the WG for including the use case, I'm
> willing to go along with that.
>
> (The reason for not wanting to normatively reference F.700 and F.703 is
> that they're very large balls of string, and I have no idea where the
> string may lead; for instance, the definition of "Total Conversation" in
> section A.3.2.3 of F.700 requires font support for all characters in
> ISO-10646-1; I doubt somewhat that the person who wrote that paragraph has
> studied the task of providing such font support - I found that particular
> linkage in a few minutes of scanning the docs.)
>
>
> On 01/30/2013 10:15 PM, Gunnar Hellstrom wrote:
>
> 4.2.15.  Simple Total Conversation service****
>
> 4.2.15.1.  Description****
>
> ** **
>
>    This use-case has the audio and video communication of the Simple****
>
>    Video Communication Service use-case (Section 4.2.1 <http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-09#section-4.2.1>).****
>
> ** **
>
>    In addition to this, the users can send and receive real-time text
>    in the same call.**** While one user types in the real-time text area, it****
>
>    is nearly immediately presented to the other user.
>
>    By providing these three media together, the Total Conversation
>    service is provided.
>
>    Interworking with SIP calls with the same media set, and with SIP
>    based emergency services is also in scope of this use case. ****
>
> ** **
>
> 4.2.15.2.  Derived Requirements****
>
> ** **
>
>    F1, F2, F3, F4, F5, F6, F8, F9, F10, F20, F21,****
>
> ** **
>
>    F39,F40, F41****
>
> ** **
>
>    A1, A2, A3, A4, A7, A8, A9, A10, A11, A12, A27****
>
> ** **
>
> ..............
>
>    F39             The browser MUST be able to handle text entry****
>
>                    via applications to generate real-time                    text streams to be included in Total Conversation
>                    calls. Real-time text and Total Conversation
>                    Services are defined in ITU-T F.700 and F.703. ****
>
>    ----------------------------------------------------------------****
>
>    F40              The browser MUST be able to send real-time text ****
>
>                    streams to a peer.****
>
> ** **
>
>    ----------------------------------------------------------------****
>
>    F41              The browser MUST be able to receive, process and****
>
>                     convey real-time text streams from peers to
>                     applications.****
>
>    ----------------------------------------------------------------****
>
>    ****
>
> **
>
> .....
> **   A27             The Web API MUST provide a mechanisms for ****
>                    handling real-time text among the streams.****
>  ----------------------------------------------------------------****
>
>
>

---

From: [email-masked] (Dale R. Worley)
Date: Fri, 1 Feb 2013 17:43:48 -0500 (EST)

> From: Harald Alvestrand <[email-masked]>
> 
> [...]

Can you explain this?  I suspect that you have a specific meaning, but
as I read it, it sounds like "I see no objection if WebRTC does not
interwork with emergency services."  If WebRTC does not interwork with
emergency services, the regulators will crush it.

Dale

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 1 Feb 2013 15:28:26 -0800

With regulations in flux, it is not easy to predict the extent of the obligation, beyond what exists for an "interconnected VoIP" service today.  For example, we have a text to 911 proceeding ongoing as well as quite a few others. In order to examine what the Issues might be, Martin and I put together the following document:
http://tools.ietf.org/html/draft-aboba-rtcweb-ecrit

Comments welcome.

---

From: Gunnar Hellstrom <[email-masked]>
Date: Sat, 02 Feb 2013 00:39:35 +0100

Harald,

You are right, the requirements on audio and video in the rtcweb use 
cases are not at all at the detail service quality level that 
F.700/F.703 are.
They merely talk about good audio and good video. So, we should align 
the real-time text and total conversation requirements to something 
similar to that level, and move details to the RTT or total conversation 
document.

It might be good to include a definition of the concepts of rea-time 
text and total conversation.

Mentioning F.700/F.703 in a note can add further high level explanations 
as Barry hints.

You are also right about the point about not requirig emergency service 
interoperability only for real-time text or total conversation. That is 
a general issue that should be considered and mentioned in a way so that 
real-time text and total conversation access to emergency services are 
included if emergency service access for video and audio is specified.

The requirement for emergency service access was not strictly expressed. 
It was "

Interworking with SIP calls with the same media set, and with SIP
    based emergency services is also in scope of this use case."

I do not see "is in scope" to lead to a "shall" requirement. It rather corresponds to "should be considered".

Some voices during the last call process for this document has been for more strict requirements wording.
So we need to make it clear what is requirements and what is for information.

I realize well that in some applications of RTCWEB, it will be obvious that there cannot be any expectation
that it could be used for emergency calls, and for such situations the emergency call requirement should not
be applied.

It seems to be valid to try to split the requirements in direct technical requirements on rtcweb, and
requirements on services made with RTCWEB.

Here is an effort to revise the proposed additions.

---------------------------Proposed addition to use cases and requirements -------------------

3. Definitions

Real-time text 		Text transmitted instantly while it is being typed or created, so that the recipient
			can read the sender's text as it is written, without waiting.  		
  
Total conversation	An audiovisual conversation service providing bidirectional real-time transfer of
			motion video, real-time text and audio between users in two or more locations.
			Note: High level information on real-time text and total conversation can be found in
			ITU-T F.700 and ITU-T F.703.

> 4.2.15.Simple Total Conversation service
>
> 4.2.15.1.Description
>   
>     This use-case has the audio and video communication of the Simple
>     Video Communication Service use-case (Section 4.2.1  <http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-09#section-4.2.1>).
>   
>     in the same call.  While one user types in the real-time text area, it
> 4.2.15.2.   Derived Requirements
>   
>     F1, F2, F3, F4, F5, F6, F8, F9, F10, F20, F21,
>   
>     F39,F40, F41
>   
>     A1, A2, A3, A4, A7, A8, A9, A10, A11, A12, A27
>   
> ..............
>
>     F39              The browser MUST be able to handle text entry
>                     via applications to generate real-time
>                     text streams to be included in Total Conversation
>                     calls.       
>     F40              The browser MUST be able to send real-time text
>                     streams to a peer.
>        
>   
>     F41               The browser MUST be able to receive, process and
>                      applications.
>     A27              The Web API MUST provide a mechanisms for  
>                     handling real-time text among the streams.  
>   .......

11.2 Informative references

[ ]    ITU-T Recommendation F.700 Framework Recommendation for 
multimedia services

[ ]    ITU-T Recommendation F.703    Multimedia Conversational Services

----------End of proposal--------------------------------------------------------------

/Gunnar

------------------------------------------------------------------------
Gunnar Hellström
Omnitor
[email-masked]
+46708204288
On 2013-02-01 14:19, Barry Dingle wrote:
> Good point Harald regarding F.700 A.3.2.3 calling up "font support for 
> _all characters_ in ISO-10646-1".
>
> I suspect that the reference to F.700 was to the service and 
> performance requirements of a range of multimedia services. I am not 
> aware of another 'more suitable' set of Service Requirements document 
> that we can reference. F.700 (and F.703) are frequently referenced - 
> but some people probably quietly ignore the full implications of A.3.2.3.
>
> So we need to capture the 'general service requirements' but remove 
> any parts of F.700 (or F.703) that are not applicable.
>
> As the proposed additional use-case just adds RTT to the video+audio, 
> I suggest that we just add the (selected) RTT Requirements that suit 
> rtcweb to the use-case and maybe put an informational note to F.700 
> and F.703.
>
> Cheers,
> /Barry Dingle
>
>
>
> On Fri, Feb 1, 2013 at 10:07 AM, Harald Alvestrand 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     If there's strong support in the WG for including the use case,
>     I'm willing to go along with that.
>
>     (The reason for not wanting to normatively reference F.700 and
>     F.703 is that they're very large balls of string, and I have no
>     idea where the string may lead; for instance, the definition of
>     "Total Conversation" in section A.3.2.3 of F.700 requires font
>     support for all characters in ISO-10646-1; I doubt somewhat that
>     the person who wrote that paragraph has studied the task of
>     providing such font support - I found that particular linkage in a
>     few minutes of scanning the docs.)
>
>
>>     4.2.15.Simple Total Conversation service
>>
>>     4.2.15.1.Description
>>       
>>         This use-case has the audio and video communication of the Simple
>>         Video Communication Service use-case (Section 4.2.1  <http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-09#section-4.2.1>).
>>       
>>         in the same call.  While one user types in the real-time text area, it
>>         based emergency services is also in scope of this use case.
>>       
>>     4.2.15.2.   Derived Requirements
>>       
>>         F1, F2, F3, F4, F5, F6, F8, F9, F10, F20, F21,
>>       
>>         F39,F40, F41
>>       
>>         A1, A2, A3, A4, A7, A8, A9, A10, A11, A12, A27
>>       
>>     ..............
>>
>>         F39              The browser MUST be able to handle text entry
>>                         via applications to generate real-time
>>                         text streams to be included in Total Conversation
>>                         Services are defined in ITU-T F.700 and F.703.
>>         F40               The browser MUST be able to send real-time text
>>                         streams to a peer.
>>       
>>         F41               The browser MUST be able to receive, process and
>>                          applications.
>>         A27              The Web API MUST provide a mechanisms for  
>>                         handling real-time text among the streams.  
>     [email-masked] <mailto:[email-masked]>

---

From: Gunnar Hellstrom <[email-masked]>
Date: Sat, 02 Feb 2013 01:13:52 +0100

It is easy to imagine applications of WebRTC where the users will not 
have any expectation that they could use it for emergency services.
E.g. a web page only providing access to a specific company's customer 
service.
So, each application does not need to provide this access.

However, the platform has apparent ambitions to be possible to use for 
telephony like applications, with an opportunity to call by address or 
number,
E.g
4.3.1 
<http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-10#section-4.3.1>. 
Telephony terminal

In at least that case, there will be an expectation from users, and a 
requirement from regulators in many countries to be able to provide 
emergency service access.

So, the topic belongs here in some way.

I withdrew it from the total conversation addition, because it is a 
general function. I hope it will be possible to find a suitable place 
and general wording for it, and there indicate that it is valid for all 
media, including audio, video and real-time text.

Gunnar
------------------------------------------------------------------------
Gunnar Hellström
Omnitor
[email-masked]
+46708204288
On 2013-02-02 00:28, Bernard Aboba wrote:
> With regulations in flux, it is not easy to predict the extent of the 
> obligation, beyond what exists for an "interconnected VoIP" service 
> today.  For example, we have a text to 911 proceeding ongoing as well 
> as quite a few others. In order to examine what the Issues might be, 
> Martin and I put together the following document:
> On Feb 1, 2013, at 14:44, "Dale R. Worley" <[email-masked] 
> <mailto:[email-masked]>> wrote:
>>>
>>

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 1 Feb 2013 16:54:37 -0800

While we didn't go into it in any depth in the document, there does seem to be a distinction between scenarios in which the application developer has little control over the endpoint (e.g. bring your own device), versus scenarios in which the application developer has some say or influence on what the capabilities of the endpoints are.

In the former case, the application may have to function even in a browser environment where WebRTC is not available, whereas in the latter case, the application developer can ensure that a set of required capabilities are available.  The "telephony terminal" case seems more in the latter category than the former. 

For example, a vendor developing a "telephony terminal" could choose the browser they wanted to embed in the device, and might even have access to the browser source code, so as to be able to add codecs and other capabilities.   In that case, the performance and extensibility of the code base will be an important consideration, since that will determine how much work will be involved to add capabilities and what the options are for accomplishing this (e.g. native code required vs. Javascript). 

Date: Sat, 2 Feb 2013 01:13:52 +0100
From: [email-masked]
To: [email-masked]
Subject: Re: [rtcweb] Playing regulator

  
    It is easy to imagine applications of
      WebRTC where the users will not have any expectation that they
      could use it for emergency services. 

      E.g. a web page only providing access to a specific company's
      customer service.

      However, the platform has apparent ambitions to be possible to use
      for telephony like applications, with an opportunity to call by
      address or number,

      E.g  

      4.3.1.
      Telephony terminal 

      In at least that case, there will be an expectation from users,
      and a requirement from regulators in many countries to be able to
      provide emergency service access.

      I withdrew it from the total conversation addition, because it is
      a general function. I hope it will be possible to find a suitable
      place and general wording for it, and there indicate that it is
      valid for all media, including audio, video and real-time text.

      Gunnar

        Gunnar Hellström

        Omnitor

        +46708204288

    
      
      With regulations in flux, it is not easy to predict the
        extent of the obligation, beyond what exists for an
        "interconnected VoIP" service today.  For example, we have a
        text to 911 proceeding ongoing as well as quite a few others. In
        order to examine what the Issues might be, Martin and I put
        together the following document:
      http://tools.ietf.org/html/draft-aboba-rtcweb-ecrit

      Comments welcome.

      
      On Feb 1, 2013, at 14:44, "Dale R. Worley" <[email-masked]>
        wrote:

        Can you explain this?  I suspect that you have a specific
          meaning, but

        as I read it, it sounds like "I see no objection if WebRTC
          does not

        interwork with emergency services."  If WebRTC does not
          interwork with

        Dale

        rtcweb mailing list

        [email-masked]

---

From: "Richard Shockey" <[email-masked]>
Date: Fri, 1 Feb 2013 20:22:41 -0500

+1

http://transition.fcc.gov/cgb/dro/cvaa.html

I hope you enjoy being amateur telecom lawyers.  Some of us are getting
pretty good at it. 

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Bernard Aboba
Sent: Friday, February 01, 2013 7:55 PM
To: Gunnar Hellstrom; [email-masked]
Subject: Re: [rtcweb] Playing regulator

While we didn't go into it in any depth in the document, there does seem to
be a distinction between scenarios in which the application developer has
little control over the endpoint (e.g. bring your own device), versus
scenarios in which the application developer has some say or influence on
what the capabilities of the endpoints are.

In the former case, the application may have to function even in a browser
environment where WebRTC is not available, whereas in the latter case, the
application developer can ensure that a set of required capabilities are
available.  The "telephony terminal" case seems more in the latter category
than the former. 

For example, a vendor developing a "telephony terminal" could choose the
browser they wanted to embed in the device, and might even have access to
the browser source code, so as to be able to add codecs and other
capabilities.   In that case, the performance and extensibility of the code
base will be an important consideration, since that will determine how much
work will be involved to add capabilities and what the options are for
accomplishing this (e.g. native code required vs. Javascript). 

  _____  

It is easy to imagine applications of WebRTC where the users will not have
any expectation that they could use it for emergency services. 
E.g. a web page only providing access to a specific company's customer
service.
So, each application does not need to provide this access.

<http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-10#
section-4.3.1> 4.3.1. Telephony terminal 

I withdrew it from the total conversation addition, because it is a general
function. I hope it will be possible to find a suitable place and general
wording for it, and there indicate that it is valid for all media, including
audio, video and real-time text.

Gunnar

  _____  

Gunnar Hellström
Omnitor

With regulations in flux, it is not easy to predict the extent of the
obligation, beyond what exists for an "interconnected VoIP" service today.
For example, we have a text to 911 proceeding ongoing as well as quite a few
others. In order to examine what the Issues might be, Martin and I put
together the following document:

Comments welcome.

Dale

_______________________________________________ rtcweb mailing list
[email-masked] https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Harald Alvestrand <[email-masked]>
Date: Sat, 02 Feb 2013 11:31:21 +0100

On 02/01/2013 01:09 PM, Stefan Håkansson LK wrote:
> 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.

---

From: Stefan Håkansson LK <[email-masked]>
Date: Sat, 2 Feb 2013 13:56:52 +0100

> 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

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

---

From: Harald Alvestrand <[email-masked]>
Date: Sat, 02 Feb 2013 19:51:37 +0100

On 02/02/2013 01:56 PM, Stefan Håkansson LK wrote:
> 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
>

The security property that has most often been expressed is that the 
correspondent should not be able to use the IP address to geolocate the 
user; this means that the most important value of "xxxx" is the globally 
routable IP address that is closest to the user's location.

Some have also mentioned the need to hide local (RFC 1918) IP addresses 
in order to prevent mapping of the user's internal network; I think this 
is usually seen as a less dramatic threat.

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 2 Feb 2013 12:48:57 -0800

On Sat, Feb 2, 2013 at 10:51 AM, Harald Alvestrand <[email-masked]>wrote:

> Some have also mentioned the need to hide local (RFC 1918) IP addresses in
> order to prevent mapping of the user's internal network; I think this is
> usually seen as a less dramatic threat.

1. If you don't want the server learning your global IP, you need to use
Tor or the like.
2. I would suggest that it is simplest to divide the world into host
addresses, server/peer
reflexive, and relayed and say that the requirement is that the browser
must be able
to send packets without revealing either of the former two, but that it is
not a requirement
that it be able to do so in the face of an adversarial server.

Note that S 5.4 of the security arch document has some specific
requirements on
implementations phrased in terms of the technologies we have actually
chosen.

-Ekr

---

From: Burger Eric <[email-masked]>
Date: Sun, 3 Feb 2013 10:32:03 -0500

Is what we are really asking for is the ability of the protocol to be TOR-, TURN-, and mumble-friendly? I am hesitant to suggest we bake in one particular anonymity network or another into the RTCweb protocol suite.

On the one hand, with my purist hat on, saying it is a requirement to make sure we do not need to have end-to-end connectivity smells a bit weird.

On the other hand, with my practical hat on, saying it is a requirement to make sure the protocol works in situations that are NOT the Internet (NATs, a need for an overlay privacy network, etc.) seems like a good thing to do.

On Feb 2, 2013, at 3:48 PM, Eric Rescorla <[email-masked]> wrote:

> On Sat, Feb 2, 2013 at 10:51 AM, Harald Alvestrand <[email-masked]> wrote:
> 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 security property that has most often been expressed is that the correspondent should not be able to use the IP address to geolocate the user; this means that the most important value of "xxxx" is the globally routable IP address that is closest to the user's location.
> 
> Some have also mentioned the need to hide local (RFC 1918) IP addresses in order to prevent mapping of the user's internal network; I think this is usually seen as a less dramatic threat.
> 
> 1. If you don't want the server learning your global IP, you need to use Tor or the like.
> 2. I would suggest that it is simplest to divide the world into host addresses, server/peer
> reflexive, and relayed and say that the requirement is that the browser must be able
> to send packets without revealing either of the former two, but that it is not a requirement
> Note that S 5.4 of the security arch document has some specific requirements on
> implementations phrased in terms of the technologies we have actually chosen.
> 
> -Ekr
> 
>

---

From: Eric Burger <[email-masked]>
Date: Sun, 3 Feb 2013 10:43:22 -0500

Is the goal to make RTCweb as complex as possible to meet an irrelevant use case, while ensuring we bring various regulatory agencies into our pants?

Last I looked, RTCweb is about the Web.  Why try to bring legacy telco/ecrit requirements into an application that 99.8% of the time has no interaction with classic emergency services? If someone will build a "telephony terminal," they are already into regulation land, and will build this descendant of Zaphod Beeblebrox appropriately. I agree that there is no reason to make it harder for someone to build a regulated device with RTCweb protocols. However, I also do not see any reason to postpone RTCweb by 3-5 more years as we try to second guess regulatory requirements. Worse yet, we would be asking for regulators to insert themselves into the protocol development process. That is all we need - the next thing they will do is require voting by governments on protocol components! Might as well move the work to the ITU-T so we do not distract people working on the Internet from getting useful work done here in the IETF.

On Feb 1, 2013, at 7:54 PM, Bernard Aboba <[email-masked]> wrote:

> It is easy to imagine applications of WebRTC where the users will not have any expectation that they could use it for emergency services. 
> E.g. a web page only providing access to a specific company's customer service.
> However, the platform has apparent ambitions to be possible to use for telephony like applications, with an opportunity to call by address or number,
> E.g  
> 4.3.1. Telephony terminal 
> 
> In at least that case, there will be an expectation from users, and a requirement from regulators in many countries to be able to provide emergency service access.
> 
> I withdrew it from the total conversation addition, because it is a general function. I hope it will be possible to find a suitable place and general wording for it, and there indicate that it is valid for all media, including audio, video and real-time text.
> 
> Gunnar
> Gunnar Hellström
> Omnitor
> _______________________________________________ rtcweb mailing list [email-masked]://www.ietf.org/mailman/listinfo/rtcweb

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 3 Feb 2013 10:32:57 -0800

On Sun, Feb 3, 2013 at 7:32 AM, Burger Eric <[email-masked]>wrote:

> Is what we are really asking for is the ability of the protocol to be
> TOR-, TURN-, and mumble-friendly? I am hesitant to suggest we bake in one
> particular anonymity network or another into the RTCweb protocol suite.
>

I'm certainly not suggesting that.

> On the one hand, with my purist hat on, saying it is a requirement to make
> sure we do not need to have end-to-end connectivity smells a bit weird.
>

I don't understand this... I don't think anyone is suggesting that.

> On the other hand, with my practical hat on, saying it is a requirement to
> make sure the protocol works in situations that are NOT the Internet (NATs,
> a need for an overlay privacy network, etc.) seems like a good thing to do.

As far as I know, the only novel requirement here is that there be a way
for Web
application to tell the browser to solely use relayed addresses/candidates
(and hopefully thus not reveal the user's actual location) when
communicating
with the peer. There is of course a requirement to be able to work when
behind NATs but that is a functional requirement, not an anonymity one.

WRT to the question of privacy networks such as Tor that isn't a requirement
on the protocol or the browser but rather the answer to the user's question
"how do I surf the net without revealing my IP address and location to
servers?" I.e., that is not a feature we intend to provide via WebRTC, but
rather one that the user needs to obtain for himself.

-Ekr

---

From: Eric Burger <[email-masked]>
Date: Sun, 3 Feb 2013 13:56:09 -0500

> 1. If you don't want the server learning your global IP, you need to use Tor or the like.

To me, this means it is totally orthogonal to RTCweb. If you want to use Tor, a TURN server, an ALG, or foo, that is up to you. That does not impact the protocol.

> that it be able to do so in the face of an adversarial server.
And this is the most reasonable. I guess the concern is we will forget all of this list discussion, and someone will require hard-coded endpoint IP addresses in the protocol, which is what sunk SIP in the early days.

Inline…

On Feb 3, 2013, at 1:32 PM, Eric Rescorla <[email-masked]> wrote:

> On Sun, Feb 3, 2013 at 7:32 AM, Burger Eric <[email-masked]> wrote:

Saying we will bake into the protocol the REQUIREMENT that it support good or bad boxes in the middle of the network does not sound like the end-to-end Internet. It sounds more like IMS.

>> As far as I know, the only novel requirement here is that there be a way for Web
>> (and hopefully thus not reveal the user's actual location) when communicating

That is asking an awful lot of an application. Moreover, as the cat-and-mouse game of anonymous application communication is ever evolving, I would challenge how meaningful it is to specify a Hidden Bit or Anonymous Bit in the protocol. I would offer that will work as well as the Evil Bit.

>> rather one that the user needs to obtain for himself.

Agreed!

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 3 Feb 2013 15:48:04 -0800

On Sun, Feb 3, 2013 at 10:56 AM, Eric Burger <[email-masked]>wrote:

> To me, this means it is totally orthogonal to RTCweb. If you want to use
> Tor, a TURN server, an ALG, or foo, that is up to you. That does not impact
> the protocol.

That's certainly what I meant to be saying, with the small caveat that
if you are using media relays (e.g., TURN) they are supposed to be
reflected in ICE candidate lines.

addresses, server/peer

> And this is the most reasonable. I guess the concern is we will forget all
> of this list discussion, and someone will require hard-coded endpoint IP
> addresses in the protocol, which is what sunk SIP in the early days.
>
> Inline…
>
> > On the one hand, with my purist hat on, saying it is a requirement to
> make sure we do not need to have end-to-end connectivity smells a bit weird.
> >
> Saying we will bake into the protocol the REQUIREMENT that it support good
> or bad boxes in the middle of the network does not sound like the
> end-to-end Internet. It sounds more like IMS.

Which requirement do you think suggests that? I certainly favor
requirements that we be
able to work in the face of as many known classes of intermediaries (NATs,
firewalls,
etc. as possible.) I mean, isn't that the point of ICE supporting TURN and
other types
of relays?

Is there something wrong with this? Do you think people are suggesting some
other requirement?

 > On the other hand, with my practical hat on, saying it is a requirement
> to make sure the protocol works in situations that are NOT the Internet
> (NATs, a need for an overlay privacy network, etc.) seems like a good thing
> to do.
> >
> That is asking an awful lot of an application. Moreover, as the
> cat-and-mouse game of anonymous application communication is ever evolving,
> I would challenge how meaningful it is to specify a Hidden Bit or Anonymous
> Bit in the protocol. I would offer that will work as well as the Evil Bit.

I really am not following what you are saying here about a "hidden bit"?

There is a very specific requirement being suggested here, namely that
applications
should be able to instruct browsers not to use host or srvflx candidates.
This is
neither a hidden bit, nor an anonymous bit. Rather, it is a mechanism
designed
to allow the site, *if it wishes* to offer a calling service that doesn't
immediately
reveal the caller's location. This isn't a complete anonymity service
against
sophisticated attackers. For that you need something like Tor. Rather, it's
an
easy-to-implement measure that offers location protection against a
(relatively common) class of limited attackers.

What is it you object to about this requirement?

-Ekr

---

From: Eric Burger <[email-masked]>
Date: Mon, 4 Feb 2013 05:52:31 -0500

Under what circumstances would it be up to the Web server to decide to make the client interaction quasi-anonymous? Would that not be a entirely up to and the responsibility of the client? By definition, the Web server is not anonymous -- the user had to reach it somehow to get the page in the first place. Likewise, it is well within the power of the server to obfuscate its media address. It is quite likely media is NOT coming from the same IP address as the Web page under normal circumstances, so the server has built-in opportunities to obfuscate its address. Conversely, it is well within the capabilities of the browser to figure out how to obfuscate its media address. More importantly, I have yet to hear a cogent use case for the server saying, "I want this interaction to not have IP addresses *TO PROTECT YOU*." If you are in a scenario where you need protection, you cannot depend on the server. You must depend on yourself, which means you will have a browser that will protect you. Moreover, will not a bad server simply always tell all browsers it connects with to open lots of anonymity relays to DDoS the relays? Saying we want to build something that is only sometimes useful and can only be useful if we trust all sides to do the right thing does not sound very useful.

Am I missing something here?

On Feb 3, 2013, at 6:48 PM, Eric Rescorla <[email-masked]> wrote:

> 
> 
> On Sun, Feb 3, 2013 at 10:56 AM, Eric Burger <[email-masked]> wrote:
> Which requirement do you think suggests that? I certainly favor requirements that we be
> able to work in the face of as many known classes of intermediaries (NATs, firewalls,
> etc. as possible.) I mean, isn't that the point of ICE supporting TURN and other types
> of relays?
> 
> There is a very specific requirement being suggested here, namely that applications
> should be able to instruct browsers not to use host or srvflx candidates. This is
> neither a hidden bit, nor an anonymous bit. Rather, it is a mechanism designed
> to allow the site, *if it wishes* to offer a calling service that doesn't immediately
> reveal the caller's location. This isn't a complete anonymity service against
> sophisticated attackers. For that you need something like Tor. Rather, it's an

---

From: John Leslie <[email-masked]>
Date: Mon, 4 Feb 2013 07:19:52 -0500

Harald Alvestrand <[email-masked]> wrote:
> On 02/01/2013 11:34 AM, Stefan H?kansson LK wrote:
>>>

   This definitely needs work: "the application", "refrain", "exposing",
and "the IP address" are all a bit ambiguous. :^(

   I have been having trouble following this discussion: let me try
to summarize my understanding.

> without one party learning the other party's IP address"

   This is a far clearer statement, leaving only "other party's IP
address" ambiguous.

   What I haven't been able to follow is whether we all believe the
problem we're trying to solve is "one party" learning the "other
party's" whatever.

   In any case, A25 is supposed to be a requirement of the API --
thus it need to be stated in terms of what the API does.

   In a later message, Harald explained:
] 
] 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.

   Later still, Harald says:
] 
] The security property that has most often been expressed is that
] the correspondent should not be able to use the IP address to
] geolocate the user; this means that the most important value of
] "xxxx" is the globally routable IP address that is closest to the
] user's location.

   AFAICT, we're now talking about:
] 
] A25    It MUST be possible to set up a call between two parties
]        A and B without one party learning the other party's
]        globally-routable IP address

and the discusion is about whether such an API requirement belongs
here at all.

   FWIW, my opinion is that it arguably belongs as a requirement
that the API have a way to request this; otherwise not. IMHO it is
not appropriate that RTCWEB require such a request to succeed.

   Furthermore, I remain very unsure whether we're talking about
hiding your globally-routable IP address only from another endpoint
(as opposed to hiding it from a middlebox near that endpoint.

   I can be happy with any requirement which is simple enough to
achieve, or no requirement in this direction at all -- a person
intent on hiding his globally-routable IP address needs to take
responsibility for hiding it -- not trust some widely-distributed
application which needs to seek distribution in countries where
such hiding is forbidden by the government.

   (YMMV, obviously...)

--
John Leslie <[email-masked]>

---

From: "Matthew Kaufman (SKYPE)" <[email-masked]>
Date: Mon, 4 Feb 2013 17:56:26 +0000

I see two possible readings (either or both of them might be useful):

1. The browser must have a way for its user to force the use of TURN servers (and this is only useful if the user also provides the address and credentials for the TURN servers) for transmission of media.

2. The browser must have an API that keeps some kinds of candidates from being included in the SDP the API generates.

#1 seems like a very useful thing to require for users who might actually care about their privacy, but I don't think that requirement belongs in an IETF document but rather the W3C requirements TR for WEBRTC, that appears to have not even been started.

#2 seems highly questionable to me, due to the large number of failure modes in both the interpretation of the spec and the ability to circumvent the intent...

For #2 do you mean "API flag to prevent local candidates from being included" or "API flag to prevent server-reflexive STUN-learned candidates from being included" or both?

For #2 how do you propose a malicious application or page injection not simply change the flag?

For #2 why can't the same behavior be accomplished by including all the candidates in the SDP and then letting the JavaScript remove the "dangerous" candidates before sending the SDP to the server?

For #2 why can't the same behavior be accomplished by including all the candidates in the SDP, sending it to the server (which you must trust anyway, as it also can change the flag itself *or* derive your IP address by looking at where you load pages from), and having the server remove the "dangerous" candidates before sending them on to the far client?

Matthew Kaufman

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Eric Burger
Sent: Monday, February 4, 2013 2:53 AM
To: Eric Rescorla
Cc: [email-masked]
Subject: Re: [rtcweb] Revealing IP addresses (Re: Review of draft-ietf-rtcweb-use-cases-and-requirements-10 (Part II))

On Feb 3, 2013, at 6:48 PM, Eric Rescorla <[email-masked]> wrote:

> > addresses, server/peer reflexive, and relayed and say that the 
> > requirement is that the browser must be able to send packets without 
> > revealing either of the former two, but that it is not a requirement that it be able to do so in the face of an adversarial server.
> Inline...
> requirements that we be able to work in the face of as many known 
> classes of intermediaries (NATs, firewalls, etc. as possible.) I mean, 
> isn't that the point of ICE supporting TURN and other types of relays?
> 
> Is there something wrong with this? Do you think people are suggesting 
> some other requirement?
> 
> 
> >> As far as I know, the only novel requirement here is that there be 
> >> a way for Web application to tell the browser to solely use relayed 
> >> addresses/candidates (and hopefully thus not reveal the user's 
> >> actual location) when communicating with the peer. There is of 
> >> course a requirement to be able to work when behind NATs but that is a functional requirement, not an anonymity one.
> 
> applications should be able to instruct browsers not to use host or 
> srvflx candidates. This is neither a hidden bit, nor an anonymous bit. 
> Rather, it is a mechanism designed to allow the site, *if it wishes* 
> to offer a calling service that doesn't immediately reveal the 
> caller's location. This isn't a complete anonymity service against 
> sophisticated attackers. For that you need something like Tor. Rather, 
> it's an easy-to-implement measure that offers location protection against a (relatively common) class of limited attackers.
>

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 4 Feb 2013 12:27:27 -0800

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Matthew Kaufman (SKYPE)
> Sent: Monday, February 04, 2013 9:56 AM
> To: Eric Burger; Eric Rescorla
> Cc: [email-masked]
> Subject: Re: [rtcweb] Revealing IP addresses (Re: Review of draft-ietf-
> rtcweb-use-cases-and-requirements-10 (Part II))
> 
> 1. The browser must have a way for its user to force the use of TURN
> servers (and this is only useful if the user also provides the address
> and credentials for the TURN servers) for transmission of media.
> 
> 2. The browser must have an API that keeps some kinds of candidates from
> being included in the SDP the API generates.

That is one way to implement it.  Another way to is an additional 
checkbox "Always use TURN servers (for privacy)" in the same place
the TURN servers are configured, *roughly* similar to how 
FTP/HTTP proxies are configured today.

-d

> #1 seems like a very useful thing to require for users who might
> actually care about their privacy, but I don't think that requirement
> belongs in an IETF document but rather the W3C requirements TR for
> WEBRTC, that appears to have not even been started.
> 
> #2 seems highly questionable to me, due to the large number of failure
> modes in both the interpretation of the spec and the ability to
> circumvent the intent...
> 
> For #2 do you mean "API flag to prevent local candidates from being
> included" or "API flag to prevent server-reflexive STUN-learned
> candidates from being included" or both?
> 
> For #2 why can't the same behavior be accomplished by including all the
> candidates in the SDP and then letting the JavaScript remove the
> "dangerous" candidates before sending the SDP to the server?
> 
> For #2 why can't the same behavior be accomplished by including all the
> candidates in the SDP, sending it to the server (which you must trust
> anyway, as it also can change the flag itself *or* derive your IP
> address by looking at where you load pages from), and having the server
> remove the "dangerous" candidates before sending them on to the far
> client?
> 
> Matthew Kaufman
> 
> 
> Subject: Re: [rtcweb] Revealing IP addresses (Re: Review of draft-ietf-
> rtcweb-use-cases-and-requirements-10 (Part II))
> 
> Under what circumstances would it be up to the Web server to decide to
> make the client interaction quasi-anonymous? Would that not be a
> entirely up to and the responsibility of the client? By definition, the
> Web server is not anonymous -- the user had to reach it somehow to get
> the page in the first place. Likewise, it is well within the power of
> the server to obfuscate its media address. It is quite likely media is
> NOT coming from the same IP address as the Web page under normal
> circumstances, so the server has built-in opportunities to obfuscate its
> address. Conversely, it is well within the capabilities of the browser
> to figure out how to obfuscate its media address. More importantly, I
> have yet to hear a cogent use case for the server saying, "I want this
> interaction to not have IP addresses *TO PROTECT YOU*." If you are in a
> scenario where you need protection, you cannot depend on the server. You
> must depend on yourself, which means you will have a browser that will
> prot  ect you. Moreover, will not a bad server simply always tell all
> browsers it connects with to open lots of anonymity relays to DDoS the
> relays? Saying we want to build something that is only sometimes useful
> and can only be useful if we trust all sides to do the right thing does
> not sound very useful.
> 
> > To me, this means it is totally orthogonal to RTCweb. If you want to
> use Tor, a TURN server, an ALG, or foo, that is up to you. That does not
> impact the protocol.
> >
> > > revealing either of the former two, but that it is not a requirement
> > And this is the most reasonable. I guess the concern is we will forget
> all of this list discussion, and someone will require hard-coded
> endpoint IP addresses in the protocol, which is what sunk SIP in the
> early days.
> >
> > Inline...
> >
> > > Is what we are really asking for is the ability of the protocol to
> be TOR-, TURN-, and mumble-friendly? I am hesitant to suggest we bake in
> one particular anonymity network or another into the RTCweb protocol
> suite.
> > >
> > > On the one hand, with my purist hat on, saying it is a requirement
> to make sure we do not need to have end-to-end connectivity smells a bit
> weird.
> > >
> > Saying we will bake into the protocol the REQUIREMENT that it support
> good or bad boxes in the middle of the network does not sound like the
> > > On the other hand, with my practical hat on, saying it is a
> requirement to make sure the protocol works in situations that are NOT
> the Internet (NATs, a need for an overlay privacy network, etc.) seems
> like a good thing to do.
> > >
> > >> course a requirement to be able to work when behind NATs but that
> is a functional requirement, not an anonymity one.
> >
> > That is asking an awful lot of an application. Moreover, as the cat-
> and-mouse game of anonymous application communication is ever evolving,
> I would challenge how meaningful it is to specify a Hidden Bit or
> Anonymous Bit in the protocol. I would offer that will work as well as
> the Evil Bit.
> >
> > it's an easy-to-implement measure that offers location protection
> against a (relatively common) class of limited attackers.
> >

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 4 Feb 2013 17:04:54 -0500

> #1 seems like a very useful thing to require for users who might actually care about their privacy, but I don't think that requirement belongs in an IETF document but rather the W3C requirements TR…

I had 2 in mind. I don't think #1 needs standardization

> For #2 how do you propose a malicious application or page injection not simply change the flag?

The intent here is to allow the server to offer an anonymous calling service so this threat isn't relevant

> For #2 why can't the same behavior be accomplished by including all the candidates in the SDP and then letting the JavaScript remove the "dangerous" candidates before sending the SDP to the server?

This I have a good answer to. You need to suppress checks on this candidates because those reveal your address. And even if you think stripping in sdp before set local accomplishes this how do you do it for trickle ice?

> For #2 why can't the same behavior be accomplished by including all the candidates in the SDP, sending it to the server (which you must trust anyway, as it also can change the flag itself *or* deri…

Same reason

---

From: "Matthew Kaufman (SKYPE)" <[email-masked]>
Date: Mon, 4 Feb 2013 22:30:09 +0000

I still don't understand how I, as a user, can possibly trust your web site to set the flags appropriately so that my browser doesn't execute connectivity checks to someone I'm worried might learn my IP address.

I get it in option #1. I set my browser that way, I trust my browser vendor, end of story.

In case #2, I go to your site, I don't trust your site, but I decide to use it anyway. It gives my addresses away when I do my HTTP GET from it. Then I make a call, and it sets the flags however it wants. Or it sets the flags to "don't do checks except over TURN" and then it sets up a TURN server, but points the TURN server to be the address of the bad guy I didn't want my addresses disclosed to and so my connection attempt to that TURN server reveals my addresses, etc. How does any of this actually help me?

If I really trust the site to protect me, the site runs a media proxy and only has me run ICE checks against that (because those are the only far candidates in the SDP). It relays the traffic. Done.

Matthew Kaufman

-----Original Message-----
From: Eric Rescorla [mailto:[email-masked]] 
Sent: Monday, February 4, 2013 2:05 PM
To: Matthew Kaufman (SKYPE)
Cc: Eric Burger; [email-masked]
Subject: Re: [rtcweb] Revealing IP addresses (Re: Review of draft-ietf-rtcweb-use-cases-and-requirements-10 (Part II))

Same reason
> Subject: Re: [rtcweb] Revealing IP addresses (Re: Review of 
> draft-ietf-rtcweb-use-cases-and-requirements-10 (Part II))
> 
>> That's certainly what I meant to be saying, with the small caveat 
>> that if you are using media relays (e.g., TURN) they are supposed to 
>> be reflected in ICE candidate lines.
>> 
>> 
>> classes of intermediaries (NATs, firewalls, etc. as possible.) I 
>> mean, isn't that the point of ICE supporting TURN and other types of relays?
>> 
>> Is there something wrong with this? Do you think people are 
>> suggesting some other requirement?
>> 
>> 
>> There is a very specific requirement being suggested here, namely 
>> that applications should be able to instruct browsers not to use host 
>> or srvflx candidates. This is neither a hidden bit, nor an anonymous bit.
>> sophisticated attackers. For that you need something like Tor. 
>> Rather, it's an easy-to-implement measure that offers location protection against a (relatively common) class of limited attackers.
>>

---

From: Richard Barnes <[email-masked]>
Date: Mon, 4 Feb 2013 17:36:04 -0500

It seems like #1 is a special case of #2, in which the browser overrides
whatever flag is set.  It seems like even in #2, there could be chrome to
mitigate the risk of pages lying.

I agree that #1 would not require standardization.

--Richard

On Monday, February 4, 2013, Matthew Kaufman (SKYPE) wrote:

> I still don't understand how I, as a user, can possibly trust your web
> site to set the flags appropriately so that my browser doesn't execute
> connectivity checks to someone I'm worried might learn my IP address.
>
> In case #2, I go to your site, I don't trust your site, but I decide to
> use it anyway. It gives my addresses away when I do my HTTP GET from it.
> Then I make a call, and it sets the flags however it wants. Or it sets the
> flags to "don't do checks except over TURN" and then it sets up a TURN
> server, but points the TURN server to be the address of the bad guy I
> didn't want my addresses disclosed to and so my connection attempt to that
> TURN server reveals my addresses, etc. How does any of this actually help
> me?
>
> If I really trust the site to protect me, the site runs a media proxy and
> only has me run ICE checks against that (because those are the only far
> candidates in the SDP). It relays the traffic. Done.
>
> Matthew Kaufman
>
> servers (and this is only useful if the user also provides the address and
> credentials for the TURN servers) for transmission of media.
> >
> belongs in an IETF document but rather the W3C requirements TR for WEBRTC,
> that appears to have not even been started.
>
> >
>
> modes in both the interpretation of the spec and the ability to circumvent
> the intent...
> >
> included" or "API flag to prevent server-reflexive STUN-learned candidates
> from being included" or both?
> >
> This I have a good answer to. You need to suppress checks on this
> candidates because those reveal your address. And even if you think
> stripping in sdp before set local accomplishes this how do you do it for
> trickle ice?
>
>
> anyway, as it also can change the flag itself *or* derive your IP address
> by looking at where you load pages from), and having the server remove the
> "dangerous" candidates before sending them on to the far client?
> >
>
> Same reason
> > Matthew Kaufman
> >
> >
> make the client interaction quasi-anonymous? Would that not be a entirely
> up to and the responsibility of the client? By definition, the Web server
> is not anonymous -- the user had to reach it somehow to get the page in the
> first place. Likewise, it is well within the power of the server to
> obfuscate its media address. It is quite likely media is NOT coming from
> the same IP address as the Web page under normal circumstances, so the
> server has built-in opportunities to obfuscate its address. Conversely, it
> is well within the capabilities of the browser to figure out how to
> obfuscate its media address. More importantly, I have yet to hear a cogent
> use case for the server saying, "I want this interaction to not have IP
> addresses *TO PROTECT YOU*." If you are in a scenario where you need
> protection, you cannot depend on the server. You must depend on yourself,
> which means you will have a browser that will pr
>  otect you. Moreover, will not a bad server simply always tell all
> relays? Saying we want to build something that is only sometimes useful and
> can only be useful if we trust all sides to do the right thing does not
> sound very useful.
> >
> > Am I m

---

From: "Matthew Kaufman (SKYPE)" <[email-masked]>
Date: Mon, 4 Feb 2013 23:07:48 +0000

We're talking about the use cases and requirements document. I believe that the W3C requirements doc for the browser should include #1. That's different than "standardization", and isn't an IETF issue either.

Matthew Kaufman

From: Richard Barnes [mailto:[email-masked]]
Sent: Monday, February 4, 2013 2:36 PM
To: Matthew Kaufman (SKYPE)
Cc: Eric Rescorla; [email-masked]
Subject: Re: [rtcweb] Revealing IP addresses (Re: Review of draft-ietf-rtcweb-use-cases-and-requirements-10 (Part II))

It seems like #1 is a special case of #2, in which the browser overrides whatever flag is set.  It seems like even in #2, there could be chrome to mitigate the risk of pages lying.

--Richard

Matthew Kaufman

-----Original Message-----
From: Eric Rescorla [mailto:[email-masked]]
Sent: Monday, February 4, 2013 2:05 PM
To: Matthew Kaufman (SKYPE)
Cc: Eric Burger; [email-masked]
Subject: Re: [rtcweb] Revealing IP addresses (Re: Review of draft-ietf-rtcweb-use-cases-and-requirements-10 (Part II))

Same reason
> Under what circumstances would it be up to the Web server to decide to make the client interaction quasi-anonymous? Would that not be a entirely up to and the responsibility of the client? By definition, the Web server is not anonymous -- the user had to reach it somehow to get the page in the first place. Likewise, it is well within the power of the server to obfuscate its media address. It is quite likely media is NOT coming from the same IP address as the Web page under normal circumstances, so the server has built-in opportunities to obfuscate its address. Conversely, it is well within the capabilities of the browser to figure out how to obfuscate its media address. More importantly, I have yet to hear a cogent use case for the server saying, "I want this interaction to not have IP addresses *TO PROTECT YOU*." If you are in a scenario where you need protection, you cannot depend on the server. You must depend on yourself, which means you will have a browser that will pr
 otect you. Moreover, will not a bad server simply always tell all browsers it connects with to open lots of anonymity relays to DDoS the relays? Saying we want to build something that is only sometimes useful and can only be useful if we trust all sides to do the right thing does not sound very useful.

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 14 Feb 2013 11:49:29 +0100

WG,

This WG last call has ended. There has been a number of comments on this
document. These needs to be addressed. I task the authors to work
through the open issues and provides document updates or drive further
discussion where needed to resolve the open issues.

We will not send this document for publication prior to giving the WG at
least two weeks to review the changes that will be applied to resolve
issues raised.

Cheers

Magnus

On 2013-01-18 17:06, Magnus Westerlund wrote:
> WG,
> 
> I would here by like to announce a two week WG last call that ends on
> the 1st of February.
> 
> Document is available here:
> 
> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-use-cases-and-requirements/
> 
> Cheers
> 
> Magnus Westerlund
> 
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------
> Ericsson AB                | Phone  +46 10 7148287
> Färögatan 6                | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden| mailto: [email-masked]
> ----------------------------------------------------------------------
> 

-- 

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------