Subject: [rtcweb] Requiring ICE for RTC calls

From: Roman Shpount <[email-masked]>
Date: Mon, 26 Sep 2011 10:29:59 -0400

I think requiring ICE in RTC is not only unfortunate, it will make it
impossible to connect to PSTN without media gateway. If we complete this
specification, and phone carriers decide that there is a business case for
them to support RTC clients directly, it will take them 3-5 years to
implement ICE in SBC. From what I've seen major carriers run SBC firmware
which is normally 2-3 years old. If we add time it takes to implement ICE in
SBC, plus time it will take PSTN provider to verify and test the feature, we
are easily looking into 5 year time frame.

Since we need to have user confirmation to start a media call anyway, and
since this is not going to be any different from what SIP clients are
currently doing, it would make sense to allow a plain non-ICE, non-SRTP
call.

Finally, ICE specification are desinged to interop with non-ICE end points.
We will need to change ICE to accomplish what you are doing.
_____________
Roman Shpount

On Mon, Sep 26, 2011 at 1:23 AM, Randell Jesup <[email-masked]>wrote:

> On 9/22/2011 4:37 PM, Cullen Jennings wrote:
>
>> On Sep 22, 2011, at 2:04 PM, Christer Holmberg wrote:
>>
>>  If so, what is your assumption then regarding ICE? That the SIP nodes
>>> will support ICE, or that the browser will be allowed to communicate with
>>> the SIP nodes without enabling ICE?
>>>
>> I see no way of solving the security problems without having ICE or
>> something more or less like it. Therefore, I'm working on the assumption
>> that it will only work if the SIP side supports ICE, or is front ended by a
>> SBC with media GW that does ICE. In the short term, there will be some
>> devices that don't do ICE but SIP devices are increasingly having ICE added.
>> Particularly SIP devices that are internet facing because the need for NAT
>> traversal.
>>
>> I find requiring ICE to be a very unfortunate assumption to have to make -
>> obviously it reduces the number of legacy voip devices WebRTC devices can
>> talk to without an SBC but I don't see any way around this limitation.
>> Allowing web browsers inside the firewall to send packets to an arbitrary
>> address that is inside the firewall with no validation that address speaks
>> RTP is not acceptable.
>>
>
> I agree we can't solve the security issue with permission to send with the
> current threat model without ICE or some equivalent.
>
> There is another option that may help with some of the use cases (I've
> mentioned
> this before in the discussion on screensharing, among others).  For a
> number
> of the use cases security is an impassible problem with the current threat
> model.
> Those use cases generally involve replacing cases where an existing desktop
> install or plugin was used (webex, screensharing, vnc, SIP softclient,
> Skype, etc).
> Those cases all currently involve the user implicitly giving these apps
> total
> or close to code that could do pretty much anything on the user's computer,
> and are also often the "ongoing usage" authentication cases.
>
> The only mitigating safety of the external app/plugin model is that they're
> typically
> signed and go through the platforms software-install procedure,
> cert-showing, UACs, etc.
>
> Currently people are trying to work out the HTML5 "installed" webapp
> security model;
> if that's far enough along we may be able to piggyback off that.   I'm
> looking into it.
>
>
> --
> Randell Jesup
> [email-masked]
>
> ______________________________**_________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/rtcweb<https://www.ietf.org/mailman/listinfo/rtcweb>
>

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 26 Sep 2011 07:45:50 -0700

>
> Finally, ICE specification are desinged to interop with non-ICE end
points. We will need to change ICE to accomplish what you are doing.

Maybe I misundersatnd you, but the PSTN carriers today and in the future
will always run an SBC because that is their security policy.

Regarding firmware, they react to market needs and timing.

Cb

_____________
>>>
>>> I find requiring ICE to be a very unfortunate assumption to have to make
- obviously it reduces the number of legacy voip devices WebRTC devices can
talk to without an SBC but I don't see any way around this limitation.
Allowing web browsers inside the firewall to send packets to an arbitrary
address that is inside the firewall with no validation that address speaks
RTP is not acceptable.
mentioned
number
>> of the use cases security is an impassible problem with the current
threat model.
Skype, etc).
total
>> The only mitigating safety of the external app/plugin model is that
they're typically
cert-showing, UACs, etc.
security model;
looking into it.
>>
>>
>> --
>> Randell Jesup
>> [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
>

---

From: Roman Shpount <[email-masked]>
Date: Mon, 26 Sep 2011 10:52:25 -0400

PSTN carriers today almost always run SBCs. At the same time I have not seen
an SBC from any major US carrier with firmware newer the 2 years old. I've
never seen an SBC in carrier deployment that currently supports ICE or SRTP.

Bottom line, no carriers currently support ICE or SRTP. If we create the
market requirements for them to support ICE and SRTP, it will take them 3-5
years to add such support. If we have anybody from SBC manufacturing
companies or carriers who can provide evidence to the opposite, I would love
to hear from them. In any case, it would be prudent to provide a way to use
current non-ICE, non-SRTP with RTC.
_____________
Roman Shpount

On Mon, Sep 26, 2011 at 10:45 AM, Cameron Byrne <[email-masked]> wrote:

> >>> I find requiring ICE to be a very unfortunate assumption to have to
> make - obviously it reduces the number of legacy voip devices WebRTC devices
> can talk to without an SBC but I don't see any way around this limitation.

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 26 Sep 2011 08:03:23 -0700

On Sep 26, 2011 7:52 AM, "Roman Shpount" <[email-masked]> wrote:
>
> PSTN carriers today almost always run SBCs. At the same time I have not
seen an SBC from any major US carrier with firmware newer the 2 years old.
I've never seen an SBC in carrier deployment that currently supports ICE or
SRTP.

I am with a mobile carrier that does FMC and we have products that use SRTP
to an SBC today. I don't know about ICE, but I think your projection is
clearly not true.  If other carriers delay, I am glad to take their
business.

Cameron

>> >
>> > Since we need to have user confirmation to start a media call anyway,
and since this is not going to be any different from what SIP clients are
currently doing, it would make sense to allow a plain non-ICE, non-SRTP
call.
>> >>>> If so, what is your assumption then regarding ICE? That the SIP
nodes will support ICE, or that the browser will be allowed to communicate
with the SIP nodes without enabling ICE?
mentioned
number
threat model.
Skype, etc).
>> >> Those cases all currently involve the user implicitly giving these
apps total
they're typically
cert-showing, UACs, etc.
security model;
looking into it.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 26 Sep 2011 17:15:37 +0200

> will always run an SBC because that is their security policy.

Hi. Please let's forget "SBC" and let's go to a simpler case: a PSTN
provider that speeak SIP and RTP with clients and SIP/SS7/ISUP with
other PSTN operators. The signaling and media conversion is done in
PSTN gateways. Most of them, for sure, don't implement ICE neither
SRTP.

Anyhow, concerning this subject, I already proposed something in other
thread: why couldn't the provider (the web site) tell their WebRTC
clients wheter they shoud or not accept media sessions without ICE
and/or SRTP?

For example, a telco operator that creates a web site for allow its
clients making PSTN calls from the web, could relax those requirements
and don't mandate ICE/SRTP. In the other side, a social network web
site which just allows calls between web users could mandate them.
Such configuration could be retrieved by the WebRTC client via HTTP or
WebSocket by standarizing a document format.

Regards.

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

---

From: Matthew Kaufman <[email-masked]>
Date: Mon, 26 Sep 2011 08:20:42 -0700

On 9/26/2011 8:15 AM, Iñaki Baz Castillo wrote:
> 2011/9/26 Cameron Byrne<[email-masked]>:

Because that doesn't meet the security requirements.
> WebSocket by standarizing a document format.

For example, an evil overlord that creates a web site for allowing its 
clients to attack systems behind a firewall could relax those 
requirements and not mandate ICE/SRTP when opening arbitrary connections 
to systems behind said firewall.

The "configuration" must be retrieved by the WebRTC client *from the 
system it will be sending traffic to*... the best format we have for 
that is to send a (rate-limited) STUN connectivity check with short-term 
credentials and see if it is replied to properly. That's how ICE works.

Matthew Kaufman

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 26 Sep 2011 17:29:37 +0200

2011/9/26 Matthew Kaufman <[email-masked]>:
> clients to attack systems behind a firewall could relax those requirements
> and not mandate ICE/SRTP when opening arbitrary connections to systems
> behind said firewall.
>
> The "configuration" must be retrieved by the WebRTC client *from the system
> it will be sending traffic to*... the best format we have for that is to
> send a (rate-limited) STUN connectivity check with short-term credentials
> and see if it is replied to properly. That's how ICE works.

I understand your points and I agree. That would be the perfect scenario.

But I'm worried about the price to pay for these security constrains
(no interoperability with 95% of SIP-PSTN providers within next 3-5
years).

Regards.

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

---

From: Matthew Kaufman <[email-masked]>
Date: Mon, 26 Sep 2011 08:48:54 -0700

On 9/26/2011 8:29 AM, Iñaki Baz Castillo wrote:
> 2011/9/26 Matthew Kaufman<[email-masked]>:

That would be the only scenario that is safe enough to ship in a browser.

> (no interoperability with 95% of SIP-PSTN providers within next 3-5

The alternative is that you don't ship anything in the browser, because 
the browser *cannot* become an attack vector as a result of adding this 
feature.

And "interoperability with SIP-PSTN providers" is only relevant if you 
are trying to turn the browser into another phone. We have enough 
phones. What we don't have are new real-time communication experiences 
that can only be created within this environment.

Matthew Kaufman

---

From: Roman Shpount <[email-masked]>
Date: Mon, 26 Sep 2011 12:26:10 -0400

On Mon, Sep 26, 2011 at 11:48 AM, Matthew Kaufman <[email-masked]
> wrote:

> And "interoperability with SIP-PSTN providers" is only relevant if you are
> trying to turn the browser into another phone. We have enough phones. What
> we don't have are new real-time communication experiences that can only be
> created within this environment.
>

Are we deliberately creating an island? To be honest, I actually wanted to
put RTC in the phone, instead of SIP. I think it would be a great idea to
have desktop phone which runs a webkit browser with RTC and serves as an
advanced display phone for a PBX. If RTC would not support no-ICE non-RTP
calls, my only option would be to ignore the standard. So, in a sense we do
not have enough phones.

I think you point in a lot of ways is similar to the argument that we should
disable HTTP and leave only HTTPS since it is the only secure way to
communicate and everything else would be an attack vector.
_____________
Roman Shpount

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 26 Sep 2011 18:39:36 +0200

2011/9/26 Matthew Kaufman <[email-masked]>:
> The alternative is that you don't ship anything in the browser, because the
> browser *cannot* become an attack vector as a result of adding this feature.

> trying to turn the browser into another phone.

If I need to make a call I use my phone rather than opening a web
browser. But a phone integrated within a web page has a big added
value (real integration of telephony in the web).

And I don't speak just about boring PSTN calls. Skype could create a
client running in a WebRTC browser for communicating with Skype
network (and also PSTN calls, why not?).

> We have enough phones.

Yes, and some privative VoIP protocols.

> What

Good vision. But such vision should not limit/restrict any other
posibility for WebRTC (as basic PSTN telephony integration).

Regards.

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

---

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Tue, 27 Sep 2011 00:01:46 +0530

I'm sort of lean towards ICE or ICElite mechanism for NAT traversal of media because there is no known better mechanism. In case there is known better mechanism, Please list out for discussion.

Thanks
Partha

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf
>Of Matthew Kaufman
>Sent: Monday, September 26, 2011 9:19 PM
>To: Iñaki Baz Castillo
>Cc: Randell Jesup; [email-masked]
>Subject: Re: [rtcweb] Requiring ICE for RTC calls
>
>requirements
>system

---

From: Roman Shpount <[email-masked]>
Date: Mon, 26 Sep 2011 14:48:02 -0400

You can determine that end point is not behind symmetric NAT using older
STUN specification and list discovered IP as a default contact address in
SDP, if you are not behind NAT, you can list the relayed address of the TURN
server as the default address. If you do this, together with the offer that
lists ICE candidates, you would be able to traverse NAT and communicate with
non-ICE end points.

I think discussion in this thread is not whether ICE needs to be supported
or implemented. I would say that ICE without a doubt should be supported. It
is about changing ICE specification as it stands right now, and force the
RTC end point only to communicate with end points that respond with ICE
compliant answer and complete ICE hand shake. This is actually against the
ICE specification as it is defined in RFC 5245, where answerer actually can
refuse to support ICE but still establish a call.
_____________
Roman Shpount

On Mon, Sep 26, 2011 at 2:31 PM, Ravindran Parthasarathi <
[email-masked]> wrote:

> I'm sort of lean towards ICE or ICElite mechanism for NAT traversal of
> media because there is no known better mechanism. In case there is known
> better mechanism, Please list out for discussion.
>
> Thanks
> Partha
>

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 26 Sep 2011 20:44:48 -0700

> that can only be created within this environment.

[BA] I think you may be on to something here.  POTS lines are dropping so rapidly
that wireline service won't even exist in some countries within a few years.  While
PSTN interop may have been a key scenario in the early days of SIP, I have serious
doubts as to how much attention we should pay to this in RTCWEB.  Ability to
make a call to an E.164 number?  Probably.  Support for every potential corner
case?  Not necessarily.

---

From: Tim Panton <[email-masked]>
Date: Mon, 26 Sep 2011 21:49:18 -0700

On 26 Sep 2011, at 09:26, Roman Shpount wrote:

> 
> On Mon, Sep 26, 2011 at 11:48 AM, Matthew Kaufman <[email-masked]> wrote:
> And "interoperability with SIP-PSTN providers" is only relevant if you are trying to turn the browser into another phone. We have enough phones. What we don't have are new real-time communication experiences that can only be created within this environment.
> 
> Are we deliberately creating an island? To be honest, I actually wanted to put RTC in the phone, instead of SIP. I think it would be a great idea to have desktop phone which runs a webkit browser with RTC and serves as an advanced display phone for a PBX. If RTC would not support no-ICE non-RTP calls, my only option would be to ignore the standard. So, in a sense we do not have enough phones.

I am confused. Which phones today connect directly to a SIP to PSTN gateway ? I'd guess none. 
Almost all of them go through some registrar and/or proxy.  

> 
> I think you point in a lot of ways is similar to the argument that we should disable HTTP and leave only HTTPS since it is the only secure way to communicate and everything else would be an attack vector.

No, HTTP today does not let me probe the innards of your network ( inside your firewall) just by sending 
a legal but evil payload. If you permit webRTC without ICE, then the browser can be told to fake up UDP packets
and send them to anywhere on your inner LAN. DOS-city.

Tim.

---

From: Justin Uberti <[email-masked]>
Date: Tue, 27 Sep 2011 01:36:00 -0400

Yes, most PSTN providers don't support ICE. They also often don't support
SRTP, RTCP, RTP over TCP, or even jitter buffers. To run a robust telephony
service, you will need to frontend that traffic with a media gateway of some
sort, and that gateway can easily support ICE.

On Tue, Sep 27, 2011 at 12:49 AM, Tim Panton <[email-masked]> wrote:

> I think you point in a lot of ways is similar to the argument that we
> should disable HTTP and leave only HTTPS since it is the only secure way to
> a legal but evil payload. If you permit webRTC without ICE, then the
> browser can be told to fake up UDP packets

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Tue, 27 Sep 2011 09:34:52 +0200

> make a call to an E.164 number?  Probably.  Support for every potential corner

PSTN gateways are one example of non-ICE capable devices (usually) as of today. But it's not the only one. None of the hardware SIP phones I've used support ICE, so we'd have trouble when talking to them.

I do agree that requiring ICE is a good idea, but I don't think the currently deployed infrastructures are ready for it today. Maybe ICE support will improve across vendors and it'll be more widely adopted if RTCweb mandates it, we'll see :-)

--
Saúl Ibarra Corretgé
AG Projects

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 27 Sep 2011 10:14:52 +0200

On 09/26/11 20:48, Roman Shpount wrote:
> You can determine that end point is not behind symmetric NAT using 
> older STUN specification and list discovered IP as a default contact 
> address in SDP, if you are not behind NAT, you can list the relayed 
> address of the TURN server as the default address. If you do this, 
> together with the offer that lists ICE candidates, you would be able 
> to traverse NAT and communicate with non-ICE end points.
>
> I think discussion in this thread is not whether ICE needs to be 
> supported or implemented. I would say that ICE without a doubt should 
> be supported. It is about changing ICE specification as it stands 
> right now, and force the RTC end point only to communicate with end 
> points that respond with ICE compliant answer and complete ICE hand 
> shake. This is actually against the ICE specification as it is defined 
> in RFC 5245, where answerer actually can refuse to support ICE but 
> still establish a call.
Roman,

Which part of RFC 5245 are you referring to with this statement?

Please describe the sections you think will be invoked when an SDP OFFER 
contains ICE candidates, the answerer does not want to use ICE, what the 
OFFER and ANSWER would look like, and which section of RFC 5245 is 
invoked when processing the ANSWER.

Details are good.

                 Harald

---

From: Roman Shpount <[email-masked]>
Date: Tue, 27 Sep 2011 10:40:54 -0400

Bernard,

What about 500M Skype users? Skype for SIP does not support SRTP or ICE.What
about 2 billion wireless subscribers? Despite what you think number of
phones and phone numbers is growing, and a wast majority of these phones are
dumb wireless phones.
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Tue, 27 Sep 2011 10:46:27 -0400

> Almost all of them go through some registrar and/or proxy.
We are not talking about SIP proxy here. We are talking about media proxy.
These have a tendency to consume wast quantities of CPU and bandwidth, since
they need to resend every media packet. There is no doubt that we need a
proxy for signaling but it will not require as much resources.

> and send them to anywhere on your inner LAN. DOS-city.

How real or big do you think this problem is going to be? None of the
current SIP/VoIP clients address this now, and we have quite a number of
them out there. I understand that this is an attack vector but how big of an
attack vector is this going to be if we ask for user confirmation?
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Tue, 27 Sep 2011 10:49:28 -0400

Sorry, correcting myself, there are over 5 billion mobile phones worldwide.
Are you sure we don't need to talk to them.
_____________
Roman Shpount

On Tue, Sep 27, 2011 at 10:40 AM, Roman Shpount <[email-masked]> wrote:

> Bernard,
>
> What about 500M Skype users? Skype for SIP does not support SRTP or
> ICE.What about 2 billion wireless subscribers? Despite what you think number
> of phones and phone numbers is growing, and a wast majority of these phones
> are dumb wireless phones.
> _____________
> Roman Shpount
>
>
> On Mon, Sep 26, 2011 at 11:44 PM, Bernard Aboba <[email-masked]
> > wrote:
>
>>

---

From: Justin Uberti <[email-masked]>
Date: Tue, 27 Sep 2011 10:55:34 -0400

We can still talk to them via a media gateway, which robust telephony
services will already provide for the reasons I mentioned previously.

On Tue, Sep 27, 2011 at 10:49 AM, Roman Shpount <[email-masked]> wrote:

>> On Mon, Sep 26, 2011 at 11:44 PM, Bernard Aboba <
>> [email-masked]> wrote:
>>
>>>

---

From: Roman Shpount <[email-masked]>
Date: Tue, 27 Sep 2011 11:06:26 -0400

Let's see:

4.1.4. Choosing Default Candidates

A candidate is said to be default if it would be the target of media
from a non-ICE peer; that target is called the DEFAULT DESTINATION.
If the default candidates are not selected by the ICE algorithm when
communicating with an ICE-aware peer, an updated offer/answer will be
required after ICE processing completes in order to "fix up" the SDP
so that the default destination for media matches the candidates
selected by ICE. If ICE happens to select the default candidates, no
updated offer/answer is required.

An agent MUST choose a set of candidates, one for each component of
each in-use media stream, to be default.

5.1. Verifying ICE Support

If this condition is not met, the agent MUST process the SDP based on
normal RFC 3264 procedures, without using any of the ICE mechanisms
described in the remainder of this specification...

6.1. Verifying ICE Support

The logic at the offerer is identical to that of the answerer as described
in Section 5.1, with the exception that an offerer would not ever generate
a=ice-mismatch attributes in an SDP.

My interpretation of this always was that ICE enabled end point MUST
generate an offer that will be understood by a non-ICE end point, properly
process on offer from a non-ICE enabled end point, and properly process an
answer from a non-ICE end point. So if we want RTC to be ICE complaint we
should be able to communicate with non-ICE end points, or define a new
specification.
_____________
Roman Shpount

On Tue, Sep 27, 2011 at 4:14 AM, Harald Alvestrand <[email-masked]>wrote:

> OFFER and ANSWER would look like, and which section of RFC 5245 is invoked
> when processing the ANSWER.
>
> Details are good.
>
>                Harald
>

---

From: Roman Shpount <[email-masked]>
Date: Tue, 27 Sep 2011 11:12:18 -0400

I am sorry, but can you name "robust telephony services" that currently
provide ICE and SRTP support in US? AFAK Verizon, Qwest, Level3, Global
Crossing, Paetec, XO do not provide this.
_____________
Roman Shpount

On Tue, Sep 27, 2011 at 10:55 AM, Justin Uberti <[email-masked]> wrote:

>> Sorry, correcting myself, there are over 5 billion mobile phones
>> worldwide. Are you sure we don't need to talk to them.
>> _____________
>> Roman Shpount
>>
>>
>>
>> On Tue, Sep 27, 2011 at 10:40 AM, Roman Shpount <[email-masked]>wrote:
>>
>>> Bernard,
>>>

---

From: Matthew Kaufman <[email-masked]>
Date: Tue, 27 Sep 2011 08:15:55 -0700

On 9/27/2011 7:46 AM, Roman Shpount wrote:
> current SIP/VoIP clients address this now, and we have quite a number 
> of them out there. I understand that this is an attack vector but how 
> big of an attack vector is this going to be if we ask for user 
> confirmation?
>

There is no plan to ask for user confirmation to open a connection, 
receive media, or send and receive data. The only user confirmation that 
is expected would be for camera and/or microphone access.

I've seen a dozen messages from you arguing that the requirement for a 
STUN connectivity check is a barrier and should be removed, but I have 
not yet seen an alternative proposal that meets the requirements of 
browser authors with regard to preventing attacks on behind-firewall 
infrastructure from the browser platform.

Matthew Kaufman

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 27 Sep 2011 17:20:37 +0200

Hi,

I don't think the question is about changing the ICE spec.

You are correct in that ICE as such allows establishment of sessions with non-ICE peers, but I don't think anyone is questioning that.

The question is whether we shall specify that the browser must use "Require:ICE" (speaking in SIP terms :), in order to fulful some security requirement.

So, in my opinion we shall focus on the requirement, and whether we need to mandate the usage of some mechanism (ICE or something else) in order to solve that requirement.

...or whether the requirement should be dropped or relaxed.

Regards,

Christer

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Roman Shpount
Sent: 27. syyskuuta 2011 18:06
To: Harald Alvestrand
Cc: [email-masked]
Subject: Re: [rtcweb] RFC 5245 interpretation (Re: Requiring ICE for RTC calls)

Let's see:

The logic at the offerer is identical to that of the answerer as described in Section 5.1, with the exception that an offerer would not ever generate a=ice-mismatch attributes in an SDP.

My interpretation of this always was that ICE enabled end point MUST generate an offer that will be understood by a non-ICE end point, properly process on offer from a non-ICE enabled end point, and properly process an answer from a non-ICE end point. So if we want RTC to be ICE complaint we should be able to communicate with non-ICE end points, or define a new specification.
_____________
Roman Shpount

On Tue, Sep 27, 2011 at 4:14 AM, Harald Alvestrand <[email-masked]<mailto:[email-masked]>> wrote:
On 09/26/11 20:48, Roman Shpount wrote:
You can determine that end point is not behind symmetric NAT using older STUN specification and list discovered IP as a default contact address in SDP, if you are not behind NAT, you can list the relayed address of the TURN server as the default address. If you do this, together with the offer that lists ICE candidates, you would be able to traverse NAT and communicate with non-ICE end points.

I think discussion in this thread is not whether ICE needs to be supported or implemented. I would say that ICE without a doubt should be supported. It is about changing ICE specification as it stands right now, and force the RTC end point only to communicate with end points that respond with ICE compliant answer and complete ICE hand shake. This is actually against the ICE specification as it is defined in RFC 5245, where answerer actually can refuse to support ICE but still establish a call.
Roman,

Please describe the sections you think will be invoked when an SDP OFFER contains ICE candidates, the answerer does not want to use ICE, what the OFFER and ANSWER would look like, and which section of RFC 5245 is invoked when processing the ANSWER.

Details are good.

               Harald

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

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 27 Sep 2011 08:23:26 -0700

I'm not going to use this mailing list as an advertising medium, but there do exist products that support both ICE and SRTP, and some of the companies you name below have deployed those products to *thousands* of their employees. 

Date: Tue, 27 Sep 2011 11:12:18 -0400
Subject: Re: [rtcweb] Requiring ICE for RTC calls
From: [email-masked]
To: [email-masked]
CC: [email-masked]; [email-masked]

I am sorry, but can you name "robust telephony services" that currently provide ICE and SRTP support in US? AFAK Verizon, Qwest, Level3, Global Crossing, Paetec, XO do not provide this._____________

Roman Shpount

---

From: Tim Panton <[email-masked]>
Date: Tue, 27 Sep 2011 08:24:30 -0700

On 27 Sep 2011, at 07:49, Roman Shpount wrote:

> Sorry, correcting myself, there are over 5 billion mobile phones worldwide. Are you sure we don't need to talk to them. 
> _____________
> Roman Shpount

Not a _single_one_ of those mobile phones is running SIP/RTP or supports G.711 - if you follow that argument,
we should be requiring GSM610 support and deriving a version of the GSM media protocol.

Tim.

---

From: Tim Panton <[email-masked]>
Date: Tue, 27 Sep 2011 08:27:48 -0700

On 27 Sep 2011, at 07:46, Roman Shpount wrote:
> 
> How real or big do you think this problem is going to be? None of the current SIP/VoIP clients address this now, and we have quite a number of them out there. I understand that this is an attack vector but how big of an attack vector is this going to be if we ask for user confirmation? 
> _____________
> Roman Shpount

It actually doesn't matter what I think. We have to do something here that the browser makers are prepared to deploy. What question would you ask the user that would satisfy them?

Tim.

---

From: Dzonatas Sol <[email-masked]>
Date: Tue, 27 Sep 2011 08:37:51 -0700

Maybe if we narrow down that selection to those that can update car 
drivers to those that have met standards (and maybe ahhh "Class E" 
licensed software upload).

On 09/27/2011 08:23 AM, Bernard Aboba wrote:
> I'm not going to use this mailing list as an advertising medium, but 
> there do exist products that support both ICE and SRTP, and some of 
> the companies you name below have deployed those products to 
> *thousands* of their employees.
>
> ------------------------------------------------------------------------
> I am sorry, but can you name "robust telephony services" that 
> currently provide ICE and SRTP support in US? AFAK Verizon, Qwest, 
> Level3, Global Crossing, Paetec, XO do not provide this.
> _____________
> Roman Shpount
>
>
>

-- 

---
<i>The wheel.</i metro-link=t dzonatasolyndra>

---

From: Roman Shpount <[email-masked]>
Date: Tue, 27 Sep 2011 11:52:03 -0400

> we should be requiring GSM610 support and deriving a version of the GSM

It does not matter what they run. Quite a few of them do not run GSM, but I
can cost effectively call every one of them using SIP/G.711, and that's what
very important. It will take some amount of time to upgrade this
infrastructure to support SRTP and ICE.
_____________
Roman Shpount

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 27 Sep 2011 09:03:21 -0700

Roman Shpount said:

"It does not matter what they run. Quite a few of them do not run GSM, but I can cost effectively call every one of them using SIP/G.711, and that's what very important. It will take some amount of time to upgrade this infrastructure to support SRTP and ICE."

[BA] Why would it be necessary to upgrade wireless carrier infrastructure?  Presumably a service that wants to make calls to E.164 numbers will install a gateway that enables this.  Wireless carriers wouldn't have to upgrade.

---

From: Roman Shpount <[email-masked]>
Date: Tue, 27 Sep 2011 12:04:20 -0400

What I meant is that not a single one of those companies offers either SRTP
or ICE in their SIP trunking products, and that's the product you will need
to interop with if you would want to connect RTC to traditional PSTN. What
those companies use for their employees or residential line customers is
less relevant.
_____________
Roman Shpount

On Tue, Sep 27, 2011 at 11:23 AM, Bernard Aboba
<[email-masked]>wrote:

>  I'm not going to use this mailing list as an advertising medium, but there
> do exist products that support both ICE and SRTP, and some of the companies
> you name below have deployed those products to *thousands* of their
> employees.
>
> ------------------------------

---

From: Roman Shpount <[email-masked]>
Date: Tue, 27 Sep 2011 12:08:51 -0400

On Tue, Sep 27, 2011 at 12:03 PM, Bernard Aboba
<[email-masked]>wrote:

>  Roman Shpount said:
>
> "It does not matter what they run. Quite a few of them do not run GSM, but
> I can cost effectively call every one of them using SIP/G.711, and that's
> what very important. It will take some amount of time to upgrade this
> infrastructure to support SRTP and ICE."
>
> [BA] Why would it be necessary to upgrade wireless carrier infrastructure?
> Presumably a service that wants to make calls to E.164 numbers will install
> a gateway that enables this.  Wireless carriers wouldn't have to upgrade.
>

No, we do not need to upgrade wireless carriers. The only people really
affected are the SIP trunking providers, and they are also often the slowest
in introducing new features.

What I meant that by supporting SIP/G.711 we get an a existing, cost
effective way to access 5 billion wireless subscribers, as well as 500M
Skype subscribers, millions of corporate customers. Calling using SIP/G.711
through a SIP trunk provider is not only about wireline PSTN, it is about a
much larger universe of people.
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Tue, 27 Sep 2011 12:30:59 -0400

Matthew,

One possible solution would be to have a slow rate RTP start, if remote end
point does not indicate ICE support. Instead of sending real media, RTC end
point will send no-media RTP packets at the rate of 2-3 per second for 10-15
seconds. If it receives a valid RTP packet back from the destination IP, it
will consider RTP flow verified and switch to sending media at normal rate,
otherwise media stream is terminated. We can have a better timing mechanism
for RTP packets to match the number of packets in the initial STUN handshake
in ICE, but the general idea is to get interoperability with existing
networks at the cost of 20 packet handshake. I do realize that the problem
with this that the RTP packets can be spoofed to force the web end point to
transmit, but this is the best solution I see so far.

If we do decide that ICE is a requirement, we can also have a local policy,
web site can be specified for which the calls are allowed without ICE.

Independently from all of this, SRTP should be optional. It does present
privacy concerns, but they are no different then privacy concerns over HTTP.
_____________
Roman Shpount

On Tue, Sep 27, 2011 at 11:15 AM, Matthew Kaufman <[email-masked]

> There is no plan to ask for user confirmation to open a connection, receive
> media, or send and receive data. The only user confirmation that is expected
> would be for camera and/or microphone access.
>
> I've seen a dozen messages from you arguing that the requirement for a STUN
> connectivity check is a barrier and should be removed, but I have not yet
> seen an alternative proposal that meets the requirements of browser authors
> with regard to preventing attacks on behind-firewall infrastructure from the
> browser platform.
>
> Matthew Kaufman
>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 27 Sep 2011 18:38:04 +0200

> web site can be specified for which the calls are allowed without ICE.

I agree. Somebody would reply now that the provider could be
malicious, but nothing prevents a malicious provider to establish a
valid and secure SRTP+ICE video session with a web visitor and later
publish the video in Youtube.

> privacy concerns, but they are no different then privacy concerns over HTTP.

The privacy concerns of RTP are the same that those present in HTTP,
SMTP, FTP, SIP, XMPP or whatever application level protocol. But none
of those specifications require TLS. Of course a service provider
could decide to impose TLS, but the specification (rtcweb here) should
not mandate so much (IMHO).

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

---

From: Justin Uberti <[email-masked]>
Date: Tue, 27 Sep 2011 13:01:02 -0400

Neither Google Voice nor Skype (both fairly popular services) send raw RTP
directly from the client to a PSTN terminator. I can't speak for Skype, but
Google Voice uses a media gateway for the quality-related reasons I
mentioned earlier.

Since these large-scale services can deploy media gateways, it's clear that
this is not a significant impediment. PSTN calling is a paid-for service,
after all.

On Tue, Sep 27, 2011 at 11:12 AM, Roman Shpount <[email-masked]> wrote:

> On Tue, Sep 27, 2011 at 10:55 AM, Justin Uberti <[email-masked]>wrote:
>
>> On Tue, Sep 27, 2011 at 10:49 AM, Roman Shpount <[email-masked]>wrote:
>>

---

From: Matthew Kaufman <[email-masked]>
Date: Tue, 27 Sep 2011 10:25:15 -0700

On 9/27/11 9:30 AM, Roman Shpount wrote:
> Matthew,
>
> One possible solution would be to have a slow rate RTP start, ... I do 
> realize that the problem with this that the RTP packets can be spoofed 
> to force the web end point to transmit, but this is the best solution 
> I see so far.

You are correct that an attacker can spoof RTP packets to override this 
mechanism. Thus it is not sufficient. RTCP is also not sufficient, as 
we've been through this before: 
http://www.ietf.org/mail-archive/web/rtcweb/current/msg00500.html

>
> Independently from all of this, SRTP should be optional. It does 
> present privacy concerns, but they are no different then privacy 
> concerns over HTTP.

The difference is that knowing whether your media is using SRTP or not 
is more difficult than knowing that the content was delivered over HTTPS 
or HTTP, without significantly more browser chrome.

Matthew Kaufman

---

From: Matthew Kaufman <[email-masked]>
Date: Tue, 27 Sep 2011 10:30:13 -0700

On 9/27/11 10:01 AM, Justin Uberti wrote:
> Neither Google Voice nor Skype (both fairly popular services) send raw 
> RTP directly from the client to a PSTN terminator. 

True.

> I can't speak for Skype, but Google Voice uses a media gateway for the 
> quality-related reasons I mentioned earlier.

I can't speak for Skype either, but this is a good guess.

>
> Since these large-scale services can deploy media gateways, it's clear 
> that this is not a significant impediment.

Agree. I'm not at all sure what the argument is that we need 
existing-PSTN-gateway-compatible RTP (without SRTP or ICE). If there is 
demand, these gateways will be upgraded to support RTCWeb. If there is 
not, service providers can run intermediate gateways.

Matthew Kaufman

---

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Wed, 28 Sep 2011 00:04:29 +0530

Hi Roman,

My understanding is same as Christer.  In case your aim is to interop
with PSTN gateway, Umpteen number of changes has to be done in current
RTCWeb and we may end-up in SIP with current standard for IP based
real-time interaction. IMO, ICE selection is not the only stopping
factor for PSTN interop and anyhow, you need RTCWeb server to PSTN
gateway which shall perform media gateway functionality as well. So,
Please don't reject ICE for PSTN or SIP trunk interop.  

In the another mail thread, there is a discussion that lot of operators
and Enterprise SIP implementation does not support ICE and so, RTCWeb
should support interop with non-ICE peer. The point to be noted is that
the default media destination is known in specific deployment, ICE
process shall be skipped. Lot of the deployment will not have NAT before
Customer premise Equipment and so, ICE is overhead . Also, SBC handles
NAT issue in a smarter way than ICE for few deployment.  So, ICE is not
required in lot of existing deployment. 

Depreciated STUN RFC has lot of loss end which results in the current
STUN, TURN, and ICE. Current STUN Indication may solve couple of NAT
issues but not all.

NAT and security consideration of RTCWeb forces us to look for mandating
ICE. In case you have alternative mechanism or any other technical
reason for not to mandate ICE, Please let us know.

Thanks

Partha

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Christer Holmberg
Sent: Tuesday, September 27, 2011 8:51 PM
To: Roman Shpount; Harald Alvestrand
Cc: [email-masked]
Subject: Re: [rtcweb] RFC 5245 interpretation (Re: Requiring ICE forRTC
calls)

Hi,

You are correct in that ICE as such allows establishment of sessions
with non-ICE peers, but I don't think anyone is questioning that.

The question is whether we shall specify that the browser must use
"Require:ICE" (speaking in SIP terms :), in order to fulful some
security requirement.

So, in my opinion we shall focus on the requirement, and whether we need
to mandate the usage of some mechanism (ICE or something else) in order
to solve that requirement.

Regards,

Christer

	 

	From: [email-masked] [mailto:[email-masked]]
On Behalf Of Roman Shpount
	Sent: 27. syyskuuta 2011 18:06
	To: Harald Alvestrand
	Cc: [email-masked]
	Subject: Re: [rtcweb] RFC 5245 interpretation (Re: Requiring ICE
for RTC calls)

	Let's see:

	A candidate is said to be default if it would be the target of
media
	from a non-ICE peer; that target is called the DEFAULT
DESTINATION.
	If the default candidates are not selected by the ICE algorithm
when
	communicating with an ICE-aware peer, an updated offer/answer
will be
	required after ICE processing completes in order to "fix up" the
SDP
	so that the default destination for media matches the candidates
	selected by ICE. If ICE happens to select the default
candidates, no
	updated offer/answer is required.
	
	An agent MUST choose a set of candidates, one for each component
of
	each in-use media stream, to be default.

	If this condition is not met, the agent MUST process the SDP
based on
	normal RFC 3264 procedures, without using any of the ICE
mechanisms
	described in the remainder of this specification...

	The logic at the offerer is identical to that of the answerer as
described in Section 5.1, with the exception that an offerer would not
ever generate a=ice-mismatch attributes in an SDP.
	
	My interpretation of this always was that ICE enabled end point
MUST generate an offer that will be understood by a non-ICE end point,
properly process on offer from a non-ICE enabled end point, and properly
process an answer from a non-ICE end point. So if we want RTC to be ICE
complaint we should be able to communicate with non-ICE end points, or
define a new specification.
	_____________
	Roman Shpount

	On Tue, Sep 27, 2011 at 4:14 AM, Harald Alvestrand
<[email-masked]> wrote:

	You can determine that end point is not behind symmetric NAT
using older STUN specification and list discovered IP as a default
contact address in SDP, if you are not behind NAT, you can list the
relayed address of the TURN server as the default address. If you do
this, together with the offer that lists ICE candidates, you would be
able to traverse NAT and communicate with non-ICE end points.
	
	I think discussion in this thread is not whether ICE needs to be
supported or implemented. I would say that ICE without a doubt should be
supported. It is about changing ICE specification as it stands right
now, and force the RTC end point only to communicate with end points
that respond with ICE compliant answer and complete ICE hand shake. This
is actually against the ICE specification as it is defined in RFC 5245,
where answerer actually can refuse to support ICE but still establish a
call.

	Roman,

	Please describe the sections you think will be invoked when an
SDP OFFER contains ICE candidates, the answerer does not want to use
ICE, what the OFFER and ANSWER would look like, and which section of RFC
5245 is invoked when processing the ANSWER.
	
	Details are good.
	
	               Harald

---

From: Roman Shpount <[email-masked]>
Date: Tue, 27 Sep 2011 14:38:28 -0400

What about intranet applications that would want to locally call existing IP
phones within the same enterprise? Should we force them to go through a
media gateway as well or should we allow to overwrite this using a policy?

As far as SRTP is concerned, once again we should at least provide a local
policy. Otherwise it would be a real problem to test and debug this.
_____________
Roman Shpount

On Tue, Sep 27, 2011 at 1:30 PM, Matthew Kaufman
<[email-masked]>wrote:

>> directly from the client to a PSTN terminator.
>>
>
> True.
>
>
> existing-PSTN-gateway-**compatible RTP (without SRTP or ICE). If there is
> demand, these gateways will be upgraded to support RTCWeb. If there is not,
> service providers can run intermediate gateways.
>
> Matthew Kaufman
>
>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 27 Sep 2011 20:53:12 +0200

> media gateway as well or should we allow to overwrite this using a policy?

+1

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

---

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Wed, 28 Sep 2011 00:25:11 +0530

Hi Roman,

RTCWeb application within Enterprise looks the reasonable argument for
not mandating ICE & SRTP in RTCWeb browser  because Enterprise shall be
visualized as single reachable private network with no NAT & SRTP
requirement. ICE & SRTP are overhead within Enterprise.

In case I understand you correctly, RTCWeb API should provide the
mechanism to include ICE & SRTP on the need basis.

Thanks

Partha

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Roman Shpount
Sent: Wednesday, September 28, 2011 12:08 AM
To: Matthew Kaufman
Cc: [email-masked]
Subject: Re: [rtcweb] Requiring ICE for RTC calls

What about intranet applications that would want to locally call
existing IP phones within the same enterprise? Should we force them to
go through a media gateway as well or should we allow to overwrite this
using a policy?

As far as SRTP is concerned, once again we should at least provide a
local policy. Otherwise it would be a real problem to test and debug
this.
_____________
Roman Shpount

On Tue, Sep 27, 2011 at 1:30 PM, Matthew Kaufman
<[email-masked]> wrote:

True.

	I can't speak for Skype, but Google Voice uses a media gateway
for the quality-related reasons I mentioned earlier.

	
	Since these large-scale services can deploy media gateways, it's
clear that this is not a significant impediment.

Matthew Kaufman

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 27 Sep 2011 11:59:04 -0700

On Tue, Sep 27, 2011 at 11:55 AM, Ravindran Parthasarathi <
[email-masked]> wrote:

>  Hi Roman,****
>
> ** **
>
> RTCWeb application within Enterprise looks the reasonable argument for not
> mandating ICE & SRTP in RTCWeb browser  because Enterprise shall be
> requirement. ICE & SRTP are overhead within Enterprise.****
>
>
Setting aside the question of whether SRTP is useful within an enterprise,
remember that ICE is being used here for consent verification as well
as NAT traversal. Consent verification is more important, not less,
when the user's machine is in an enterprise environment, because
failure to verify consent can result in firewall traversal by the attacker.

-Ekr

In case I understand you correctly, RTCWeb API should provide the mechanism
> to include ICE & SRTP on the need basis.****
>
> ** **
>
> Thanks****
>
> Partha****
>
> ** **
>
>  ****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On
> Behalf Of *Roman Shpount
> *Sent:* Wednesday, September 28, 2011 12:08 AM
> *To:* Matthew Kaufman
> *Cc:* [email-masked]
>
> *Subject:* Re: [rtcweb] Requiring ICE for RTC calls****
>
>  ** **
>
> What about intranet applications that would want to locally call existing
> IP phones within the same enterprise? Should we force them to go through a
> ****
>  On Tue, Sep 27, 2011 at 1:30 PM, Matthew Kaufman <
> [email-masked]> wrote:****
>
> On 9/27/11 10:01 AM, Justin Uberti wrote:****
>
> directly from the client to a PSTN terminator. ****
>
> ** **
>
> True.****
>
> ** **
>
> quality-related reasons I mentioned earlier.****
>
> ** **
>
> I can't speak for Skype either, but this is a good guess.****
>
> ** **
>
>
> this is not a significant impediment.****
>
> ** **
>
> Matthew Kaufman****
> ** **

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 27 Sep 2011 21:04:39 +0200

The current assumption is that browsers will get Javascript from 
multiple sources, some of which will be malicious. Malicious sources 
cannot be allowed to initiate sessions without ICE, for all the reasons 
given in the "security" I-D.

Before we can even consider relaxing the ICE requirement, we need to see 
a trust model formulated for who gets to decide, for a particular piece 
of Javascript, if it's allowed to operate within a relaxed trust model.

So far, I have seen no such proposals. Can you who argue for this 
solution please go away and write a draft that describes one, instead of 
repeating "+1" without any new solutions?

On 09/27/2011 08:53 PM, Iñaki Baz Castillo wrote:
> 2011/9/27 Roman Shpount<[email-masked]>:

---

From: "Olle E. Johansson" <[email-masked]>
Date: Tue, 27 Sep 2011 22:04:37 +0200

27 sep 2011 kl. 18:08 skrev Roman Shpount:

> What I meant that by supporting SIP/G.711 we get an a existing, cost effective way to access 5 billion wireless subscribers, as well as 500M Skype subscribers, millions of corporate customers. Calling using SIP/G.711 through a SIP trunk provider is not only about wireline PSTN, it is about a much larger universe of people.

Well, when SIP was developed you could have argued that there are millions of users that can only be reached by using ISDN - so why disregard this user base and invent something that did not interop properly?

Sometimes we need to move forward. After many years of insecure calls having issues with traversing NATs everywhere, I think enough is enough and it's time to provide a better solution.

/O

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 27 Sep 2011 22:05:12 +0200

2011/9/27 Harald Alvestrand <[email-masked]>:
> The current assumption is that browsers will get Javascript from multiple
> sources, some of which will be malicious. Malicious sources cannot be
> allowed to initiate sessions without ICE, for all the reasons given in the
> "security" I-D.
>
> Before we can even consider relaxing the ICE requirement, we need to see a
> trust model formulated for who gets to decide, for a particular piece of
> Javascript, if it's allowed to operate within a relaxed trust model.
>
> So far, I have seen no such proposals. Can you who argue for this solution
> please go away and write a draft that describes one, instead of repeating
> "+1" without any new solutions?

Hi Harald. Don't take me wrong, I understand the security requeriments
and I agree with them. But I think that it would be a bit sad that
WebRTC model cannot interoperate with most of the current SIP
deployments.

Anyhow, I also think that this is the price that people involved in
SIP must pay for our laziness implementing security specifications
*already* standarized for SIP and RTP protocols.

The fact is that SIP is mostly deployed in the following scenarios:
- In local networks with an internal SIP PBX and SIP phones.
- In SIP-PSTN SIP providers.
- In operators internal infrastructure and intercommunication with
other operators.

All these scenarios can be considered "trusted" (more or less) as the
user does never talk SIP with an external unknown user. So they are
mostly "wallen gardens".

Of course this is not the case in pure Internet in which most of the
WebRTC deployments will exist, so I agree that security is more
important than compatibility with legacy SIP networks, even more when
those legacy SIP networks have no cared about security.

Anyhow, I still think that local policy (rather than mandating
SRTP+ICE in the spec) could make sense. As I've said in some other
thread, a malicious provider could invite the user (the web visitor)
to make a call to some "number" or "destination" controlled by the
malicious provider. The destination could implement SRTP+ICE so the
communication "seems secure", but nothing prevents the malicious
provider to record the video session and upload it to Youtube. It's
more or less than expecting that HTTPS solves Phishing problem in the
web (it does not).

In the same way, web browsers could come pre-configured with an
enabled checkbox:

  [X] don't allow unsecure calls

The user could disable such checkbox. Anyhow, when a call is being
established and the WebRTC stack realizes that the peer does not
support ICE and/or SRTP, it could warn the user by showing something
like a pop-up ("This call is not secure"), also providing a button
"Don't show again for this site".

I don't know if this could be enough.

Regards.

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

---

From: "Olle E. Johansson" <[email-masked]>
Date: Tue, 27 Sep 2011 22:10:28 +0200

27 sep 2011 kl. 20:55 skrev Ravindran Parthasarathi:

> Hi Roman,
>  
> RTCWeb application within Enterprise looks the reasonable argument for not mandating ICE & SRTP in RTCWeb browser  because Enterprise shall be visualized as single reachable private network with no NAT & SRTP requirement. ICE & SRTP are overhead within Enterprise.
We need to consider the dual stack need for ICE as well. It's not only NAT. And this may happen within the enterprise.

/O
>  
> In case I understand you correctly, RTCWeb API should provide the mechanism to include ICE & SRTP on the need basis.
>  
> Thanks
> Partha
>  
>  
>  
> What about intranet applications that would want to locally call existing IP phones within the same enterprise? Should we force them to go through a media gateway as well or should we allow to overwrite this using a policy?
> 
> As far as SRTP is concerned, once again we should at least provide a local policy. Otherwise it would be a real problem to test and debug this.
> _____________
> Roman Shpount
> 
> 
> On Tue, Sep 27, 2011 at 1:30 PM, Matthew Kaufman <[email-masked]> wrote:
> Neither Google Voice nor Skype (both fairly popular services) send raw RTP directly from the client to a PSTN terminator.
>  
> True.
>  
> 
> I can't speak for Skype, but Google Voice uses a media gateway for the quality-related reasons I mentioned earlier.
>  
> Since these large-scale services can deploy media gateways, it's clear that this is not a significant impediment.
>  
> Agree. I'm not at all sure what the argument is that we need existing-PSTN-gateway-compatible RTP (without SRTP or ICE). If there is demand, these gateways will be upgraded to support RTCWeb. If there is not, service providers can run intermediate gateways.
> 
> Matthew Kaufman
> 
>  

---
* Olle E Johansson - [email-masked]
* Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 27 Sep 2011 22:27:29 +0200

2011/9/27 Olle E. Johansson <[email-masked]>:
> Sometimes we need to move forward. After many years of insecure calls having
> issues with traversing NATs everywhere, I think enough is enough and it's
> time to provide a better solution.

I also agree. The IETF has produced lot of security specifications for
SIP but vendors have implemented nothing (or just a few of them).

SIP is mostly deployed in islands, and each island defines its own
security constrains (usually no security at all as the island itself
is a secure wallen garden). Rtcweb is like a new island (a very big
island), and it will also become the island with major number of
malicious users and site providers. So let's add all the security
constrains we can in order to make it secure.

Legacy SIP vendors/providers/manufactures should react if they want to
offer services on top of rtcweb.

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

---

From: Roman Shpount <[email-masked]>
Date: Tue, 27 Sep 2011 16:52:21 -0400

I would reluctantly have to agree that we should by default require ICE,
since this is the only way to work around the security problems associated
with SIP. I am not sure SRTP has to be required but if ICE is required, SRTP
is an easy requirement to satisfy (if you are putting a media proxy or an
SBC upgrade for one feature, you might as well place it for two). I still
think there should be a way to disable requiring ICE and SRTP through a
local policy, but I am not sure this should be a requirement. I guess what I
am saying that requiring ICE and SRTP should be a SHOULD and not a MUST.
_____________
Roman Shpount

---

From: Tim Panton <[email-masked]>
Date: Tue, 27 Sep 2011 13:56:57 -0700

Sent from my iPhone

> offer services on top of rtcweb.

But it is worth remembering that many of those SIP deployments have the phones on a separate (V)LAN from which the browsers would be firewalled. So it wouldn't be a simple drop in case even if the browser did have a 100% SIP deskphone emulation. 

Tim.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 27 Sep 2011 14:55:58 -0700

> "Don't show again for this site".

Again, the reason for ICE is the threat to other people using the browser as
a vector.
For this reason, allowing the user to disable the security feature is quite
problematic.

-Ekr

---

From: Roman Shpount <[email-masked]>
Date: Tue, 27 Sep 2011 18:13:26 -0400

Eric,

I would suggest we should have an ability to disable ICE/SRTP in browser
settings altogether for debugging purposes and have an ability to add a web
site to browser settings (or assign it to intranet zone), which would enable
this web site to setup calls without ICE/SRTP. This way a developer can
disable these protocols to test things, and user can take an action to say
that it trust a certain web site and allows it to place calls anywhere. I
would think browser settings are outside of the standards document, but we
at least should have requirements for ICE-required and SRTP as SHOULD, not
MUST.
_____________
Roman Shpount

On Tue, Sep 27, 2011 at 5:55 PM, Eric Rescorla <[email-masked]> wrote:

> Again, the reason for ICE is the threat to other people using the browser
> as a vector.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 27 Sep 2011 15:33:08 -0700

> at least should have requirements for ICE-required and SRTP as SHOULD, not

It's really a mistake to conflate ICE and SRTP here. If the user opets not
to use SRTP,
he's primarily hurting himself. If he opts not to use ICE, he's potentially
allowing his
browser to be used as an attack platform. These are not the same thing.

As for what's convenient for developers... I'm a developer, and while it
might be useful
to allow a setting to disable ICE and/or SRTP, that doesn't mean I need to
expose that
setting to the user. I really don't understand the virtue of a user-visible
setting to
disable the ICE requirement.

-Ekr

---

From: Roman Shpount <[email-masked]>
Date: Tue, 27 Sep 2011 18:50:20 -0400

> browser to be used as an attack platform. These are not the same thing.
We are not disabling SRTP and ICE. We stop requiring them for the call and
allow to process offers and answers without ICE or SAVP. Offer generated by
RTC should still include "crypto" attributes and ICE candidates. But offers
and answers without "crypto" and ICE candidates should be processed for an
application distributed by this site. We can separate those two settings but
this is primarily the function of use trusting the site vs. not trusting it.

> disable the ICE requirement.

Same reason we allow to add exception for an invalid SSL certificate. This
will allow us to work with end points that are currently available vs just
other RTC clients.

BTW, mechanism similar to SSL certificate exceptions is probably the best
way to implement this. First time an application from a web site gets an
answer without ICE or SRTP, we can show the dialog box and ask user if this
application should be stopped, allowed for current session or allowed
always.
_____________
Roman Shpount

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 27 Sep 2011 15:54:16 -0700

On Tue, Sep 27, 2011 at 3:50 PM, Roman Shpount <[email-masked]> wrote:

>> he's primarily hurting himself. If he opts not to use ICE, he's
>> potentially allowing his

I'm sorry, but I think you're still missing the point: requiring ICE *is*
the security
feature.

>> setting to the user. I really don't understand the virtue of a
>> user-visible setting to

The problem is that users inevitably click through such dialogs and when
they do their
browsers become an attack platform. That's why this isn't comparable.

-Ekr

---

From: Roman Shpount <[email-masked]>
Date: Tue, 27 Sep 2011 19:20:43 -0400

> I'm sorry, but I think you're still missing the point: requiring ICE *is*
I'm sorry, but it I do get the point: ICE is security. My point is, if you
have a trust relationship with a site, ICE validation can be bypassed, i.e.
if you trust the application on the site you trust it not to do something
malicious with your media.  You point is that you do not trust the user with
the decision to turn off ICE or trust the website, since unlike with all the
other security decisions this can be used to hurt other people vs. just
users themselves. So, unless we can invent a robust mechanism to set trust
agreements with specific web sites, we would be better off forcing ICE for
everybody. Is this correct description of the problem?
_____________
Roman Shpount

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 27 Sep 2011 16:30:13 -0700

> everybody. Is this correct description of the problem?

I don't know what "trust agreements with specific web sites" means.

The basic situation here is that browser vendors do not want to ship
browsers
which can be used as an attack platform. And since the victim is not the
user
but rather the recipient of the traffic, that's why WebSockets and CORS
require that the server (i.e., the recipient of the traffic) confirm its
willingness
to receive the traffic, as opposed to having the user agree to it. I don't
see
how any trust mechanism that doesn't involve the recipient can have the
right security properties.

-Ekr

---

From: Matthew Kaufman <[email-masked]>
Date: Tue, 27 Sep 2011 17:09:55 -0700

On 9/27/2011 3:13 PM, Roman Shpount wrote:
> Eric,
>
> I would suggest we should have an ability to disable ICE/SRTP in 
> browser settings altogether for debugging purposes 

No idea why that would be helpful. If you really want cleartext traffic, 
allow a null SRTP cipher, not plain RTP.

And disabling ICE doesn't help anything.

> and have an ability to add a web site to browser settings (or assign 
> it to intranet zone), which would enable this web site to setup calls 
> without ICE/SRTP. 

Bad idea.

> This way a developer can disable these protocols to test things, and 
> user can take an action to say that it trust a certain web site and 
> allows it to place calls anywhere. 

Yes, and the same way a malicious site can say "if you want to browse 
our free porn collection, you must click 'yes' on the next dialog" and 
then proceed to attack at will. Totally unacceptable.

> I would think browser settings are outside of the standards document, 
> but we at least should have requirements for ICE-required and SRTP as 
> SHOULD, not MUST.

ICE needs to be a MUST. Debate is still going on support (or not) for 
plain RTP.

Matthew Kaufman

---

From: Matthew Kaufman <[email-masked]>
Date: Tue, 27 Sep 2011 17:17:18 -0700

On 9/27/2011 4:20 PM, Roman Shpount wrote:
>
> On Tue, Sep 27, 2011 at 6:54 PM, Eric Rescorla <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     I'm sorry, but I think you're still missing the point: requiring
>     ICE *is* the security
>     feature.
>
>
> I'm sorry, but it I do get the point: ICE is security. My point is, if 
> you have a trust relationship with a site, ICE validation can be 
> bypassed, i.e. if you trust the application on the site you trust it 
> not to do something malicious with your media.  You point is that you 
> do not trust the user with the decision to turn off ICE or trust the 
> website, since unlike with all the other security decisions this can 
> be used to hurt other people vs. just users themselves. So, unless we 
> can invent a robust mechanism to set trust agreements with specific 
> web sites, we would be better off forcing ICE for everybody. Is this 
> correct description of the problem?

No. This is not a correct description of the problem.

ICE isn't about "trusting the site to not do something malicious with 
your media". ICE is about "trusting your browser to not attack other 
devices on your local network or the Internet".

The browser must, without asking the user, be able to prove that the far 
end wishes to receive a stream of media. The standard we have available 
for that is a STUN connectivity check with short-term credentials, using 
a transaction ID that can neither be set from Javascript nor inspected 
from Javascript (to prevent spoofing of the reply). This is basically 
how ICE tests connectivity.

Note that the consent must use the same protocol and port you will be 
sending media on. So for RTP or SRTP over UDP, the consent request must 
be sent and received over that same UDP port.

Matthew Kaufman

---

From: Roman Shpount <[email-masked]>
Date: Tue, 27 Sep 2011 20:39:05 -0400

On Tue, Sep 27, 2011 at 8:17 PM, Matthew Kaufman
<[email-masked]>wrote:

> ICE isn't about "trusting the site to not do something malicious with your
> media". ICE is about "trusting your browser to not attack other devices on
> your local network or the Internet".
>
> end wishes to receive a stream of media. The standard we have available for
> that is a STUN connectivity check with short-term credentials, using a
> transaction ID that can neither be set from Javascript nor inspected from
> Javascript (to prevent spoofing of the reply). This is basically how ICE
> tests connectivity.
>
> sending media on. So for RTP or SRTP over UDP, the consent request must be
> sent and received over that same UDP port.
>
> Matthew Kaufman
>
>
You just repeated the same thing that I said, just a bit more clearly.

I guess we are making a conscientious not to be able to communicate with any
of the existing VoIP infrastructure including IP phones and SIP trunking
providers and expect them to implement ICE support. Until this happens RTC
end points will have to rely on some sort of media proxy to communicate with
existing infrastructure. Is this correct?

Do we have anybody in this list who has real life experience with deploying
large scale ICE based solutions over public internet? I just want to make
sure that we are not putting all of our eggs in the basket that no one ever
used.
_____________
Roman Shpount

---

From: Matthew Kaufman <[email-masked]>
Date: Tue, 27 Sep 2011 18:34:37 -0700

On 9/27/2011 5:39 PM, Roman Shpount wrote:
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     ICE isn't about "trusting the site to not do something malicious
>     with your media". ICE is about "trusting your browser to not
>     attack other devices on your local network or the Internet".
>
>     The browser must, without asking the user, be able to prove that
>     the far end wishes to receive a stream of media. The standard we
>     have available for that is a STUN connectivity check with
>     short-term credentials, using a transaction ID that can neither be
>     set from Javascript nor inspected from Javascript (to prevent
>     spoofing of the reply). This is basically how ICE tests connectivity.
>
>     Note that the consent must use the same protocol and port you will
>     be sending media on. So for RTP or SRTP over UDP, the consent
>     request must be sent and received over that same UDP port.
>
>     Matthew Kaufman
>
>

If you say so.

>
> I guess we are making a conscientious not to be able to communicate 
> with any of the existing VoIP infrastructure including IP phones and 
> SIP trunking providers and expect them to implement ICE support.

Unfortunately that appears to be necessary.

> Until this happens RTC end points will have to rely on some sort of 
> media proxy to communicate with existing infrastructure. Is this correct?

Yes. Of course there's numerous examples of this working well already.

>
> Do we have anybody in this list who has real life experience with 
> deploying large scale ICE based solutions over public internet? I just 
> want to make sure that we are not putting all of our eggs in the 
> basket that no one ever used.

Good question, but I believe Google has a fair bit of ICE experience.

Matthew Kaufman

---

From: Randell Jesup <[email-masked]>
Date: Wed, 28 Sep 2011 00:50:48 -0400

I've been staying out of this one, but one comment:

On 9/27/2011 7:30 PM, Eric Rescorla wrote:
> which can be used as an attack platform. And since the victim is not 
> the user
> require that the server (i.e., the recipient of the traffic) confirm 
> its willingness
> to receive the traffic, as opposed to having the user agree to it. I 
> don't see

Is there any way we could leverage something similar to CORS to allow
destinations to specify they're willing to take traffic in some manner
other than per-connection ICE?

This could be a lot simpler for PBXes, gateways, and the like to
implement than ICE/SRTP/etc.

The general idea would be to try ICE, and if the other side doesn't
do ICE, check a CORS-equivalent at the same same address on a port
(the port could be specified in DNS SRV records perhaps, or even an
alternate address to use to check).  If it says it's willing to
accept webrtc traffic without verification, great.  (This could be
additionally secured by requiring the server to mark the app/service
as known to be acceptable in the CORS data.)

-- 
Randell Jesup
[email-masked]

---

From: Igor Faynberg <[email-masked]>
Date: Wed, 28 Sep 2011 02:37:35 -0400

+1!

Igor

On 9/27/2011 5:55 PM, Eric Rescorla wrote:
>
>
> On Tue, Sep 27, 2011 at 1:05 PM, Iñaki Baz Castillo <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
> Again, the reason for ICE is the threat to other people using the 
> browser as a vector.
> For this reason, allowing the user to disable the security feature is 
> quite problematic.
>
> -Ekr
>
>

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 28 Sep 2011 09:04:57 +0200

> basket that no one ever used.
Yes.

Google Talk Video, Google Voice and Google+ Hangouts all use ICE.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 28 Sep 2011 10:36:14 +0200

2011/9/28 Matthew Kaufman <[email-masked]>:
> ICE needs to be a MUST. Debate is still going on support (or not) for plain
> RTP.

After all these threads, now I strongly consider that ICE should be a MUST.

But I don't think the same for SRTP. I don't consider that content
carried via plain RTP is more important than content carried via HTTP,
and AFAIK HTTPS is not a requirement in RFC 2616, neither in any web
browser.

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

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 28 Sep 2011 08:41:23 -0600

> I'm not going to use this mailing list as an advertising medium, but there do exist products that support both ICE and SRTP, and some of the companies you name below have deployed those products to…

I'd just like to +1 Bernard on this - a bunch of the stuff that I read on this list just not seem to match what I see shipping. Sure lots of stuff does not support ICE, or does not support SRTP, but vendors build what the market needs and where there is a need for these, vendors are building them.

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 28 Sep 2011 08:42:09 -0600

On Sep 26, 2011, at 11:36 PM, Justin Uberti wrote:

> Yes, most PSTN providers don't support ICE. They also often don't support SRTP, RTCP, RTP over TCP, or even jitter buffers.

uh, that's probably not right for most of the vendors but not sure it changes your point ....

> To run a robust telephony service, you will need to frontend that traffic with a media gateway of some sort, and that gateway can easily support ICE.

Many service providers front end their services with an SBC for a wide variety of reasons - and that is the place they would likely run ICE Lite (note it's not even full ICE they need).

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 28 Sep 2011 08:43:18 -0600

> make a call to an E.164 number?  Probably.  Support for every potential corner

I wish I could agree but I think we have a long, long, way to go here. I will point out that the only way Microsoft can phone Cisco is over the PSTN and that is two of the most pro VoIP companies in the world. Thought I agree with rate of land lines is dropping in some countries, the rate of  what VoIP reaches via the PSTN, which is land lines + mobile phones, is growing in every country I have stats for. Now of course, I'd love to see the PSTN replaced with something better but I think it is highly unrealistic to think that is going to happen in less than 10 years.

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 28 Sep 2011 09:02:58 -0600

On Sep 27, 2011, at 10:50 PM, Randell Jesup wrote:

>> The basic situation here is that browser vendors do not want to ship browsers
>> which can be used as an attack platform. And since the victim is not the user
>> require that the server (i.e., the recipient of the traffic) confirm its willingness
>> to receive the traffic, as opposed to having the user agree to it. I don't see

Randell, I have thought about this awhile back and what I come up with is something that has very close to the same messages as ICE. In addition, this new thing would have to be deployed on all the end points - so it would be even hard to get deployed than ICE and I doubt it would end up being any easier - and that just to solve the security problem. You still have to solve the nat  traversal problem and things like transition to v6. So, I'd be happy to talk about ideas on this, but when I drew the "boxes and arrows" diagram for something like CORS for RTP, it did not come out looking any easier than ICE, and in fact it looked awfully close to the "boxes and arrows" for ICE. Give it a try on a napkin and see if you come to the roughly the same conclusion.

---

From: Cameron Byrne <[email-masked]>
Date: Wed, 28 Sep 2011 08:10:19 -0700

> > ICE needs to be a MUST. Debate is still going on support (or not) for
plain
> and AFAIK HTTPS is not a requirement in RFC 2616, neither in any web

Everytime we design a new voip product or concept, I am always told by the
product management people that users expect security with voice calls on the
internet or any public access network. Examples include gsm, umts, gan, uma,
skype and the various sip implementations for IMS over the internet...
granted, not all public sip services are secure.

The end result is that users may not require it upfront, but they will be
shocked and angry when some blog post shows how anyone on a public WLAN can
effortlessly wiretap their calls, and possibly intercept personal credit
card and medical information that is commonly shared on a voice call.

In this day and age, I think it has been proven, to me at least, that end to
end encryption is always required and we would be simply negligent to not
require encyption of the media and signalling.

Cb

---

From: Roman Shpount <[email-masked]>
Date: Wed, 28 Sep 2011 12:01:48 -0400

On Wed, Sep 28, 2011 at 10:42 AM, Cullen Jennings <[email-masked]> wrote:

> Many service providers front end their services with an SBC for a wide
> variety of reasons - and that is the place they would likely run ICE Lite
> (note it's not even full ICE they need).
>

I understand that this can be considered advertisement on the forum, but
does ACME, Sonus and Genband SBC support ICE or ICE lite? As far as I know
they do not. If I am wrong and they do, how long did they have this support?
If they do not, does anybody know what their plans are?

Sorry for such direct line of questioning, but dealing with SIP trunk
providers in US, you interface to an SBC from one of those vendors. So, if
these vendors support ICE, most of the SIP trunk providers would be able to
support ICE.

Even with this covered, we still have an issue of supporting ICE by PBXs and
IP Phones. As far as I know (and my information can be outdated), Polycom
and Cisco phones do not support ICE. I am not sure about the others, but
from what I've generally seen hardware phones in vast majority do not
support ICE.

Please correct me if I am wrong about any of this. I am mostly trying to
determine the level of current market support for ICE.
_____________
Roman Shpount

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 28 Sep 2011 18:18:31 +0200

> Many service providers front end their services with an SBC for a wide variety of reasons - and that is the place they would likely run ICE Lite (note it's not even full ICE they need).

Just to add information about ICE Lite:

http://tools.ietf.org/html/draft-rescorla-mmusic-ice-lite-00

--------------
   During the design of ICE, many implementors expressed concern about
   the complexity of the protocol and the difficulty of implementing it.
   This draft specifies a compatible simplified subset of ICE called
   "ICE Lite" which is suitable for implementations which will always be
   operated with public IP addresses.  One particular environment where
   ICE Lite is intended to be useful is in SIP-PSTN gateways which are
   generally directly connected to the Internet.
--------------

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

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 28 Sep 2011 18:21:55 +0200

> http://tools.ietf.org/html/draft-rescorla-mmusic-ice-lite-00

However such draft is expired. Shouldn't it be considered nowadays in
which, finally, we see the *real* requirements of ICE?

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

---

From: Roman Shpount <[email-masked]>
Date: Wed, 28 Sep 2011 12:26:55 -0400

Inaki,

ICE Lite is defined in RFC 5245 were procedures for lite implementation are
defined side-by-side with regular one.
_____________
Roman Shpount

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 28 Sep 2011 09:27:08 -0700

All the relevant material here was supposed to be merged into 5245. Some of
it
is in fact there though I can't vouch for all of it.

-Ekr

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 28 Sep 2011 18:31:36 +0200

On 09/28/11 18:21, Iñaki Baz Castillo wrote:
> 2011/9/28 Iñaki Baz Castillo<[email-masked]>:
Browsers have to implement full ICE.

ICE-Lite is described in RFC 5245 - section 2.7, 4.2, 7.2.2 may be 
particularly relevant. There's an introduction to the subject in 
appendix A of the RFC.

Seriously, if you want to discuss ICE, it helps to read the RFC.

                  Harald

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 28 Sep 2011 18:32:53 +0200

> defined side-by-side with regular one.

Thanks for the explanation.

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

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 28 Sep 2011 11:04:13 -0600

On Sep 28, 2011, at 10:01 AM, Roman Shpount wrote:

> I understand that this can be considered advertisement on the forum, but does ACME, Sonus and Genband SBC support ICE or ICE lite? As far as I know they do not. If I am wrong and they do, how long did they have this support? If they do not, does anybody know what their plans are?

I'll note some vendors have both SBC and endpoints that do ICE but clearly not all of them - only the ones where there was a market for it. My experience with ACME and Sonus has been they will provide what the market needs. Today the "SIP Trunking" is used in situation where no ICE is needed and keep in mind most the SBC vendors have other solutions for the pure NAT traversal part of the problem that predate ICE. 

When a single large voice provider asked it's sip trunking providers to add iLBC, they asked the gateway providers to add it. Pretty much every major gateway vendor added it - for a single voice service provider - and that was probably harder than adding ICE. Vendors don't build something because the IETF made an RFC - they build it because it meets a customer need. If we could solve this problem without ICE, or something about the same, clearly we would, but if we can't, vendors will build the minimum they need to meet market needs. The fact they will build the minimum is why VoIP, and the internet, just barely works. There no point in doing more than that.

> 
> Sorry for such direct line of questioning, but dealing with SIP trunk providers in US, you interface to an SBC from one of those vendors. So, if these vendors support ICE, most of the SIP trunk providers would be able to support ICE.
> 
> Even with this covered, we still have an issue of supporting ICE by PBXs and IP Phones. As far as I know (and my information can be outdated), Polycom and Cisco phones do not support ICE. I am not sure about the others, but from what I've generally seen hardware phones in vast majority do not support ICE.

I agree with you point that the majority of deployed phones don't support ICE. But so what, what do you propose to do. One thing that is not going to happen is browser vendors do something which makes browsers such a security threat that the browsers are banned from every corporate network. Solutions like CORS solve the problem but short of something like that, I don't see browser vendors deciding that remove same origin policy is a good idea. 

> 
> Please correct me if I am wrong about any of this. I am mostly trying to determine the level of current market support for ICE.
> _____________
> Roman Shpount
>

---

From: "Olle E. Johansson" <[email-masked]>
Date: Wed, 28 Sep 2011 21:02:54 +0200

28 sep 2011 kl. 01:20 skrev Roman Shpount:

> My point is, if you have a trust relationship with a site, ICE validation can be bypassed, i.e. if you trust the application on the site you trust it not to do something malicious with your media.  

These kind of statements may work for "you", which is us on this list, but I do not like having to force users to have to evaluate trust in regards to website. They will fail and the app will do bad things.

I agree with Eric, I don't see a point with disabling ICE ever. It is needed both for NAT, for IPv6/IPv4 and for consent of the media streams. There are very many situations within a trusted network where at least one of these functions are needed. And users can not determine when.

/O

---

From: "Olle E. Johansson" <[email-masked]>
Date: Wed, 28 Sep 2011 21:10:12 +0200

> and AFAIK HTTPS is not a requirement in RFC 2616, neither in any web

If you look into your web browser, you will see that more and more sites are moving to only HTTPS. There's a reason for that. Facebook, Twitter and many others. Large sites that are not "banks", but social media or just information sites  like www.iis.se.

When HTTP was written there wasn't CPU enough to handle mandatory SSL. Now we have CPU power to handle it and encryption accelerators are much cheaper. The world is different and comparing  the situation we have now with what was reality when RFC 2616 was written is a bad comparision that I would not consider valid.

(Iñaki: I see that we have fun some discussions ahead of us at Voip2day.net in Madrid next week :-) )
/O

---

From: Roman Shpount <[email-masked]>
Date: Wed, 28 Sep 2011 15:27:45 -0400

On Wed, Sep 28, 2011 at 3:10 PM, Olle E. Johansson <[email-masked]> wrote:

> If you look into your web browser, you will see that more and more sites
> are moving to only HTTPS. There's a reason for that. Facebook, Twitter and
> many others. Large sites that are not "banks", but social media or just
> information sites  like www.iis.se.
>
> When HTTP was written there wasn't CPU enough to handle mandatory SSL. Now
> we have CPU power to handle it and encryption accelerators are much cheaper.
> The world is different and comparing  the situation we have now with what
> was reality when RFC 2616 was written is a bad comparision that I would not
> consider valid.
>
>
This is not about CPU power -- the CPU impact of SRTP is a lot smaller then
the CPU impact of a lower bitrate codec. The problem with SRTP is that
debugging becomes much harder and vast majority of the current VoIP
monitoring tools will stop working. You can no longer use a simple packet
capture to create call logs and quality metrics for the voip call. You
cannot even do it for a particular client that is experiencing problem. AFAK
service provider can turn off encryption on GSM calls for troubleshooting
purposes. I think RTC should be able to do the same. Doing interop, if all
you have is SRTP, would become much harder, even if this is an interop
between two web browsers.
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Wed, 28 Sep 2011 15:44:16 -0400

On Wed, Sep 28, 2011 at 1:04 PM, Cullen Jennings <[email-masked]> wrote:

> I agree with you point that the majority of deployed phones don't support
> ICE. But so what, what do you propose to do. One thing that is not going to
> happen is browser vendors do something which makes browsers such a security
> threat that the browsers are banned from every corporate network. Solutions
> like CORS solve the problem but short of something like that, I don't see
> browser vendors deciding that remove same origin policy is a good idea.
>
>
As I wrote before, you can use RTC not only in the desktop browser but also
in the desktop phone. It is not unreasonable to use the same CPU platform
being used in mobile phones and build a desk IP phone which primarily runs
the web browser to control its screen and uses RTC to setup voice/video
calls. This phone can be a much better and more extendable standard platform
for building UC solutions then most of the current SIP phones. The problem
is if standard requires ICE/SRTP this phone will not be able to work with
most of the current enterprise phones. Once again, since this can be
considered a marginal use case, we don't need to cover it in the standard
and the phone vendor can just ignore that ICE requirement since it knows
that the phone is located in the fully controlled network.
_____________
Roman Shpount

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 28 Sep 2011 13:49:00 -0600

On Sep 28, 2011, at 1:44 PM, Roman Shpount wrote:

> As I wrote before, you can use RTC not only in the desktop browser but also in the desktop phone. It is not unreasonable to use the same CPU platform being used in mobile phones and build a desk IP phone which primarily runs the web browser to control its screen and uses RTC to setup voice/video calls. This phone can be a much better and more extendable standard platform for building UC solutions then most of the current SIP phones. The problem is if standard requires ICE/SRTP this phone will not be able to work with most of the current enterprise phones. Once again, since this can be considered a marginal use case, we don't need to cover it in the standard and the phone vendor can just ignore that ICE requirement since it knows that the phone is located in the fully controlled network.
> _____________
> Roman Shpount
> 

Sure, in that sort of case, I'm sure lots of the code being open sourced for RTCweb will will be reused to build phones and modified in ways like you suggest - but as you say, that's outside the scope of what we want to solve here.

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 29 Sep 2011 21:59:58 +0000

ICE-Lite is easier for gateway-type devices, but it's still got to do the SHA-1 calc per STUN connectivity-check response packet, which is painful from a performance/scale perspective (and thus cost).

That's one of the things we've been arguing about in MMUSIC as being a problem for IPv4/v6 since ICE is the only "official" way to handle a dual-stack offer/answer... and the extra cost incurred for doing ICE is hard to justify since IPv6 transition is an expense with no added "feature".  But no one seems to care about that there, so we've been forced to go outside the IETF. :(

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 29 Sep 2011 22:19:44 +0000

If you built a "phone" which used an RTCWeb model, you would simply ignore the requirement to mandate ICE.  And that's ok.  First, there's no protocol police - nothing forces even Web Browsers to follow these rules, they just will because they're concerned about their Browser's reputations.  And second, presumably your phone wouldn't accept Javascript blindly from any random website, but rather only from something trustworthy and verifiable by the phone… something which couldn't/wouldn't easily be subverted nor unintentionally allowed by the users using the phone.

-hadriel

On Sep 28, 2011, at 3:44 PM, Roman Shpount wrote:

On Wed, Sep 28, 2011 at 1:04 PM, Cullen Jennings <[email-masked]<mailto:[email-masked]>> wrote:
I agree with you point that the majority of deployed phones don't support ICE. But so what, what do you propose to do. One thing that is not going to happen is browser vendors do something which makes browsers such a security threat that the browsers are banned from every corporate network. Solutions like CORS solve the problem but short of something like that, I don't see browser vendors deciding that remove same origin policy is a good idea.

---

From: Matthew Kaufman <[email-masked]>
Date: Thu, 29 Sep 2011 15:25:47 -0700

> ICE-Lite is easier for gateway-type devices, but it's still got to do the SHA-1 calc per STUN connectivity-check response packet, which is painful from a performance/scale perspective (and thus cos…

Ridiculous. We're not talking something like one SHA-1 HMAC per packet 
received... this is one SHA-1 per connectivity test. That's one or two 
packets *per call*. No way that increases the cost/complexity of any 
possible device that might be terminating or transcoding media.

Matthew Kaufman

---

From: "Richard Shockey" <[email-masked]>
Date: Thu, 29 Sep 2011 19:21:39 -0400

> make a call to an E.164 number?  Probably.  Support for every potential
corner

I wish I could agree but I think we have a long, long, way to go here. I
will point out that the only way Microsoft can phone Cisco is over the PSTN
and that is two of the most pro VoIP companies in the world. Thought I agree
with rate of land lines is dropping in some countries, the rate of  what
VoIP reaches via the PSTN, which is land lines + mobile phones, is growing
in every country I have stats for. Now of course, I'd love to see the PSTN
replaced with something better but I think it is highly unrealistic to think
that is going to happen in less than 10 years. 

RS> And at the rate this discussion is going it is reasonable to assume that
it might be 10 years before RTCWEB might be able to reach consensus. But for
what it's worth the end of POTS/PSTN is under active discussion. If for no
other reason than the  backplanes of the 5E's and DMS 500's are literally
cracking at a increasing pace. Remember 3G mobile networks still use TDM
Switches. Bernard's point is well taken RTCWEB shouldn't worry about
interconnection some gateway or border element will normalize that problem
in some way shape or form.

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 30 Sep 2011 00:18:10 +0000

On Sep 29, 2011, at 6:25 PM, Matthew Kaufman wrote:

> Ridiculous. We're not talking something like one SHA-1 HMAC per packet received... this is one SHA-1 per connectivity test. That's one or two packets *per call*. No way that increases the cost/complexity of any possible device that might be terminating or transcoding media.

Not as far as I know; the SHA-1 hash is calculated on every single STUN request and response packet, because it covers the STUN header which includes the transaction-id, which is unique per request; and the request has different content than the response.  So per ICE-pair connectivity check, it could be two STUN requests and two responses (for the "normal" mode).  And since I'm assuming v4/v6 dual-stack, that's potentially double that number. 

And yes while 8 SHA-1's per call isn't a lot compared to transcoding or terminating media, I wasn't talking about this being done in the PSTN TDM-facing gateways themselves, but rather in the "media-plane gateway" interworking RTCWeb with the legacy SIP world. (ie, SBCs)  At least I assumed that's what people here meant by "media gateways" - it's not like real PSTN-TDM gateways are eager to do ICE... nor are MTAs, voicemail servers, announcement servers, conference servers, IVRs, etc.

And note that I was responding to the emails which made it sound like "all" the SBC has to do is ICE-Lite, and since it has the word "Lite" in it it must therefor be easy/free.  And my point was it's fewer calories, not zero calories. :)

-hadriel
p.s. I should note the arguments in MMUSIC are about this burden for SBCs and v4/v6 transition - not for plain IPv4 and PSTN gateways... not many people expect real PSTN gateways to be involved with ICE, afaict.

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 30 Sep 2011 00:40:17 +0000

> in some way shape or form. 

But it's not "POTS" that's really the point - it's the "PSTN".  From the perspective of this group, the "PSTN" is everything reachable through SIP service providers: every cell/mobile phone, DSL/Cablemodem MTA, PRI trunk, SIP Enterprise trunk, POTS landline, etc.  There are more of those right now than there are devices on the Internet.[1]  And way more of those than number of users and Web Browsers on the Internet.[2]

-hadriel

[1] Based on several sources which claim approx 5 Billion mobile phones, 1.2 Billion POTS lines, and hundreds of millions of MTAs, and untold number of PRI and SIP trunks; which I'm guesstimating totals about 7 Billion.  Compared to approx 5 Billion current devices on the Internet, according to www.imsresearch.com. (though they include things like printers and cameras in their counts)

[2] Based on ~2 Billion users, from www.internetworldstats.com and data.worldbank.org.

---

From: "Richard Shockey" <[email-masked]>
Date: Thu, 29 Sep 2011 21:23:04 -0400

> in some way shape or form. 

But it's not "POTS" that's really the point - it's the "PSTN".  From the
perspective of this group, the "PSTN" is everything reachable through SIP
service providers: every cell/mobile phone, DSL/Cablemodem MTA, PRI trunk,
SIP Enterprise trunk, POTS landline, etc.  There are more of those right now
than there are devices on the Internet.[1]  And way more of those than
number of users and Web Browsers on the Internet.[2]

Ok but that is a distinction that is causing lots of problems in identifying
the real issue. The PSTN as you put it, is essentially a national and
internationally regulated business model of mandated interconnection for
realtime communications that uses E.164 addressing. It's a policy construct.
It's a set of national specific rules, regulations, emergency services and
cost recovery models. 

POTS, as I would prefer it to be defined, is the technical underpinning of
everything in the PSTN reachable through SIP service providers etc and
that's what we are ultimately talking about.   And yes you are right there
are more POTS end points out there than devices on the Internet, until we
get rid of POTS and fold them into the "greater good" of IP and that process
is progressing very well as far as I can tell. 

Confusing the two is going to cause everyone a lot of grief. 

-hadriel

[1] Based on several sources which claim approx 5 Billion mobile phones, 1.2
Billion POTS lines, and hundreds of millions of MTAs, and untold number of
PRI and SIP trunks; which I'm guesstimating totals about 7 Billion.
Compared to approx 5 Billion current devices on the Internet, according to
www.imsresearch.com. (though they include things like printers and cameras
in their counts)

[2] Based on ~2 Billion users, from www.internetworldstats.com and
data.worldbank.org.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 29 Sep 2011 19:37:40 -0700

On Thu, Sep 29, 2011 at 5:18 PM, Hadriel Kaplan <[email-masked]>wrote:

> Not as far as I know; the SHA-1 hash is calculated on every single STUN
> request and response packet, because it covers the STUN header which
> includes the transaction-id, which is unique per request; and the request
> has different content than the response.  So per ICE-pair connectivity
> check, it could be two STUN requests and two responses (for the "normal"
> mode).  And since I'm assuming v4/v6 dual-stack, that's potentially double
> that number.
>
> And yes while 8 SHA-1's per call isn't a lot compared to transcoding or
> terminating media, I wasn't talking about this being done in the PSTN
> TDM-facing gateways themselves, but rather in the "media-plane gateway"
> interworking RTCWeb with the legacy SIP world. (ie, SBCs)  At least I
> assumed that's what people here meant by "media gateways" - it's not like
> real PSTN-TDM gateways are eager to do ICE... nor are MTAs, voicemail
> servers, announcement servers, conference servers, IVRs, etc.
>

Absent some measurements, I tend to agree with Matthew here.
My Macbook Air can do roughly 3x10^3 SHA-1 operations per
second on a single core. In order for this to be 10% of your load,
you would need to be processing on the order of
75K STUN requests/sec/core. How many total calls/second
can you do/core w/o STUN?

-Ekr

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 30 Sep 2011 04:37:23 +0000

> can you do/core w/o STUN?

That's not the problem - the problem is "media" isn't handled in CPUs on many SBCs to begin with.  There're basically two types of SBC architectures in common use: software-based and hardware-based.  The software-based ones don't scale well in terms of concurrent call media capacity (for obvious reasons), so aren't usually used by service providers.  The hardware-based ones do media processing in dedicated hardware (ASICs, NPs, whatever).  To date, most hardware-based SBCs that I've seen couldn't possibly do SHA-1 for STUN messages in their base hardware without either additional hardware components (which costs more money), or they have to send the STUN messages back/forth to their signaling processors on an exception path, which means the overhead isn't just the SHA-1 alone.  So to be fair I shouldn't call it so much the overhead of SHA-1, as the overhead inflicted by going beyond what things like NPs can easily do by themselves (which is the SHA-1 piece).

And this is in the context of the IPv4/v6 debate in MMUSIC, where any additional cost burden for service providers to bear to deploy IPv6 is a sunk cost with no additional revenue and thus very hard to support.  The RTCWeb model is a new "service" in some ways, so the market may bear a different cost burden for it.  

And I haven't been arguing against ICE for RTCWeb - I was a few weeks ago when I was hoping we could get away without it, but I don't see a safe way without it - I was only arguing in this thread against the notion of ICE-Lite being easy/free.

The bigger problem is RTCP for G.711: since many SIP devices don't do RTCP, and there's no way to know if they do/don't from SIP signaling, having to have the SBC's create "fake" RTCP every 5 seconds for every call is a real ball-buster.

-hadriel
p.s. note, the above is based on what I know of 5 different SBC vendors' equipment - there are plenty more than that many SBC vendors in the World, but my assumption is they're not too dissimilar.
p.p.s. some SBCs are "decomposed", meaning separate physical systems doing SIP signaling vs. media processing, and they're usually called things like "BGF" or "AGW" or whatever, but it's logically the same concepts.

---

From: "Martin J. Dürst" <[email-masked]>
Date: Fri, 30 Sep 2011 14:15:24 +0900

On 2011/09/30 9:40, Hadriel Kaplan wrote:

> But it's not "POTS" that's really the point - it's the "PSTN".  From the perspective of this group, the "PSTN" is everything reachable through SIP service providers: every cell/mobile phone, DSL/Cablemodem MTA, PRI trunk, SIP Enterprise trunk, POTS landline, etc.

> And way more of those than number of users and Web Browsers on the Internet.[2]

Just for the record:

This seems to be based on the assumption that a) mobile phones don't 
have browsers (many of them do) and b) that each user has only one 
browser (many of them have installed (and use) more than one; many 
people don't even realize they have installed (and use) more than one 
because browsers and their components are used behind the scenes in all 
kinds of shapes and forms.

Regards,    Martin.

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 30 Sep 2011 07:19:26 +0200

On 09/30/2011 06:37 AM, Hadriel Kaplan wrote:
> That's not the problem - the problem is "media" isn't handled in CPUs on many SBCs to begin with.  There're basically two types of SBC architectures in common use: software-based and hardware-based.  The software-based ones don't scale well in terms of concurrent call media capacity (for obvious reasons), so aren't usually used by service providers.  The hardware-based ones do media processing in dedicated hardware (ASICs, NPs, whatever).  To date, most hardware-based SBCs that I've seen couldn't possibly do SHA-1 for STUN messages in their base hardware without either additional hardware components (which costs more money), or they have to send the STUN messages back/forth to their signaling processors on an exception path, which means the overhead isn't just the SHA-1 alone.
Still, it's on the order of a few packets per call, and most hardware 
devices have a software processor for "exceptional processing" these 
days. What number of simultaneous calls per box are you envisioning?
>    So to be fair I shouldn't call it so much the overhead of SHA-1, as the overhead inflicted by going beyond what things like NPs can easily do by themselves (which is the SHA-1 piece).
>
Time to change the subject line, then?
> The bigger problem is RTCP for G.711: since many SIP devices don't do RTCP, and there's no way to know if they do/don't from SIP signaling, having to have the SBC's create "fake" RTCP every 5 secon…
Let's use a different subject line for that one, too.

---

From: "Olle E. Johansson" <[email-masked]>
Date: Fri, 30 Sep 2011 08:36:17 +0200

30 sep 2011 kl. 06:37 skrev Hadriel Kaplan:

> To date, most hardware-based SBCs that I've seen couldn't possibly do SHA-1 for STUN messages in their base hardware without either additional hardware components (which costs more money), or they have to send the STUN messages back/forth to their signaling processors on an exception path, which means the overhead isn't just the SHA-1 alone.  So to be fair I shouldn't call it so much the overhead of SHA-1, as the overhead inflicted by going beyond what things like NPs can easily do by themselves (which is the SHA-1 piece).

Hadriel,
While on the topic of the hardware, I would like to ask how these systems handle DTLS and SRTP.

/O

---

From: Tim Panton <[email-masked]>
Date: Fri, 30 Sep 2011 14:30:11 +0100

On 30 Sep 2011, at 06:15, Martin J. Dürst wrote:

> This seems to be based on the assumption that a) mobile phones don't have browsers (many of them do) and b) that each user has only one browser (many of them have installed (and use) more than one; many people don't even realize they have installed (and use) more than one because browsers and their components are used behind the scenes in all kinds of shapes and forms.

c) it defines the problem space in terms of SIP reachability - then un-surprisingly concludes that we need to reach
devices via SIP.  

Most of those users are directly reachable via the GSM Um radio interface - but I don't see  any need to add Um constructs to rtcweb. Or looked at different way - the stated group perspective is wrong IMHO .

Tim (speaking for no-one but himself).

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 30 Sep 2011 16:39:51 +0000

On Sep 30, 2011, at 2:36 AM, Olle E. Johansson wrote:

Hadriel,

Assuming you mean terminating the SRTP, I only know of one hardware-based SBC that claims support for terminating DTLS-SRTP, but I don't know if it's real or slideware.  I know of a couple software-based ones that do. (you can probably google it to find out who)

But in general the most popular support by far is for SDES-based keying.  There are a couple of off-the-shelf chip solutions for large-scale SRTP that handle it as a bump-in-the wire, but they need to be told the keys per stream and don't handle DTLS inline themselves to do so, so naturally SDES made it a lot easier to use them.  Having said that, I do believe that more SBC vendors in the US market will be supporting DTLS-SRTP in the future because the US government has it mandated in some agency or other I've been told.  Whether other governments will do the same I don't know. (then again the US government mandates a lot that never gets used in practice)

Also, someone asked on this list if SBC vendors support SRTP to begin with.  Almost every SBC vendor I know of does support SRTP (at least with SDES keying), but it usually costs more to do so, because it's done in dedicated hardware.  So most deployed SBC systems don't do SRTP, because the people buying/deploying them have decided they don't need it and don't want to pay for it.  It's more popular in specific vertical markets, but overall it's definitely a minority today.

-hadriel

---

From: Cameron Byrne <[email-masked]>
Date: Fri, 30 Sep 2011 09:50:52 -0700

On Fri, Sep 30, 2011 at 9:39 AM, Hadriel Kaplan <[email-masked]> wrote:
> Assuming you mean terminating the SRTP, I only know of one hardware-based
> SBC that claims support for terminating DTLS-SRTP, but I don't know if it's
> real or slideware.  I know of a couple software-based ones that do. (you can
> probably google it to find out who)
> But in general the most popular support by far is for SDES-based keying.
>  There are a couple of off-the-shelf chip solutions for large-scale SRTP
> that handle it as a bump-in-the wire, but they need to be told the keys per
> stream and don't handle DTLS inline themselves to do so, so naturally SDES
> made it a lot easier to use them.  Having said that, I do believe that more
> SBC vendors in the US market will be supporting DTLS-SRTP in the future
> because the US government has it mandated in some agency or other I've been
> told.  Whether other governments will do the same I don't know. (then again
> the US government mandates a lot that never gets used in practice)
> Also, someone asked on this list if SBC vendors support SRTP to begin with.
>  Almost every SBC vendor I know of does support SRTP (at least with SDES
> keying), but it usually costs more to do so, because it's done in dedicated
> hardware.  So most deployed SBC systems don't do SRTP, because the people
> buying/deploying them have decided they don't need it and don't want to pay
> for it.  It's more popular in specific vertical markets, but overall it's
> definitely a minority today.
> -hadriel
>

As a service provider, i cannot imagine rolling out a solution that
lacks encryption.  Cost of bad press and unmet user expectations is
higher than a few extra boxes. If you choose not to encrypt, well...
that becomes a differentiation for those that do.

We have already bought and paid for SRTP in our existing IMS/SIP
applications that exist on the Internet and will mandate it for
anything we do with RTCWeb too, it's policy.

Cameron

---

From: "Olle E. Johansson" <[email-masked]>
Date: Fri, 30 Sep 2011 20:57:03 +0200

> Also, someone asked on this list if SBC vendors support SRTP to begin with.  Almost every SBC vendor I know of does support SRTP (at least with SDES keying), but it usually costs more to do so, bec…

I heard from another hardware vendor about the issues with DTLS and hardware chips. Thanks for confirming that. 

/O

---

From: "Olle E. Johansson" <[email-masked]>
Date: Fri, 30 Sep 2011 21:10:40 +0200

> anything we do with RTCWeb too, it's policy.

Thank you for that comment. It confirms a lot of our previous discussion.

- we need SRTP by default
- service provides will get the equipment needed to provide the new services

/O

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 30 Sep 2011 12:11:00 -0700

> probably google it to find out who)

I don't know a huge amount about how hardware-based SBCs are constructed,
but it's important
to remember that DTLS-SRTP is DTLS key management but SRTP data transport,
so the naive
way to build the system would be to do the DTLS in software and then push
the keys onto
SRTP, thus using all the normal SRTP packet processing.

Obviously, there will be some performance cost associated with this (as
there is for any
asymmetric key exchange). The typical acceleration strategy for TLS is to
have hardware
acceleration for the asymmetric operations but have the actual TLS stack in
software,
for the obvious reasons of flexibility and upgradeability. Don't know how
much that
helps.

-Ekr

>  Also, someone asked on this list if SBC vendors support SRTP to begin
> with.  Almost every SBC vendor I know of does support SRTP (at least with
> SDES keying), but it usually costs more to do so, because it's done in
> dedicated hardware.  So most deployed SBC systems don't do SRTP, because the
> people buying/deploying them have decided they don't need it and don't want
> to pay for it.  It's more popular in specific vertical markets, but overall
> it's definitely a minority today.
>
>  -hadriel
>
>
>

---

From: Dzonatas Sol <[email-masked]>
Date: Fri, 30 Sep 2011 12:35:02 -0700

On 09/30/2011 09:50 AM, Cameron Byrne wrote:
> On Fri, Sep 30, 2011 at 9:39 AM, Hadriel Kaplan<[email-masked]>  wrote:
>    
>> real or slideware. �I know of a couple software-based ones that do. (you can
>> �There are a couple of off-the-shelf chip solutions for large-scale SRTP
>> made it a lot easier to use them. �Having said that, I do believe that more
>> told. �Whether other governments will do the same I don't know. (then again
>> �Almost every SBC vendor I know of does support SRTP (at least with SDES
>> hardware. �So most deployed SBC systems don't do SRTP, because the people
>> for it. �It's more popular in specific vertical markets, but overall it's
> lacks encryption.

Perhaps node.js would be easier for browsers such that the browser's JS 
API can forward-to node.js where available. I'd imagine despite the 
choice of browser flavor that something like "use local node.js for 
encryption" in each may be ideal over direct to cloud/SBC. That may be 
easier for this WG for select innovation.

Either that, or let browsers run API regression against JS-UNIX (i.e. 
jslinux) with RTP and with hardcoded SHA validators in /dev. This may be 
more ideal for B2B portability and manufacturer automation, yet it may 
seem anti-game despite being more federal-ready.

I can imagine the JS API that includes encryption with real-time 
constraints. I have no interest in JS other than it helps convey that idea.

>   Cost of bad press and unmet user expectations is

-- 

---