Special BGP Topics
To conclude the BGP coverage, several modern features of BGP are discussed in the remaining sections.
BGP "Pseudo" Load Balancing
As already mentioned, BGP intrinsically was not designed to carry out load balancing; it is a protocol optimized for reflecting highly granular routing policies and picks a single best path based on prefix length and shortest AS path. However, certain levels of equal ingress or egress traffic distribution can be achieved via manual measures such as weight, local preference, or MED, AS path prepending and route deaggregation of provider aggregates.
Several measures naturally have negative side effects; they are circumventing what the protocol was designed for after all. Just because the underlying IGP is capable of load balancing does not mean that BGP behaves similarly. For example, MED and community concepts especially require acceptance of your peering partners to take effect.
The real challenge of load balancing is to equalize flows over geographically distant edge nodes for both attracted and exiting traffic for at least EBGP and preferably for IBGP, too. The Cisco IOS BGP multipath load-sharing feature in combination with the maximum-paths command installs up to six most recently received paths in the IP routing and CEF tables. This works per packet or per flow, but only for EBGP and multiple paths to the same EBGP neighbor AS. Zebra/Quagga and GateD lack this feature. For more sophisticated BGP load-sharing approaches, Cisco IOS Software Release 12.2 has introduced several EBGP and IBGP unequal-cost features based on MPLS VPN technology.
BGP Security Considerations
As should be obvious by now, BGP represents the "blood" that keeps the organism (Internet) alive and its "organs" (the autonomous systems) connected and cooperating. Disruption or a state of nonequilibrium of this critical resource can, in the worst case, affect large regions, continents, or even the entire worldwide Internet. These effects occur regardless of the nature of the cause, which, among others, can include any of the following:
- Distributed denial-of-service (DDoS) attacks
- Human configuration error
- Aggregate decomposition
- Scripting and database errors
- Malicious update injection
- TCP session hijacking attempts
- Spoofing
- Secondary effects caused by triggering route flaps
- Blackholing
- Suboptimal routing
TCP itself and the BGP protocol provide certain mechanisms that can be used proactively to prevent or counteract these incidents, accelerate recovery, or reduce the magnitude/range of these negative effects. A common problem (human error) is the announcement of prefixes that do not belong to your administrative realm or, even worse, announcing a default route 0.0.0.0/0 to the Internet and blackholing all traffic. In addition, folks are often leaking private autonomous systems, martian networks, or bogon routes, which are often used as the source for (D) DoS attacks (resource-saturation attacks), such as SYN flooding. Martian networks are essentially RFC 1918 aggregates, and bogon routes are a superset of these—routes that never should appear in the global Internet routing table (see Example 10-34). The obvious countermeasure of choice is thorough filters. For further information, look at RFC 3330, "Special-Use IPv4 Addresses."
Example 10-34. RADB Martian Filter-Set Entries
[root@callisto:~#] whois -h whois.radb.net fltr-martian [whois.radb.net] filter-set: fltr-martian filter: { 0.0.0.0/8^+ , 10.0.0.0/8^+ , 127.0.0.0/8^+ , 169.254.0.0/16^+ , 172.16.0.0/12^+ , 192.0.2.0/24^+ , 192.168.0.0/16^+ , 198.18.0.0/15^+ , 224.0.0.0/3^+ } descr: Special use and reserved IPv4 prefixes. remarks: For the complete set of bogons, please see: fltr-unallocated - unallocated prefixes. fltr-bogons - fltr-unallocated + fltr-martian. http://www.cymru.com/Documents/bogon-list.html admin-c: Rob Thomas RT624 tech-c: Rob Thomas RT624 notify: radb@cymru.com mnt-by: MAINT-BOGON-FILTERS changed: radb@cymru.com 20021229 changed: radb@cymru.com 20021230 changed: radb@cymru.com 20021230 source: RADB [root@callisto:~#] whois -h whois.radb.net RS-MARTIAN [whois.radb.net] route-set: rs-martian descr: Routes non desirables members: 0.0.0.0/0, 0.0.0.0/0^32, 127.0.0.0/8^9-32, 10.0.0.0/8^+, 172.16.0.0/12^+, 192.168.0.0/16^+, 192.0.2.0/24^+, 128.0.0.0/16^+, 191.255.0.0/16^+, 192.0.0.0/24^+, 223.255.255.0/24^+, 224.0.0.0/3^+, 169.254.0.0/16^+ remarks: NONE admin-c: YB4 tech-c: YB4 notify: routing@risq.qc.ca mnt-by: MAINT-AS376 changed: boudreau@risq.qc.ca 20010814 source: RISQ
Modern BGP implementations provide the MD5 signature option to secure the BGP TCP connection (RFC 2385) via MD5 digests. Keep in mind that enabling this feature might increase the CPU load on a BGP speaker. In addition, there exists a transparent wrapper approach for Linux (Secure BGP for Linux), which you can retrieve from http://shell.webchat.org/~jk/securebgp/. You can retrieve another Perl script facilitating netfilter QUEUE targets from http://www.pilotsoft.com/bgpmd5/bgpmd5.pl. MD5 digest capabilities are not yet included in Zebra bgpd and are completely missing from GateD-public v3.6. In addition, a kernel IPSec approach exists via the TCP_SIGNATURE, and a FAST_IPSEC configuration option exists for 4.10 FreeBSD.
There was a discussion thread going on recently on the Zebra list as to whether the proposed Internet Engineering Task Force (IETF) MD5 password option (RFC 2385) or external IP Security (IPSec) should be implemented to secure peerings.
The 3.5 release of OpenBSD includes a standalone bgpd that is not part of this discussion yet. This implementation of BGP uses OpenBSD's TCP MD5 signature capabilities for added security. For an excellent discussion of BGP exploits and countermeasures, I highly recommend http://www.cymru.com/Documents/barry2.pdf. This website also operates a bogon route server via private AS EBGP multihop peerings (a helpful gesture worth supporting).
In summary, the following approaches/countermeasures to BGP security have emerged:
- IETF TCP MD5 signature option (RFC 2385)
- The BBN Secure BGP Project (S-BGP)
- Secure Origin BGP by Cisco Systems according to draft-ng-sobgp-bgp-extensions-00.txt and draft-white-sobgp-bgp-extensions-00.txt
- Route flap damping
- MAX Prefix Filter
- Ingress/Egress filtering
- BGP over IPSec
- The BGP TTL Security Hack (draft-gill-btsh-01.txt)
Also look at draft-ietf-rpsec-routing-threats-01.txt (RPSEC), draft-murphy-bgp-vuln-02.txt, and draft-turk-bgp-dos-04.txt. I also highly recommend that you investigate and deploy Rob Thomas's Secure BGP Configuration Template available at http://www.cymru.com/Documents/secure-bgp-template.html and the bogon list at http://www.cymru.com/Documents/bogon-list.html.
Remember that a clear policy and sound community concept will save you from a lot of headache, result in more readable configurations, and help define different service classes for transit and downstream customers. Religiously maintaining these policies in RADB can save a lot of administrative work if you do as most professional providers and run your router config scripts once or twice per day. I would even say that maintaining strict and coherent routing policies is the key to professional and successful international/intercarrier service provisioning of any kind. And it will earn you a good reputation with registries and your fellow providers.
Multiprotocol BGP Extensions
Multiprotocol BGP is a generic term for several extensions of BGP, also referred to as BGP4+ and optionally negotiated via BGP capabilities during session setup. The framework is covered in RFC 2858, "Multiprotocol Extensions for BGP-4." It includes the ability to carry NLRI for IPv6, IPX, BGP MPLS VPNs, interdomain Multicast BGP (MBGP), and any non-IPv4 network layer protocol (in principle).
To identify individual network layer protocols, address families and subaddress families were introduced. RFC 1700, "Assigned Numbers," is quoted often in the literature. (However, it is not authoritative anymore, because its status was changed to "historic" and replaced by the IANA online database.)
Zebra provides the necessary hooks to deal with multicast, IPv6, and IPv4 NLRI. For example, when a BGP router enables interdomain Multicast BGP, it manages two separate RIBs for unicast and multicast prefixes (or for two address families, so to speak).
| Number | Description |
|---|---|
| 0 | Reserved |
| 1 | IP (IP version 4) |
| 2 | IP6 (IP version 6) |
| 3 | NSAP |
| 4 | HDLC (8-bit multidrop) |
| 5 | BBN 1822 |
| 6 | 802 (includes all 802 media plus Ethernet "canonical format") |
| 7 | E.163 |
| 8 | E.164 (SMDS, Frame Relay, ATM) |
| 9 | F.69 (Telex) |
| 10 | X.121 (X.25, Frame Relay) |
| 11 | IPX |
| 12 | AppleTalk |
| 13 | DECnet IV |
| 14 | Banyan Vines |
| 65535 | Reserved |
Note the following quote from RFC 2858, "Multiprotocol Extensions for BGP-4":
To provide backward compatibility, as well as to simplify introduction of the multiprotocol capabilities into BGP-4, this document uses two new attributes: Multiprotocol Reachable NLRI (MP_REACH_NLRI), and Multiprotocol Unreachable NLRI (MP_UNREACH_NLRI). The first one (MP_REACH_NLRI) is used to carry the set of reachable destinations together with the next hop information to be used for forwarding to these destinations. The second one (MP_UNREACH_NLRI) is used to carry the set of unreachable destinations. Both of these attributes are optional and nontransitive. This way a BGP speaker that doesn't support the multiprotocol capabilities will just ignore the information carried in these attributes, and will not pass it to other BGP speakers.
MPLS work in progress specific to Linux can be found at http://linux-vrf.sourceforge.net, and http://mpls-linux.sourceforge.net. You can find an MPLS implementation for NetBSD with Zebra integration at http://www.ayame.org.
UNIX MPLS implementations are at an early stage and require coexistence, hooks, and interfaces with several tools for beneficial operation:
- The kernel (multiple routing tables)
- iproute2
- iptables/netfilter
- mplsadm2
- Zebra/Quagga
- RSVP-TE (http://dsmpls.atlantis.rug.ac.be)
- Diffserv (http://diffserv.sourceforge.net)
NOTE
By the way, the ethereal packet analyzer is capable of decoding MPLS LDP (Label Distribution Protocol)
If You Enjoyed This Post Please Take a Second To Share It.
You Might Also Like
Stay Connected With Free Updates
 |
 |
 |
|
Subscribe via Email
|
