Editor’s Note: TS Newsletter readers get a 35% discount on Akhil Behl's book CCIE Collaboration Quick Reference. See discount code at the end of this article.   Cisco Collaboration (aka Cisco Unified Communications) solutions have come a long way since the conception of IP Telephony. With advancements in technology and the need to reduce economic and environmental impact, virtualization is well on way to become the core of all major technologies including Unified Communications. Cisco Collaboration solutions are now fully supported on Cisco UCS, with backend Nexus, storage, and Fibre Channel over Ethernet (FCoE) based systems complementing the next gen solutions. However, with inclusion and dependency on virtualized environments the issue of Quality of Service (QoS) remains to be understood as it is no longer physical switches, NICs, or application instances that are deployed; it is virtual switches (for example Nexus 1000V), virtual NICs, and virtual machines that are deployed as Cisco Collaboration solutions are increasingly virtualized.   QoS with UC on UCS In today’s converged environments, every application and/or device may be marking the traffic originating from it. From UC applications to virtual switches to Cisco Unified Computing Server (UCS) to Fabric Interconnects (61XX, 62XX) every application/device is capable of marking traffic, however, it makes more sense to mark it closest to the source of the traffic and then carry those trust markings as such in the network. In general, the rule of thumb applied to bare metal servers and physical infrastructure still applies in case of virtualized environments: Voice marking for QoS is classified as CoS 5 or DSCP 46 (EF). Videoconferencing marking for QoS is classified as CoS 4 or DSCP 34 (AF41, CS4). Call signaling for voice and videoconferencing is classified as CoS 3 or DSCP 24 (CS3).   At a high level, table 1-1 defines the traffic classification that can be defined for a virtualized Cisco Collaboration setup. Table 1-1: Traffic Classification for Virtualized Cisco Collaboration Network   A virtual machine running as a base for a UC application can connect to following virtual switches: Cisco Nexus 1000V Switch: Requires the Enterprise Plus Edition of VMware ESXi and is a distributed virtual switch. Nexus 1000V offers policy-based virtual machine connectivity and enhanced QoS. Local VMware vSwitch: This vSwitch is available with all editions of VMware ESXi hypervisor and is limited to the local physical blade server on which the virtual machine is running. Distributed VMware vSwitch: This vSwitch is available only with the Enterprise Plus Edition of VMware ESXi hypervisor and can span multiple physical blade servers. In this article, we will cover Nexus 1000V as this is the most commonly used and viable solution in a multiple server/application Cisco Collaboration network where juggling CoS to DSCP and vice-versa is required. Moreover, we will emphasize Cisco UCS’s capabilities to support QoS.   Nexus 1000V – Where and Why Do I Need It? The Nexus 1000V is the edge switch on the virtual access layer and therefore provides a full quality of service (QoS) solution that includes: Traffic classification and marking Traffic policing (rate-limiting) Class-Based Weighted Fair Queuing for congestion management. UCS Fabric Interconnects (FIs) create fibre-channel priority QoS class for traffic destined for the SAN Switch, which is set to FC QoS class that has no drop and marks traffic as CoS 3. With UC applications marking traffic (media and signaling) as L3 DSCP values only, it becomes challenging to prioritize or de-prioritize the traffic when UCS FIs as well as VMware (local or distributed) vSwitches are not designed to map L3 DSCP values to L2 CoS values. This issue is resolved with the help of the Nexus 1000V software switch which  has the ability to map L2 CoS values to L3 DSCP values and vice versa. Example 1-1 illustrates the configuration of Nexus 1000V to map DSCP to CoS (L3 to L2) markings. Example 1-1: Nexus 1000V MQC to Prioritize L3 Traffic Transiting to FI and SAN class-map type qos match-all media-audio   match dscp EF class-map type qos match-any media-video   match dscp CS4   match dscp AF41 class-map type qos match-all signaling   match dscp CS3 ! policy-map type qos voice-qos   class media-audio     set cos 5   class media-video     set cos 4   class signaling     set cos 3 ! port-profile type vethernet  VM_INTERFACES   service-policy type qos input voice-qos   Figure 1-1 depicts the association of Nexus 1000V with vEthernet interface for a VM on VCenter.   So, as you can see, Nexus 1000V makes it very convenient to mark multiple traffic types and, at the same time, preserve the classification while the traffic transits form applications to FI/SAN or vice-versa. However, in case Nexus 1000V is not part of a solution in a UC network, you could create multiple virtual switches and assign a different CoS value for the uplink ports of each of those switches. In other words, each virtual switch would have uplink ports configured with a different CoS value (for example, vSwitch 1 with a CoS value of 5, vSwitch 2 with a CoS value of 4, and so on). In such case, each VM would be assigned to a virtual switch, however, that will limit the traffic to a certain class. This is not a workable solution for Cisco UC on UCS as applications mark different traffic in different classes. Hence, a leading practice recommendation is to leverage Nexus 1000V for end-to-end QoS in a Cisco Collaboration solution.   QoS on Cisco UCS – How Can I Go About It? Cisco UCS also offers the ability to mark traffic in various CoS values. Traffic classification in UCS is done on per vNIC basis. If you want a certain type of traffic to be treated a certain way, it needs its own vNIC(s).With the vNIC or vNIC template, you can configure the QoS policy you wish to put into effect on it. As discussed earlier, Nexus 1000V offers mapping CoS to DSCP and DSCP to CoS when the traffic is ingress and egress respectively to/from UC applications. QOS for the entire UCS Fabric is configured from the UCS Manager. By default 50 percent of the bandwidth is allocated for COS3 traffic. This includes the FCOE traffic (which is marked as COS3) and any other traffic that is marked COS3 value. This queue has a no-drop policy. The remaining 50 percent is best effort for all other traffic. Table 1-2 gives an overview of the different configurable classes in UCS.   Table 1-2: UCS Fabric QoS Classes Figure 1-2 shows the UCS based QoS classes that can be configured to keep CoS consistent across the virtual network. Figure 1-2: Cisco UCS-based QoS Classes   Because leading practice recommends avoiding overlap with voice/video signaling traffic marked as CoS 3, FCoE traffic should be marked at a different CoS value. QoS policies can be created and properties for each policy can be set such that when a policy is applied to a vNIC the traffic is treated per the policy. Figure 1-3 shows the definition of Platinum policy.   Figure 1-3: Cisco UCS-based QoS Policy The challenge with marking traffic in UCS is that multiple traffic classes cannot be linked to VM’s unless each VM is tagged to a specific vNIC. Moreover, the traffic markings are L2 CoS markings only, which still need Nexus 1000V to resolve the markings to L3 DSCP markings and vice-versa.   Summary While virtualization of Cisco Collaboration solutions bring a rich feature set, and data center optimization (power, rack space, management), it also introduces certain key challenges that must be addressed, QoS is one of the major roadblocks if not properly planned and managed. QoS has its own twist and flavor with virtualized UC networks and requires diligent planning and deployment to ensure that the end-users do not feel anything out of place when it comes to voice media and signaling QoS requirements. This article focused on deployment of QoS in virtualized Cisco Collaboration solution; explicitly on Cisco Nexus 1000V and Cisco UCS. Nexus 1000V is an important component of any virtualized UC solution and must be strongly considered for inclusion in design and deployment. Cisco UCS offers QoS however, it is limited in QoS capabilities without support of Nexus 1000V, that enables L2 CoS to L3 DSCP conversion which the FI is unable to perform. Nexus 1000V and UCS together build a strong foundation for enabling QoS in virtualized Cisco Collaboration environments.   Akhil Behl is a Solutions Architect with Cisco Services, focusing on Cisco Collaboration and Security Architectures. He leads collaboration and security projects and service delivery worldwide for Cisco Services and the Collaborative Professional Services (CPS) portfolio. He's played major role in service conception and creation for various services within Cisco Advanced Services. He has Pre-Sales to Sales to Professional Services to Delivery to Post Sales experience with expertise in Consulting, Advisory, and Guidance services. He has extensive experience in Borderless, Collaboration and Data Center portfolio. Prior to his current role, he spent ten years working in various roles at Linksys as a Technical Support Lead, as an Escalation Engineer at Cisco Technical Assistance Center (TAC), and as a Network Consulting Engineer in Cisco Advanced Services. Akhil has a bachelor of technology degree in electronics and telecommunications from IP University and a master’s degree in business administration from Symbiosis Institute. He is dual Cisco Certified Internetwork Expert CCIE # 19564 in Voice and Security. He also holds many other industry certifications, such as PMP, ITIL, VCP, CCNA, CCSP, CCVP, ISO/IEC 27002, TOGAF and CEH. Over the course of his career, he has presented and contributed at various industry forums such as Interop, Enterprise Connect, Cloud Connect, Cloud Summit, Cisco Networkers, and Cisco SecCon. He also has several research papers published in various national and international journals including IEEE. He is the author of Cisco Press books: CCIE Collaboration Quick Reference, and Securing Cisco IP Telephony Networks. He is an avid blogger and maintains blogs @ http://cciecollaboration.blog.com/ and http://ucsecurity.wordpress.com     CCIE Collaboration Quick Reference By Akhil Behl Series: Quick Reference Published: May 20, 2014 ISBN-10: 0-13-384596-6 ISBN-13: 978-0-13-384596-9 Published by Cisco Press.   DISCOUNT: 35% off ciscopress.com for Cisco Technical Newsletter customers; use code CISCOTECH at checkout.   This article is featured in the May 2014 issue of the Cisco TS Newsletter. Are you subscribed?   ... View more

  Introduction     Akhil Behl is a solutions architect with Cisco Services, focusing on Cisco Collaboration and Security architectures. He leads collaboration and security projects and service delivery worldwide for Cisco Services and the Collaborative Professional Services (CPS) portfolio. He has played a major role in service conception and creation for various services within Cisco Advanced Services. He has presales to sales to Professional Services to delivery to post sales experience with expertise in consulting, advisory, and guidance services. He has extensive experience in borderless, collaboration, and data center portfolios. Prior to his current role, he spent 10 years working in various roles at Linksys as a technical support lead, as an escalation engineer at the Cisco Technical Assistance Center (TAC), and as a network consulting engineer in Cisco Advanced Services.   Akhil has a bachelor of technology degree in electronics and telecommunications from IP University and a master's degree in business administration from Symbiosis Institute. He is dual Cisco Certified Internetwork Expert CCIE 19564 in voice and security. He also holds many other industry certifications, such as PMP, ITIL, VCP, ISM, CCNA, CCSP, CCVP, ISO/IEC 27002, TOGAF, and CEH.   Over the course of his career, Akhil has presented and contributed at various industry forums such as Enterprise Connect, Cloud Connect, Cloud Summit, Interop, Cisco Networkers, and SecCon. He has several research papers published in various national and international journals, including IEEE. He is an avid blogger and maintains a blog about unified communications security at http://ucsecurity.wordpress.com.   Akhil is the author of the Cisco Press title “Securing Cisco IP Telephony Networks” (ISBN 1-58714-295-3) http://click.linksynergy.com/fs-bin/click?id=aV8WWcTd0Yc&offerid=145238.10000326&type=3&subid=0   Expert Aashish Jolly was helping Akhil Behl to answer few of the questions asked during the session.   You can download the slides of the presentation in PDF format here. The related Ask The Expert sessions is available here. The complete recording of this live Webcast can be accessed here.     Cisco Unified Communications Manager (CUCM) Certificates & Cisco Unity Connection (UC) Security   Q. What is the function of CAPF? A. Certificate Authority Proxy Function (CAPF) is the core of CUCM security and enables secure signaling with Transport Layer Security (TLS) and secure media with Secure Real-Time Transport Protocol (SRTP) on the CUCM cluster. CAPF enables the endpoints in order to establish secure signaling with the CUCM cluster and SRTP between themselves. CAPF is also the root for the Locally Significant Certificate (LSC).   Q: Does SRTP use symmetric key cryptography? A: SRTP uses asymmetric keys. TLS also uses   Q: What is the difference between the Identity certificate and the Certificate Authority (CA) certificate? A: The CA Certificate is a self-signed certificate generated by a trusted third party (CA). It is used to sign the Certificate Signing Request (CSR) and installed on the client before the signed certificate can be installed. The Identity certificate is a certificate that results from CA signing the CSR, and it is installed on the server. Q: Can you describe the phone downloading certificate process? A: Refer to the IP Phone Security and CTL (Certificate Trust List) document for that information.   Q: When is the Phone-Site Administrator Security Token (SAST)-Trust certificate used? A: The CTL client signs the CTL file with the private key (SAST) from the security token (USB token). As a result the CTL file is created with the CTL client and signed by the Cisco Site Administrator Security Token (SAST) Q: Hostname=FQDN. Does this mean that, when you create servers, you have to use a Fully Qualified Domain Name ( FQDN) instead of IP addresses in order to create a  CUCM cluster? A: When you create a cluster, you enter the IP address if you do not use a Domain Name Server (DNS). If you want to use an external CA in order to sign the certificate of your CUCM node, you need to use the FQDN or the hostname. This further implies that CUCM may not use an FQDN with DNS suffix however, DNS server records be created to resolve CUCM hostname to IP address therefore, avoiding any need for DNS client on CUCM.   Q: If CA can create certificates with IP addresses instead of FQDN, can you keep the IP addresses in CUCM? A: Yes, the Subject Name can be the IP Address. In most cases, subject name is kept at FQDN or hostname and Alt Subject name can be added (if requried) as FQDN/hostname or IP address.   Q: Are certificate chains upload supported by CUCM? A: Certificate chains can be uploaded to CUCM. Refer to the Uploading a Certificate or Certificate Chain section of the Security document.   Q: Do you need to restart the CUCM service after you install Call Manager certificates for secure conferencing? A: Yes, you need to restart the CUCM service. Q: How is the VPN phone certificate affected when a CUCM upgrade is performed? A: I deally the VPN certificate should not expire if a VPN phone works remotely, is connected to the CUCM, and is upgraded. However, if the certificate expires, the phone must be brought back to the enterprise premises, and you can download the new certificate over the trust-established connection. The CUCM upgrade does not impact the VPN phones remotely because the upgrade does not replace any certificates.   Q: Will CUCM support Simple Certificate Enrollment Protocol (SCEP)? A: SCEP is not supported yet and SCEP support isn't on the roadmap.   Q: Online Certificate Status Protocol (OCSP) certificate verification happens only during the certificate upload process. Why does it not occur during the certificate lifetime like all other products that use OCSP, such as the Cisco Identity Services Engine (ISE)? Will this be changed in a future UCM release? A: This is not committed yet. Q: Will CUCM, Cisco Unified Presence Server (CUPS), or Jabber support the Network Device Enrollment Service (NDES) (Microsoft)? Do CUPS, CUCM, or another Cisco application support SCEP? A: These are not supported as of today and not on the Roadmap.   Q: What about SCEP in UC? A: SCEP is not used commonly with Cisco devices/applications and is not currently supported on any UC applications. Q: Is it expected to use SCEP in any UC product? A: There is no SCEP support on any UC application at this time.     Related Information Slides of the Live Webcast Webcast Recording Ask the Expert event Cisco Support Voice community CUCM Administration Guide - Security Release 8.6(1) ... View more

Agenda   An overview of Cisco Unified Communications PKI Insights into Cisco Unified Communications Manager certificates Understanding Cisco Unified Communications Manager certificates & their functions Managing Cisco Unified Communications Manager certificates   Webcast related links: Ask the Expert Event FAQ from the live webcast Slides from the live webcast ... View more

In today’s world, organizations are striving to stay connected with their employees. With businesses going 24X7, no organization can afford to have employees disconnected from the enterprise network and not able to access corporate voice or data resources. Understanding that modern day organizations need secure connectivity for their remote employees as well as telecommuters, Cisco has come out with the concept of VPN client on physical Cisco Unified IP Phone. Yes, you read it right, it’s an SSL client installed on a Cisco IP Phone that enables remote workforce and on-the-go employees to get access to corporate UC resources. Cisco VPN Phone Overview This new feature is called Cisco VPN Phone, and it leverages Cisco AnyConnect SSL client built into an IP phone’s firmware to connect to enterprise edge firewall (Cisco ASA). Cisco VPN Phone feature has numerous benefits,such as: No additional hardware is required by the end-user except for the IP Phone itself. Cisco Unified IP Phone with Cisco VPN client can get online from wherever Internet access is available. Cisco VPN Phone feature is supported with both Cisco ASA and Cisco IOS routers. Cisco VPN Phone can secure voice and video media along with IP Phone service traffic. This gives additional flexibility to go from a voice-only call to a video call. VPN tunnel applies only to voice, video, and IP phone services. The PC connected to PC port is responsible for authenticating and establishing its own tunnel with VPN client software (Split Tunneling) All settings are configured via CUCM administration, thereby providing ease of administration. Figure 1 gives an overview of Cisco VPN Phone solution: Figure 1: Cisco VPN Phone Overview The Cisco Unified IP Phone creates an AnyConnect-based SSL tunnel to Cisco ASA, where all voice pertinent data is sent into the tunnel, whereas all regular data (non-voice traffic) is sent directly to the internet (split-tunnel) for the PC connected behind the IP Phone. When the SSL-tunneled data reaches Cisco ASA, matching the tunnel group, it decrypts the traffic and sends unencrypted traffic to CUCM (signaling as SCCP) and to the IP Phone within enterprise (media as RTP). Cisco VPN Phone Configuration Prerequisites There are certain pre-requisites that must be met before Cisco VPN Phone can be configured on a Cisco ASA and subsequently on a CUCM cluster. Cisco VPN Phone client is supported on 7942G, 7945G, 7962G, 7965G, 7975G, and 99xx and 89xx series IP phones. For a list of phones supported with your CUCM version, you can check Feature: Virtual Private Network Client from CUCM Administration GUI > Cisco Unified Reporting > System Reports > Unified CM Phone Feature List > Generate a new report option. The minimum requirements for support Cisco VPN Phone are as following: CUCM version 8.0.1 or above are supported. IP Phone SCCP firmware version 9.0(2) SR1S or later Cisco ASA IOS 8.0.4 or later Anyconnect VPN Pkg 2.4.1012 or later Two licenses,  i.e. a premium AnyConnect license and AnyConnect for Cisco VPN Phone license is required for Cisco ASA. The part number for AnyConnect for Cisco VPN Phone is L-ASA-AC-PH-55XX (55XX is firewall model number such as 5505, 5510, 5580 and so on). Detailed Steps to Configure Cisco VPN Phone Step 1.  Ensure that ASA Security Appliance Software version is 8.0(2) or greater UCASA# show version Cisco Adaptive Security Appliance Software Version 8.2(2)99 Device Manager Version 6.3(1) Step 2. Confirm ASA is licensed for Cisco AnyConnect VPN Phone and AnyConnect Software 2.0 or greater is installed in flash. UCASA#show disk0: <output ommited> 140 2154944 Mar 18 2013 03:38:06 anyconnect- win-3.1.00495-k9.pkg Step 3. Generate self signed certificate on cisco ASA. UCASA (config)# crypto key generate rsa label vpnphone UCASA (config)# crypto ca trustpoint asatrust UCASA (config)# encrollment self UCASA (config)# fqdn sslphone.cisco.com UCASA (config)# subject-name CN=sslphone.cisco.com UCASA (config)# keypair vpnphone UCASA (config)# crypto ca enroll asatrust noconfirm UCASA (config)# ssl trust-point asatrust outside Step 4. Enable AnyConnect access on the interface that will terminate SSL VPN Connections. UCASA (config)# webvpn UCASA(config-webvpn)# enable outside UCASA(config-webvpn)# svc enable Step 5. Create a VPN Pool for assigning the VPN Phones unique IP addresses. UCASA(config)# ip local pool SSLPool 192.168.250.1 - 192.168.250.254 mask 255.255.255.0 Step 6. Create a Group Policy, which specifies the configuration parameters that will be applied to the clients when they connect to Cisco ASA. UCASA(config)# group-policy SSLVPNPhone internal UCASA(config)# group-policy SSLVPNPhone attributes UCASA(config-group-policy)# dns-server value 10.60.70.80 UCASA(config-group-policy)# vpn-tunnel-protocol svc UCASA(config-group-policy)# default-domain value cisco.com UCASA(config-group-policy)# address-pools value SSLPool Step 7. Create a Connection Profile and Tunnel Group for the AnyConnect Client Connections, and assign an alias. UCASA(config)# tunnel-group SSLPhone type remote-access UCASA(config)# tunnel-group SSLPhone general-attributes UCASA(config-tunnel-general)# default-group-policy SSLVPNPhone UCASA(config-tunnel-general)# tunnel-group SSLPhone webvpn-attributes UCASA(config-tunnel-webvpn)# group-alias SSLPhoneClient enable UCASA(config-tunnel-webvpn)# group-url https://10.81.80.200/VPNPhone enable Step 8. Enable alias/tunnel group selection for SSL VPN Connections. UCASA(config-tunnel-webvpn)# webvpn UCASA(config-webvpn)# tunnel-group-list enable Step 9. Add user(s) to ASA local DB or use the  TACACS+/RADIUS backend (if available). UCASA(config)# username vpnclient password C1sc0123 UCASA(config)# username vpnclient attributes UCASA(config-username)# service-type remote-access Step 10. Export the ASA crypto certificate and save it as a .pem file on your laptop/PC. UCASA(config)# crypto ca export vpnphone identity-certificate The PEM encoded identity certificate follows: -----BEGIN CERTIFICATE----- MIIB8zCCAVygAwIBAgIEAoMjTTANBgkqhkiG9w0BAQUFADA+MRowGAYDVQQDExFl <output omitted> -----END CERTIFICATE----- Step 11. Upload the ASA Certificate on CUCM. Go to Cisco Unified OS Administration > Security/Certificate Management Select "Upload Certificate" Upload the ASA certificate to "Phone-VPN-Trust" Figure 2: Cisco ASA to CUCM Certificate Upload Step 12. Go to CUCM Administration > Advanced Features > VPN > VPN Gateway. Select the certificate that was uploaded earlier from ASA to CUCM, and ensure it’s listed under VPN gateway certificates. Figure 3: CUCM VPN Gateway Configuration Step 13. Go to CUCM Administration > Advanced Features > VPN > VPN Group. Under VPN Gateway Information, add the VPN Gateway created earlier. Figure 4: CUCM VPN Group Configuration Step 14. Go to CUCM Administration > Advanced Features > VPN > VPN Profile. Ensure that the client authentication method is set to ‘user and password’ (similar to what was configured in Cisco ASA). Figure 5: CUCM VPN Profile Configuration Step 15. Go to CUCM Administration > Device > Device Settings > Common Phone Profile. Assign ‘Common Phone Profile’ to VPN phone. Cisco VPN Phone configuration is now complete. After connecting the phone from within the enterprise environment, the IP Phone can be handed over to the user. The end user has multiple options to connect to VPN on Cisco Unified IP Phone: The user can select between VPN client (mode) enabled or disabled in the phone menu. With disabled mode on the VPN client; the phone makes no attempt to create a VPN connection and proceeds with the standard startup sequence. With enabled mode on the VPN client (and auto-network detection) the phone tries to detect the type of network and attempts to initiate a VPN connection only if the phone is outside of the enterprise network i.e. on a public network. With enabled mode on the VPN client and auto-network detection disabled the phone attempts to initiate a VPN connection. This allows the VPN connection to be established within the secure enterprise network. The following figure gives an overview of user end configuration to initiate a VPN connection from IP Phone: Figure 6: End USer VPN Phone -- VPN Connection Initiation Summary Cisco VPN Phone is a promising feature that is easy to deploy and maintain. It gives end users the flexibility to connect to the enterprise network and leverage voice resources from anywhere; wherever there is Internet connectivity. Moreover, it’s a solution that replaces older Phone Proxy and the need to have a VPN client side hardware, thereby reducing complexity of deploying a remote worker solution and helping lower costs. Author's Biography Akhil Behl is a Solutions Architect with Cisco Services, focusing on Cisco  Collaboration and Security Architectures. He leads collaboration and  security projects and service delivery worldwide for Cisco Services and  the Collaborative Professional Services (CPS) portfolio. He's played  major role in service conception and creation for various services  within Cisco Advanced Services. He has Pre-Sales to Sales to  Professional Services to Delivery to Post Sales experience with  expertise in Consulting, Advisory, and Guidance services. He has  extensive experience in Borderless, Collaboration and Data Center  portfolio. Prior to his current role, he spent ten years working in  various roles at Linksys as a Technical Support Lead, as an Escalation  Engineer at Cisco Technical Assistance Center (TAC), and as a Network  Consulting Engineer in Cisco Advanced Services. Akhil  has a bachelor of technology degree in electronics and  telecommunications from IP University and a master’s degree in business  administration from Symbiosis Institute. He is dual Cisco Certified  Internetwork Expert CCIE # 19564 in Voice and Security. He also holds  many other industry certifications, such as PMP, ITIL, VCP, ISM, CCNA,  CCSP, CCVP, ISO/IEC 27002, TOGAF and CEH. Over the  course of his career, he has presented and contributed at various  industry forums such as Enterprise Connect, Cloud Connect, Cloud Summit,  Interop, Cisco Networkers, and SecCon. He has several research papers  published in various national and international journals including IEEE. He is an avid blogger and maintains a blog on Unified Communications Security - http://ucsecurity.wordpress.com Securing Cisco IP Telephony Networks Series: Networking Technology: IP Communications Published: Aug 31, 2012 Copyright 2012 ISBN-10: 1-58714-295-3 ISBN-13: 978-1-58714-295-6 Published by Cisco Press This article is featured in the December 2013 issue of the Cisco TS Newsletter. Are you subscribed? ... View more

Now that your Cisco world class Collaboration Network is set up and functional, it is time to leverage the benefits of the Unified IP environment. With reduction in Total Cost of Ownership (TCO), leveraging converged network for transporting both voice and data and increased Return on Investment (ROI), what can possibly go wrong? Well, if you didn’t think in a holistic way while setting up the management aspect of your Collaboration network, a lot can go wrong. With things on the move, you should concentrate on making sure they keep going as planned. That is, ensure that you have a plan to securely manage the vital assets of your organization’s communications channels. More often than not, the topic of “secure management” does not come up as early as it should in most network management discussions. Reasons can vary, such as – lack of support from higher management (monetary or manpower) or lack of insight or experience about what goes into secure management of a Collaboration network. With that said, a Secure Collaboration Network can be achievable only if network management is secured. All in all, if a true collaboration experience is to be achieved, it can be only by way of well-rounded security strategy, and secure network management is an indispensable part of any security strategy. A Collaboration network’s secure management can be looked upon as a task to move away from unsecure management protocols to standards-driven secure management protocols. The following sections discuss the importance of switching from relatively unsecure or weak security posture management protocols to comparatively secure management protocols. Something’s Just Not Right! Until now many organizations still stick with clear text, and in turn, vulnerable protocols for managing their Collaboration networks. The burning question is – why use an insecure protocol at all? The answer is pretty straight forward –a default clear text protocol doesn’t require any special software at Network Management Station (NMS) nor any special configuration at the device being managed. While this may sound great at first, it’s not a leading practice or a recommendation for managing an organization’s Collaboration network. Did Someone Say Telnet? A few protocols deserve special mention here, which are still used whence their usage should be a thing of past. Telnet is one of those protocols that is used very frequently despite the fact that it is as good as leaving a device open to access with any authentication. Being clear text, telnet sessions can be sniffed and username and password can be used to gain access to the device being managed. In essence, it’s serving the access control to network devices on a silver platter to attackers/hackers. Who’s Using FTP? Similar to telnet, is File Transfer Protocol (FTP). Primarily used for transferring files e.g. IOS firmware, it’s a popular choice of management protocol for Cisco IOS routers and switches. While FTP can be secured by enforcing use of username and password (not leaving system exposed for anonymous access), the default unencrypted mode of FTP leaves it vulnerable to sniffing and Man-In-The-Middle (MITM) attacks. An insider or an external attacker can exploit and compromise the equipment being managed, by manipulating files as desired or by injecting code into files being transferred. More so, the attacker can still sniff the FTP stream for username and password (as it is unencrypted) and can start a new FTP session to the managed device. To SNMP or Not to SNMP? Simple Network management Protocol (SNMP) is one of the most popular and widely used network monitoring and notification protocol. SNMP can be deployed in various versions ranging from v1 to v2c to v3. If SNMP version is below version 2c, it is not the safest of options SNMP v1 has no data authentication or encryption capability, which leaves it wide open to attacks e.g. MITM attack. Both the device being managed and the NMS station can be compromised by a determined hacker/attacker. While SNMP v2c is not entirely secure; in that it doesn’t provide encryption abilities, it does offer authentication mechanism to keep nosy audiences out. Now We are Getting Somewhere! This section focuses on secure management protocols and their configuration for Cisco Collaboration network. Why Didn’t I Use SSH to Begin With? So, if Telnet is a high priority risk what are the alternatives? How about Secure Shell (SSH)? As a trustworthy protocol, SSH helps thwart all security risks associated with Telnet. SSH is secure by its very nature, being driven off RSA and can be configured very easily on Cisco gear, not to mention, it is now the default choice to access any appliance based server’s CLI. For configuring SSHv2 (yes, we’ll talk about v2, which is more secure) for a Cisco IOS device such as a router or a switch, you’ll need to do the following: Example 1: Enabling SSH on Cisco IOS Router UCRouter(config)# ip domain-name mydomain.corp UCRouter(config)# ip ssh version 2 UCRouter(config)# crypto key generate rsa usage-keys exportable modulus 1024 ! UCRouter(config)# aaa new-model UCRouter(config)# aaa authentication login default local UCRouter(config)# aaa authorization exec default local ! UCRouter(config)# username nmsuser privilege 15 password 0 C1sc0123 ! UCRouter(config)# ip ssh time-out 120 UCRouter(config)# ip ssh authentication-retries 3 Who Needs FTP When I Have SCP and SFTP! A viable and secure replacement for FTP exists as Secure Copy Protocol (SCP) and Secure File Transfer Protocol (SFTP). SCP handles the file transfer and relies on the SSH protocol to provide authentication and security for both user credentials and data. SCP basically tunnels Remote Copy (RCP) over SSH tunnel. You can enable SCP server on Cisco IOS switches and routers to transfer firmware or any other files, securely. The following example outlines IOS configuration to enable SCP transfer: Note: Since SCP leverages SSH, we need the commands used in previous example for configuring SSH before configuring SCP. Example 2: Enabling SCP Server on Cisco IOS Router UCRouter(config)# ip scp server enable At this time the Cisco IOS device is ready to accept an incoming session from an SCP client machine, which can be setup as shown in figure 1. For the following example WinSCP client is used, which is a free SCP client. Figure 1: WinSCP client configuration Similar to SCP, SFTP also leverages SSH to provide a secure service, allowing the application server to encrypt the data and the file transfer. Cisco UC applications, such as CUCM, CUC, CUPS, and so on, only support SFTP for secure image, update, locale, and phone firmware transfer. WinSCP can also act as an SFTP client. Just a flip of the “file protocol” option from SCP to SFTP and you have a working SFTP client. With SNMPv3, You Just Can’t Go Wrong! From SNMP perspective, SNMPv3 provides an application-level authentication and encryption capability that is not provided by either of other two flavors. While one could use SNMP v1 or v2c over IPSec tunnels, it is neither a scalable nor an supple solution. SNMPv3 does an excellent job to secure the data transferred between two or more entities and the NMS by enabling you to apply authentication (MD5, SHA) and encryption (DES, 3DES, AES). As of today, almost all Cisco IP Telephony applications and all the underlying infrastructure components such as routers, switches, and gateways etc. provide support for SNMPv3. Following is a snippet of SNMPv3 configuration on Cisco IOS router: Example 3: Cisco IOS router SNMPv3 Configuration UCRouter(config)#SNMP-Server view NMSManager system included UCRouter(config)#SNMP-Server group SNMPv3Group v3 priv Read NMSManager Write NMSManager UCRouter(config)#SNMP-Server user SNMPv3User SNMPv3Group v3 auth MD5 C1sc0123 priv DES C1sc0123 The following figure shows the basic construct of Cisco Unified Communication Manager (CUCM) SNMPv3 user: Figure 2: CUCM SNMPv3 user creation Summary A Cisco Collaboration network deserves to be managed as securely as it is expected to deliver. For managing the Cisco Collaboration network, infrastructure and applications ensure you do fair bit of planning before actually start managing the solution. A Collaboration solution can be built to serve users and provide resilient, supple, and robust services provided, it’s management is secure. Author's Biography Akhil Behl is a Solutions Architect with Cisco Services, focusing on Cisco Collaboration and Security Architectures. He leads collaboration and security projects and service delivery worldwide for Cisco Services and the Collaborative Professional Services (CPS) portfolio. He's played major role in service conception and creation for various services within Cisco Advanced Services. He has Pre-Sales to Sales to Professional Services to Delivery to Post Sales experience with expertise in Consulting, Advisory, and Guidance services. He has extensive experience in Borderless, Collaboration and Data Center portfolio. Prior to his current role, he spent ten years working in various roles at Linksys as a Technical Support Lead, as an Escalation Engineer at Cisco Technical Assistance Center (TAC), and as a Network Consulting Engineer in Cisco Advanced Services. Akhil has a bachelor of technology degree in electronics and telecommunications from IP University and a master’s degree in business administration from Symbiosis Institute. He is dual Cisco Certified Internetwork Expert CCIE # 19564 in Voice and Security. He also holds many other industry certifications, such as PMP, ITIL, VCP, ISM, CCNA, CCSP, CCVP, ISO/IEC 27002, TOGAF and CEH. Over the course of his career, he has presented and contributed at various industry forums such as Enterprise Connect, Cloud Connect, Cloud Summit, Interop, Cisco Networkers, and SecCon. He has several research papers published in various national and international journals including IEEE. He is an avid blogger and maintains a blog on Unified Communications Security - http://ucsecurity.wordpress.com Securing Cisco IP Telephony Networks Series: Networking Technology: IP Communications Published: Aug 31, 2012 Copyright 2012 ISBN-10: 1-58714-295-3 ISBN-13: 978-1-58714-295-6 Published by Cisco Press This article is featured in the November 2013 issue of the Cisco TS Newsletter. Are you subscribed? ... View more