The Internet Protocol Journal - Volume 6, Number 4

Letters to the Editor


I just finished reading the article about Secure BGP [Border Gateway Protocol] by Stephen T Kent. It was very informative and educational with regard to the application and overhead of using the additional BGP attributes and IPSec [IP Security]. However, it should be noted that the reliance of a PKI [Public Key Infrastructure]-based system, although strong, may also present another possible exploit. If the PKI KDS (Key Distribution System) is attacked and subsequently knocked out, including redundant Key Distribution Engine (KDE) servers, this may cause serious ramifications to the operation of Secure BGP [SBGP].

Here is a very informative link regarding S-BGP resources for your readers:

Also, did you know that the North American Operators' Group (NANOG) in conjunction with Cisco engineers recently conducted a BGP vulnerability test? This test confirms that BGP implemented properly is pretty secure in and of itself, without the need for something like S-BGP. The article, titled "BGP Vulnerability Testing: Separating Fact from FUD," was written by Sean Convery and Matthew Franz, Cisco Systems. The article can provide a contrast to the one submitted by Kent and give the technical community both sides of the BGP security issues. Following is the link:

I thoroughly enjoy IPJ and look forward to each issue. Keep up the great work.

—Jeffrey J. Sicuranza, Applied Methodologies Inc.

The author responds:


Jeffrey makes a few observations about S-BGP in his letter, and they merit responses.

First, I would hope that the discussion of the security features of S-BGP and their direct derivation from the semantics of BGP was as informative as the discussion of performance aspects of the system. After all, a system with good performance but questionable security is probably a poor candidate to S-BGP routing.

Jeffrey raises the question of whether the reliance of S-BGP on certificates, CRLs [Certificate Revocation Lists], and address attestations creates significant vulnerabilities that need to be addressed. This is a fair question, but one which I think we have addressed.

The data that S-BGP stores in repositories is data that changes slowly, and thus the system tolerates unavailability of these repositories fairly well. Note that no router ever accesses these repositories in order to verify a route attestation received in an UPDATE. Instead, each ISP [Internet Service Provider] or multihomed subscriber NOC [Network Operations Center] accesses the repositories to retrieve this data, process it, and distribute the extracted public keys and authorization data to the routers in its network. We anticipate that this process might occur roughly every 24 hours. Because the information represented by the signed objects in the repositories changes very slowly, this retrieval rate seems appropriate. One would expect that these repositories can be engineered to meet these availability requirements. In the worst case, network operators can choose to keep working with the last set of data that they have successfully retrieved. This works because operators process the data before distributing it to their network, and thus can override expired CRLs, etc. So, I think the answer to Jeffrey's cited concern is that S-BGP is not very vulnerable to attacks against these repositories.

I strongly disagree with the conclusions Jeffrey draws from the BGP vulnerability tests he cites. Numerous incidents of BGP security breaches have been reported over the last few years, so there is no question that BGP, as implemented, deployed, and operated, is insecure. Correct implementation of BGP and improved network operator management practices certainly can reduce BGP vulnerabilities. However, the article in question is hardly a refutation of the wide range of vulnerabilities that exist both in practice and in principle. Much of it focuses on a narrow range of attacks, not broader security concerns.

In addressing broader security concerns, for example, the article argues that proper filtering of routes will mitigate the impact of a compromised router. But we know that such filtering is not feasible for many transit network connections, and route filterers are prone to configuration errors. Reliance on transitive trust (for example, assuming that peers filter routes appropriately) makes BGP intrinsically insecure. Relying on all ISP operators to never make exploitable errors in configuring their route filters, where such filters can be used, is a fundamentally flawed security approach. S-BGP accounts for the reality that not every ISP will operate its network perfectly, and employs mechanisms to allow other ISPs to detect and reject a wide class of errors (or attacks) that may result from such imperfect operation. Thus I reassert that the security vulnerability characterizations that appear in the S-BGP publications are accurate, not overblown.

As a side note, I find it odd that some critics of S-BGP argue that it fails to account for operational reality, yet they offer alternatives that are based on unrealistic assumptions about network operators acting perfectly!

—Steve Kent, BBN Technologies