Welcome to Volume 2, Issue 5 of The Internet Security Conference Newsletter, Insight. Insight provides commentaries and educational columns, authored by some of the best minds in the security community.
The editorial calendar at this time includes:
For previous Insight issues, click here.
TISC is about sharing clue. So is the newsletter. If we fail to provide something *useful* each issue, complain directly to me.
In this issue, Steven Kent describes security enhancements to the Border Gateway Protocol, the routing protocol used (primarily) to determine routing and Policy information among the Autonomous Systems that comprise large multi-organizational internetworks. The security enhancements Steve describes offer ways to protect BGP from attacks or misconfigurations that would cause BGP to operate incorrectly. Such attacks could disrupt global connectivity and communication.
Enjoy, and be safe,
Dave
The Border Gateway Protocol (BGP) is the glue that connects together the major networks that compromise the Internet. BGP is used to exchange routing information between ISPs (and major, dual-homed subscriber networks), so that each of these networks (Autonomous Systems or ASs in BGP parlance) knows how to route traffic to other parts of the Internet. BGP UPDATE messages are exchanged by the routers that represent each AS to its neighbors, to announce changes to existing routes, introduction of new routes, and withdrawal of old routes. Attacks against BGP can undermine the Internet routing infrastructure, resulting in diversion and non-delivery of subscriber traffic ("black hole" routing). No significant attacks against the BGP system have been detected so far, but errors by the individuals who maintain the BGP databases in several ISPs have resulted in outages analogous to what would happen as a result of an attack.
The primary security requirement for BGP is one of correct operation, i.e., attacks that cause the system to behave differently than it would under normal operation should be detected and rejected. The attacks could be launched in many ways. An attacker could send spurious BGP traffic (active wiretapping), or could attack the workstations used for management of the routers, and thus attack the system indirectly. An ideal security solution for BGP should embody the principle of least privilege, i.e., a security breach at any BGP router or ISP should not cause other ISPs to misbehave.
The BGP packet format includes a field intended to authenticate and integrity check the contents of the packet. This mechanism, if it were employed, would offer protection only against wiretapping attacks effected on the links between BGP routers. In practice, this field is not used; instead, a modified form of TCP checksum, based on a keyed MD5 hash algorithm, is sometimes employed. By performing the same sort of security function at a lower layer, the TCP traffic is also protected, avoiding attacks such as spurious TCP RESET messages. However, this sort of point-to-point security does not address accidental "attacks" by ISP staff, or more sophisticated attacks launched by compromising BGP routers or associated management systems.
S-BGP is a security-enhanced version of BGP developed under DARPA and NSA funding over the last 4 years. It protects all BGP traffic on a point-to-point basis, and protects UPDATE messages in a way that prevents attackers (including compromised, otherwise legitimate routers) from undetectably tampering with routing data, or making assertions about routes that are not consistent with network topology or with the policies of other ISPs. S-BGP ensures that an UPDATE originated from an ISP that was authorized to advertise a specified portion of IP address space (by the "owner" of that address space), and that each ISP along the path has authorized the next to advertise that portion of IP address space.
S-BGP makes use of several security mechanisms to protect against a wide range of attacks, and even against errors by authorized personnel maintaining BGP routers. First, S-BGP calls for the use of IPsec to protect all BGP traffic between routers, in lieu of the keyed MD5 checksum for TCP. The automated key management features of IPsec will ensure better security for the keys used for point-to-point protection, and the cryptographic integrity check is stronger than the keyed MD5 mechanism. S-BGP also relies on the creation of two Public Key Infrastructures (PKIs). One PKI parallels the allocation of IP address space from ICANN, to registries, to ISPs, to subscribers, and the second matches the allocation of Autonomous System numbers to ISPs and subscribers. Finally, S-BGP defines two digitally signed data structures: address attestations and route attestations. The former are generated from the IP address space PKI noted above, while the latter are created by BGP routers, and rely on the other PKI noted above.
S-BGP defines a new, optional path attribute for BGP UPDATE messages, taking advantage of the extension features designed into BGP. In S-BGP, an UPDATE contains a sequence of route attestations, each signed by an ISP along the path. This sequence nominally terminates with an address attestation, anchoring the path. By validating the signatures of these attestations, using the PKIs described above, a router can determine if any router along the path has attempted to act outside of the scope of its authorization. Thus S-BGP satisfies the principle of least privilege.
This security does not come for free. The addition of attestations significantly increases the size of BGP UPDATE messages. But since such messages comprise a very tiny percentage of all traffic carried in the Internet, the added transmission overhead is quite tolerable. To avoid overloading UPDATEs, address attestations are not sent with each UPDATE, nor are the public key certificates needed to validate address and route attestations. All BGP routers require access to all the address attestations and certificates, because they must be able to verify UPDATEs for all of the IP address space. Thus it makes more sense to distribute them in bulk, e.g., from servers located at peering points. Each ISP can retrieve these signed data items and validate them prior to downloading them to the routers in its AS. (This also avoids the need for these routers to process all of the signatures on the certificates and address attestations.) The certificate and address attestation database occupies about 40M bytes, including pointers and similar data structure overhead.
Based on analysis of recent BGP traffic, a router would have to verify an average of 3.6 signatures on each received UPDATE, and generate one signature on each UPDATE it sends. Peak signature validation rates, encountered by routers at large peering points, might be as high as about 18 signatures per second, still within the range of what can be accomplished using software on a general purpose processor. (The verification figure can be halved by caching the route attestations associated with the previous UPDATE received from each neighbor AS.)
The storage requirements imposed by adding route attestations to UPDATEs are about 30M bytes per neighbor, which could add up to over 500M bytes at a major peering point. This exceeds the storage capacity of currently deployed routers. Thus, one cannot immediately deploy S-BGP in the Internet today, primarily because of storage (vs. digital signature performance) limitations. However, storage density follows Moore's Law, and the routers that execute BGP are typically high end models, where the cost of added memory would not be very significant.
So, where are we today? S-BGP is a promising technology for significantly improving the security of the Internet routing infrastructure. However, before it can be deployed, three things must happen:
Obviously, these actions will not happen overnight. A concerted, coordinated effort is required by several players to make S-BGP a reality. However, if we do not secure the Internet routing infrastructure, the consequences could be severe. The recent spate of distributed denial of service attacks illustrates the growing sophistication of attackers, and shows that breaking into systems is not the only form of attack of interest.
The following papers, internet draft, and web site provide more information on S-BGP: