<div dir="ltr">Alex, what has been your experience with tunnel based solutions? Our choice seems to be IPSec VPN on existing gear or spending some cash on an SRTP-RTP "transcoder".</div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr">Regards,<div><br></div><div><p style="font-family:helvetica,arial,sans-serif;font-size:12px;margin:0px;padding:0px 0px 20px;color:rgb(0,0,0)"><strong>Calvin Ellison</strong><br>Voice Operations Engineer<br><a href="mailto:calvin.ellison@voxox.com" style="text-decoration:none;color:rgb(14,123,174)" target="_blank">calvin.ellison@voxox.com</a><br>+1 (213) 285-0555<br><br>-----------------------------------------------<br><strong><a href="http://www.voxox.com/" style="text-decoration:none;color:rgb(14,123,174)" target="_blank">voxox.com</a> </strong><br>5825 Oberlin Drive, Suite 5<br>San Diego, CA 92121<br></p><img src="http://cdn.voxox.com/img/voxox-logo.png" alt="Voxox" style="color:rgb(0,0,0);font-family:'Times New Roman';font-size:medium"><br></div></div></div></div></div></div></div></div></div></div>
<br><div class="gmail_quote">On Thu, Aug 9, 2018 at 1:46 AM, Alex Balashov <span dir="ltr"><<a href="mailto:abalashov@evaristesys.com" target="_blank">abalashov@evaristesys.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Yes, but until and unless your upstream supply chain is doing TLS and<br>
you can provide end-to-end security, it's a pointless waste of time.<br>
<br>
My customers have numerous customers who "require" "encryption" and<br>
"security", and this is provided to them on the "Last Mile" SIP trunk.<br>
But as soon as it goes to the usual Bandwidths and friends all that TLS<br>
is sheathed off.<br>
<br>
As long as that is the case, and I expect it will be the case for quite<br>
some time, this whole concept is a joke.<br>
<br>
The second problem is how incredibly inconsistent/broken SIP-TLS is.<br>
It's a trainwreck with way too many moving parts. My finding over the<br>
years has been that when it comes to providing faux-"security", my<br>
happiest customers are the ones that settled for a tunnel-based<br>
approach.<br>
<span class="HOEnZb"><font color="#888888"><br>
-- Alex<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On Wed, Aug 08, 2018 at 10:09:40PM -0700, Ryan Delgrosso wrote:<br>
<br>
> I used to follow the same logic but recently have shifted. I now<br>
> wholeheartedly follow the encrypt everywhere stance. Too many industries<br>
> have compliance regulations where VoIP got the exemption because of<br>
> grandfathered PSTN focused laws, but just because you CAN go plaintext<br>
> doesnt make it the best answer, and its always stronger to say "yes" to the<br>
> encryption question than "No but..."<br>
> <br>
> <br>
> <br>
> On 8/8/2018 5:14 PM, Alex Balashov wrote:<br>
> > Agree with everything Ryan said, with the caveat that TLS for TLS's sake is, in my own humble opinion, a terrible idea from a troubleshooting and general complexity perspective. Use where absolutely necessary and nowhere else.<br>
> > <br>
> > On August 8, 2018 7:37:13 PM EDT, Ryan Delgrosso <<a href="mailto:ryandelgrosso@gmail.com">ryandelgrosso@gmail.com</a>> wrote:<br>
> > > OK so to expand on my previous smug-ness<br>
> > > <br>
> > > Upsides:<br>
> > > <br>
> > >   * No more signaling nat issues. Literally zero. If you want to be<br>
> > >     super-sneaky run your edge over TLS port 443 and most things wont<br>
> > >     touch you.<br>
> > >   * No retransmission's or registration avalanches. They simply cannot<br>
> > >     happen since you need a tcp session first.<br>
> > > * No packet fragmentation issues. Send massive bloated SDP's and never<br>
> > >     worry about pruning headers again. If you are doing sip SIMPLE send<br>
> > >     mime bodies in messages if you want. Its all good.<br>
> > > * Faster convergence (if you reset the TCP connections to your devices<br>
> > >     it will usually trigger an instantaneous proxy advance)<br>
> > >   * Real-HA on carrier grade SBC's works just fine and TCP state is<br>
> > >     maintained across pairs (Acme, Perimeta etc)<br>
> > >   * Never chase lost signaling<br>
> > > <br>
> > > <br>
> > > Downsides:<br>
> > > <br>
> > >   * Conventional HA doesnt work so well. Your reg/subscription etc will<br>
> > >    all be in the context of a single TCP session (with or without TLS).<br>
> > >     This means for that second when you restart your proxy the session<br>
> > >     is lost and MUST be re-establised by the client.<br>
> > >   * SIP Outbound support, which would basically be the answer here<br>
> > >     basically doesn't exist in a usable fashion for reliable dual-reg.<br>
> > >     Device support is partial and broken. Its not good. There are<br>
> > >     potential solutions but it involves real commitment to this right<br>
> > >     now and the gulf of experience between having and not isnt huge.<br>
> > > * Moderately more load since TCP state must be retained, but on modern<br>
> > >     hardware this is so trivial its almost not worth mentioning.<br>
> > >   * Need to re-learn KPI's for network. The entire signaling profile<br>
> > >     changes. Its just a different animal.<br>
> > > * Most of your sniffer-based diagnostic tools become useless (for tls)<br>
> > >     since packets wont be readable. This is dodged with an edge that<br>
> > >     will feed encrypted traffic to a collector.<br>
> > > <br>
> > > <br>
> > > Suggestions:<br>
> > > <br>
> > > STRONGLY recommend terminating TCP/TLS at the edge and still running<br>
> > > core in straight UDP with jumbo frames. You dont want a cascde of tcp<br>
> > > session reestablishments<br>
> > > <br>
> > > I have a growing SP network today doing this with great success and<br>
> > > also<br>
> > > advise my consulting clients to take this path.<br>
> > > <br>
> > > <br>
> > > <br>
> > > On 8/8/2018 12:36 PM, Alex Balashov wrote:<br>
> > > > On Wed, Aug 08, 2018 at 12:21:09PM -0700, Carlos Alvarez wrote:<br>
> > > > <br>
> > > > > So...who else on the list uses TCP and has any comments about it?<br>
> > > > We are not an ITSP and are Polycom-only with a trivial number of<br>
> > > > endpoints, but we do use it and it works just fine.<br>
> > > > <br>
> > > > However, we have numerous customers, some of whom use TCP<br>
> > > predominantly<br>
> > > > for thousands of endpoints. It works just fine.<br>
> > > > <br>
> > > > In terms of downsides:<br>
> > > > <br>
> > > > In addition to a historical lack of (RFC 3261-mandated) support,<br>
> > > there<br>
> > > > are of course theoretical trade-offs involved in using TCP. There's<br>
> > > > more overhead, and connection state to be maintained on the server<br>
> > > side,<br>
> > > > which of course consumes resources — resources considered trivial<br>
> > > > nowadays, but once upon a time, when RFC 3261 was ratified (2002),<br>
> > > > perhaps not. As with all things TCP, it can also present a DoS vector<br>
> > > if<br>
> > > > you don't limit the number of connections somewhere.<br>
> > > > <br>
> > > > The congestion control/end-to-end delay aspects of TCP are certainly<br>
> > > not<br>
> > > > as important now as they were at a time when the public IP backbone<br>
> > > and<br>
> > > > was in an entirely different place in its evolution. Also, nowadays<br>
> > > the<br>
> > > > congestion/windowing algorithms used in TCP can be tweaked to<br>
> > > something<br>
> > > > more efficient.<br>
> > > > <br>
> > > > I think the most damning thing about using TCP is perceived to be the<br>
> > > > relative difficulty of failing over TCP session state to a different<br>
> > > > host. UDP does not require connection state, so as long as you have<br>
> > > some<br>
> > > > means of handling requests in a relatively stateless fashion, things<br>
> > > can<br>
> > > > just carry on as they did before in the event of an IP takeover<br>
> > > without<br>
> > > > anyone having to "reconnect". This is one area where the big<br>
> > > enterprise<br>
> > > > boxes certainly trump the open-source ecosystem, where transparent<br>
> > > TCP<br>
> > > > failover *for SIP* doesn't really exist, although in my opinion the<br>
> > > > whole issue is getting a bit moot with the way cloud infrastructure<br>
> > > and<br>
> > > > virtualisation networking is evolving.<br>
> > > > <br>
> > > > -- Alex<br>
> > > > <br>
> > <br>
> > -- Alex<br>
> > <br>
> > --<br>
> > Sent via mobile, please forgive typos and brevity.<br>
> > ______________________________<wbr>_________________<br>
> > VoiceOps mailing list<br>
> > <a href="mailto:VoiceOps@voiceops.org">VoiceOps@voiceops.org</a><br>
> > <a href="https://puck.nether.net/mailman/listinfo/voiceops" rel="noreferrer" target="_blank">https://puck.nether.net/<wbr>mailman/listinfo/voiceops</a><br>
> <br>
> ______________________________<wbr>_________________<br>
> VoiceOps mailing list<br>
> <a href="mailto:VoiceOps@voiceops.org">VoiceOps@voiceops.org</a><br>
> <a href="https://puck.nether.net/mailman/listinfo/voiceops" rel="noreferrer" target="_blank">https://puck.nether.net/<wbr>mailman/listinfo/voiceops</a><br>
<br>
</div></div><span class="im HOEnZb">-- <br>
Alex Balashov | Principal | Evariste Systems LLC<br>
<br>
Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) <br>
Web: <a href="http://www.evaristesys.com/" rel="noreferrer" target="_blank">http://www.evaristesys.com/</a>, <a href="http://www.csrpswitch.com/" rel="noreferrer" target="_blank">http://www.csrpswitch.com/</a><br>
</span><div class="HOEnZb"><div class="h5">______________________________<wbr>_________________<br>
VoiceOps mailing list<br>
<a href="mailto:VoiceOps@voiceops.org">VoiceOps@voiceops.org</a><br>
<a href="https://puck.nether.net/mailman/listinfo/voiceops" rel="noreferrer" target="_blank">https://puck.nether.net/<wbr>mailman/listinfo/voiceops</a><br>
</div></div></blockquote></div><br></div>