Subject: [rtcweb] Summary of ICE discussion

From: Magnus Westerlund <[email-masked]>
Date: Tue, 4 Oct 2011 16:33:18 +0200

WG,

I have bellow tired to summarize the result of the ICE discussion. This
is intended as furthering this discussion and form a basis for going
forward in the consensus process. I do expect people that disagree with
my summary of the discussion to speak up.

Major requirements

- Need for data transmission consent for protocols using UDP as the
traffic receiver needs to consent to receiving the data

- Perform NAT and FW traversal when ever needed

- Support IPv4 to IPv6 transition

Desired behavior:

- Be interoperable with deployed legacy systems as SIP Trunk, PSTN
gateways, VoIP phones.

WG chairs conclusion of discussion so far:

- ICE is so far the only solution that provides the security goals and
have any legacy deployment.

- ICE usage will require that STUN connectivity MUST have succeeded
prior to any data transmission to fulfill security goals.

  * The Browser will enforce this requirement to prevent being an attack
vector in all cases.

- If anyone can find a solution that fulfill the security goals and have
improved legacy interoperability people would be interested in that
solution. So far RTCP has been discarded as insufficient.

- Media Gateway can support a reduced functionality set from Full ICE

Cheers

Magnus Westerlund
as WG chair

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

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 4 Oct 2011 16:44:23 +0200

> - Media Gateway can support a reduced functionality set from Full ICE

I agree with all the above.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Randell Jesup <[email-masked]>
Date: Tue, 04 Oct 2011 11:05:30 -0400

> solution. So far RTCP has been discarded as insufficient.

I've been discussing some options on this with Cullen on the side.  No 
breakthroughs yet, though there may still be some hope.  If there's 
something there I'll post it soon, otherwise assume it didn't pan out.

One observation about the security/attack-vector side of this:  Any 
objection that includes "if an attacker is in a MITM position they could 
trick the rtcweb client into sending media" is an invalid objection.  A 
MITM attacker could inject or re-route any amount of traffic they wanted 
already if they're in the media path.  I'll also note that an attacker 
could be in MITM on the signalling side or DNS, but not MITM on the 
media/ICE routing; those are valid cases to consider.  And DNS poisoning 
doesn't require MITM.

-- 
Randell Jesup
[email-masked]

---

From: "Olle E. Johansson" <[email-masked]>
Date: Tue, 4 Oct 2011 17:32:17 +0200

> - Media Gateway can support a reduced functionality set from Full ICE
I think Harald brought up that ICE can assist in IP mobility in a handover situation. I don't know if this is required/desired or ignored behaviour at this point.

/O

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 4 Oct 2011 08:33:57 -0700

On Tue, Oct 4, 2011 at 8:05 AM, Randell Jesup <[email-masked]> wrote
> trick the rtcweb client into sending media" is an invalid objection.  A MITM
> attacker could inject or re-route any amount of traffic they wanted already
> if they're in the media path.

Concur. ICE is primarily about web attackers, not network attackers.

-Ekr

---

From: "Cary Bran (cbran)" <[email-masked]>
Date: Tue, 4 Oct 2011 09:02:56 -0700

I will integrate this into the NAT traversal draft and submit a 02 version of draft-cbran-rtcweb-nat for review.

-Cary

On Oct 4, 2011, at 8:34 AM, "Eric Rescorla" <[email-masked]> wrote:

> One observation about the security/attack-vector side of this:  Any objection that includes "if an attacker is in a MITM position they could trick the rtcweb client into sending media" is an invalid objection.  A MITM attacker could inject or re-route any amount of traffic they wanted already if they're in the media path.
> 
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 4 Oct 2011 16:24:11 +0000

On Oct 4, 2011, at 11:05 AM, Randell Jesup wrote:

> One observation about the security/attack-vector side of this:  Any objection that includes "if an attacker is in a MITM position they could trick the rtcweb client into sending media" is an invalid objection.  A MITM attacker could inject or re-route any amount of traffic they wanted already if they're in the media path.  I'll also note that an attacker could be in MITM on the signalling side or DNS, but not MITM on the media/ICE routing; those are valid cases to consider.  And DNS poisoning doesn't require MITM.

Excellent - I was hoping someone else would feel that way about a MITM on the media/ICE path.  I'm not sure that's universally agreed on, though: it was the main reason for requiring the hash on the STUN connectivity checks, afaict.

The hard part about this all, frankly, is that we're not allowed to trust the JavaScript.  Since the JavaScript can learn so much, we're stuck with the Browser generating something that the JS can't learn but that the media peer will learn in the media plane only.  The transaction-id of the STUN connectivity check essentially provides that proof that the STUN answer comes from a real media peer willing to participate.  Unfortunately RTP has no such proof, and RTCP has one but I think people have said it's not strong enough? (I can't find where someone said that, but it could be)

Regardless, fundamentally it seems to me W3C and Browser manufacturers have a problem if they can't ever trust JavaScript: plugins and native apps will always be able to do things JS can't do if W3C can't agree on a way for the user+browser to safely say "yes, this really is JS I trust, with the same level of trust/policies I give to plugins/apps".  I don't mean this for all web-page JS downloads of RTCWeb, but rather for specific sites that I would have a long-term relationship with.  For example if I am a Facebook user and Facebook wants to run JS on my browser, I'd be willing to give them control similar to downloading a Facebook app, even if it requires me to follow the same process of consent that downloading an application does.  What about the Mozilla signed scripts model?

For general RTCWeb JS downloads I think requiring ICE and all is fine and good, and frankly I expect most RTCWeb applications to fall in that model and not care about legacy SIP or the PSTN.  But for some RTCWeb cases it will communicate with legacy SIP/PSTN and those are the types of applications that I think would have a longer-term relationship with the user, for which requiring a more stringent JS trust model seems worthwhile to me.

-hadriel

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 4 Oct 2011 09:28:34 -0700

I think this is a good summary of where we are with respect to ICE, and
since there are no good alternatives on the table, it seems reasonable to
move on to the next step. 

IMHO, this would involve a more detailed analysis of the threats and what
needs to be done to resolve them. 

In particular, the statement "STUN Connectivity Check MUST have succeeded" is 
necessary but not sufficient.   We need to get into a discussion of the specific
conditions under which media can be sent, and what attacks are still
possible.  For example, there exist public STUN servers on the Internet, and 
RTCWEB should not permit the browser to execute a DoS attack on these servers. 
Also, it would be desirable to prevent a browser from sending much more
bandwidth than the receiver has consented to;  however, because signaling
is largely opaque to the browser, it is not obvious (at least to me) how to 
prevent this.

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 4 Oct 2011 09:47:07 -0700

In particular, I'm concerned about vulnerabilities created by multiplexing
audio and video on the same port.  When that is done, the ICE procedure loses
some of its DoS prevention properties.

From: [email-masked]
To: [email-masked]
Date: Tue, 4 Oct 2011 09:28:34 -0700
CC: [email-masked]
Subject: Re: [rtcweb] Summary of ICE discussion

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 4 Oct 2011 16:40:09 -0600

On Oct 4, 2011, at 10:28 AM, Bernard Aboba wrote:

>  For example, there exist public STUN servers on the Internet, and 

Note that when STUN was designed, we did some experiments and found that adding passwords to STUN made it easier to DOS the servers even if you did not know the password than just having the STUN server respond with no password. Paul Hoffman (CC'd) might have some interesting stats about operating a public STUN server.

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 4 Oct 2011 16:40:53 -0600

Could you say more... I'm not following your logic.

On Oct 4, 2011, at 10:47 AM, Bernard Aboba wrote:

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

---

From: Matthew Kaufman <[email-masked]>
Date: Tue, 04 Oct 2011 19:48:14 -0700

>> some of its DoS prevention properties.

I think what he's concerned about is that a device might consent (using 
ICE) to receive audio and unexpectedly receive multiplexed video on the 
same RTP port.

Not sure this really matters, as there's not much difference between 
low-frame-rate low-res video and 16-bit linear stereo PCM at 48 kHz 
(which might indeed be an audio codec you can choose).

Matthew Kaufman

---

From: Matthew Kaufman <[email-masked]>
Date: Tue, 04 Oct 2011 19:51:13 -0700

I believe this is a correct summary.

Agree with Bernard that we need to ensure that the connectivity check as 
done by ICE doesn't have inadvertent effects on public STUN servers, 
however my understanding of how the ICE credential mechanism works leads 
me to believe that this isn't actually a problem, as long as we are 
clear about what "check succeeded" means when we tell browser vendors 
how to implement this.

Matthew Kaufman

---

From: Matthew Kaufman <[email-masked]>
Date: Tue, 04 Oct 2011 19:52:37 -0700

On 10/4/2011 9:24 AM, Hadriel Kaplan wrote:
>   requiring a more stringent JS trust model seems worthwhile to me.
>

Great idea. Already being discussed elsewhere. Out of scope for both of 
these groups except to note that *if* someone solves the JS trust issue, 
we might be able to relax the ICE requirement when running applications 
that are "trusted".

I wouldn't be adverse to even saying just that in the requirements 
document that explains why ICE is needed.

Matthew Kaufman

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 4 Oct 2011 20:14:44 -0700

Right, that's the attack I had in mind, but with high bandwidth video.

On Oct 4, 2011, at 7:49 PM, "Matthew Kaufman" <[email-masked]> wrote:

> I think what he's concerned about is that a device might consent (using ICE) to receive audio and unexpectedly receive multiplexed video on the same RTP port.
> 
> Not sure this really matters, as there's not much difference between low-frame-rate low-res video and 16-bit linear stereo PCM at 48 kHz (which might indeed be an audio codec you can choose).
> 
> Matthew Kaufman

---

From: Randell Jesup <[email-masked]>
Date: Tue, 04 Oct 2011 23:16:59 -0400

On 10/4/2011 10:52 PM, Matthew Kaufman wrote:
> Great idea. Already being discussed elsewhere. Out of scope for both 
> of these groups except to note that *if* someone solves the JS trust 
> issue, we might be able to relax the ICE requirement when running 
> applications that are "trusted".

Right; pretty much the "Installed WebApp" model.

> document that explains why ICE is needed.

I'll agree with this approach.

(Just to verify: which of many possible places are you referring to it 
being discussed?)

-- 
Randell Jesup
[email-masked]

---

From: Matthew Kaufman <[email-masked]>
Date: Tue, 04 Oct 2011 21:15:19 -0700

> (Just to verify: which of many possible places are you referring to it 

I believe there will be a document produced by this WG that requires ICE 
and explains what security aspects it is addressing. That document would 
be the right place.

Matthew Kaufman

---

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Wed, 5 Oct 2011 11:37:32 +0530

In case user consent is the reason for ICE, ICE may not be right choice because of the multiplexing RTP in RTCWeb and user may be consent for audio and not for video which is not possible to indicate through ICE. It is possible to achieve by having different streams for each media but I strongly believe that it is not interesting topic for RTCWeb.

I think that trust model with browser---RTCWeb server---browser for the user consent with individual media stream works because browser user trust RTCWeb server. I could think of offer/answer as user consent with media stream mechanism because offer or answer indicates media port is allocated in browser and listening for media from remote party, the consent reaches remote browser through RTCWeb server. The advantage in the model is that RTCWeb server shall have the policy to control media. Please let me know your comments on this.

The other reason like NAT & FW is not mandatory for intranet RTCWeb applications. I have mentioned as part of http://www.ietf.org/mail-archive/web/rtcweb/current/msg01619.html

Thanks
Partha

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf
>Of Magnus Westerlund
>Sent: Tuesday, October 04, 2011 8:03 PM
>To: [email-masked]
>Subject: [rtcweb] Summary of ICE discussion
>
>WG,
>

---

From: Roman Shpount <[email-masked]>
Date: Wed, 5 Oct 2011 02:35:01 -0400

On Tue, Oct 4, 2011 at 10:48 PM, Matthew Kaufman
<[email-masked]>wrote:

> ICE) to receive audio and unexpectedly receive multiplexed video on the same
> RTP port.
>
> low-frame-rate low-res video and 16-bit linear stereo PCM at 48 kHz (which
> might indeed be an audio codec you can choose).
>

Since we already agreed that RTC end point does not need to interact with
anything except other RTC end points, and everything outside RTC would just
be extended to support it, why would not we add additional parameters to
STUN connectivity check? We can add media types, rates, codecs and codec
parameters to STUN request and let the end point only accept the
connectivity check if the media matches what's expected to be sent to this
IP/port. This will probably even work with existing ICE implementations, if
we make these codec parameters comprehension-optional.
_____________
Roman Shpount

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 5 Oct 2011 10:09:32 +0200

Hi,

good that my summary lets us move forward.

A question on this attack. How common is it that these STUN servers use
other ports than 3478? Would a rule about that port mitigate the issue,
even if it could result in connectivity failures in cases where the NAT
external port is 3478 by chance?

In addition does these public servers use the username and password
convention from ICE? Isn't that what prevents STUN server deployed for
just determining your server reflexive candidate from actually respond
correctly to a connectivity check? As ICE do concatenate one part
generated by one peer with a part generated by the other peer I don't
see this as an issue as long as the random username fragment is
generated by the browser not the JS.

Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 5 Oct 2011 10:19:09 +0200

On 2011-10-05 08:07, Ravindran Parthasarathi wrote:
> In case user consent is the reason for ICE, ICE may not be right
> choice because of the multiplexing RTP in RTCWeb and user may be
> consent for audio and not for video which is not possible to indicate
> through ICE. It is possible to achieve by having different streams
> for each media but I strongly believe that it is not interesting
> topic for RTCWeb.

No, it is not user consent, it is data transmission consent that is the
issue here.

> 
> I think that trust model with browser---RTCWeb server---browser for
> the user consent with individual media stream works because browser
> user trust RTCWeb server. I could think of offer/answer as user
> consent with media stream mechanism because offer or answer indicates
> media port is allocated in browser and listening for media from
> remote party, the consent reaches remote browser through RTCWeb
> server. The advantage in the model is that RTCWeb server shall have
> the policy to control media. Please let me know your comments on
> this.

My interpretation is that several has disagreed with you on this model.
I personally also disagree with this. There is a big difference between
allowing a webservice access to my media devices, i.e. microphone and
video as will expect it to perform a communication service where I at
least see parts of that communication happening. However, the user has
no way of verifying that of the media streams being setup by the web
service that it in fact not in addition uses the users resources for a
DoS attack. It is the destination of the media stream that needs to
consent to the media delivery, not the siganlling node for it. Thus a
path based media verification that ensures that information from the
signalling and the media path agrees provides a reasonable but not
perfect security against attacks. This is still vulnerable to attackers
that have the capability of both running the web service and intercept
and inject packets in the network on path between the web client and the
target of the attack.

> 
> The other reason like NAT & FW is not mandatory for intranet RTCWeb
> applications. I have mentioned as part of
> http://www.ietf.org/mail-archive/web/rtcweb/current/msg01619.html

My interpretation of your statement was that it was disputed and that
the disputing statement was not faulty.

Cheers

Magnus Westerlund

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 05 Oct 2011 14:07:04 +0200

On 10/04/2011 05:05 PM, Randell Jesup wrote:
> objection that includes "if an attacker is in a MITM position they 
> could trick the rtcweb client into sending media" is an invalid 
> objection.  A MITM attacker could inject or re-route any amount of 
> traffic they wanted already if they're in the media path.  I'll also 
> note that an attacker could be in MITM on the signalling side or DNS, 
> but not MITM on the media/ICE routing; those are valid cases to 
> consider.  And DNS poisoning doesn't require MITM.

Concur that the first form of the objection is invalid without further 
description ... I would note that any proposed solution that allows the 
attacker to be MITM on the path for verification of 
acceptance-to-receive (such as a hypothetical RTCP-based mechanism where 
mechanisms exist to let RTCP use IP addresses completely independent of 
the RTP path) would make the MITM objection valid.

(ouch. That was a convoluted sentence. Parse leniently!)

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 05 Oct 2011 14:22:34 +0200

On 10/04/2011 06:28 PM, Bernard Aboba wrote:
> possible.
....
> is largely opaque to the browser, it is not obvious (at least to me) 
Note - at the moment, the PeerConnection proposal has a lot of the 
signalling happening within the browser. So the browser knows what 
bandwidths have been negotiated and so on, and can police accordingly. 
An implementation that followed the "low level" model and did 
negotiation in (untrusted) Javascript would have less insight.

This helps less than it might - the messages are sent in the clear, and 
unprotected against intermediaries, and they have to be that way to 
enable signalling gateways to do their thing, so the browser has no way 
of verifying that a reply that comes back with the suggestion "let's 
send 100 Mbits/sec" was actually what the remote end consented to; a 
malevolent (or even just broken) signalling relay could easily change 
this parameter.

I suspect that the solutions here may have to involve congestion control 
and slow start; for instance, ubiquitous, browser-policed support of a 
TMMBR-like mechanism where the recipient states what it's willing to 
receive over the RTCP channel would reduce the attack window of this 
particular attack to something that we might consider acceptable.

                  Harald

---

From: Jonathan Lennox <[email-masked]>
Date: Wed, 5 Oct 2011 10:28:03 -0400

> Right, that's the attack I had in mind, but with high bandwidth video.

This sounds to me like the congestion control mechanism needs to be part of the browser-enforced security properties, and transported in a secure manner that an attacker can't spoof (which probably means over DTLS-SRT(C)P).

Once congestion control has indicated that a receiver has consented to a certain bitrate, how an application choses to fill it isn't so important as a security property.  Sending a consenting peer (e.g.) 48 kHz L16 audio instead of low-res video (or vice versa) would be kind of pointless, but not really a DoS attack if the peer has already agreed to receive that much bandwidth.

-- 
Jonathan Lennox
[email-masked]

---

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Wed, 5 Oct 2011 20:07:39 +0530

Hi Magnus,

Thanks for the clarification about the issue in webserver based trust model. I agree for ICE as there is no other known solution for user consent in the proposed trust model. Still, data transmission consent is an open item.

Thanks
Partha

>From: Magnus Westerlund [mailto:[email-masked]]
>Sent: Wednesday, October 05, 2011 1:49 PM
>To: Ravindran Parthasarathi
>Cc: [email-masked]

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 5 Oct 2011 08:35:34 -0700

What I was trying to point out was that there are very specific conditions
under which the browser will consider the STUN exchange to be "successful" that
will not be met by a public STUN server, which typically will not support ICE
extensions.   If we articulate this, it would not be possible to DoS a public STUN
server with *media*, which has been the bar we've been applying so far. 

It should be understood that when the "answer" is not directly available to the 
offering browser,  the STUN exchange is only able to verify the willingness
to receive on a particular IP address/port combination.  Without multi-plexing,
this should ensure that the receiver has consented to each media type.
Assuming that we can satisfactorily handle "continuing consent" determination,
I'm not sure that we would need ICE extensions to address the issue.
This seems like a slippery slope that could result in a continuing stream of
ICE extensions.   

IMHO, the "congestion control" problem is separable.  Since
it seems inevitable that RTCWeb implementations will support
non-adaptive codecs, I don't believe we can rely on "congestion
control" for DoS avoidance. 

> Date: Wed, 5 Oct 2011 10:09:32 +0200
> From: [email-masked]
> To: [email-masked]
> CC: [email-masked]; [email-masked]

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 05 Oct 2011 17:51:23 +0200

> server with *media*, which has been the bar we've been applying so far.
Indeed, a public STUN server will not be configured with an username / 
password (RFC 5245 section 7.1.2.3), and thus its answers will not pass 
the ICE check for a correct MIC.
> control" for DoS avoidance.

The control I was thinking of is that when a Javascript DoS attacker 
attempts to send media to a DoS victim at some significant traffic 
volume, the DoS victim can send back a TMMBR saying "I only want this 
much data" (where "this much" is a reasonable amount for the media types 
it's been expecting). That won't solve large scale DDoS attacks, of 
course, but at least it is pushback against the "I said yes to 32 Kbits 
and you hit me with 2 Mbits" attacks.

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 5 Oct 2011 13:42:13 -0600

Thanks

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 4 Oct 2011 16:02:42 -0700

On Oct 4, 2011, at 3:40 PM, Cullen Jennings wrote:

> Paul Hoffman (CC'd) might have some interesting stats about operating a public STUN server. 

- Ran stunserver.org for a while because Cullen and Rohan thought it might be interesting.

- My ISP (a friend) complained about the traffic. We could see huge amounts, even though no one had asked.

- I transferred the domain to Cullen to run.

- A year after I turned off stun at the IP address that stunserver.org used to run on, the ISP's firewall says that the port gets *much* more traffic than vpnc.org and imc.org combined web and mail. Note that on the stunserver.org web page, we explicitly said that people should put our domain name in, not the IP address. This is all traffic that is getting no reply.

Conclusion: STUN is probably riper for tragedy of the commons than other protocols due to negligent developers who don't care if their clients keep hitting dead servers.

--Paul Hoffman

---

From: <[email-masked]>
Date: Sun, 9 Oct 2011 12:00:02 +0200

Hi there,

Re Magnus's call for proposal (If anyone can find a solution that fulfill
 the security goals and have improved legacy interoperability people would 
be interested in that solution. So far RTCP has been discarded as insufficient.) 
on media consent verification, here is below a suggestion for the group:

Basically, the idea, compared to Hadriel's RTCP proposal, relies on the use 
of the signalling path instead of RTCP as a feedback channel for media 
consent verification.

Here are the steps I foresee before allowing the establishment of a media session:
 
- Let's consider A (a RTC-Web compliant browser) connected to server S and 
wishing to share real-time media with destination B (potentially a SIP 
endpoint or a browser)
- A & B learn via the signalling channel the triple @IP, transport proto and 
associated listening port of the remote media
- A sends a few RTP packets to B (3 as in RFC 2833/4733 or more?).- This would
 allow the mechanism to resist against packet loss -. The format of such packets
 are to be discussed   
- Assuming B receives these packets, it then sends via the signalling channel 
an information from the media path unknown from S (i.e. not accessible via JS). 
I propose to use the min of the sequence number of the RTP packets received 
(which is random per RFC 3550)
- A receives via S this info granting B's consent to receiving media from A
- A now can start sending media to B

When B uses SIP as its signalling channel, Step 4 would probably require a 
SDP extension to convey this info, as well as possibly extended H.248/Diameter
 informations would be required in a decoupled sig./media architecture.  
Of course, a solution avoiding extensions would be more than welcome.

The benefit of this mechanism largely relies on the assumption that the 
transmission of information from the media termination of the destination 
to its associated signalling channel is less costly than implementing ICE connectivity 
checks. Which is still to be checked.

This mechanism provides basic media consent verification and if it turns out 
that it provides less security properties than ICE or other drawbacks (e.g. 
increasing media session establishment delay, issues with the few initial RTP 
packets,..), it could be seen as a fallback media consent verification 
when ICE is not implemented at each end of media terminations. 

Looking forward to hearing feedbacks from the group on this.

Cheers
Sebastien

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Magnus Westerlund
Envoyé : mardi 4 octobre 2011 16:33
À : [email-masked]
Objet : [rtcweb] Summary of ICE discussion

WG,

Major requirements

Desired behavior:

Cheers

Magnus Westerlund
as WG chair

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Sun, 9 Oct 2011 18:24:29 +0200

Hi,

ICE is clearly the best solution as it handles NAT, security (peer
verification) and allows IPv4/IPv6 transition. SIP endpoints *MUST*
implement it or continue working in vendors wallen gardens. Bad luck
for them.

But creating a new spec (as you suggest) just to allow lazy SIP
vendors (those who has never cared about security) to interoperate
with RTCweb world instead on forcing them to implement ICE is IMHO a
very bad idea.

SIP vendors MUST do their homeworks. ICE and SRTP were initially
designed for SIP. So SIP devices MUST implement them.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 10 Oct 2011 22:50:19 +0200

Changing the subject to keep threads separate....

On 10/09/2011 12:00 PM, [email-masked] wrote:
> - A&  B learn via the signalling channel the triple @IP, transport proto and
The sequence number is a 16-bit number, so there are 16 bits of 
randomness to play with here.
An attack based on just returning a random number will succeed 1 out of 
65.536 times; if any of the 3 packets' sequence numbers are acceptable, 
it will succeed 1 out of 21.845 times.

A browser can reasonably limit the number of attempts per second (either 
overall or per-script); multiple browsers will not be able to coordinate 
on any such limit.

Is this defense strong enough to warrant considering this further?

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 10 Oct 2011 16:04:16 -0700

On Mon, Oct 10, 2011 at 1:50 PM, Harald Alvestrand <[email-masked]> wrote:
> The sequence number is a 16-bit number, so there are 16 bits of randomness
> to play with here.
> 65.536 times; if any of the 3 packets' sequence numbers are acceptable, it
> will succeed 1 out of 21.845 times.
>
> overall or per-script); multiple browsers will not be able to coordinate on
> any such limit.
>

IMO, this is far too little entropy.

It's also unclear to me why this is significantly easier than just
doing ICE Lite.

-Ekr

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 11 Oct 2011 01:09:52 +0200

> It's also unclear to me why this is significantly easier than just

And it does not solve NAT neither allows IPv4/IPv6 interoperability.
Why to make SIP devices to implement that instead of ICE (or
ICE-Lite)?

ICE was designed for SIP but now there are much more XMPP clients
implementing it than SIP... how much must we wait in SIP? now it's
clearly the moment but instead of endorsing ICE, do we really prefer
to create a new pseudo-spec just to make SIP devices RTC-web
compliant? And then, what will we do when IPv6 arrives?

I strongly vote for using ICE and requiring ICE in SIP world (they
just MUST, this is the time).

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Randell Jesup <[email-masked]>
Date: Mon, 10 Oct 2011 20:11:44 -0400

On 10/10/2011 7:04 PM, Eric Rescorla wrote:
> On Mon, Oct 10, 2011 at 1:50 PM, Harald Alvestrand<[email-masked]>  wrote:
>>> - A&    B learn via the signalling channel the triple @IP, transport proto
>>> and associated listening port of the remote media
>>> - A sends a few RTP packets to B (3 as in RFC 2833/4733 or more?).- This
>>> would allow the mechanism to resist against packet loss -. The format of such
>>> packets are to be discussed
>>> - Assuming B receives these packets, it then sends via the signalling
>>> channel an information from the media path unknown from S (i.e. not accessible via
>>> JS).
>>> I propose to use the min of the sequence number of the RTP packets
>>> received (which is random per RFC 3550)
>>

If you use the sequence number and the timestamp, you have 48 bits of 
entropy...

-- 
Randell Jesup
[email-masked]

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 10 Oct 2011 23:13:00 -0400

Security issues aside, the proposed solution does not work with existing 
SIP/RTP implementations. The main drawback of the ICE solution is that 
it won't work with deployed equipment. I see little benefit in 
specifying another solution which does not fix the main limitation we 
have with ICE.

-Jonathan R.

On 10/10/2011 8:11 PM, Randell Jesup wrote:
>>>> Here are the steps I foresee before allowing the establishment of a
>>>> media
>>>> session:
>>>>

-- 
Jonathan D. Rosenberg, Ph.D.                   SkypeID: jdrosen
Skype Chief Technology Strategist
[email-masked]                              http://www.skype.com
[email-masked]                            http://www.jdrosen.net

---

From: Randell Jesup <[email-masked]>
Date: Tue, 11 Oct 2011 00:22:03 -0400

> specifying another solution which does not fix the main limitation we

The only thing I've come up with that can work with existing equipment 
is a variant of CORS.

Basically, if the destination doesn't respond to ICE (or more likely the 
app tells you it won't) you do a CORS-style 'preflight' check to the 
same IP address.  If you're told "I'm an RTP gateway that accepts 
non-ICE traffic" with a valid handshake from the signalling (ala an ICE 
check), then traffic can flow/continue flowing (you may want to allow it 
to start before the check is complete, with a limited time/data until 
verification is required to continue).

In practice, this could be implemented by redirecting HTTP/HTTPS traffic 
to the gateway's IP to an internal webserver that would respond.  This 
allows layering onto existing gateways permission for a webrtc/rtcweb 
client to send to them, without modifying the gateway itself.

Downsides: More complex.  Assumes the gateway can either run a (dummy) 
webserver, at least enough to redirect, or it's behind a firewall that 
can port-forward traffic.

An advantage, if the gateway is willing to risk DoS attempts, is that 
the gateway could indicate a max age for the CORS-type check, and so 
indicate that for future calls to that address the browser doesn't have 
to check.  This is optional, though, and just saves checks (and if 
pre-check-complete data sending isn't allowed, then it may save setup 
time as well, except on the first call to a particular gateway).

Is it workable?  I think so.  Is it worthwhile?  I don't know.  I'm 
somewhat skeptical since it solves only a subset of the problem space 
(for connecting to legacy devices/gateways).

-- 
Randell Jesup
[email-masked]

---

From: <[email-masked]>
Date: Tue, 11 Oct 2011 09:48:26 +0200

Hi Jonathan, 

The use of the SSRC - prior to being accessible via JS for mux/demux purposes- could be an alternative to using the sequence number and/or the timestamp (as suggested by Randell). SIP endpoints interfacing with RTC-Web browsers would then only be required to implement RFC 5576 (which may be less costly than STUN implementation, the SHA-1 computation + CRC compute for the fingerprint)..
Cheers
Sebastien   

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Jonathan Rosenberg
Envoyé : mardi 11 octobre 2011 05:13
À : [email-masked]
Objet : Re: [rtcweb] Sebastien Cubaud's non-ICE mechanism (Re: Summary of ICE discussion)

-Jonathan R.

---

From: <[email-masked]>
Date: Tue, 11 Oct 2011 10:00:05 +0200

Hi Iñaki,

>verification) and allows IPv4/IPv6 transition. 

Of course, this solution doesn't mean to address NAT traversal issues, nor multihoming.
ICE still remains the best candidate for such requirements and it is in no way my intent to 
question the use of ICE for RTC-Web compliant agents : my proposal's goal is only to permit 
the minimal interoperability costs with existing SIP endpoints whilst trying to address RTC-Web 
specific security challenges (i.e. media consent verification). Again, it doesn't preclude the 
use of ICE for media consent verification, should all endpoints support ICE. 
Cheers
Sebastien

-----Message d'origine-----
De : Iñaki Baz Castillo [mailto:[email-masked]] 
Envoyé : dimanche 9 octobre 2011 18:24
À : CUBAUD Sebastien RD-CORE-LAN
Cc : [email-masked]; [email-masked]
Objet : Re: [rtcweb] Summary of ICE discussion

Hi,

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 11 Oct 2011 10:03:18 +0200

2011/10/11 Jonathan Rosenberg <[email-masked]>:
> SIP/RTP implementations. The main drawback of the ICE solution is that it
> won't work with deployed equipment. I see little benefit in specifying
> another solution which does not fix the main limitation we have with ICE.

I agree. IMHO it's time for SIP vendors to implement escurity in SIP
devices (let's say ICE and SRTP, some specifications originally
designed for SIP).

SIP is deployed in different scenarios and each scenario has its own
requirements (some of them require certain codecs, SIP over TLS,
UPDATE/PRACK methods and so on). I consider RTCweb to be another
multimedia communication scenario (but very big!!) so it can impose
its own requirements (for example ICE+SRTP which sounds appropriate
given the open Internet nature).

So if SIP vendors want to interoperate with RTCweb devices, then
implement ICE+SRTP, that's the key.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 11 Oct 2011 10:08:19 +0200

> use of ICE for media consent verification, should all endpoints support ICE.

Hi Sebastien,

As I've said in other mails, ICE and SRTP was designed for SIP. If SIP
vendors don't care about security (due to wallen gardens in which most
of SIP is deployed) neither IPv4/IPv6 migration (again due the same
reasons) that is their fault.

If SIP vendors just react when needed, this is a good time for that,
as the "market" will be Internet full of RTCweb capable web browsers
implementing ICE+SRTP (being safer that 99% of current SIP devices,
which is really sad).

It's time for implementing ICE+SRTP in SIP. Please don't give SIP
vendors another oportunity to avoid implementing that by offering them
some workaround for media verification.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Tim Panton <[email-masked]>
Date: Tue, 11 Oct 2011 10:34:02 +0100

On 11 Oct 2011, at 05:22, Randell Jesup wrote:
> 
> Is it workable?  I think so.  Is it worthwhile?  I don't know.  I'm somewhat skeptical since it solves only a subset of the problem space (for connecting to legacy devices/gateways).

I just want to add that in my experience it is a _small_ subset of the problem space. 
This group risks duplicating my costly mistake by assuming
that people want to connect to the PSTN/desk phones from their browser.

In general they don't. 
They want to communicate with other browser users on the same (or related) site(s).
That is the area we should be focussing on. If we get legacy interop too - great, but
PSTN interconnect really shouldn't be the deciding factor.

Tim.

---

From: <[email-masked]>
Date: Tue, 11 Oct 2011 13:10:15 +0200

Hi, sorry for my previous message that I probably sent too rapidly: I have just realized that RFC 5576 couldn't be used to describe synchronization source from remote endpoints. So, even for SSRC, extended procedures would be required.. Too bad! (;
Cheers
Sebastien

-----Message d'origine-----
De : CUBAUD Sebastien RD-CORE-LAN 
Envoyé : mardi 11 octobre 2011 09:48
À : 'Jonathan Rosenberg'; [email-masked]
Objet : RE: [rtcweb] Sebastien Cubaud's non-ICE mechanism (Re: Summary of ICE discussion)

Hi Jonathan, 

-----Message d'origine-----

-Jonathan R.

---

From: "Muthu Arul Mozhi Perumal (mperumal)" <[email-masked]>
Date: Tue, 11 Oct 2011 17:35:07 +0530

|> - Assuming B receives these packets, it then sends 
|> via the signalling channel an information from the 
|> media path unknown from S (i.e. not accessible via JS).

A requirement hidden here is that B shouldn't alert the user till the entire consent verification is complete (otherwise B would have to buffer the media coming from the user). If B is a PSTN gateway this isn't going to be trivial to implement.

If we go down this path, I think we would end up reinventing ICE/ICE-Lite in a different form (which doesn't look worth the effort), so we should just make use of ICE.

Muthu

|-----Original Message-----
|From: [email-masked] [mailto:[email-masked]] On Behalf Of Harald Alvestrand
|Sent: Tuesday, October 11, 2011 2:20 AM
|To: [email-masked]
|Subject: [rtcweb] Sebastien Cubaud's non-ICE mechanism (Re: Summary of ICE discussion)
|
|Changing the subject to keep threads separate....
|
|On 10/09/2011 12:00 PM, [email-masked] wrote:
|> Hi there,
|>
|> Re Magnus's call for proposal (If anyone can find a solution that fulfill
|>   the security goals and have improved legacy interoperability people would
|> be interested in that solution. So far RTCP has been discarded as insufficient.)
|> on media consent verification, here is below a suggestion for the group:
|>
|> Basically, the idea, compared to Hadriel's RTCP proposal, relies on the use
|> of the signalling path instead of RTCP as a feedback channel for media
|> consent verification.
|>
|> Here are the steps I foresee before allowing the establishment of a media session:
|>
|> - Let's consider A (a RTC-Web compliant browser) connected to server S and
|> wishing to share real-time media with destination B (potentially a SIP
|> endpoint or a browser)
|> - A&  B learn via the signalling channel the triple @IP, transport proto and
|> associated listening port of the remote media
|> - A sends a few RTP packets to B (3 as in RFC 2833/4733 or more?).- This would
|>   allow the mechanism to resist against packet loss -. The format of such packets
|>   are to be discussed
|> - Assuming B receives these packets, it then sends via the signalling channel
|> an information from the media path unknown from S (i.e. not accessible via JS).
|> I propose to use the min of the sequence number of the RTP packets received
|> (which is random per RFC 3550)
|The sequence number is a 16-bit number, so there are 16 bits of
|randomness to play with here.
|An attack based on just returning a random number will succeed 1 out of
|65.536 times; if any of the 3 packets' sequence numbers are acceptable,
|it will succeed 1 out of 21.845 times.
|
|A browser can reasonably limit the number of attempts per second (either
|overall or per-script); multiple browsers will not be able to coordinate
|on any such limit.
|
|Is this defense strong enough to warrant considering this further?
|
|> - A receives via S this info granting B's consent to receiving media from A
|> - A now can start sending media to B
|>
|> When B uses SIP as its signalling channel, Step 4 would probably require a
|> SDP extension to convey this info, as well as possibly extended H.248/Diameter
|>   informations would be required in a decoupled sig./media architecture.
|> Of course, a solution avoiding extensions would be more than welcome.
|>
|> The benefit of this mechanism largely relies on the assumption that the
|> transmission of information from the media termination of the destination
|> to its associated signalling channel is less costly than implementing ICE connectivity
|> checks. Which is still to be checked.
|>
|> This mechanism provides basic media consent verification and if it turns out
|> that it provides less security properties than ICE or other drawbacks (e.g.
|> increasing media session establishment delay, issues with the few initial RTP
|> packets,..), it could be seen as a fallback media consent verification
|> when ICE is not implemented at each end of media terminations.
|>
|> Looking forward to hearing feedbacks from the group on this.
|>
|> Cheers
|> Sebastien
|>
|> -----Message d'origine-----
|> De : [email-masked] [mailto:[email-masked]] De la part de Magnus Westerlund
|> Envoyé : mardi 4 octobre 2011 16:33
|> À : [email-masked]
|> Objet : [rtcweb] Summary of ICE discussion
|>
|> WG,
|>
|> I have bellow tired to summarize the result of the ICE discussion. This
|> is intended as furthering this discussion and form a basis for going
|> forward in the consensus process. I do expect people that disagree with
|> my summary of the discussion to speak up.
|>
|> Major requirements
|>
|> - Need for data transmission consent for protocols using UDP as the
|> traffic receiver needs to consent to receiving the data
|>
|> - Perform NAT and FW traversal when ever needed
|>
|> - Support IPv4 to IPv6 transition
|>
|> Desired behavior:
|>
|> - Be interoperable with deployed legacy systems as SIP Trunk, PSTN
|> gateways, VoIP phones.
|>
|> WG chairs conclusion of discussion so far:
|>
|> - ICE is so far the only solution that provides the security goals and
|> have any legacy deployment.
|>
|> - ICE usage will require that STUN connectivity MUST have succeeded
|> prior to any data transmission to fulfill security goals.
|>
|>    * The Browser will enforce this requirement to prevent being an attack
|> vector in all cases.
|>
|> - If anyone can find a solution that fulfill the security goals and have
|> improved legacy interoperability people would be interested in that
|> solution. So far RTCP has been discarded as insufficient.
|>
|> - Media Gateway can support a reduced functionality set from Full ICE
|>
|> Cheers
|>
|> Magnus Westerlund
|> as WG chair
|>
|> ----------------------------------------------------------------------
|> 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]
|> ----------------------------------------------------------------------
|>
|> _______________________________________________
|> rtcweb mailing list
|> [email-masked]
|> https://www.ietf.org/mailman/listinfo/rtcweb
|> _______________________________________________
|> rtcweb mailing list
|> [email-masked]
|> https://www.ietf.org/mailman/listinfo/rtcweb
|>
|
|_______________________________________________
|rtcweb mailing list
[email-masked]
|https://www.ietf.org/mailman/listinfo/rtcweb

---

From: <[email-masked]>
Date: Tue, 11 Oct 2011 14:44:57 +0200

Hi Muthu, 

|>A requirement hidden here is that B shouldn't alert the user till the entire consent verification is complete (otherwise B would have to buffer the |>media coming from the user).

I am not sure to follow your concern here: alerting the user would look to me as associated to the first signalling step in which B provides its @IP, transport port, listening port. For instance, as in your example, if B is a PSTN gateway, assuming SIP is the protocol used by the GW to interoperate with RTC-Web, the PSTN gateway may send a IAM message upon reception on the initial SIP INVITE. And this IAM would trigger the alerting of the user (and should alerting the user be a concern, SIP preconditions could be used to prevent it until a precondition being that A has received media consent verification from B be satisfied).

If you mean that the initial "testing" RTP packets could be rendered to the user, this is what I meant as "the format [of the initial RTP packets] are to be discussed" in my initial mail. I guess there are possible ways to make those RTP flows transparent to the end user (e.g. having them discarded by a standard RTP implementations, containing white noise, etc..). Prior to discussing these details, I guess the main point is to determine whether an extension to SIP, as minimal as it can be, is a viable option for SIP endpoints interfacing with RTC-Web compared to ICE connectivity checks procedure. 
Kind regards,

Sebastien
-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Muthu Arul Mozhi Perumal (mperumal)
Envoyé : mardi 11 octobre 2011 14:05
À : Harald Alvestrand; [email-masked]
Objet : Re: [rtcweb] Sebastien Cubaud's non-ICE mechanism (Re: Summary ofICE discussion)

Muthu

---

From: <[email-masked]>
Date: Sun, 9 Oct 2011 11:48:59 +0200

Hi there,

 
 allow the mechanism to resist against packet loss -   

Cheers
Sebastien

-----Message d'origine-----

WG,

Major requirements

Desired behavior:

Cheers

Magnus Westerlund
as WG chair