Aaron | Slash32

Author: Aaron
Aaron is a Senior Network Engineer working in the managed services space. He achieved his CCIE Collaboration in 2014 and has more than 15 years of experience in the IT sector. While his primary focus is on Cisco Collaboration, he also has a strong focus in the Cisco Firewall and Route/Switch domains. When not at work, he enjoys cycling, smoking meat, and building Legos.

SIP Trunking Demystified: Security

Posted on May 26, 2020 by Aaron

I’m not old enough to remember the old school party line phones that my mom talks about. Heck, the idea of sharing one phone per house seems far enough in the past at this point, let alone sharing a phone with neighbors.

If you’re not familiar with the concept of party line phones, you basically shared a single line from the telephone company with a handful of your neighbors. When the phone would ring, you would listen to the number of rings to determine if the call was for your house. There was no second call on the line allowed either. You could pick up the phone at any time and listen to your neighbors phone calls as well. No guarantee of privacy!

SIP trunks can be sort of the same thing. Standard SIP providers hand off their SIP trunks on the default TCP port of 5060. This port is typically used for unencrypted SIP communications. That means that anyone who can get a packet capture of your calls gets to replay the whole conversation. If the handoff for the SIP trunk is through a private connection to the carrier, this may not be much of an issue. However, most SIP carriers hand off their trunks across the internet. This means that all of your calls are then unencrypted across the internet and are subject to interception!

Enter SIP-TLS and SRTP. SIP-TLS puts a TLS wrapper around your SIP signaling to ensure that all call setup and teardown messages are encrypted. SRTP does the same, but for the actual call audio. Setup for SIP-TLS and SRTP is pretty simple. All it takes is the exchange of a digital certificate between the provider and the customer to verify and encrypt traffic on both sides. However, the majority of providers don’t offer this as a service and non-enterprise grade PBXs don’t support it either.

No so with a Cisco based SIP solution. Cisco’s Unified Border Element (CUBE) has supported call encryption for quite some time now. Starting with the ISR 2900/3900 line, and now extended in to the 4300/4400 series. On the provider side, I’ve had great luck with Intelepeer and their secure SIP options. Easy to work with and rock solid one set up.

Cisco ASAs and RSASSA-PSS

Posted on May 26, 2020 by Aaron

I ran into a weird issue recently where I was trying to import a CA cert for cert auth with AnyConnect but the ASA wouldn’t take it. This CA cert was part of a two-tier Microsoft CA so maybe I had an issue with the chain. Nope. Cert expired? Nope. CRL URL not available? Nope.

Since all of the usual culprits weren’t checking out, I enabled a debug crypto ca 14 on the ASA and took a look at the logs while attempting to import the cert. Here’s what I saw.

A search on Error #705h led me to a Cisco bug report detailing a lack of support on the ASA platform for the RSASSA-PSS algorithm. This certificate algorithm is a part of the RFC 3447 and was meant to address some limitations in Certificate Authorities at the time. While the standard has been around since 2002, it still lacks broad support.

Even through it is a little supported cryptography standard, Microsoft has included in the default CAPolicy.inf files that are in their standard TechNet articles for configuring a Microsoft CA. In my case, it wasn’t the end of the world. Just had to disable the Alternate Certificate Algorithm and then reissue the CA certs. It will take a while for all of the clients to check in and request new certs based on SHA256, but it’ll happen eventually.

Word of caution: if you’re not sure of the impact, DO NOT regenerate your CA certs without a through review of the implications.

Phones don’t last forever?

Posted on May 17, 2020 by Aaron

I’ve been having a lot of conversations lately around Cisco phone models. Until version 11.5, it was a true statement that Cisco Call Manager still supported every Cisco phone that had ever been replaced. While this was a great thing for the customer on cost and ease of upgrade, it limited Cisco’s path forward. With every major release since, Cisco has begun to discontinue support for older phone models. When Cisco Call Manager 14 comes out later this year, there will be another batch of phones that drop off of support. I was a bit surprised to see the 6900 series make it in to the list so quickly, but they always felt like sort of a step child to the flagship 7900 series that came out a decade before them and look to outlast them with the release of 14.

Cisco Unified SIP Phone 3911
Cisco Unified SIP Phone 3951
Cisco Unified IP Phone 6911
Cisco Unified IP Phone 6921
Cisco Unified IP Phone 6941
Cisco Unified IP Phone 6945
Cisco Unified IP Phone 6961
Cisco Unified IP Phone 7906G
Cisco Unified IP Phone 7911G
Cisco Unified Wireless IP Phone 7925
Cisco Unified Wireless IP Phone 7925G-EX

Cisco Unified Wireless IP Phone 7926
Cisco Unified IP Phone 7931
Cisco Unified IP Conference Station 7936
Cisco Unified IP Conference Station 7937G
Cisco Unified IP Phone 7940
Cisco Unified IP Phone 7941
Cisco Unified IP Phone 7960
Cisco Unified IP Phone 7961
Cisco Unified IP Phone 7985
Cisco Unified IP Phone 8941

If you’re running some of these models in your environment, it’s not the end of the world. Call Manager 11.5 is still an active release with no current end of support date (as of Mid 2020). Even once announced, there will still be a good 4 to 5 years of life still in it. That’s more than enough time to plan for hardware refreshes and to get users up to speed.

Source: https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/trouble/14_0_1/fieldNotices/cucm_b_deprecated-phones-14.html

SIP Trunking Demystified: Transport

Posted on May 10, 2020May 17, 2020 by Aaron

Traditional phone service has been delivered via PRI or POTS connections. These connections are maintained by your local phone company and are their responsibility to maintain. In the case of a PRI, 23 phone calls can be delivered over a single line. POTS lines are similar to the phone lines that used to be common in residential settings which only allow one call at a time. The advent of networking and the Internet has brought alternatives to these traditional phone services; with the most popular standard being SIP. SIP was developed in the late 1990s as a way of digitizing voice communications to be sent over networks that would have been traditionally reserved for data communications. By treating this communication more like data traffic, phone providers are able to quickly provision service, scale it up and down as necessary, and provide for disaster recovery functions. SIP has slowly gained adoption over the last 20 years to the point where we see it as the primary choice for phone connectivity today. This post will be part of a three part series making the business case for moving to SIP and bringing awareness to the common pitfalls of making the transition.

One of the great things about SIP phone service is its transport independence. It can be installed over a common internet connection or though dedicated lines from a provider. The internet transport method tends to be the cheapest because it uses what is already there. However, this approach can bring about issues since there’s no guarantee of call quality across the internet. Do video streaming services ever freeze up when you are binge watching your favorite show? Sure! How then would it impact your business if your phone service did the same? On the other hand, dedicated connections for SIP can require build out costs and high monthly fees. Is it worth it? Well, that depends how critical phone service is your business.

I generally prefer to handle this conversation differently than most providers. Rather than putting in a solution and hoping it all works out, my preference is to use the business needs to recommend a solution that works for you. Maybe it’s SIP over the public internet, or it is private transport. Or it’s sticking to POTS lines! This is never a one size fits all conversation!