Best Practices for Securing Service Provider Networksibest.ee › documentation › Juniper › T Series › Best Practices for Secu… · ii Copyright © 2009, Juniper Networks,

WHITE PAPER

Copyright © 2009, Juniper Networks, Inc.

Best Practices for securing service Provider networks

Protecting Infrastructure and Managing Customer Security

ii Copyright © 2009, Juniper Networks, Inc.

wHite PaPer - Best Practices for securing service Provider networks

Table of Contentsexecutive summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

the network’s greatest strength is its greatest weakness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

spam as social engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

Managed security services as strategic Purchases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

securing the network infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

the role of administrative Practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

Securing the Router’s Control and Data Planes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Making Routers Invisible: Filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Line Rate Packet Filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Stringent Packet Classification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Nested and Chained Filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Advanced Packet Filtering and Scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Making Routers Untouchable: Traffic Shaping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Protecting the Network from Infected Hosts: Stateful Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Securing Routing Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Securing IP/MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

securing users and servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Profitable Security: Managed Security Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Protecting Users and Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Using Unicast RPF to Verify Source Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Implementing Real Time Traffic Analysis and Stateful Firewall Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

implementing Policy on the network control Plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Using Dynamic Threat Mitigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Mitigating Attacks Using BGP Distributed Traffic Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Juniper Networks Web Casts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Juniper Networks White Papers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Network Reliability and Interoperability Council (NRIC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

North American Network Operators’ Group (NANOG) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Operational Security for Large ISP IP Network Infrastructure (RFC 3871) . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

OPSec: Operational Security Capabilities for IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

about Juniper networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Copyright © 2009, Juniper Networks, Inc. iii


Table of Figuresfigure 1: corporate and branch office network infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

figure 2: vulnerability of the control plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

figure 3: flowchart logic for nested and chained filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

figure 4: effect of icMP ping traffic rate limiting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

figure 5: unicast rPf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

figure 6: secure, virtualized core network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

figure 7: volume-based dynamic threat mitigation using src . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

figure 8: BgP distributed firewall filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Copyright © 2009, Juniper Networks, Inc. 1


Executive SummaryTo thrive in today’s economy, service providers must provide open, easily accessible communications services that enable their end users to contact anyone worldwide. The same open, freely scalable communication architecture that provides unlimited communications services to your end users also poses an extremely attractive target to hackers who would abuse that open access for their own financial advantage.

Worldwide ownership of today’s networking platforms means that there is little meaningful enforcement to deter hackers. With few consequences to hackers for their attacks, most of the burden—financial and otherwise—is borne by service providers and their customers.

As a result, security has become increasingly important over the last several years. The question is no longer, How often is your network under attack? Rather, the question is—How many attacks are you under right now? Because networks are continuously under attack, the defenses have to be available continuously. That means network operators must be able to manage their networks securely while continuing to provide service to their customers.

Because security is a long-term issue, service providers need a security strategy and a staff that is well educated in that strategy. To that end, this paper discusses tools and practices that are indispensable to network operators in securing their networks against denial of service (DoS) attacks and other common security threats. It also discusses ways in which service providers can turn those necessary security protections into profitable managed security services for their enterprise customers. Finally, it provides a bibliography of some of the research that has been done in the area of best practices for service provider security. Much of this research is documented in the form of RFC and other Internet draft documents. Links to these and other helpful security resources are provided at the end of this paper.

OverviewToo often, security and performance are seen as competing aspects of networking—with security improvements often coming at the cost of degrading performance. In today’s environment, that can no longer be the case.

To safeguard their networks without sacrificing performance, service providers need to deploy equipment that can provide the advanced protections they need. Key among them are line rate packet filtering capabilities (sometimes to the tune of over 100,000 entries, particularly for content service providers) and the ability to dynamically augment and propagate packet filters during a debilitating attack. It is also valuable to have traffic shaping capabilities that include the ability to rate limit traffic and place it into prioritized queues on both the control planes and data planes of routers. Finally, service providers need a security toolkit that includes automation on the policy layer of the network to help mitigate threats dynamically. Tools to achieve this can be found in both specialized service delivery points and in routing software.

Security is not just a question for network service providers, however. Enterprise customers also need to open their networks to their branch offices, remote workers, business partners, suppliers, vendors, and even customers to facilitate business operations, while safeguarding their vital business and financial information from hackers and other unauthorized users.

Security breaches can lead to significant financial losses for your customers. A 2005 Infonetics Research report estimated that annual network downtime costs for enterprises averaged 3.6 percent of revenues. While some of that downtime is undoubtedly related to equipment failures, the prospect of suffering network downtime due to security breaches is a powerful motivator for enterprises to consider boosting network security. At the same time, legislation such as HIPAA, Gramm-Leach-Bliley, and Sarbanes-Oxley in the U.S. and similar measures in countries worldwide is putting pressure on enterprises to implement new policies to better manage private information. These factors, paired with the costs of implementing 24 x 7 x 365 network monitoring and the constant discovery of new network vulnerabilities, are leading to an increased reluctance in enterprises to rely solely on in-house security solutions.

Most enterprises, especially larger ones, now see managed security services as being a critical component of their future business operations1. These managed security services can range from asking a service provider to supplement an existing security feature to the enterprise relinquishing full control of their network security to their service provider partner. Whatever the level of service provider involvement, offering managed security services—including firewalling, intrusion detection and prevention, and dynamic threat mitigation—to enterprise customers is big business.

1Heavy Reading, “Survey of Enterprise Purchasing Plans,” Vol. 2, No. 28, December, 2004.

2 Copyright © 2009, Juniper Networks, Inc.


As a result, by deploying equipment with advanced security capabilities today, operators are both securing their own network infrastructure and laying the foundation for a new set of profitable, revenue-generating services. Achieving this, however, requires that compatible security functionality be available across the portfolio and already designed for use supporting subscriber-based security services. Only Juniper Networks® provides this complete suite of functionality across every network element available to service providers2.

The Network’s Greatest Strength Is Its Greatest WeaknessTo thrive in today’s economy, service providers must provide open, easily accessible communications services that enable their end users to contact anyone worldwide. Your enterprise customers are in a similar situation. They too need to open their networks to their branch offices, remote workers, business partners, suppliers, vendors, and even customers to facilitate business operations, while safeguarding their vital business and financial information from hackers and other unauthorized users.

The same open, freely scalable communication architecture that provides unlimited communications services to your end users and their business partners also poses an extremely attractive target.

Networking services that are economically affordable for end users to access by definition pose a low barrier to entry for hackers who would abuse that access. Our reliance on widely distributed common computing platforms creates significant vulnerabilities. If even one virus successfully penetrates today’s widely distributed common computing platforms, that virus can infect up to 1 million hosts.

Meanwhile, worldwide ownership of today’s networking platforms means that there is little meaningful deterrence or enforcement to counter that relatively low barrier to entry. There are no real consequences to hackers for their attacks. Most of the burden—financial and otherwise—is borne by service providers and their customers.

As a result, the underground cyber economy is thriving. Attacks occur for a variety of reasons, but for the most part the motivation is financial. There is a very large community that thrives on network vulnerabilities. With almost no barrier to entry, extremely low costs, and little by way of enforcement to deter bad behavior, it will come as no surprise that this underground cyber economy is thriving. But it is not because people are buying and selling the stocks, medicines, and other products hyped in all those spam messages. The financial model for the underground cyber economy treats the recipients of those spam messages as products, not consumers.

Spam as Social Engineering Spam is fundamentally a social engineering attack. Any “click level” of interest leads to a sale for the spammer —regardless of whether the end user purchases the merchandise hyped in the original message. In this underground version of the click-through revenue generation model, servers or end user workstations are infected with viruses, then turned into proxies or made part of attack networks, as known as “botnets.” Lists of these infected computers are then bought and sold online.

Customers purchase these compromised hosts for various purposes at resale, wholesale, or service specific prices. Spam proxying costs pennies per host week to set up. A raw bot for a distributed denial of service (DDoS) attack may sell for around $1 a host. Meanwhile, access to a CEO’s laptop may sell for several thousand dollars. Credit card databases are also being bought and sold, as well as accounts from such popular online trading venues as eBay and PayPal3.

The bottom line—this financial model works. The following figure illustrates how hackers can use the compromised hosts created by spam and other malware to launch a botnet attack. In this figure, an attacker compromises hosts in multiple networks, using them to launch a coordinated attack that cannot be stopped at any single point.

Botnet attacks achieve bandwidth leverage from multiple sources. Attacks such as this can include from 1,000 to over 100,000 bots (infected hosts4). If they are all connected at 512 kbps, then an army of 10,000 can be assembled to send at 5 Gbps to the victim. Attacks on this scale amply illustrate the potential benefit of very large filter lists and the ability to provide dynamic filter updates during an attack.

2See Joanne VanAuken, Managed Security Service Providers: Hired Guns at www.networkcomputing.com/showArticle.jhtml?articleID=191203015.

3See Organized Crime Invades Cyberspace at www.computerworld.com/securitytopics/security/story/0,10801,95502,00.html?from=story package.

4 Bots can also be used to send spam. They can get onto a user’s PC through an e-mail attachment or from phony Web sites. They come in the form of an agent that runs on the PC and “phones home” to a centralized herder, which sets up a control channel to launch the attack.



figure 1: corporate and branch office network infrastructure

Most large service providers report that they undergo dozens of general DDoS attacks per month, and that many of these significantly affect their customers for some time period. In addition to financial industries, there are many other industries that use service providers and whose business depends on having their networks up and running all the time. For example, transportation companies, eCommerce sites, and energy companies stand to lose a great deal of revenue from DDoS attacks. To prevent a potential liability, service providers are under mounting pressure to prevent, monitor, and ultimately mitigate these attacks towards their customers and their own infrastructure.

Spam proxying and botnet-powered DDoS attacks are only two of the many ways the underground cyber economy exploits open and accessible networking platforms. For more information on vulnerabilities and incidents, see www .cert .org/stats. It is also important to keep in mind that most attacks are still unreported, either due to concerns about negative publicity or the possibility that competitors might exploit a weakness5.

Managed Security Services as Strategic PurchasesSuffering network downtime from any source can pose a significant financial burden to any enterprise. At the same time, legislation such as HIPAA, Gramm-Leach-Bliley, and Sarbanes-Oxley in the U.S. and similar measures in countries worldwide is putting pressure on enterprises to implement new policies to better manage private information. To adequately safeguard their own networks internally, enterprises must incur the high cost of implementing 24 x 7 x 365 network monitoring and the need to rapidly respond to new network vulnerabilities as they are discovered. Not surprisingly, enterprises of all sizes are being to view managed security services from their service provider partners as a strategic business imperative.

A majority of large enterprises consider managed security services as being either essential or very important to their future business operations—this trend will likely continue as the cost of security breaches continues to be so substantial. Managed security services can range from asking a service provider to supplement an existing security feature to the enterprise relinquishing full control of their network security to their service provider partner. Whatever the level of service provider involvement, offering managed security services, including firewalling, intrusion detection and prevention, and dynamic threat mitigation to enterprise customers is big business.

But before service providers can take advantage of this profitable service opportunity, they must secure their own network infrastructure.

Assuming bots connected at 512 kbps

5See the 2005 CSI/FBI Computer Crime and Security Survey online.



Securing the Network Infrastructure In a service provider network, the basic infrastructure to secure is the routers and the links. A hacker who gains control of a core router can cause a great deal of damage. In addition to using the router to bring the network down, a hacker could establish themselves as a so-called “man in the middle,” and use the hacked router as a way to steal financial information, perhaps by spoofing a web site address based on information obtained from a DNS server.

Fortunately, operators can strictly secure their routers and links, because there are very few systems that have legitimate reasons to send traffic to a router. Therefore, packet filters that prevent all but legitimate users from sending traffic to the control planes of routers can go a long way towards protecting this basic infrastructure.

This section discusses the basic administrative practices network operators should put in place as well as specific steps operators can take to secure their network infrastructure.

The Role of Administrative Practices A great deal of infrastructure security can be handled by following certain best practices in terms of network administration. The security and other administrative policies you establish will determine how you set up your network operations center (NOC). Begin by documenting procedures and creating an operations and security team with differing levels of expertise. Your team should include personnel with experience in intrusion detection and prevention, interior routing protocols, such as OSPF, and exterior routing protocols, such as BGP. Once you establish these teams, have them set up security policies that reflect their philosophy and practice using those policies to mitigate attacks. These dry runs are critical—you do not want your first attempt to mitigate a DDoS attack to be during a live attack.

When setting up your security policies, it is crucial to consider the rules governing password selection. Many routers still (unfortunately) use manufacturer names or easy variants of them. There are also tools that allow hackers to obtain passwords from encrypted passwords, a vulnerability for systems that share encrypted passwords with unauthorized users. Any password based on what a human can remember can be broken6. One-time passwords are very effective at addressing this problem. Logging is also helpful. When establishing security policies, it is also important to consider policies to protect your edge and core routers—particularly their vulnerable control planes, as well as ways you can use telemetry to monitor traffic patterns to identify any unusual activity.

Next, encourage your security team to join mitigation communities, including the NSP-SEC forum (www .nspsec .org), the DSHIELD Distributed Intrusion Detection System (www.dshield.org), and the Forum of Incident Response and Security Teams (FIRST, www.first.org). These communities exist to provide service providers with a means to share incidence response lists, vendor-oriented mitigation tools, and other information critical to spotting and thwarting security threats. Participating in them can enable your operating personnel to protect your network more effectively against known security threats to minimize incidents. Should an incident occur, having access to the knowledge base in these communities could help your team identify and respond to security incidents much more quickly and effectively.

In addition to sharing information about current security threats with your colleagues in the networking industry, it is wise to establish and maintain customer and vendor hotlines so that your clients and vendors know whom to contact if they spot an attack.

Managed security services have a role to play here too. Building them into your portfolio may encourage your customers to take appropriate steps to secure their network infrastructure so that it does not become a point of entry for viruses, worms and other malware into your network.

RFC 3871, Operational Security for Large ISP IP Network Infrastructure, outlines many other useful administrative practices7. For instance, RFC 3871 addresses the question of out-of-band (OOB) versus in-band management access. Good sources of information include the security tutorials available from the North American Network Operators’ Group (NANOG) at www . nanog .org/ispsecurity .html.

6See Bruce Schneier, Secrets and Lies: Digital Security in a Networked World, John Wiley and Sons, 2004.

7See RFC 3871, available online and referenced in the Appendices in this document.



Securing the Router’s Control and Data PlanesA router’s data plane transmits many gigabits of traffic at high speed, while its control plane processes the routing protocols and network management tasks. As router technology has evolved over the years, the link between the control and data planes has been getting faster to accommodate the increasing amount of control traffic that the route processor has to handle. But the links on the data plane have been increasing in speed at a much faster rate, as the demands and quantity of Internet and wide area traffic become greater. The result is a link between the control and data planes that is much slower (by orders of magnitude) than the sum of the links on the data plane (see Figure 2). This disparity creates a potential security vulnerability, and as a result, there have been many cases of major DoS attacks aimed at a router’s control plane.

figure 2: vulnerability of the control plane

To protect against these attacks, it is important to limit the authorization of parties who can send packets to the control processor. Discarding bad packets en route to the control processor should prevent any degradation in performance. Using multiple prioritized queues to the control processor can make a large difference here, as attack traffic can then be quarantined in a separate queue8. This approach enables legitimate management traffic to get through, while blocking attack traffic.

Another necessary safeguard is to have the control processor compartmentalize resources. This enables the processor to guarantee a certain amount of CPU and memory on a per-task basis. For example, in the case of a multicast attack, the control processor will be involved in setting up a great deal of spurious state information. In this situation, it is imperative that the operating system be able to ensure that a portion of the control processor will be available for valid management traffic to maintain adjacencies and routing tables9.

Protecting the data plane is fairly straightforward. Because the data plane’s primary function is to accept and process inputs at line rate, the main concern here is that incoming interfaces not be affected by attack traffic. Service providers can use line rate packet filtering for all but the smallest packets to ensure this does not happen. Rate limiting is also potentially very useful here, as it can protect the router from legitimate users who may be inadvertently compromised. The remainder of this section talks about the filtering and traffic shaping techniques operators can use to secure their network routers.

“2n x 10G”

Control Plane

Data Plane

“Approx” 100 M

InternalBandwidth

n x 10G (for example) n x 10G (for example)

8 In cases where router operating systems do not support multiple prioritized queues, the only alternative is to increase the queue depth, which is not very effective.

9 Historically, routers performed control and forwarding tasks using a single processor. In order to gain high-performance, it was necessary to use an operating system that allowed a process to take hold of a control processor entirely. Many router operating systems still allow this, and this allows attacks to succeed more readily.



Making Routers Invisible: Filtering In theory, it would be useful to make routers invisible to all but a few users on the Internet. As a general rule, users should only see as much of a router as they need to. This section describes several techniques available to service providers to accomplish this, including:

Line rate packet filtering•

Stringent packet classification •

Nested and chained filters•

To secure their multiservice networks, service providers should look for routing equipment that can support all of these capabilities at scale without affecting network performance.

Line Rate Packet FilteringPacket filtering protects both the control plane and the data plane. In the case of the control plane, the packet filter discards packets that use the router’s address as the destination address. This approach, which essentially establishes a stateless firewall, can be achieved with sophisticated packet filters as long as the router can support them and still process traffic at line rate. To stop an attack as close as possible to its source, this filtering needs to be available as close to end-to-end as possible, from core routers to customer premises equipment10.

Filtering out these packets will stop end users from sending traffic to routers. However, operators will have to poke holes in these filters for valid routing protocol traffic. For instance, other internal routers running an interior gateway routing protocol such as IBGP, OSPF, IS-IS and external routers serving as EBGP peers will both need to access network routers. Network management stations, directly attached hosts, and servers on the same subnet will also need to send traffic to the router.

There are also issues as to where to put the filters. In principle, it would be ideal to only accept a packet whose destination address is the router’s control plane if it comes from a routing peer or some other legitimate source. In some cases, this may be too difficult to configure based on the addressing scheme of the various networks the provider supports, or because performance will degrade too rapidly. If you have this sort of addressing limitation, it is possible to quickly mitigate the attack by dynamically propagating filter updates between network elements until you get as close as possible to the source.

Of course, all of this assumes that the routers can perform packet filtering at line rate. The inability to do line rate packet filtering on tens of thousands of entries due to equipment limitations has forced many service providers to simply turn off interfaces that are under attack. This approach, known as “completing the attack,” does halt the spread of the attack, but comes at the cost of guaranteeing that the attack will successfully interrupt at least some services.

Stringent Packet Classification In order to provide the voice, video, data, and multimedia services in multiservice networks, the data planes of routers must go well beyond destination-based forwarding and source lookups. As the multiservice networking environment becomes more prominent, basic policy assignment and packet filtering operations become more important. The burden is on the data plane to provide more, larger, and more sophisticated service tunnels—VPNs or MPLS Label Switched Paths (LSPs) for instance—and to do so in the most operationally efficient manner. This requires the router’s data plane to use more advanced packet classification techniques.

The necessary operations include correctly classifying packets using route table lookups and filtering packets based on multiple fields. Other packet forwarding and filtering activities that are needed to handle the demands of multiservice networks include such activities as counting packets, filtering, policing, policy-based routing, traffic sampling, quality of service (QoS), and many other classification tasks that involve table lookups and actions to perform field and route matching11.

10Only Juniper Networks provides this feature across the entire range of routing equipment, from enterprise to core.

11 For more information on Juniper’s unique ability to combine these services in any order and to perform nested and chained filtering operations at enormous scale, see the white paper, Efficient Scaling for Multiservice Networks at www.juniper.net/solutions/literature/white_papers/200207.pdf.



Nested and Chained FilteringThe ability to nest and chain filters can play a vital role in securing multiservice networks as well. Nested filtering, the ability to nest a firewall filter so that it can be reused in several places, allows service providers to save memory. Chained filtering provides the ability to implement specific filters one after another in a technique known as forwarding table filtering. Nested and chained filters are unique capabilities on Juniper Networks routers.

The nesting capability allows a number of applications. For example, operators could set up one nested filter to check IP address prefixes after protocol redistribution, while another nested filter rejects unallocated (Bogon) prefix blocks. Still another application is to set up a filter to police (rate limit) traffic once a traffic count on an interface reaches a specified threshold. This count may be different for different logical and physical interfaces. In all cases, service providers create and invoke a separate nested filter as needed.

The main application for chaining is in a feature called forwarding table filtering. Forwarding table filtering allows operators to specify filters for individual routing instances such as an MPLS VRF, the Internet, and the control plane of the router.

The following diagram shows the logical flow of these features.

figure 3: flowchart logic for nested and chained filters

Advanced Packet Filtering and Scalability As multiservice networks continue to expand, scalability becomes a critical concern for service providers. Fundamentally, scalability has to do with the ability of the packet forwarding engine (PFE) to process packets.

Core network devices must be able to filter traffic and allow carriers to set policy. The greater the number of firewall filter terms that an interface can support, the more control a carrier has over the traffic traversing the core.

On the other hand, policy based rules at the edge of the network are more stringent. The filtering requirements for security, QoS, accounting and other features are usually more specific and the amount of rules are multiplied based on customer applications. A router positioned in the edge or in a collapsed PoP solution should have the ability to scale to and match or exceed a real world network requirement.

Firewall filter term handling is thus an important test of scalability. Juniper Networks T Series Core Routers and M Series Multiservice Edge Routers easily accommodate many hundreds of thousands of firewall filter entries while forwarding traffic at line rate.

For more information on the scalability issues associated with advanced filtering techniques, see the Efficient Scaling for Multiservice Networks white paper, available at www .juniper .net/solutions/literature/white_papers/2000207 .pdf.

Item

Term

Term

Term

Term

Term

Invoke Nested Filter

Invoke Filter

Filter 1

Filter 2

Chain to Next(Separate RoutingInstance or FIB)

Nested Filter(Subroutine)

Continue the Chain

Term

Term

Term

Term



Making Routers Untouchable: Traffic Shaping Although in theory, it would be best to hide routers from all but a few users, in some cases, routers may need to be visible. For example, Internet Control Message Protocol (ICMP) traffic between directly attached devices needs to reach the control plane of all routers in the network. Similarly, an MPLS Customer Edge (CE) router must be able to talk to the MPLS Provider Edge (PE) router. Another example is the multicast state, which must be shared between participating routers.

Traffic shaping and rate limiting are very effective tools for handling these traffic types. Operators can use rate limiting to ensure that attacks that use these valid techniques for router intercommunication will be unsuccessful.

For instance, it is a good practice to constantly limit ICMP traffic levels. Abnormal rapid increases in inbound ICMP traffic can indicate the initiation of a DoS attack. Once the predefined maximum level has been reached, traffic can be rate limited on the service provider access router, and excess traffic discarded. As the following figure shows, this greatly diminishes the amount of unwelcome traffic.

figure 4: effect of icMP ping traffic rate limiting

Service providers can enhance their rate limiting service to include event recording, real-time customer notification of the event, source tracing, liaison with upstream network administrators, and monthly ICMP traffic volume reporting. The service provider can also choose to limit ICMP traffic at interconnect points with other networks to further reduce the impact of attempted attacks.

Rate limiting could mean that legitimate users who may be compromised will experience performance hits, or that entire blocks of users from affected access networks may not have access to certain sites (until the attack stops). The important consideration, however, is that the rest of the network is protected.

Remote triggered rate limiting can be based on the volume of traffic or other factors and is discussed in more detail in the “Implementing Policy on the Network Control Plane” section.

Protecting the Network from Infected Hosts: Stateful Filters Stateful filters are another important tool in the security arsenal. A stateful filter essentially looks at traffic on a flow basis, verifying a flow via source and destination IP addresses and TCP/UDP ports, among other fields in the IP header and the logical input interface on the router.

Stateful filters can be extremely useful in protecting BGP sessions or protecting the network from infected hosts. Stateful filters are not limited to either discarding or accepting the packet. They can also set QoS for the next hop, increment a counter, dynamically establish a rate limit, or send a copy of the flow to another device to be monitored.

Rogue flows with spoofed (valid) IP or port addresses can bypass a stateless filter but would be caught in a stateful filter. Examples include Transmission Control Protocol synchronized (TCP SYN) floods, too many BGP OPEN sessions, or TCP zombies. Rate limiting on a flow basis can be accomplished by examining signatures or anomalies to thwart more sophisticated attacks. This level of intrusion detection and prevention can be provided either in the router itself (with a hardware service interface12) or in a separate Intrusion Detection and Prevention (IDP) device—and can be a profitable addition to your managed security service portfolio.

DoS Threshold

Without Service

“Unwelcome” Traffic

Other IPICMP Packets

DoS Threshold

Other IPICMP Packets

With Service

ICMP RateLimit

12See Juniper Networks Multiservices PIC



Securing Routing Protocols Control packets from all major routing protocols (from all vendors) can be authenticated via MD5. However, it is worth noting that MD5 does not protect against DoS and can in fact exacerbate a DoS attack as the control plane attempts to check the validity of attack traffic. Of course, this is not a reason to eschew authentication—the benefits far outweigh this risk.

A DoS attack against the CPU is not the only issue at hand here. DoS attacks targeting the data plane can cause routing adjacencies to be lost if the data plane does not handle queuing of control traffic. Many legacy routers have lost adjacencies by not being able to prioritize routing traffic on the data traffic links.

It is also important to compartmentalize resources through individual processes. For example, it is useful to be able to limit the amount of resources that a potentially resource-intensive mechanism, such as multicast, can take up.

In terms of routing protocols, securing BGP is especially important. There are methods to place limits on maximum prefixes advertised in order to prevent de-aggregation attacks. Filtering on both the ingress and egress links is very useful here to prevent unauthorized route injection, bogon routes, Martian routes, or DDoS attacks. There are also certain best practices recommended such as removing default routes in core routers, which may allow grant hackers access to key servers or directly attached networks once they have gotten through to a router13.

Securing IP/MPLS In general, MPLS restricts filtering capabilities, as IP/MPLS core routers tend only to look at the MPLS headers and do not look past the MPLS headers to filter on IP, TCP, and UDP. Furthermore, special purpose filtering hardware (ASIC) does not allow for MPLS headers. It is theoretically possible to perform this filtering in the central processor, but this degrades performance so considerably that it negates the value of using MPLS in the first place14.

This implies that filtering needs to be done either at the ingress or egress of the LSP. Of course, those are the spots where filtering ought to be performed anyway. At ingress, one can filter on the IP packet and forward it on to the LSP. At the network egress, operators can have the last router perform filtering if PHP is turned on, and the penultimate router has stripped off the last MPLS header before the packet reached the egress PE router.

Securing Users and Servers Servers and end-user computers are inherently less secure than routers. While router control planes have only a few legitimate users, many people have valid reasons to access a server. Server operating systems also have many more security holes than router operating systems. Web browsing and email allow end users to take a lot of actions in response to requests, making it difficult to maintain a secure environment.

Destination-based or black hole filtering (also called “completing the attack” as previously described) is achieved by installing a “black hole route” in all routers in the network. This route entry essentially says to “discard any packets going to the specified host address.” All routers allow this in the forwarding table. The disadvantage of this is that, of course, the attack is successful. On the other hand, this approach protects the rest of the network infrastructure, and eases network congestion.

Similarly, if the attack is coming from a small number of ingress links, one can simply pull these links. This cuts down on both attack packets and good packets. On the one hand, it keeps the rest of the infrastructure from collapsing, but on the other, a lot of valid traffic is lost and again, the attack is successful. All of this is really an unfortunate consequence of routers that cannot do packet filtering with performance that is good enough to be used in the field.

Profitable Security: Managed Security ServicesWithout routers that support line rate filtering and flexible updating, many providers and their customers are still living with antiquated techniques such as destination-based filtering. Service providers who can lead their customers away from partial solutions such as this can quickly become trusted advisors to their customers.

13 A white paper, BGPv4 Security Essentials, has more detail on these issues. It can be found at www.nanog.org/mtg-0206/ppt/BGP-Risk-Assesment-v.5.pdf.

14 In Juniper Networks routers, you can circumvent this restriction by forwarding the packets through a Tunnel Services PIC, which leverages a comprehensive set of tunneling technologies to deliver IP/MPLS services over any IP infrastructure.



And that’s the good news—this is where the money is. Companies that cannot afford downtime and that need transaction-based assurances with accurate reporting are eager to take advantage of managed security services that help ensure service continuity. Once integrated with IDP systems and real-time traffic analysis on the routers, policy-aware systems in the NOC such as Juniper Networks SRC Series Session and Resource Control Modules, can provide the needed service guarantees with critical audit trails. When the system identifies an attack, sophisticated mitigation techniques such as BGP firewall filter propagation can neutralize that attack quickly across multiple networks.

A unified threat management approach incorporates stateful firewalls; an IDP system that provides multimode detection of protocol anomalies and custom signatures; and antivirus, anti-adware, and anti-phishing protection; as well as URL filtering.

Other managed service or CPE-resale offerings that can make all the difference in the world to these customers include high-throughput secure firewall gateways such as Juniper Networks SSG Series Secure Services Gateways devices for branch offices. The SSG Series represents a new class of purpose-built security appliance that delivers a perfect mix of performance, security and LAN/WAN connectivity for regional and branch office deployments15.

The remainder of this section describes other steps service providers can take to protect their servers and end users.

Protecting Users and Applications As a general rule, if there are services or ports you are not using, you should turn them off16. Critical applications should use a small number of well-defined ports. Any unused ports and services should be turned off ahead of time for user hosts, servers, and via filter lists on routers.

Another step is to use line rate packet filters to avoid completing the attack while minimizing collateral damage. Rate limits and separate queuing are also potentially very useful in this regard. One of the advantages of using rate limits is that they can be turned on ahead of time to ensure resources are available for critical applications.

Using Unicast RPF to Verify Source Addresses Spoofed source addresses make the source of an attack very hard to trace and can enable attack amplification via servers. Spoofed source addresses can get around packet filters. However, routers can verify that source addresses are valid through a technique known as unicast RPF. When set on an ingress interface, unicast RPF can drop IP packets with spoofed source addresses at the service provider customer’s edge, depending on the method of deployment.

To verify incoming traffic, unicast RPF matches the source address against the routing table. The unicast RPF check will only admit traffic where the source IP address belongs to a subnet reachable on the incoming interface. All other packets are rejected.

There are two primary unicast RPF techniques: strict mode and loose mode. Strict mode unicast RPF, which is commonly used at the network edge, looks for a definite match on the reverse path. The downside of this approach is that it can lead to false positives.

Loose mode unicast RPF does not verify the source address using reverse path forwarding, but will not accept any traffic from unallocated addresses. The tradeoff on this approach is that it can drop traffic that ought to be allowed in. Loose mode unicast RPF is commonly used in core and aggregation routers. A sample implementation is shown in the following figure.

15 For more information on the SSG Series of firewall/VPN appliances, see www.juniper.net/ssg-series.

16In fact, the way some networks completely avoided getting hit by Slammer was to turn off the UDP ports that Slammer utilized ahead of time.



figure 5: unicast rPf

Implementing Real Time Traffic Analysis and Stateful Firewall Integration Operators can choose from various implementations of real time traffic analysis. Port mirroring allows a copy of a sampled packet to be transmitted through an arbitrary interface—this can be any interface and any speed and can mirror up to 100 percent of selected packets. This is useful for network forensics and traffic analysis. Passive monitoring provides detailed real-time traffic measurements, which can be categorized by port or interface.

Some forms of filters require state maintenance and/or inspection of application contents. This can help protect against TCP SYN attacks. Operators can also limit the number of flows per host and isolate the hosts that are part of an attack. Stateful functions include Network Address Translation (NAT), Port Address Translation (PAT), stateful firewall, Intrusion Detection System (IDS) and Application Layer Gateway (ALG). Stateful filters have historically been implemented in external devices, but are being moved into routers.

In the following scenario, one router provides multiple stateful firewalls to protect users, servers, and routers at multiple sites. Users from these sites are connected to the Internet via Layer 2 or Layer 3 MPLS VPNs. They can connect to a DMZ where servers handle external web requests but may need to prevent other types of traffic from entering the network.

figure 6: secure, virtualized core network

15.10.10/24

I’m connectedusing ip sa15.10.10.2

Multimedia

I’ll take over15.10.10.2

premium session

No, you won’t. This IP addressis not part of a subnet learnt

on this interface.

32.10.10/24

MPLS/VPN

PE

CE

CE CE

Customers withPrivate Addresses

10.x.x.x

Managed NAT/PAT FWat Provider Edge

INTERNET



Operators can perform virus checking on all email within a particular VPN. Servers that are generally meant to serve the outside world, but might be accessible from inside the company (for example, by employees updating a web page), can have separate access controls. This is a flexible solution that does not tie up many interfaces.

Implementing Policy on the Network Control Plane Another critical security consideration is how you use policies to implement your security philosophy. Being able to automate policy on a network-level control plane is extremely useful. Automated policies mean a quicker response and policy enforcement that is less prone to errors.

The Juniper Networks SRC is a flexible, customizable application that enables the rapid creation and deployment of IP services. When used in conjunction with Juniper routers—all of which provide line rate packet filtering, dynamic rate limiting and flexible queuing on both the data and control planes—SRC allows administrators to define service offerings as they are needed. This section describes how service providers can use dynamic threat mitigation and BGP distributed traffic filters to safeguard their network control plane.

Using Dynamic Threat Mitigation Dynamic threat mitigation enables operators to quickly identify, automatically isolate, and notify infected customers of a problem and to dynamically add remedied customers back to normal service. This solution requires an in-depth understanding of traffic flows and patterns on a per-user basis.

The following figure illustrates a volume-based dynamic threat mitigation solution. Packet thresholds are set in a volume tracking application, and subscribers are redirected to a captive portal and offered remedial support.

figure 7: volume-based dynamic threat mitigation using src

The process is as follows:

1) A subscriber is infested with a worm.

2) The SRC policy decision server notes the increase in the traffic load.

3) An IDP platform tells the policy server to notify the subscriber.

4) All routers are told to redirect the user traffic to the IDP device.

5) The SRC policy server sends the user to a captive portal to get the worm cleaned off the PC.

4 2

31

IDP

SDX300

INTERNETTRANSIT POINT

IDP Signals Policy

ActionableEvent

NOC

Warning:PC infectedwith Virus

Volume TrackingApplication



Mitigating Attacks Using BGP Distributed Traffic Filters The ability to distribute traffic filters throughout a network of BGP routers can mitigate an attack in a very concerted way. Traffic filtering policies have traditionally been relatively static. However, the popularity of traffic-based DoS attacks, which often require network operator to be able to use traffic filters for detection and mitigation, brings with it requirements that are not fully satisfied by existing tools.

Several techniques are currently used to control traffic filtering of DoS attacks. One of the most common of these is to inject unicast route advertisements corresponding to a destination prefix being attacked. One variant of this technique marks such route advertisements with a community that gets translated into a discard next-hop by the receiving router. Other variants attract traffic to a particular node that serves as a deterministic drop point.

Using unicast routing advertisements to distribute traffic filtering information has the advantage of using the existing infrastructure and inter-Autonomous System (AS) communication channels. This can allow service providers to accept filtering requests from customers for address space they own.

There are several drawbacks, however. One issue that is immediately apparent is the granularity of filtering control: only destination prefixes may be specified. Another area of concern is the fact that filtering information is intermingled with routing information.

The mechanism illustrated in the following diagram addresses these limitations.

figure 8: BgP distributed firewall filters

The process works as follows:

1a) The NOC identifies the attack and creates a flow filter update, which includes a mechanism to defeat the attack. This may include source address, port number, protocol type, or other fields in the packet header.

1b) A flow filter update can also be sent directly from the BGP router closest to the victim.

2) The egress router takes immediate action.

3) Flow filter updates are communicated through all BGP peers in succession, and the forwarding planes of these routers are updated with the new filter information.

4) These flow filter updates can be communicated across AS boundaries17.

VICTIM

NOC

1b

1a

3

3

3

2

4

44

Firewall

17See the draft specification for this at www.tcb.net/draft-marques-idr-flow-spec-00.txt.



Conclusion Because security is a long-term issue, service providers need to develop a security strategy. A good place to start is to educate your staff on best practices. When implementing your security plan, begin by instituting the most obvious protections first and by deploying equipment that is capable of the more advanced protections. Deploying equipment capable of applying line-rate packet filtering today turns what might have been a major forklift upgrade into a simple configuration problem. All Juniper Networks routers have this capability.

Other straightforward steps include protecting routers and servers by using one-time passwords and only allowing authorized users to get to routers by implementing authorization systems based on TACACS+ or RADIUS.

Operators can also implement rate limiting to manage incoming traffic, which can include DoS attacks against the control processors of routers. In general, operators should turn off unused and unneeded services, even when this may entail turning off features on servers. Finally, consider applying packet filters to turn off particular TCP or UDP ports and to verify source addresses.

Implementing policy-based security also brings many advantages to the security arsenal, because it automates the implementation of the security philosophy and lessens the chance of user error in protecting the network.

When implementing your security policy, keep in mind that many of the same filtering, traffic shaping, and intrusion detection and prevention techniques that are so critical to securing your network infrastructure can be turned into managed security services that you can sell to your enterprise customers.

References There is a great deal of literature on service provider security, including the following content.

Juniper Networks Web Casts Intrusion Prevention for Service Providers

http://www .juniper .net/company/events/archive/051208 .html

SSL VPN for Service Providers


VoIP for Service Providers


Juniper Networks White Papers The following Juniper Networks white papers are available:

Building (and Securing) IMS

http://www .juniper .net/solutions/literature/white_papers/200175 .pdf

Efficient Scaling for Multiservice Networks


Evolving Security Needs in the Mobile World


Network Reliability and Interoperability Council (NRIC) There is a link at http://www .nric .org for best practices. Click on NRIC Best Practices and it will take you to a selector tool. You can search from a menu of network types, industry roles and other keywords.

North American Network Operators’ Group (NANOG) NANOG actively works to produce sessions and seminars to help foster security on the Internet. All sessions are taped and converted to streaming media for all to use for their personal education. There are over 50 articles listed at http://www .nanog .org/resources/tutorials .

The white paper, BGPv4 Security Essentials, which has more detail on the BGP security issues discussed in this paper, is on this page at: http://www .nanog .org/mtg-0206/ppt/BgP-risk-assesment-v .5 .pdf .


corporate and sales Headquarters Juniper Networks, Inc. 1194 North Mathilda Avenue Sunnyvale, CA 94089 USA Phone: 888.JUNIPER (888.586.4737) or 408.745.2000 Fax: 408.745.2100

aPac HeadquartersJuniper Networks (Hong Kong) 26/F, Cityplaza One 1111 King’s Road Taikoo Shing, Hong Kong Phone: 852.2332.3636 Fax: 852.2574.7803

eMea HeadquartersJuniper Networks Ireland Airside Business Park Swords, County Dublin, Ireland Phone: 35.31.8903.600 Fax: 35.31.8903.601

Copyright 2009 Juniper Networks, Inc. All rights reserved. Juniper Networks, the Juniper Networks logo, JUNOS, NetScreen, and ScreenOS are registered trademarks of Juniper Networks, Inc. in the United States and other countries. “Engineered for the network ahead” and JUNOSe are trademarks of Juniper Networks, Inc. All other trademarks, service marks, registered marks, or registered service marks are the property of their respective owners. Juniper Networks assumes no responsibility for any inaccuracies in this document. Juniper Networks reserves the right to change, modify, transfer, or otherwise revise this publication without notice.

2000180-001-EN Feb 2009 Printed on recycled paper.

15

To purchase Juniper Networks solutions, pleasecontact your Juniper Networks representative

at 1-866-298-6428 or authorized reseller.

Operational Security for Large ISP IP Network Infrastructure (RFC 3871) RFC 3871 defines a list of operational security requirements for the infrastructure of large IP networks (routers and switches). The goal is to provide network operators with a clear, concise way to communicate security requirements to equipment vendors.

RFC 3871 can be found at: http://www .faqs .org/rfcs/rfc3871 .html

OPSec: Operational Security Capabilities for IP The following papers are available as links at the bottom of http://www .ietf .org/html .charters/opsec-charter .html

Framework for Operational Security Capabilities for IP Network Infrastructure •

Security Best Practices Efforts and Documents•

Operational Security Current Practices •

Filtering Capabilities for IP Network Infrastructure •

Miscellaneous Capabilities for IP Network Infrastructure •

Network Management Access Security Capabilities•

About Juniper NetworksJuniper Networks, Inc. is the leader in high-performance networking. Juniper offers a high-performance network infrastructure that creates a responsive and trusted environment for accelerating the deployment of services and applications over a single network. This fuels high-performance businesses. Additional information can be found at www .juniper .net .