Blu3c4t's Journal

Few days ago, I read a posted news on Slashdot about BGP (Border Gateway Protocol) security vulnerability presentation by Alex Pilosov at DEFCON 16 Conference. His presentation is really interesting because of its attack scale and the damage which could be affecting Internet user. Then now, let's talk "little bit" about that .
-------------->>

[Background]

Generally, we can define the Internet is a network of networks. They are owned and operated by different companies, including Internet backbone providers. These networks are called Autonomous Systems (AS), which are managed independently. Those ASes connect with each other to provide connectivity to end-users. In order to provide connectivity across Internet, each AS must manage its own routing information as well as exchange routing information with other ASes. The interdomain routing is the type of routing across ASes. And the de facto interdomain routing protocol in use to route Internet traffic among backbone is Border Gateway Protocol.
Development Border Gateway Protocol itself has gone through several phases and improvements since its original version, BGPv1, in 1989. BGPv4 deployment began in 1993. It is the first BGP version that handles route aggregation (classless interdomain routing [CIDR]) and supernetting.
The BGP protocol is used to communicate information about networks currently residing (or homed) in an autonomous system to other autonomous systems. The exchange of network information is done by setting up a communication session between bordering autonomous systems. For reliable delivery of information, a TCP-based communication session is set up between bordering autonomous systems using TCP listening port number 179. This communication session is required to stay connected, which is used by both sides to periodically exchange and update information. When this TCP connection breaks for some reason, each side is required to stop using information it has learned from the other side. BGP imposes no restrictions on the underlying network topology. It assumes that routing within an autonomous system is done via an intra-autonomous system routing protocol (Interior Gateway Protocol [IGP]). BGP constructs a graph of autonomous systems based on the information exchanged between BGP routers. This directed graph environment is sometimes referred to as a tree. As far as BGP is concerned, the whole Internet is a graph of ASes, with each AS identified by a unique AS number. Connections between two ASes together form a path, and the collection of path information forms a route to reach a specific destination. BGP uses the path information associated with a given destination to ensure loop-free interdomain routing.

Internet: a conceptional graph view through clouds of autonomous systems connected by BGP sessions
Although unknown to most users, the Border Gateway Protocol (BGP) is critical to keeping the Internet running. BGP is a routing protocol, which means that it is used to update routing information between major systems. BGP is in fact the primary interdomain routing protocol, and has been in use since the commercialization of the Internet. Because systems connected to the Internet change constantly, the most efficient paths between systems must be updated on a regular basis. Otherwise, communications would quickly slow down or stop. Without BGP, email, Web page transmissions, and other Internet communications would not reach their intended destinations.

[How BGP Works]

AS numbers are managed by the Internet Corporation for Assigned Names and Numbers (ICANN), as of May 2007, the Internet included more than 25,000 advertised ASes. Packets that make up an Internet transmission, such as a request for a Web page, are passed from one autonomous system to another until they reach their destination. BGP's task is to maintain lists of efficient paths between ASes. The paths must be as short as possible, and must be loop-free. BGP routers exchange and store tables of reachability data, which are lists of AS numbers that can be used to reach a particular destination network. Active BGP entries (i.e., the number of reachable prefixes) in the Forwarding Information Base (FIB) table are currently approaching 300,000. The reachability information sent between ASes is used by each AS to construct graphs of Internet paths that are loop-free and as short as practical. Each AS will have many routers for internal communication, and one or more routers for communications outside the local network. Internal routers use internal BGP (iBGP) to communicate with each other, and external routers use external BGP (eBGP). (iBGP and eBGP are the same protocol, but use different routing rules; iBGP does not advertise third-party, outside routes).
Any two routers that have established a connection for exchanging BGP information are referred to as peers. BGP peers use TCP, the same protocol used for email and Web page transmissions, to exchange routing information in the form of address prefixes that the routers know how to reach, plus additional data used in choosing among available routes. When a BGP router starts, it attempts to establish sessions with its configured peer routers by opening connections to port 179, the standard BGP port. The router attempting to establish the connection receives packets on a random port number greater than 1024 (referred to as an ephemeral port). Autonomous systems can be categorized as either transit or non-transit. A transit AS is one with connections to multiple peer ASes, which will pass transit traffic between ASes. Large Internet service providers typically function as transit ASes. In most cases it will be easier to secure a non-transit AS because it is connected to only one neighbor AS. A transit AS, with multiple connections, can be more easily attacked and may require greater care in establishing filtering rules. However, a non-transit AS must ensure that it is not inadvertently being used for transit. This can be done by configuring BGP to announce only those networks that the AS specifically lists, and denying all others.
BGP is a path vector protocol used to carry routing information between autonomous systems. The term path vector comes from the fact that BGP routing information carries a sequence of AS numbers that identifies the path of ASs that a network prefix has traversed. The path information associated with the prefix is used to enable loop prevention.
Routers that run a BGP routing process are often referred to as BGP speakers. Two BGP speakers form a transport protocol connection between one another. They exchange messages to open and confirm the connection parameters.

BGP Routers become neighbors
Two types of BGP messages are important to BGP operation. First is KeepAlive message, which is sent periodically to ensure the aliveness of the connection. If the peers can't receive KeepAlive messages in a preset period of time, the BGP connection has to be closed. Physical connectivity failure (link failure, router crash), transient connectivity problems due to congestion, or even manual reboots, may result in the delay of KeepAlive message to the peers. Sequentially, when BGP sessions restart, the peers have to send the full routing table again. Second is the Update message. Update messages are used to exchange routing information change between two peers. Usually it has two forms: announcement and withdrawal. Announcement messages carry on the prefix (destination) and ASPATH. Upon receipt of a new Announcement, each router evaluates the path vector and use local decision algorithms to select the best route among all of the backup routes to that prefix. If the router is a transit router, it will append its unique AS number to the ASPATH and propagate to the downstream BGP speakers. Route withdrawals are sent when a router makes a new local decision that a network is no longer reachable.
BGP also provides a mechanism to gracefully close a connection with a peer. In other words, in the event of a disagreement between the peers, be it resultant of configuration, incompatibility, operator intervention, or other circumstances, a NOTIFICATION error message is sent, and the peer connection does not get established or is torn down if it's already established. The benefit of this mechanism is that both peers understand that the connection could not be established or maintained and do not waste resources that would otherwise be required to maintain or blindly reattempt to establish the connection. The graceful close mechanism simply ensures that all outstanding messages, primarily NOTIFICATION error messages, are delivered before the TCP session is closed.
Initially, BGP peers exchange their full routing tables. After that, incremental updates are exchanged as routing configurations change. Conceptually, each BGP router uses three tables, or routing information bases (RIBs):

• adj-RIB-In - routes learned from inbound update messages from BGP peers
• loc-RIB - routes selected from the adj-RIB-In table
• adj-RIB-Out - routes that the BGP router will advertise, based on its local policy, to its peers.

After the session has been established and the initial route exchange has occurred, only incremental updates are sent as network information changes. The incremental update approach has shown an enormous improvement in CPU overhead and bandwidth allocation compared with complete periodic updates used by previous protocols, such as EGP.

Exchanging all routing updates
Routes are advertised between a pair of BGP routers in UPDATE messages. The UPDATE message contains, among other things, a list of <length, prefix> tuples that indicate the list of destinations that can be reached via a BGP speaker. The UPDATE message also contains the path attributes, which include such information as the degree of preference for a particular route and the list of ASs that the route has traversed.
In the event that a route becomes unreachable, a BGP speaker informs its neighbors by withdrawing the invalid route. As illustrated in picture below, withdrawn routes are part of the UPDATE message. These routes are no longer available for use. If information associated with a route has changed, or a new path for the same prefix has been selected, a withdrawal is not required; it is enough to just advertise a replacement route.

Goes down; Partial update sent
And picture below, illustrates a steady state situation: If no routing changes occur, the routers exchange only KEEPALIVE packets.

Steady state N1 is still down
KEEPALIVE messages are sent periodically between BGP neighbors to ensure that the connection is kept alive. KEEPALIVE packets (19 bytes each) should not cause any strain on the router CPU or link bandwidth, because they consume a minimal amount of bandwidth (one instantaneous 152-bit packet every 60 seconds, or about 2.5 bps per peer for a periodic rate of 60 seconds).
BGP keeps a table version number to keep track of the current instance of the BGP routing table. If the table changes, BGP increments the table version number. A table version that increments rapidly is usually an indication of network instability (although this is quite common in large Internet service provider networks). Because of this, instability introduced by Internet-connected networks anywhere in the world will result in the table version number incrementing on every BGP speaker that has a full view of the Internet routing tables. Route flap dampening and other provisions have been designed to scope the effects of this instability.
Thus, in order to make decisions in its operations with other BGP peers, a BGP peer uses a simple finite state machine (FSM) that consists of six states: Idle, Connect, Active, OpenSent, OpenConfirm, and Established. For each peer-to-peer session, a BGP implementation maintains a state variable that tracks which of these six states the session is in. The BGP protocol defines the messages that each peer should exchange in order to change the session from one state to another. The first mode is the "Idle" mode. In this mode BGP initalizes all resources, refuses all inbound BGP connection attempts, and initiates a TCP connection to the peer. The second state is "Connect". In this state the router waits for the TCP connection to complete, transitioning to the "OpenSent" state if successful. If not, it resets the ConnectRetry timer and transitions to the "Active" state upon expiration. In the "Active" state, the router resets the ConnectRetry timer to zero, and returns to the "Connect" state. After "OpenSent," the router sends an Open message, and waits for one in return. Keepalive messages are exchanged next, and upon successful receipt, the router is placed in the "Established" state. Once established the router can now send/receive Keepalive, Update, and Notification messages to/from its peer.

BGP state machine

[BGP Injection]

BGP provides two essential services : first, the mapping of address prefixes (e.g., 192.168.0.0/16) onto the ASes that own them, and second, the construction of source specific paths to each reachable prefix. The interdomain routing topology is defined by physical links between adjacent ASes. Each AS originates the prefixes associated with a network by identifying and enumerating them in an UPDATE message sent to its neighbors (adjacent ASes). Received announcements are recursively concatenated with local AS numbers and propagated, AS by AS, to form a routing path. This path (also called a route) is used to forward network traffic to the origin. Note that an AS may receive many paths for a single prefix. The AS identifies the "best" path using the path selection algorithm. The selection algorithm determines the best route by evaluating path length, policy, and other factors. Only the selected best path is propagated. IP traffic is routed, hop-by-hop, based on the best path known by the AS.
Which route represents the best path is reevaluated each time a new route for a prefix is received. Suppression of non-best routes prevents undesirable routes from polluting the larger Internet, and is a key ingredient to the scalability of BGP. Recursive propagation of best routes ensures that every AS on the Internet acquires a route for every reachable prefix. A route is withdrawn when the AS discovers that the prefix is no longer reachable.
So mainly, we can divide BGP injection attacks become four type attacks which have "relationship" among them:
# Peer Spoofing and TCP Resets
Spoofing attacks are a concern for all network protocols. Spoofing refers to transmission of packets that are modified to make them appear as if they originate from somewhere other than their true source. With ordinary TCP connections under IPv4, it is easy to disguise the source address of an IP connection. When applied to BGP, this means that the spoofed source must be that of one of the BGP speaker's peer routers. The goal of the spoofing attack may be to insert false information into a BGP peer's routing tables. Peer IP addresses can often be found using the ICMP traceroute function, so BGP implementations should include countermeasures against this attack.
A special case of peer spoofing, called a reset attack, involves inserting TCP RESET messages into an ongoing session between two BGP peers. BGP is carried over TCP (the same protocol used for common Internet communications such as Web browsing). By monitoring communication between two BGP peers, an attacker may gain enough information to send a forged reset message to one of the routers.

TCP Reset Attack
When a reset is received, the target router drops the BGP session and both peers withdraw routes previously learned from each other, thus disrupting network connectivity until recovery, which may take several minutes to hours, depending on the number of BGP peers affected. This attack is more difficult to accomplish than spoofing the source of a new session, because in addition to the source IP address, the source port of the session must be known, and the sequence number must fit into the ongoing connection.
# Session Hijacking
Like the TCP reset attack, session hijacking involves intrusion into an ongoing BGP session, i.e., the attacker successfully masquerades as one of the peers in a BGP session, and requires the same information needed to accomplish the reset attack. The difference is that a session hijacking attack may be designed to achieve more than simply bringing down a session between BGP peers. For example, the objective may be to change routes used by the peer, in order to facilitate eavesdropping, blackholing, or traffic analysis.
# Malicious Route Injection
BGP exists to spread routing information across the Internet. Routers tell each other what prefixes they can reach and provide data on how efficiently they can reach addresses within these prefixes. In a benign, cooperative environment this works well, but a malicious party could begin sending out updates with incorrect routing information. For example, if my AS address space is 129.6.0.0/16 . Then suppose that I announce 129.6.0.0/16 through my BGP speaker. An attacker who announces a more specific route, such as a /24 address in my IP address space, would be able to divert packets that should be sent to my AS. This would occur because other routers would view the /24 as a more direct route to some of the addresses within my AS, so packets would be routed to the attacker's machine, which could observe and record the packets, data and address information. I would have no control over the routes announced by the attacker, other than contacting the attacker's service provider to request a correction, and it would be difficult to prove whether the mis-routing was malicious or accidental. In fact, I may not even see the attacker's route announcement, since it would be discarded locally by BGP to prevent route loops. Note that a similar risk occurs when an attacker gains control of a BGP router and forces it to announce a less specific route, such as a /15. In this case, traffic would flow to neighboring BGP routers that are announcing more specific (/16 or longer) paths, possibly overloading these routers.
And if the adversary wants to destabilize the network while remaining relatively clandestine, it can randomly drop a percentage of the traffic (called grey-holing). Note that it takes few drops to vastly reduce the throughput between the victim and the destination: each drop causes the congestion control algorithm to aggressively throttle traffic. Connection recovery is slow, and the attacker gains advantage with little effort. Paths may also be manipulated to route traffic through malicious ASes for monitoring. That is, if an adversary can redirect traffic (as above), then it can monitor, record, or even modify that traffic as it transits its network. Furthermore, an AS's ability to filter or rapidly advertise and withdraw advertisements leads to a range of DoS attacks that may easily render targeted networks unreachable.
Consequences could include eavesdropping - causing other nodes to route information through the attacker's node; and denial of service - traffic that otherwise would be forwarded efficiently is sent via slower routes or disappears entirely. Malicious route injection of this kind is possible because standard BGP has no authentication to guarantee the identity of BGP peers, and no authorization mechanism to ensure that a BGP peer has the authority to update routes to particular prefixes. Route filtering and MD5 authentication primarily address the first of these issues.
# Unallocated Route Injection
A particular variety of malicious route injection involves the transmission of routes to unallocated prefixes. These prefixes specify sets of IP addresses that have not been assigned yet, i.e., no one should be using these addresses, so no traffic should be routed to them. Therefore, any route information for these prefixes is clearly faulty or malicious, and should be dropped.

The risks in BGP arise from three fundamental vulnerabilities. BGP has no internal mechanism that provides strong protection of the integrity, freshness and peer entity authenticity of the messages in peer-peer BGP communications, no mechanism has been specified within BGP to validate the authority of an AS to announce Network Layer Reachability Information (NLRI), and no mechanism has been specified to ensure the authenticity of the path attributes announced by an AS.
BGP injection generally depends to the ability to spoof/malformed these UPDATE messages which can lead to a severe disruption of routing over a wide area.
AS_PATH:
There are two types of AS_PATH: AS_SEQUENCE and AS_SET. An AS_PATH of type AS_SEQUENCE consists of an ordered list of ASes traversed by the route in question. An AS_PATH of type AS_SET consists of an unordered list of ASes, sometimes created when multiple routes are aggregated. Due to space limitations, we focus on the security of AS_SEQUENCE. (Note: AS_SET is less widely used on the Internet. For example, as of August 1, 2004, only 23 of 17884 ASes originated 47 of 161796 prefixes with AS_SET). An AS_PATH is falsified if an AS or any other entity illegally operates on an AS_PATH, e.g., inserting a wrong AS number, deleting or modifying an AS number on the path, etc. Since AS_PATH is used for detecting routing loops and used by route selection processes, falsification of AS_PATH can result in routing loops or selecting routes not selected otherwise.

Changing traffic flow by AS_PATH falsification
We use picture above to illustrate how an attacker might influence traffic flow by manipulating AS_PATH. Suppose AS H multi-homes with D and B; H-D is a primary link and H-B is a backup link. In the normal situation, traffic destined to AS H and H's customers (e.g., AS J) should go through link H-D. When H-D fails, H-B should then be used. To achieve this traffic engineering objective, AS H can legitimately utilize AS_PATH to influence other ASes' routing decisions. For example, AS H announces (10/8, H-J) to AS D (normal BGP operation), but (10/8, H-H-H-J) to AS B (this is a legitimate traffic engineering technique). After the network converges on 10/8, all traffic to 10/8 will be forwarded over link D-H to AS H.
However, B can attract traffic destined to 10/8 by announcing a route to 10/8 with a fraudulent AS_PATH, e.g., (10/8, B-J). Note the AS PATH B-J is shorter than B-H-H-H-J which is supposed to be advertised by B. As a result, other ASes may select the route to 10/8 which goes through AS B. See table below for details of route changes. To summarize, traffic flow can be changed by falsification of AS_PATH.

Routes to 10/8 from each AS before and after B announces fraudulent (10/8, B-J) - Note the "after" route as listed herein may not actually exist.
Next_hop :
The NEXT_HOP attribute defines the IP address of the border router that should be used as the next hop when forwarding the NLRI listed in the UPDATE message. If the recipient is an external peer, then the recipient and the NEXT_HOP address must share a subnet. It is clear that an outsider modifying this field could disrupt the forwarding of traffic between the two AS's.
In the case that the recipient of the message is an external peer of an AS and the route was learned from another peer AS (this is one of two forms of "third party" NEXT_HOP), then the BGP speaker advertising the route has the opportunity to direct the recipient to forward traffic to a BGP speaker at the NEXT_HOP address. This affords the opportunity to direct traffic at a router that may not be able to continue forwarding the traffic. A malicious BGP speaker can also use this technique to force another AS to carry traffic it would otherwise not have to carry. In some cases, this could be to the malicious BGP speaker's benefit, as it could cause traffic to be carried long-haul by the victim AS to some other peering point it shared with the victim.
Local_pref:
The LOCAL_PREF attribute must be included in all messages with internal peers and excluded from messages with external peers. Consequently, modification of the LOCAL_PREF could effect the routing process within the AS only. Note that there is no requirement in the BGP RFC that the LOCAL_PREF be consistent among the internal BGP speakers of an AS. As BGP peers are free to choose the LOCAL_PREF as they wish, modification of this field is a vulnerability with respect to outsiders only.
Atomic_aggregate:
The ATOMIC_AGGREGATE field indicates that an AS somewhere along the way has aggregated several routes and advertised the aggregate NLRI without the AS_SET formed as usual from the AS's in the aggregated routes'AS_PATHs. BGP speakers receiving a route with ATOMIC_AGGREGATE are restricted from making the NLRI any more specific. Removing the ATOMIC_AGGREGATE attribute would remove the restriction, possibly causing traffic intended for the more specific NLRI to be routed incorrectly. Adding the ATOMIC_AGGREGATE attribute when no aggregation was done would have little effect, beyond restricting the un-aggregated NLRI from being made more specific. This vulnerability exists whether the source is a BGP peer or an outsider.
So, by modifying or forging NLRI field, either an outsider or BGP peer source could cause disruption of routing to the announced network, overwhelm a router along the announced route, cause data loss when the announced route will not forward traffic to the announced network, route traffic by a sub-optimal route, etc.

[Countermeasures]

These are problems of BGP security which become holes or ways to do BGP injection:

a. Hop Integrity
A computer network is said to provide hop integrity if and only if the following condition holds for every pair of adjacent routers P and Q in the network. When Q receives a message m supposedly from P, then Q can check that m was not modified after it was sent by P, and that m was not a replay of an old message sent long ago by P.
In BGP, hop integrity is not provided. BGP should provide following to satisfy hop integrity :

• Data integrity: A verification performed at each hop to assure that the data in a message has not been modified, destroyed, lost, or replayed in an unauthorized or accidental manner.
• Source authentication: A verification performed at each hop to assure that the sender of a message is who it claims to be and not a pretender.

b. Origin authentication
Origin authentication is a corroboration (such as by using a digital signature) that the origin of a message or data is as claimed. Origin authentication is validation of AS claims of address ownership. After it has been determined that a BGP router is authenticated, the next logical step is to determine if that BGP router is authorized to advertise the information it had sent. Addresses on the Internet are matched to ASes through a hierarchical network of issuing authorities and organizations. Origin authentication should ask questions such as "Is AS1024 authorized to advertise the prefix 120.40.0.0/16 ?".
c. Path Validation
Path validation is process of validating :

• All the digital certificates in a certification path
• The required relationships between those certificates, thus validating the contents of the last certificate on the path.

Inside a BGP UPDATE message sent by BGP router, each announced prefix has an associated AS path to that prefix. Path validation ensures that the path is valid (each BGP router in the path is accessible from the previous BGP router), and each AS on the path is authenticated.


Many solutions have been proposed for securing BGP. Here we describe some of BGP security proposals: S-BGP, soBGP, IRV, and psBGP.
1. S-BGP (Secure BGP)
S-BGP proposes use of two strict hierarchical PKIs and other mechanisms (e.g., IPsec) for securing BGP. The proposed S-BGP PKIs are parallel to the existing allocation and delegation systems for AS numbers and IP address space. A single Certificate Authority (CA) rooted at IANA/ICANN was initially proposed for S-BGP, but it evolved to multiple CAs rooted at four RIRs due to political sensibility and security considerations.
2. IRV (Interdomain Route Validation)
IRV defines a service that protects against completely ruined, or misconfigured ASes, and is used to identify and diagnose routing configuration problems. IRV relies on out-of-band communication with a route originator to verify the correctness of a route.
3. soBGP (Secure Origin BGP)
soBGP proposes use of a web-of-trust model for authenticating AS public keys and a hierarchical structure for verifying IP prefix ownership. Each AS has a public key certificate, binding an AS number with a public key, signed by a "trusted" public key. To bootstrap trust, a small number of "root public key certificates" are distributed using out-of-band mechanisms. Some tier-1 ISPs and well-known authentication service providers (e.g., Verisign) are suggested to be candidates of trusted public key certificate authorities. An AS with a trusted AS public key certificate (e.g., signed by a trusted CA) may further sign a public key certificate for another AS, thus naturally forming a web-of-trust model. While a web-of-trust model has strong proponents for authenticating user public keys within the technical PGP community, it would appear to be less suitable for authenticating public keys of ASes which are identified by AS numbers strictly controlled by IANA; thus it is questionable if any entity other than IANA should be trusted for signing AS public key certificates.
4. psBGP (Pretty Secure BGP)
Pretty Secure BGP (psBGP) in essence combining best features from S-BGP and soBGP. psBGP makes use of a centralized trust model for authenticating AS numbers, and a decentralized trust model for verifying IP prefix ownership; the latter is in line with the IAB recommendations. One advantage of psBGP is that apparently it can successfully defend against threats from uncoordinated, misconfigured or malicious BGP speakers in a practical way.



As originally designed, BGP has no built-in security functionality. Several alternative BGP protocols like I mention before have been proposed, but none widely implemented. Alternatively, one practical approach today to securing BGP is to adopt these countermeasures.
a. The Secure BGP Template
The Secure BGP Template is a useful collection of BGP configuration settings for Cisco routers, made available by Team-Cymru. It is widely used and should be considered during the procurement and configuration of BGP. This section provides a non-vendor specific discussion of the secure BGP template; following sections cover many of the topics noted here, and other security mechanisms, in
greater depth.
b. Prefix Filtering
Prefix filtering is the most basic mechanism for protecting BGP routers from accidental or malicious disruption. Filtering of both incoming prefixes (ingress filtering), and outgoing prefixes (egress filtering) is needed. Router filters are specified using syntax similar to that for firewalls. One option is to list ranges of IP prefixes that are to be denied, then permit all others. Alternatively, ranges of permitted prefixes can be specified, and the rest denied. This option will normally provide greater security. The choice of which approach to use depends on practical considerations determined by system administrators. Normally, BGP peers should have matching prefix filters, i.e., the egress filters of an AS should be matched by the ingress filters of peers with which it communicates. For example, if AS 100 filters its outgoing prefixes to only those in set P, and AS 200 is a BGP peer, then AS 200 establishes ingress filters to ensure that the prefixes it accepts from AS 100 are only those in set P. This approach helps to reduce the risk from attackers that seek to inject false routes by pretending to send updates from AS 100 to its peers. Attackers can of course still send faulty routes to the prefixes in set P, but filtering helps to limit the damage to these routes and no further.
c.Sequence Number Randomization
Because packet-based networks allow packets to take a variety of paths through the network, some messages may be received in a different order than they were sent. TCP, over which BGP is transported, uses sequence numbers to ensure that packets are assembled into the correct order by the receiving system. On establishing a connection (Figure 4-1), the systems at either end of the connection exchange an Initial Sequence Number that should be selected at random from a range of 32-bit integers. The sequence number is incremented with each message, making it possible to determine the correct order in which to reassemble packets, which comprise pieces of a message. The receiving system will accept packets that are within a configurable window around the sequence number for the session. Packets outside of the window are assumed to be in error (e.g., possibly duplicated or late), and are discarded.

TCP Sequence Number Establishment
Sequence numbers were designed to allow for reassembly of messages and protect against transmission errors. They also provide a minimal protection against session hijacking and message spoofing because an attacker must be able to predict the correct sequence number for a session to fool the victim system into accepting the forged packet as legitimate. Ideally, initial sequence numbers should be chosen at random, so that an attacker has a probability of only 2^32 of guessing the correct number. Unfortunately, many operating systems and network devices have flawed algorithms that do not provide good initial sequence number randomization, making it possible for a sophisticated attacker to forge messages for session hijacking or spoofing. The risk of these attacks can be reduced by ensuring that vendor patches for sequence number algorithms are up to date. Stronger defense is provided by using IPsec to fully protect TCP and BGP messages.
d. Generalized TTL Security Mechanism (TTL Hack)
The Time to Live (TTL), or "hop count", field is an 8-bit field in each IP packet that prevents packets from circulating endlessly in the Internet. At each network node, the TTL is decremented by one, and is discarded when it is reduced to zero without reaching its destination. The TTL serves a variety of purposes for Internet protocols, since it provides a count of the number of nodes through which a packet has passed, simply by subtracting its current value from its initial value. As the Internet has grown, the number of nodes through which a packet may pass has increased. It is not unusual for 20 or more hops to be required before a packet is finally received, so a packet that starts with a value lower than this has a high probability of being discarded before it reaches its intended destination. For normal communication, a TTL initial value of 64 is typically used.
TTL processing
The Generalized TTL Security Mechanism (GTSM, RFC 3682), often referred to as the "TTL hack", is a simple but effective defense that takes advantage of TTL processing. As noted, normal communications such as e-mail or Web browsing often require 20 or more nodes to reach their destination, and this value varies depending on the application. With BGP, however, peers are normally adjacent, thus only one hop should be required for a packet sent in a BGP message. A BGP message that has passed through multiple nodes is therefore almost certainly either an error or a packet from an attacker. The TTL hack sets the TTL to 255 on outgoing packets. Since routers decrement the TTL field by one when a packet is forwarded, adjacent peers should see incoming packets with TTL = 255. (Note that some implementations decrement the TTL before processing, in which case the incoming packets should have TTL = 254.) A lower value is an indication that the packet originated from somewhere other than the neighboring peer router. (Note that it is impossible for the packet to start with an initial value above 255, because the TTL field is an 8-bit value.) When implementing the TTL hack, it is also possible to set an expected incoming value below 255 on a per-peer basis when the peer is a known number of hops away, allowing a small variation to allow for changes in topology. For example, if the peer is known to be one hop away, the adjacent peer should reject packets with a TTL < 254. One limitation with the TTL hack is its availability. Code implementing RFC 3682 is provided on newer routers from major vendors, but may not always be included on older, or "legacy", routers, so not all organizations may be able to deploy it.

BGP TTL Hack
e. MD5 Signature Option
The MD5 hash algorithm (RFC 2385) can be used to protect BGP sessions by creating a keyed hash for TCP message authentication. MD5 takes a variable length message and computes a fixed length "digest", a 128-bit cryptographic hash (checksum) value, for each packet using a secret key that is shared by both ends of the session. Because MD5 is a cryptographic algorithm, rather than a simple checksum such as CRC32, it is computationally difficult to determine the MD5 key from the hash value. MD5 is designed so that a single bit change to a packet will produce a different hash value, so the receiving peer can be reasonably certain that no changes, deletions, or insertions have been made to BGP messages. BGP peers can include an MD5 value with each message, and the receiving peer checks to ensure that the value matches that computed using the shared secret key. If the values do not match, or the MD5 checksum is missing, the message is discarded. MD5 provides protection against TCP-based attacks such as spoofing and session hijacking, because the attacker must know the secret key used in the hash computation. Commercial routers offer MD5 as a configuration option, and it is relatively easy to set up, using one or two statements in configuration files.
A disadvantage is that a secret key must be shared between every pair of peers, and the keys must be updated periodically to prevent brute force cracking by an attacker who has accumulated a large volume of messages. In a large operation this can be expensive and time-consuming. An additional consideration is that, because MD5 uses a shared secret key, keys must be changed at the same time by both ends of the BGP connection, so administrative errors can result in disruption to routing operations. Because password crackers are widely available, which can also be used for cracking keys, strong keys should be chosen. See the key selection and management guidelines in RFC 3562.
f. IPsec
In evaluating the security of a BGP configuration, it is important to keep in mind that BGP is transported over the standard TCP protocol. While randomized sequence numbers and the TTL hack can make an attacker's job more difficult, they are not cryptographically secure. Whenever an attacker has access to unencrypted traffic between BGP peers, these systems are vulnerable to a variety of TCP-based attacks, such as peer spoofing and session hijacking. The only comprehensive solution to these vulnerabilities is a cryptographic protocol such as IPsec. IPsec is an IP layer protocol, so standard BGP can use IPsec without modification. IPsec can provide both authentication and data encryption (see RFC 4301), and thus could be used instead of MD5 authentication. Where only authentication is needed, the Authentication Header (AH) option can be used at the IP layer. An added layer of protection is available using the Encapsulating Security Payload (ESP) option to encrypt the data passed in BGP updates. Alternatively, IPsec tunneling can provide encryption of BGP data. The principal disadvantage of IPsec is the need to coordinate keys with BGP peers, as with MD5. Additionally, the strong encryption used with IPsec can be resource-intensive, adding processing load to routers that may be already close to overload. In most cases, encryption of BGP data should not be needed, since the information is expected to be passed throughout the Internet anyway, so using only cryptographic authentication (IPsec or MD5) may be the most cost-effective approach to adding security.
g. BGP Protocol Variations and Configuration
BGP implementations vary in their handling of protocol events, and some configuration changes can affect how events are handled as well. Some investigations suggest better BGP security or dependability with some protocol variations, as described below. It is not clear that these options are always preferred, but administrators should review the following list and evaluate whether the findings are relevant to their system and configuration.

BGP Event Handling


[Conclusion]
BGP routing protocol is very stable and reliable in the transmission of routing data. But security is not provided within interdomain routing protocols, so that it's still vulnerable to be attacked with various kind of injection types.
BGP is an critical infrastructure protocol. That is, it is a service that is used to keep the Internet running, so a major risk to Internet operations from attacks on BGP is either local or widespread outage of service. Improving the dependability of systems subject to denial of service attacks can be done in two ways increase the difficulty of an attack, or reduce the time needed to recover from such an attack.