Restricted CUCM – Rated R

If you’ve gone to download Cisco Unified Communications Manager (CUCM) software any time in the past couple of years, you’ve probable found yourself momentarily befuzzled by the option to download one of two different versions – Restricted and Unrestricted.  On the surface, without any research, you might be tempted to jump into the Unrestricted version. After all, no restrictions is usually a good thing, right?  In this case, that’s not what you want to do.  In fact, it could cause more problems than you think it might solve.

Prior to version 7.1(5), CUCM was an export restricted product.  Why would the government care about exporting a phone system?  The offending piece of code is in fact the media and signaling encryption that CUCM can provide in a secure RTP (SRTP) implementation.  Encryption has always been a very tightly controlled subject.  Initially developed heavily in World War II, the government needed to be sure to regulate the use of encryption (and cryptography) afterwards.  Normally, technology export is something that is controlled by the U.S. Department of Commerce.  However, since almost all applications for cryptography were military in nature it was classified as a munition by the military and therefore subject to regulation via the State Department.  And regulate it they did.  They decreed that no strong encryption software would be available to be exported out of the country without a hearing and investigation.  This usually meant that companies created “international versions” that contained the maximum strength encryption key that could be exported without a hearing – 40 bits.  This affected many programs in the early days of the Internet Age, such as Internet Explorer, Netscape Navigator, and even Windows itself.

In 1996, President Bill Clinton signed an order permitting cryptography software export rulings to be transferred to the Department of Commerce.  In fact, the order said that software was no longer to be treated as “technology” for the purposes of determining restrictions for export.  The Department of Commerce decided in 2000 to create new rules governing the export of strong encryption.  These restrictions were very permissive and have allowed encryption technology to flourish all over the world.  There are still a few countries on the Export Restriction list, such as those that are classified as terrorist states or rogue states as classified by the U.S. Government.  These countries may not be the recipient of strong encryption software.  In addition, even those countries that can receive such software are subject to inspection at any time by the U.S. Department of Commerce to ensure that the software is being used in line with the originally licensed purpose.  When you think of how many companies today have a multi-national presence, this could be a nightmare for regulatory compliance.

Cisco decided in CUCM 7.1(5) to create a version of software that eliminated the media and signaling encryption for voice traffic in an effort to avoid the need to police export destinations and avoid spot audits for CUCM software.  These Export Unrestricted versions are developed in parallel with other CUCM versions so all users can have the same functionality no matter their location.  CUCM Unrestricted versions do have a price when you install them, however.  Once you have upgraded a cluster to an Unrestricted version of CUCM, you can never go back to a Restricted (High Encryption) version.  You can’t migrate or insert any Restricted servers into the cluster.  The only way to go back is to blow everything away and reload from scratch.  Hence the reason you want to be very careful before you install the software.

If you’ve been running CUCM prior to version 7.1(5), you are running the Restricted version.  Unless you find yourself in a scenario where you need to install CUCM in a country that has Department of Commerce export restrictions or has some sort of import restriction on software (Russia is specifically called out in the Cisco release notes), you should stay on the Restricted version of CUCM.  There’s no real compelling reason for you to switch.  The cost is the same.  The licensing model is the same.  The only things you lose are the media encryption and the ability to ever upgrade to Restricted version.  Just like when going to the movies, all the good stuff is in the R-rated version.

Tom’s Take

I still get confused by the Restricted vs. Unrestricted thing from time to time.  Cisco needs to do a better job of explaining it on the download page.  I occasionally see references to the Unrestricted version being for places like Russia, but those warnings aren’t consistent between point releases, let along minor upgrades and major versions.  I think Cisco is trying to do the right thing by making this software as available to everyone in the world as they can.  With the rise of highly encrypted communications being used to launch things like command and control networks for massive botnets and distributed denial of service campaigns, I don’t doubt that we’ll see more restriction on cryptography and encryption coming sooner or later.  Until that time, we’ll just have to ensure we download the right version of CUCM to install on our servers.

“None” Ain’t No Partition I Ever Heard Of

When you setup your first Cisco Unified Communications Manager (CUCM) server, you’ve got a lot of programming to do.  You have to program phones and partitions and calling search spaces.  You have to worry about gateways and route patterns and voice mail.  Many times, the default settings in the setup will be more than sufficient to get you up and running quickly.  However, there is one default that you must avoid no matter what.  The dreaded <none>.

You see, when you configure a directory number (DN) on a phone, the default partition for this number is a special partition labeled <none>. None exists on the system mostly as a placeholder, a catch-all for devices without a home, much in the same way Uncategorized is the default category for posts on my blog.  Normally, <none> isn’t much of a bother.  I ignore it almost entirely.  However, in situations where I’m forced to deal with it, I start wanting to pull my hair out.

<none> interacts with the system in some pretty strange ways.  By rule, when you configure a DN, it can call other DNs in the same partition (provided the calling search spaces match).  As long as all your devices exist in the same partition everything is great.  However, much like creating a large network with only one VLAN, creating a phone system with only one partition can lead to problems down the road.  What if you want your voice mail system segregated from certain phones?  One of my other favorites is the executive that only wants his phone to be dialable from certain extensions on the system.  In order to accomplish these things (and more), you are going to need to create additional partitions. And the second you do, the <none> problem becomes a real hassle.

<none> is actually a null partition.  It doesn’t really exist in the system, so it can’t be assigned or removed from any calling search spaces (CSS).  This means that <none> exists in EVERY CSS.  If a phone or gateway is located in <none>, any partition on the system will be able to dial it.  However, the phones located in <none> won’t be able to dial any other partitions.  You could create a special CSS to allow it to dial other partitions, but you’ll never be able to make the phone non-dialable.  No matter what, every search space created will be able to dial that phone because every CSS has the <none> partition listed as an unlisted member, kind of like the understood “deny” statement at the end of an access list.

The best thing to do is create two different partitions for your internal devices.  One, which I call “InternalDN”, is where all your phone’s directory numbers go.  If you are creating partitions for multiple groups for a multi-tenant cluster, you could give them more specific names like “InternalDN-CoA” and so on.  Then, you create CSS groups that only allow phones in those partitions to call each other, but no one else.  Then, you put your devices that need general access to only the cluster, such as voice mail and gateways, in a partition name “ClusterOnly”.  That way, you can remember to keep your DNs different from your VM ports, and you can restrict access to each as needed.

Tom’s Take

Don’t use <none>! I’ll come and slap you.  Seriously, while it may be quick and easy to set up, if you keep using <none> for everything, it’s like building a house on quicksand.  Sooner or later, you’re going to get sucked into a huge time sink to fix a strange problem that is going to require you to unravel your entire configuration to fix it.  Better to split your phones and cluster resources into separate partitions and build it right the first time.  Just pretend you’ve never even heard of <none> and all will be well.