Subject: Re: [rtcweb] SBC hardware and SHA1

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Mon, 3 Oct 2011 11:43:41 +0530

It is possible in SBC Hardware to provide DTLS-SRTP in case customer
asks for it. IMO, The performance impacts is based on individual SBC
Hardware architecture. 

Thanks

Partha

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Eric Rescorla
Sent: Saturday, October 01, 2011 12:41 AM
To: Hadriel Kaplan
Cc: <[email-masked]>
Subject: Re: [rtcweb] SBC hardware and SHA1

On Fri, Sep 30, 2011 at 9:39 AM, Hadriel Kaplan <[email-masked]>
wrote:

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

Hadriel,

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

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)

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

	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

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

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Mon, 3 Oct 2011 09:39:28 +0200

Hi,

Sorry for coming a bit late...

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

We do deploy ICE-enabled network infrastructure to our customers, the free http://sip2sip.info site is an example of such a platform.

The problem we faced with ICE was the fact that in most cases NAT is fixed by modifying the SDP and changing c/m lines in order to put a media relay in between, but this breaks ICE negotiation because there is no candidate for the new c line. We solved this in two Open Source projects: OpenSIPS and MediaProxy by also adding a new candidate which would appear to be a TURN server, so both ends are fooled to believe there was a candidate. The media relay lets STUN probes pass so that ICE connectivity checks will succeed.

This ensures that if both endpoints do support ICE the negotiation will succeed. Unfortunately, not many endpoints do implement ICE, so those that don't would need to be gateway-ed, but IMHO it's for a greater good.

Regards,

--
Saúl Ibarra Corretgé
AG Projects

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 5 Oct 2011 15:06:38 -0600

On Sep 29, 2011, at 3:59 PM, Hadriel Kaplan wrote:

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

I have this weird feeling we have had this conversation before but I'm a bit skeptical. What processor are you running SHA-1 on and how many STUN requests per second do you think might be reasonable for carrier grade box (whatever "Carrier Grade" is :-). The implementation I have been involved with, the SHA-1 is a drop in the bucket compared to the overall processing to setup a new call. 

> 
> 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
> 
> 
> On Sep 28, 2011, at 12:18 PM, Iñaki Baz Castillo wrote:
> 
>> 2011/9/28 Cullen Jennings <[email-masked]>:
>>> 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]>