<div dir="ltr">On the security side...there's reality and there's perception.  I go through HIPAA/PCI compliance docs all the time, and they ask things about encryption or secure/dedicated connections.  I can say "no, but...." or I can just say "yes."  Our HIPPA-covered clients are all on MPLS to us so we can answer yes.  When I say "no but" on other topics, there's always a hassle.<div><br></div><div>There is a practical matter that there are probably more threats on the last mile than anywhere else.  Someone at Level 3 is unlikely to be sniffing on a large connection, but consumer ISP employees have much easier access to the data.  Downstream from there, plenty of places where there is little security.  So "secure to the first server" does have a certain value.</div><div><br></div><div>Either way, I don't intend to use TLS.  It was more of an academic question.</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Aug 9, 2018 at 1:48 AM Alex Balashov <<a href="mailto:abalashov@evaristesys.com">abalashov@evaristesys.com</a>> wrote:<br></div><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>
<br>
-- Alex<br>
<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" target="_blank">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>
> > _______________________________________________<br>
> > VoiceOps mailing list<br>
> > <a href="mailto:VoiceOps@voiceops.org" target="_blank">VoiceOps@voiceops.org</a><br>
> > <a href="https://puck.nether.net/mailman/listinfo/voiceops" rel="noreferrer" target="_blank">https://puck.nether.net/mailman/listinfo/voiceops</a><br>
> <br>
> _______________________________________________<br>
> VoiceOps mailing list<br>
> <a href="mailto:VoiceOps@voiceops.org" target="_blank">VoiceOps@voiceops.org</a><br>
> <a href="https://puck.nether.net/mailman/listinfo/voiceops" rel="noreferrer" target="_blank">https://puck.nether.net/mailman/listinfo/voiceops</a><br>
<br>
-- <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>
_______________________________________________<br>
VoiceOps mailing list<br>
<a href="mailto:VoiceOps@voiceops.org" target="_blank">VoiceOps@voiceops.org</a><br>
<a href="https://puck.nether.net/mailman/listinfo/voiceops" rel="noreferrer" target="_blank">https://puck.nether.net/mailman/listinfo/voiceops</a><br>
</blockquote></div>