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