A Standards-Based Approach for Offering a Managed Security Service in a Multivendor Network Environment
As transport becomes a commodity, service providers are seeking new revenue sources and new ways to differentiate themselves. Managed security services address a growing market because business customers are struggling to comply with regulatory requirements such as the Payment Card Industry-Data Storage Standards (PCI-DSS), the Sarbanes-Oxley Act, the Gramm-Leach Bliley Act, Health Insurance Portability and Accountability Act (HIPAA), Directive 2002/58/EC, and the Asia-Pacific Economic Cooperation-Organization for Economic Cooperation and Development (APEC-OECD) initiative on regulatory reform. Increasingly, business customers recognize that outsourcing network security is less costly than staffing with highly specialized security personnel who can provide 24-hour incident detection and response. Another incentive for outsourcing is to free existing IT resources to focus on the core business. A standards-based approach helps service providers take best advantage of the managed security service opportunity because it increases the potential breadth and depth of the service offering. Multivendor solutions are becoming the norm when deploying services on an integrated backbone. Therefore, standards simplify deployment and management, helping control operational costs and accelerating time to market. Service providers are experiencing a growing need for skilled engineers who understand multivendor environments—the motivation for conducting a multivendor security workshop at the 2006 Asia Pacific Regional Internet Conference on Operational Technologies (APRICOT 2006) [15], held in Perth, Australia, in February 2006. During the workshop (which was repeated again at APRICOT 2007 in Bali), participants successfully deployed and tested a multivendor service environment using IP Security (IPsec)-based Layer 3 Virtual Private Networks (VPNs) [1, 2, 3] over a Border Gateway Protocol/Multiprotocol Label Switching (BGP/MPLS) core [4]. Technical ChallengesTo offer managed security services, service providers need the following:
An effective managed security service requires tools and techniques to address the following challenges:
Infrastructure Security in Multivendor EnvironmentsSecuring the service provider infrastructure requires the following common best practices:
Point ProtectionBefore offering a managed security service, providers need to protect the backbone; security operations center or network operations center; Authentication, Authorization, and Accounting (AAA) [10, 11] server; and remote-access networks. Securing individual network devices requires enforcing AAA, controlling the type of packets destined to network devices, and performing regular configuration audits to ensure that no unauthorized changes have been made. Best common practices include:
It is strongly recommended that service providers use TACACS+ [13] authentication rather than Remote Authentication Dial-In User Service (RADIUS) [12] authentication. With RADIUS, traffic is sent in the clear between the AAA servers and network devices using the User Datagram Protocol (UDP), which defeats the use of SSH to encrypt logins and passwords. Open-source implementations of TACACS+ are available.
Traditionally, service providers enforced policy at the process level, using vty ACLs, Simple Network Management Protocol (SNMP) ACLs, and others. Some service providers used ingress ACLs when possible. Today, it is far preferable to stop DoS traffic at ingress points: the peer edge, downstream and upstream routers, colocated network devices, and the customer access edge, enabling central policy enforcement and more granular protection schemes. In addition, many network devices at the network edge have hardware acceleration, which provides far more robust resistance to attack than the process level. Edge ProtectionIn many service provider networks, each core router is individually secured but still accessible to outsiders using SNMP or Telnet. Now service providers can supplement individual router protection with infrastructure protection that prevents undesired traffic from ever touching the infrastructure. The following steps help protect the network edge (Figure 1):
Infrastructure packet filters at the edge of the network protecting the infrastructure are an effective first layer of defense. Service providers need additional forms of infrastructure protection for their older routers that do not support infrastructure packet filters and for packets that cannot be filtered with infrastructure packet filters. Remote Triggered Black Hole FilteringRemote Triggered Black Hole Filtering (RTBH) is among the most effective reaction and mitigation tools for DoS, Distributed DoS (DDoS), and backscatter tracebacks. It enables service providers to quickly drop DoS traffic at the network edge (Figure 2). Rather than sending commands to every router to drop DoS or other problem traffic, the service provider can deploy a trigger router that uses BGP to signal all other routers—just as fast as iBGP can update the network. In destination-based RTBH, all traffic headed to the destination under attack is dropped—the good traffic as well as the bad. In source-based RTBH, traffic from all or certain sources are blocked. The advantage of sourced-based RTBH is that service providers can whitelist certain addresses, such as the Network Operations Center (NOC) or route-name servers, so that they can continue providing services. Source Address Validation on all Customer TrafficSource address validation, defined in Best Current Practices (BCP) 38 [8], prevents service provider customers from spoofing traffic—that is, sending IP packets out to the Internet with a source address other then the address allocated to them by the service provider. Best practices from BCP 38 are to filter as close to the edge as possible, filter precisely, and filter both the source and destination address when possible. Every access technology has antispoofing mechanisms derived from BCP 38:
To gain operational confidence in BCP 38, service providers can take a phased approach—for example, implementing it first on one port, then on a line card, then on an entire router, and then on multiple routers. Control-Plane ProtectionProtecting the infrastructure control plane helps prevent an attacker from taking down a BGP session and thereby causing denial of service. The exploits a service provider needs to prevent include saturating the receive-path queues so that BGP times out, saturating the link so that the link protocols time out, dropping the Transmission Control Protocol (TCP) session, and dropping the Interior Gateway Protocol (IGP), which causes a recursive loop-up failure. Following are techniques for control-plane protection.
Visibility into Network ActivityTo gain visibility into the network for early detection of security incidents, service providers can use open-source tools to analyze flow-based telemetry data, which is retrieved from routers and switches. Open-source tools for visibility into security incidents include RRDTool, FlowScan, Stager, and NTOP Remote Monitoring (RMON). These tools provide information such as packets per second, bits per second, and traffic types. For example, RRDTool shows the number of Domain Name System (DNS) queries per second, according to record type. A spike in Mail Exchange (MX) Record queries might indicate that a customer's router has been compromised and is being used as a spam proxy. Similarly, a sharp increase in round-trip-time latency might indicate a DoS attack. MPLS Security in a Multivendor EnvironmentIn addition to securing the infrastructure, managed security service providers need to secure packets as they travel from one customer-edge router to another—regardless of the equipment the customer uses at the edge. Layer 3 VPNs meet this need. RFC 4364, which replaced RFC 2547bis, defines a BGP/MPLS IP VPN that creates multiple virtual routers on a single physical router: one virtual router for each customer. In BGP/MPLS VPNs, Customer Edge (CE) routers send their routes to the Service Provider Edge (PE) routers. Customer edge routers at different sites do not peer with each other, and the customer's routing algorithms are not aware of the overlay. Data packets are tunneled through the backbone so that the core routers do not need to know the VPN routes. BGP/MPLS IP VPNs support either full mesh or partial mesh, although full mesh is more cost-effective. A unique advantage of BGP/MPLS VPNs is that two service provider customers with overlapping IP addresses can connect across the service provider backbone. The router distinguishes between traffic from different companies by examining the label at the beginning of the packet, and then instantly forwards the traffic based on the Label Switching Path (LSP) that has been established for each customer's VPN. Eliminating the need to look at the packet in depth enables faster forwarding. That is, the service provider core does not impose any latency as packets pass between the provider edge routers. IPsec Security in a Multivendor EnvironmentIn addition to or instead of deploying a BGP/MPLS IP VPN, the service provider can extend its service to other partner provider networks using IPsec. The options are to use MPLS alone, IPsec alone, or a combination (Figure 3 on page 12). A retail customer that needs to comply with PCI-DSS, for example, needs IPsec or Secure Sockets Layer (SSL) encryption for payment card transaction data as part of its managed security service. Table 1 summarizes the process based on the option the service provider selects. In the table, VPNA refers to one customer's VPN on a router that hosts VPNs for multiple customers. Table 1: Comparing Packet Flow in IPsec VPNs, BGP/MPLS VPNs, and Combination VPNs
Six-Step MethodologyService providers can detect and mitigate attacks on the infrastructure using a six-step incident-response methodology (Figure 4).
Real-Life Observations About Interoperability from the APRICOT WorkshopsCisco and Juniper conducted a multivendor security workshop at APRICOT 2006 in Perth, Australia, and again at APRICOT 2007 in Bali, Indonesia. The workshops were offered in response to the fact that service providers often deploy a multivendor network for reasons ranging from financial to political. Hands-on workshops were conducted in a lab using 12 routers running the Cisco IOS Software and another 12 running JUNOS software. Topics included:
The goal of the workshops was to achieve a working configuration that interoperated with JUNOS and the Cisco IOS Software, resulting in consistent technology implementation, as well as common security policy enforcement. The workshops underscored the fact that interoperability is not automatic—even among standards-based network products. The reason is that standards bodies such as IETF, ITU, IEEE, and others define some aspects of protocols but leave others to vendor discretion. Standards do define protocol format, which is a syntactical structure identifying bit-field definition, length, and more. They also define protocol behavior, which specifies when actions occur, such as sending Hello and Keepalive timer probes and handling retransmission and reset packets. For purposes of analogy, a spoken language such as English is like a protocol format, and polite conversation conventions, such as beginning with a greeting and concluding with goodbye, is like a protocol behavior. What standards do not cover are vendor-specific internal implementations, such as software coding techniques, hardware acceleration for performance, command-line interface (CLI) structure, and so on. Therefore, even though the APRICOT workshops involved deploying standards-based technology such as BGP-based MPLS VPNs and IPsec, vendor-specific differences had to be accounted for in the workshop materials and were noticed by participants. Following are examples noted at the APRICOT workshop:
Although these subtle differences in protocols are documented by the vendors, service provider operational teams often have little time to research them. Therefore, it can be valuable for them to participate in multivendor hands-on workshops. Anecdotal evidence suggests that operators who are comfortable with multiple vendors understand the protocols, helping them design networks that can support new, revenue-generating services. It is hoped that events such as the APRICOT workshops will help build a community of professionals who can add value for their employers, each other, and the broader Internet community. The result will be a secure and trusted networking environment that people and industry can rely on and useto connect in new and innovative ways. SummaryManaged security services represent a growing revenue opportunity for service providers. Most service providers operate in a multivendor environment, either because of mergers and acquisitions or because their customers use other vendors' equipment. Therefore, a standards-based approach positions providers to capitalize on the managed security service opportunity. Providers can secure their infrastructure in a multivendor environment by following best practices for point protection, edge protection, RTBH protection, source-address validation, control-plane protection, and total visibility into network activity. References[1] S. Kent and R. Atkinson, "Security Architecture for the Internet Protocol," RFC 2401, November 1998. [2] S. Kent and R. Atkinson, "IP Authentication Header," RFC 2402, November 1998. [3] S. Kent and R. Atkinson, "IP Encapsulating Security Payload (ESP)," RFC 2406, November 1998. [4] E. Rosen and Y. Rekhter, "BGP/MPLS VPNs," RFC 2547, March 1999. [5] S. Hanks, T. Li, D. Farinacci, and P. Traina, "Generic Routing Encapsulation (GRE)," RFC 1701, October 1994. [6] Y. Rekhter, B. Moskowitz, D. Karrenberg, G. J. de Groot, and E. Lear, "Address Allocation for Private Internets," RFC 1918, February 1996. [7] Internet Assigned Numbers Authority (IANA), "Special-Use IPv4 Addresses," RFC 3300, September 2002. [8] F. Baker and P. Savola, "Ingress Filtering for Multihomed Networks," RFC 3704, March 2004. [9] D. Harkins and D. Carrel, "The Internet Key Exchange (IKE)," RFC 2409, November 1998. [10] Convery, S., "Network Authentication, Authorization, and Accounting — Part One: Concepts, Elements, and Approaches," The Internet Protocol Journal, Volume 10, No. 1, March 2007. [11] Convery, S., "Network Authentication, Authorization, and Accounting — Part Two: Protocols, Applications, and the Future of AAA," The Internet Protocol Journal, Volume 10, No. 2, June 2007. [12] Rigney et. al., "Remote Authentication Dial-In User Service (RADIUS)," RFC 2865 (Obsoletes RFC 2138, and RFC 2058), June 2000. [13] Carrel et al., "The TACACS+ Protocol Version 1.78," Internet Draft, Work in Progress, draft-grant-tacacs-02.txt, January 1997. KUNJAL TRIVEDI joined Cisco in 1999 as a consulting engineer initially and then worked in product management covering Cisco IOS Software infrastructure security. Currently, he is helping Cisco shape a Managed Security Services marketing vision and strategy. A widely respected networking security expert, Kunjal presents infrastructure security, IP Security, and Managed Security topics at Cisco Networkers events as well as at conferences such as APRICOT. Kunjal has a Bachelor of Engineering degree with honors in electrical and electronics engineering from University of Wales, College of Cardiff, and a Master of Science degree in Artificial Intelligence from Cranfield Institute of Technology, UK. He holds CISSP and CCIE designations in routing and switching as well as security. Recently, he published a book titled [Read Me First]: Building or Buying VPNs; Kunjal has been awarded Chartered Engineer status by Institute of Engineering and Technology. He can be reached at kunjal@cisco.com DAMIEN HOLLOWAY joined Juniper Networks in 2004 as an Instructing Engineer. He contributes to the development of the Juniper Technical Certification Program and custom delivery of training in the Asia Pacific region. Previously he was a consulting engineer and provided design, installation, and training to providers in Australia and the United States. Damien has presented a wide variety of topics relevant to customers, including backbone design, application acceleration, and Broadband Remote Access Server edge design, to audiences, including APRICOT and SANOG. Damien has a Bachelor of Electrical Engineering and Bachelor of Science from University of Sydney, Australia. He is a CCIE expert in routing and switching and JNCIE-M, JNCIP-E, and CISSP. He can be reached at holloway@juniper.net |
||||||
![]() |