subject:"Re\: \[VoiceOps\] Phone auth for incoming calls\?"

Re: [VoiceOps] Phone auth for incoming calls?

2018-08-09 Thread Alex Balashov

On Thu, Aug 09, 2018 at 10:57:36AM -0700, Calvin Ellison wrote:

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

I personally find IPSec way too complicated. My preference is to do
OpenVPN, because it's so, so much simpler. There is at least one handset
vendor - Snom - that supports it right in the handset. 

I've seen lots of tunnel-based approaches with hosted PBX. A lot of them
involve sending the customer a router to put on their network where the
tunnels can land and the traffic can be diverted into the tunnel. Others
involve putting it straight into the phones, or in the case of
softphones, packaging it with the UA. 

Whatever it is, it works better and is easier to set up and make behave
more consistently than SIP-TLS.

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

Re: [VoiceOps] Phone auth for incoming calls?

2018-08-09 Thread Paul Timmins

> On Aug 9, 2018, at 9:47 PM, Brandon Martin  
> wrote:
> 
> On 08/09/2018 04:46 AM, Alex Balashov 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.
> 
> There's also an argument to be made that I haven't seen brought up for 
> protecting SIP registration credentials either by providing transport 
> confidentiality for a conventional password/secret or by using TLS client 
> certificates.  If you're at all worried about an adversary observing your 
> actual comms, I'd be doubly worried about somebody stealing registration 
> credentials and abusing them.

TLS was never about end to end confidentiality. We have wiretap obligations 
after all. Until the last copper line is dead and gone there will always be a 
way for unencrypted calls to occur.

TLS is good when you don't want your local IT staff to know what the CEO is 
talking about, or to wiretap his coworkers (assuming hosted PBX). The likely 
attack surface for a customer's confidentiality will be somewhere between that 
handset and you, and you have a means to protect that.

-Paul
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Phone auth for incoming calls?

2018-08-09 Thread Brandon Martin


On 08/09/2018 04:46 AM, Alex Balashov 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.


There's also an argument to be made that I haven't seen brought up for 
protecting SIP registration credentials either by providing transport 
confidentiality for a conventional password/secret or by using TLS 
client certificates.  If you're at all worried about an adversary 
observing your actual comms, I'd be doubly worried about somebody 
stealing registration credentials and abusing them.


--
Brandon Martin
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Phone auth for incoming calls?

2018-08-09 Thread Ryan Delgrosso


The "but look at them" argument never tasted good to me.

Someone has to break rank and do it right first or it never gets better.

There is also the point that intra-org communications can be end-to-end 
guarenteed. That resonates strongly.




On 8/9/2018 1:46 AM, Alex Balashov 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  
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

Re: [VoiceOps] Phone auth for incoming calls?

2018-08-09 Thread Carlos Alvarez

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.

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.

Either way, I don't intend to use TLS.  It was more of an academic question.


On Thu, Aug 9, 2018 at 1:48 AM Alex Balashov 
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

Re: [VoiceOps] Phone auth for incoming calls?

2018-08-09 Thread Calvin Ellison

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  *
5825 Oberlin Drive, Suite 5
San Diego, CA 92121
[image: Voxox]

On Thu, Aug 9, 2018 at 1:46 AM, Alex Balashov 
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

Re: [VoiceOps] Phone auth for incoming calls?

2018-08-09 Thread Alex Balashov

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

Re: [VoiceOps] Phone auth for incoming calls?

2018-08-08 Thread Ryan Delgrosso

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

Re: [VoiceOps] Phone auth for incoming calls?

2018-08-08 Thread Alex Balashov

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

Re: [VoiceOps] Phone auth for incoming calls?

2018-08-08 Thread Ryan Delgrosso


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



___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Phone auth for incoming calls?

2018-08-08 Thread Ryan Delgrosso


Step 1: Move everything to TCP (or better yet TLS).

Step 2: Use LetsEncrypt for free perpetual certificates.

Step 3: Profit (and smug superiority over UDP based competitors battling 
nat issues).





On 8/8/2018 10:43 AM, Carlos Alvarez wrote:
Do most of you have the phones authenticate incoming calls?  We 
haven't been, but occasionally find a router that has unfiltered full 
cone NAT (Cisco) or that puts one phone on 5060 with no filtering by 
IP.  The result is that the phone will start ringing at random as 
script kiddies hit the IP and port 5060 trying to find servers to 
exploit.  I don't see a downside to changing to auth, but not having 
done it outside of a few tests of a small number of phones, I figured 
I would ask.




___
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

Re: [VoiceOps] Phone auth for incoming calls?

2018-08-08 Thread Alex Balashov

On Wed, Aug 08, 2018 at 12:39:17PM -0700, Carlos Alvarez wrote:

> So those of you using TCP, are you also using TLS?

For some customers who require it, it's done, though as we both know,
it's silly since you can only provide encryption on the last mile. 

But no, SIP-TLS is a whole different ball of wax with an entirely
different reliability, interoperability and practicality profile, and
one I would not advise you to get into unnecessarily.

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

Re: [VoiceOps] Phone auth for incoming calls?

2018-08-08 Thread Carlos Alvarez

So those of you using TCP, are you also using TLS?


On Wed, Aug 8, 2018 at 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 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

Re: [VoiceOps] Phone auth for incoming calls?

2018-08-08 Thread Alex Balashov

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

Re: [VoiceOps] Phone auth for incoming calls?

2018-08-08 Thread Aviv Shaham

TCP is definitely the way to go nowadays. We use TCP on Grandstreams all
the time, especially on their ATAs. Speaking of which, switching from
UDP to  TCP will reduce your customers' support calls dramatically.
I don't know the current status over there, but 2 years ago RingCentral
moved to TCP as well:
https://netstorage.ringcentral.com/documents/sip.pdf
Aviv


On Wed, Aug 8, 2018, at 12:21 PM, Carlos Alvarez wrote:
> It has, but it wasn't that long ago that people were still having
> challenges.  Our preferred phone vendor, Grandstream, still generally
> advises against it.> 
> So...who else on the list uses TCP and has any comments about it?
> 
> 
> On Wed, Aug 8, 2018 at 11:12 AM Alex Balashov
>  wrote:>> That has changed greatly since 2005.
>> 
>>  On August 8, 2018 2:07:50 PM EDT, Carlos Alvarez
>>   wrote:>>  >That's a change I've never investigated.  
>> Or more precisely,
>>  >haven't>>  >investigated since the days when the advice for doing it was 
>> "good>>  >luck!!"
>>  >
>>  >
>>  >On Wed, Aug 8, 2018 at 11:00 AM Alex Balashov
>>  >
>>  >wrote:
>>  >
>>  >> I would have to agree with Calvin. Just use TCP.
>>  >>
>>  >> On August 8, 2018 1:58:47 PM EDT, Calvin Ellison
>>  >
>>  >> wrote:
>>  >> >Using TCP or TLS would avoid open NAT issue, and can cure some
>>  >naughty
>>  >> >SIP
>>  >> >ALG issues as well, assuming you want to tolerate the overhead.>>  >> >
>>  >> >For UDP, we've used both Digest and Source request validation
>>  >> >with>>  >> >Polycom
>>  >> >devices. Source validation is probably the easiest route,
>>  >> >assuming>>  >the
>>  >> >UA
>>  >> >doesn't need to receive calls from anyone but its proxy or
>>  >registrar.
>>  >> >Digest (nonce challenge) is better if you want to accept calls
>>  >> >from>>  >> >anyone
>>  >> >who knows your password, but we had an issue with a softswitch
>>  >> >that>>  >> >would
>>  >> >properly handle auth channel to INVITE but choked when a BYE was>>  >> 
>> >challenged.
>>  >> >
>>  >> >
>>  >> >
>>  >> >
>>  >> >Regards,
>>  >> >
>>  >> >*Calvin Ellison*
>>  >> >Voice Operations Engineer
>>  >> >calvin.elli...@voxox.com
>>  >> >+1 (213) 285-0555
>>  >> >
>>  >> >---
>>  >> >*voxox.com  *
>>  >> >5825 Oberlin Drive, Suite 5
>>  >> >San Diego, CA 92121
>>  >> >[image: Voxox]
>>  >> >
>>  >> >On Wed, Aug 8, 2018 at 10:43 AM, Carlos Alvarez
>>  >
>>  >> >wrote:
>>  >> >
>>  >> >> Do most of you have the phones authenticate incoming calls?
>>  >> >> We>>  >> >haven't
>>  >> >> been, but occasionally find a router that has unfiltered full
>>  >> >> cone>>  >> >NAT
>>  >> >> (Cisco) or that puts one phone on 5060 with no filtering by
>>  >> >> IP.>>  >The
>>  >> >result
>>  >> >> is that the phone will start ringing at random as script
>>  >> >> kiddies>>  >hit
>>  >> >the IP
>>  >> >> and port 5060 trying to find servers to exploit.  I don't see
>>  >> >> a>>  >> >downside to
>>  >> >> changing to auth, but not having done it outside of a few
>>  >> >> tests of>>  >a
>>  >> >small
>>  >> >> number of phones, I figured I would ask.
>>  >> >>
>>  >> >>
>>  >> >> ___
>>  >> >> VoiceOps mailing list
>>  >> >> VoiceOps@voiceops.org
>>  >> >> https://puck.nether.net/mailman/listinfo/voiceops
>>  >> >>
>>  >> >>
>>  >>
>>  >>
>>  >> -- Alex
>>  >>
>>  >> --
>>  >> Sent via mobile, please forgive typos and brevity.
>>  >> ___
>>  >> VoiceOps mailing list
>>  >> VoiceOps@voiceops.org
>>  >> https://puck.nether.net/mailman/listinfo/voiceops
>>  >>
>> 
>> 
>>  -- 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

___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Phone auth for incoming calls?

2018-08-08 Thread Carlos Alvarez

It has, but it wasn't that long ago that people were still having
challenges.  Our preferred phone vendor, Grandstream, still generally
advises against it.

So...who else on the list uses TCP and has any comments about it?


On Wed, Aug 8, 2018 at 11:12 AM Alex Balashov 
wrote:

> That has changed greatly since 2005.
>
> On August 8, 2018 2:07:50 PM EDT, Carlos Alvarez 
> wrote:
> >That's a change I've never investigated.  Or more precisely, haven't
> >investigated since the days when the advice for doing it was "good
> >luck!!"
> >
> >
> >On Wed, Aug 8, 2018 at 11:00 AM Alex Balashov
> >
> >wrote:
> >
> >> I would have to agree with Calvin. Just use TCP.
> >>
> >> On August 8, 2018 1:58:47 PM EDT, Calvin Ellison
> >
> >> wrote:
> >> >Using TCP or TLS would avoid open NAT issue, and can cure some
> >naughty
> >> >SIP
> >> >ALG issues as well, assuming you want to tolerate the overhead.
> >> >
> >> >For UDP, we've used both Digest and Source request validation with
> >> >Polycom
> >> >devices. Source validation is probably the easiest route, assuming
> >the
> >> >UA
> >> >doesn't need to receive calls from anyone but its proxy or
> >registrar.
> >> >Digest (nonce challenge) is better if you want to accept calls from
> >> >anyone
> >> >who knows your password, but we had an issue with a softswitch that
> >> >would
> >> >properly handle auth channel to INVITE but choked when a BYE was
> >> >challenged.
> >> >
> >> >
> >> >
> >> >
> >> >Regards,
> >> >
> >> >*Calvin Ellison*
> >> >Voice Operations Engineer
> >> >calvin.elli...@voxox.com
> >> >+1 (213) 285-0555
> >> >
> >> >---
> >> >*voxox.com  *
> >> >5825 Oberlin Drive, Suite 5
> >> >San Diego, CA 92121
> >> >[image: Voxox]
> >> >
> >> >On Wed, Aug 8, 2018 at 10:43 AM, Carlos Alvarez
> >
> >> >wrote:
> >> >
> >> >> Do most of you have the phones authenticate incoming calls?  We
> >> >haven't
> >> >> been, but occasionally find a router that has unfiltered full cone
> >> >NAT
> >> >> (Cisco) or that puts one phone on 5060 with no filtering by IP.
> >The
> >> >result
> >> >> is that the phone will start ringing at random as script kiddies
> >hit
> >> >the IP
> >> >> and port 5060 trying to find servers to exploit.  I don't see a
> >> >downside to
> >> >> changing to auth, but not having done it outside of a few tests of
> >a
> >> >small
> >> >> number of phones, I figured I would ask.
> >> >>
> >> >>
> >> >> ___
> >> >> VoiceOps mailing list
> >> >> VoiceOps@voiceops.org
> >> >> https://puck.nether.net/mailman/listinfo/voiceops
> >> >>
> >> >>
> >>
> >>
> >> -- Alex
> >>
> >> --
> >> Sent via mobile, please forgive typos and brevity.
> >> ___
> >> VoiceOps mailing list
> >> VoiceOps@voiceops.org
> >> https://puck.nether.net/mailman/listinfo/voiceops
> >>
>
>
> -- 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

Re: [VoiceOps] Phone auth for incoming calls?

2018-08-08 Thread Alex Balashov

That has changed greatly since 2005.

On August 8, 2018 2:07:50 PM EDT, Carlos Alvarez  wrote:
>That's a change I've never investigated.  Or more precisely, haven't
>investigated since the days when the advice for doing it was "good
>luck!!"
>
>
>On Wed, Aug 8, 2018 at 11:00 AM Alex Balashov
>
>wrote:
>
>> I would have to agree with Calvin. Just use TCP.
>>
>> On August 8, 2018 1:58:47 PM EDT, Calvin Ellison
>
>> wrote:
>> >Using TCP or TLS would avoid open NAT issue, and can cure some
>naughty
>> >SIP
>> >ALG issues as well, assuming you want to tolerate the overhead.
>> >
>> >For UDP, we've used both Digest and Source request validation with
>> >Polycom
>> >devices. Source validation is probably the easiest route, assuming
>the
>> >UA
>> >doesn't need to receive calls from anyone but its proxy or
>registrar.
>> >Digest (nonce challenge) is better if you want to accept calls from
>> >anyone
>> >who knows your password, but we had an issue with a softswitch that
>> >would
>> >properly handle auth channel to INVITE but choked when a BYE was
>> >challenged.
>> >
>> >
>> >
>> >
>> >Regards,
>> >
>> >*Calvin Ellison*
>> >Voice Operations Engineer
>> >calvin.elli...@voxox.com
>> >+1 (213) 285-0555
>> >
>> >---
>> >*voxox.com  *
>> >5825 Oberlin Drive, Suite 5
>> >San Diego, CA 92121
>> >[image: Voxox]
>> >
>> >On Wed, Aug 8, 2018 at 10:43 AM, Carlos Alvarez
>
>> >wrote:
>> >
>> >> Do most of you have the phones authenticate incoming calls?  We
>> >haven't
>> >> been, but occasionally find a router that has unfiltered full cone
>> >NAT
>> >> (Cisco) or that puts one phone on 5060 with no filtering by IP. 
>The
>> >result
>> >> is that the phone will start ringing at random as script kiddies
>hit
>> >the IP
>> >> and port 5060 trying to find servers to exploit.  I don't see a
>> >downside to
>> >> changing to auth, but not having done it outside of a few tests of
>a
>> >small
>> >> number of phones, I figured I would ask.
>> >>
>> >>
>> >> ___
>> >> VoiceOps mailing list
>> >> VoiceOps@voiceops.org
>> >> https://puck.nether.net/mailman/listinfo/voiceops
>> >>
>> >>
>>
>>
>> -- Alex
>>
>> --
>> Sent via mobile, please forgive typos and brevity.
>> ___
>> VoiceOps mailing list
>> VoiceOps@voiceops.org
>> https://puck.nether.net/mailman/listinfo/voiceops
>>


-- Alex

--
Sent via mobile, please forgive typos and brevity. 
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Phone auth for incoming calls?

2018-08-08 Thread Carlos Alvarez

That's a change I've never investigated.  Or more precisely, haven't
investigated since the days when the advice for doing it was "good luck!!"


On Wed, Aug 8, 2018 at 11:00 AM Alex Balashov 
wrote:

> I would have to agree with Calvin. Just use TCP.
>
> On August 8, 2018 1:58:47 PM EDT, Calvin Ellison 
> wrote:
> >Using TCP or TLS would avoid open NAT issue, and can cure some naughty
> >SIP
> >ALG issues as well, assuming you want to tolerate the overhead.
> >
> >For UDP, we've used both Digest and Source request validation with
> >Polycom
> >devices. Source validation is probably the easiest route, assuming the
> >UA
> >doesn't need to receive calls from anyone but its proxy or registrar.
> >Digest (nonce challenge) is better if you want to accept calls from
> >anyone
> >who knows your password, but we had an issue with a softswitch that
> >would
> >properly handle auth channel to INVITE but choked when a BYE was
> >challenged.
> >
> >
> >
> >
> >Regards,
> >
> >*Calvin Ellison*
> >Voice Operations Engineer
> >calvin.elli...@voxox.com
> >+1 (213) 285-0555
> >
> >---
> >*voxox.com  *
> >5825 Oberlin Drive, Suite 5
> >San Diego, CA 92121
> >[image: Voxox]
> >
> >On Wed, Aug 8, 2018 at 10:43 AM, Carlos Alvarez 
> >wrote:
> >
> >> Do most of you have the phones authenticate incoming calls?  We
> >haven't
> >> been, but occasionally find a router that has unfiltered full cone
> >NAT
> >> (Cisco) or that puts one phone on 5060 with no filtering by IP.  The
> >result
> >> is that the phone will start ringing at random as script kiddies hit
> >the IP
> >> and port 5060 trying to find servers to exploit.  I don't see a
> >downside to
> >> changing to auth, but not having done it outside of a few tests of a
> >small
> >> number of phones, I figured I would ask.
> >>
> >>
> >> ___
> >> VoiceOps mailing list
> >> VoiceOps@voiceops.org
> >> https://puck.nether.net/mailman/listinfo/voiceops
> >>
> >>
>
>
> -- 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

Re: [VoiceOps] Phone auth for incoming calls?

2018-08-08 Thread Eric Wieling

I've seen similar issues with Polycom phones, the fix was to set 
voIpProt.SIP.strictUserValidation to "1".   I don't use any other 
brands, so I don't know about others.


On 08/08/2018 01:43 PM, Carlos Alvarez wrote:
Do most of you have the phones authenticate incoming calls?  We haven't 
been, but occasionally find a router that has unfiltered full cone NAT 
(Cisco) or that puts one phone on 5060 with no filtering by IP.  The 
result is that the phone will start ringing at random as script kiddies 
hit the IP and port 5060 trying to find servers to exploit.  I don't see 
a downside to changing to auth, but not having done it outside of a few 
tests of a small number of phones, I figured I would ask.




___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops



--
http://help.nyigc.net/
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Phone auth for incoming calls?

2018-08-08 Thread Alex Balashov

I would have to agree with Calvin. Just use TCP. 

On August 8, 2018 1:58:47 PM EDT, Calvin Ellison  
wrote:
>Using TCP or TLS would avoid open NAT issue, and can cure some naughty
>SIP
>ALG issues as well, assuming you want to tolerate the overhead.
>
>For UDP, we've used both Digest and Source request validation with
>Polycom
>devices. Source validation is probably the easiest route, assuming the
>UA
>doesn't need to receive calls from anyone but its proxy or registrar.
>Digest (nonce challenge) is better if you want to accept calls from
>anyone
>who knows your password, but we had an issue with a softswitch that
>would
>properly handle auth channel to INVITE but choked when a BYE was
>challenged.
>
>
>
>
>Regards,
>
>*Calvin Ellison*
>Voice Operations Engineer
>calvin.elli...@voxox.com
>+1 (213) 285-0555
>
>---
>*voxox.com  *
>5825 Oberlin Drive, Suite 5
>San Diego, CA 92121
>[image: Voxox]
>
>On Wed, Aug 8, 2018 at 10:43 AM, Carlos Alvarez 
>wrote:
>
>> Do most of you have the phones authenticate incoming calls?  We
>haven't
>> been, but occasionally find a router that has unfiltered full cone
>NAT
>> (Cisco) or that puts one phone on 5060 with no filtering by IP.  The
>result
>> is that the phone will start ringing at random as script kiddies hit
>the IP
>> and port 5060 trying to find servers to exploit.  I don't see a
>downside to
>> changing to auth, but not having done it outside of a few tests of a
>small
>> number of phones, I figured I would ask.
>>
>>
>> ___
>> VoiceOps mailing list
>> VoiceOps@voiceops.org
>> https://puck.nether.net/mailman/listinfo/voiceops
>>
>>


-- Alex

--
Sent via mobile, please forgive typos and brevity. 
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Phone auth for incoming calls?

2018-08-08 Thread Calvin Ellison

Using TCP or TLS would avoid open NAT issue, and can cure some naughty SIP
ALG issues as well, assuming you want to tolerate the overhead.

For UDP, we've used both Digest and Source request validation with Polycom
devices. Source validation is probably the easiest route, assuming the UA
doesn't need to receive calls from anyone but its proxy or registrar.
Digest (nonce challenge) is better if you want to accept calls from anyone
who knows your password, but we had an issue with a softswitch that would
properly handle auth channel to INVITE but choked when a BYE was challenged.

Regards,

*Calvin Ellison*
Voice Operations Engineer
calvin.elli...@voxox.com
+1 (213) 285-0555

---
*voxox.com  *
5825 Oberlin Drive, Suite 5
San Diego, CA 92121
[image: Voxox]

On Wed, Aug 8, 2018 at 10:43 AM, Carlos Alvarez  wrote:

> Do most of you have the phones authenticate incoming calls?  We haven't
> been, but occasionally find a router that has unfiltered full cone NAT
> (Cisco) or that puts one phone on 5060 with no filtering by IP.  The result
> is that the phone will start ringing at random as script kiddies hit the IP
> and port 5060 trying to find servers to exploit.  I don't see a downside to
> changing to auth, but not having done it outside of a few tests of a small
> number of phones, I figured I would ask.
>
>
> ___
> 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

Re: [VoiceOps] Phone auth for incoming calls?

2018-08-08 Thread Carlos Alvarez

You're right, most phones have both options also.  However I'm not sure how
the "same server" is applied for a phone behind NAT.  Would the phone
actually know where the call came from?  I've never tried it.

Alex, it does work fine with Asterisk, at least on a small scale test.  But
the fear of changing something so drastic on thousands of phones lead me to
asking about it here.


On Wed, Aug 8, 2018 at 10:48 AM David Knell  wrote:

> Been there, had that :-)  Auth works; you might also find an option to
> only accept calls from the server to which the phone's registered.
>
> --Dave
>
> On Wed, Aug 8, 2018 at 8:43 PM, Carlos Alvarez 
> wrote:
>
>> Do most of you have the phones authenticate incoming calls?  We haven't
>> been, but occasionally find a router that has unfiltered full cone NAT
>> (Cisco) or that puts one phone on 5060 with no filtering by IP.  The result
>> is that the phone will start ringing at random as script kiddies hit the IP
>> and port 5060 trying to find servers to exploit.  I don't see a downside to
>> changing to auth, but not having done it outside of a few tests of a small
>> number of phones, I figured I would ask.
>>
>>
>> ___
>> VoiceOps mailing list
>> VoiceOps@voiceops.org
>> https://puck.nether.net/mailman/listinfo/voiceops
>>
>>
>
>
> --
>
> David Knell, Director, TelNG
> T: +44 1223 797979 / +1 970-315-4721
> W: http://www.telng.com
> H: http://www.daveknell.com
>
>
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Phone auth for incoming calls?

2018-08-08 Thread Alex Balashov

That would depend on the sending UA's ability to answer such challenges, unless 
you're referring to some setting to white-list IPs or restrict sources to 
previously called endpoints. 

On August 8, 2018 1:43:45 PM EDT, Carlos Alvarez  wrote:
>Do most of you have the phones authenticate incoming calls?  We haven't
>been, but occasionally find a router that has unfiltered full cone NAT
>(Cisco) or that puts one phone on 5060 with no filtering by IP.  The
>result
>is that the phone will start ringing at random as script kiddies hit
>the IP
>and port 5060 trying to find servers to exploit.  I don't see a
>downside to
>changing to auth, but not having done it outside of a few tests of a
>small
>number of phones, I figured I would ask.


-- Alex

--
Sent via mobile, please forgive typos and brevity. 
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Phone auth for incoming calls?

Re: [VoiceOps] Phone auth for incoming calls?

Re: [VoiceOps] Phone auth for incoming calls?

Re: [VoiceOps] Phone auth for incoming calls?

Re: [VoiceOps] Phone auth for incoming calls?

Re: [VoiceOps] Phone auth for incoming calls?

Re: [VoiceOps] Phone auth for incoming calls?

Re: [VoiceOps] Phone auth for incoming calls?

Re: [VoiceOps] Phone auth for incoming calls?

Re: [VoiceOps] Phone auth for incoming calls?

Re: [VoiceOps] Phone auth for incoming calls?

Re: [VoiceOps] Phone auth for incoming calls?

Re: [VoiceOps] Phone auth for incoming calls?

Re: [VoiceOps] Phone auth for incoming calls?

Re: [VoiceOps] Phone auth for incoming calls?

Re: [VoiceOps] Phone auth for incoming calls?

Re: [VoiceOps] Phone auth for incoming calls?

Re: [VoiceOps] Phone auth for incoming calls?

Re: [VoiceOps] Phone auth for incoming calls?

Re: [VoiceOps] Phone auth for incoming calls?

Re: [VoiceOps] Phone auth for incoming calls?

Re: [VoiceOps] Phone auth for incoming calls?

Re: [VoiceOps] Phone auth for incoming calls?

23 matches

Site Navigation

Mail list logo

Footer information