Ole,
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].
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.
I thoroughly enjoy IPJ and look forward to each issue. Keep up the great work.
The author responds:
Ole,
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!