In previous articles, (Designing large-scale BGP networks and Scale your backbone with core MPLS, BGP on the edge), I've described how you can build large, scalable service provider networks using the Border Gateway Protocol (BGP) routing protocol. But even the best-designed network will fail to meet your business goals unless it offers the services your customers want and is protected from active attacks by malicious users, as well as errors made by your peers or customers.
In this article, you'll find guidelines that will make your network more resilient and easier to maintain.
Plan for advanced services
The service provider industry entered the commodity phase a long time ago, with cost-based competition one of the major focuses.
 |
|
|
|
|
It still amazes me that you can find smaller service providers that simply cannot implement them (advanced services) properly.
Ivan Pepelnjak
Chief Technology Advisor, NIL Data Communications
|
|
|
|
|
|
|
|
|
|
Nonetheless, there are still customers that would appreciate extra services you could offer them (for example, a comprehensive backup link implementation). These services are no longer leading-edge technology, as some major players have been offering them for years. But it still amazes me that you can find smaller service providers that simply cannot implement them properly.
Before rushing to your web browser trying to figure out what services to offer (based on what the competition is doing), it's worthwhile analyzing your particular market:
- Who are your target customers?
- What business goals are they trying to achieve by using your services?
- Which services should you offer to help them reach their goals?
Only after the analysis should you focus on designing the implementation of those services in your network.
Use BGP communities
There are two ways to implement additional services for your customers: You could plan them in advance and implement them network-wide, or you could implement a specific solution (most often a kludge) for each customer request. Obviously, the second approach results in a network that is hard to maintain and troubleshoot (more so if the implementation of a customer-specific solution is not followed by thorough documentation).
If you want to implement a scalable approach to BGP-related network services (for example, implementation of backup links or specific quality-of-service requirements), you should introduce BGP communities into your network. You can use them to mark customer routes as they enter your network and implement various policies based on communities attached to the customer routes at other places in the network. For example, you could use BGP communities to implement QoS marking of ingress traffic at the Internet Exchange Points.
Sometimes you would want to control the BGP communities yourself (you probably don't want the customers to select premium QoS parameters without your control), or you could help the customers use the communities you have defined to select the services they need (resulting in a self-service approach that minimizes your costs).
Protect your network
You cannot offer reliable services to your customers if you're vulnerable to outside denial-of-service (DOS) attacks. To stop the majority of the brute-force attacks, you should implement inbound access-lists on all interfaces attached to external sources (your customers or peer networks). These access-lists should:
- Block all network control protocols that you don't plan to offer as a service. At the very minimum, you should not accept any routing protocol updates through these interfaces (apart from BGP).
- Block all traffic with source addresses in the private address space.
- Block all traffic from bogon prefixes.
- Block all traffic originating from the IP addresses belonging to your core network.
Note: To simplify the filters, allocate the IP address of your core devices from a continuous block of IP address space.
The access-lists deployed on peering interfaces should also block all traffic originating from IP prefixes allocated to you by the Internet registries. On the customer-facing interfaces, you should also implement the unicast Reverse Path Forwarding.
Guard your routing protocols
While it's important to stop the denial-of-service attacks from spoofed source IP addresses, it's even more important to protect your routing protocols. No traffic filter will help you if your routers have an invalid view of the network.
Ideally, the only routing protocol you would use on the external connections (with your peers and your customers) would be BGP. If you have to run any other routing protocol with your customers, accept only distance-vector protocols (RIP or EIGRP), as the technology they're using allows you to filter incoming updates. If you run a link-state protocol (OSPF or IS-IS) with your customer, you've lost all control of the stability of your network.
If at all possible, implement digital signatures in the routing protocol you're using with external neighbors to prevent route spoofing. Major router vendors support MD5 signatures in all distance-vector protocols.
Last but not least, filter all inbound routing updates. Your peers should not advertise private IP prefixes or prefixes belonging to you. Very small IP prefixes (less than /24) usually indicate a configuration error or an active attack. You should discard them unless you have special arrangements with your customers.
Trust no one…especially your customers
It sounds ridiculous, but your customers can cause you more headaches than your competitors, as some of them simply don't have the experience necessary to configure their devices in a complex (usually multi-homed) scenario. As far as possible, you should help them by protecting them from their mistakes.
For example, do not accept transit BGP routes (routes with multiple different autonomous system numbers) or very small IP prefixes (less than /24 or /25) from your customers. If you want to implement even tighter control, you can also filter the IP prefixes they're announcing based on the contract you have with them.
Unless you have extremely good reason not to, you should limit the number of IP prefixes that you're willing to accept from your customers. Routers from major vendors allow you to disconnect a BGP neighbor for a configurable amount of time (or even shut it down completely) if it sends too many prefixes.
Malicious customers might also try to get free extra services by attaching numerous BGP communities to their routes. While you should accept BGP communities that implement self-service options (like backup link selection), you should remove those that you use to implement value-added services.
About the author: Ivan Pepelnjak, CCIE No. 1354, is a 25-year veteran of the networking industry. He has more than 10 years of experience in designing, installing, troubleshooting and operating large service provider and enterprise WAN and LAN networks and is currently chief technology advisor at NIL Data Communications, focusing on advanced IP-based networks and web technologies. His books include MPLS and VPN Architectures and EIGRP Network Design. You can read his blog here: http://ioshints.blogspot.com/index.html
