[VoiceOps] Phone auth for incoming calls?

Thu Aug 9 13:57:36 EDT 2018

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.ellison at 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 <abalashov at 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 <
> ryandelgrosso at 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 at voiceops.org
> > > https://puck.nether.net/mailman/listinfo/voiceops
> >
> > _______________________________________________
> > VoiceOps mailing list
> > VoiceOps at 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 at voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20180809/d52fe673/attachment.html>