Internet DRAFT - draft-white-sobgp-bgp-extensions
draft-white-sobgp-bgp-extensions
Network Working Group Russ White
Internet Draft (editor)
Expiration Date: March 2003 Cisco Systems
File Name: draft-white-sobgp-bgp-extensions-00.txt October 2002
Deployment Considerations for Secure Origin BGP (soBGP)
draft-white-sobgp-bgp-extensions-00.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet Drafts are working documents of the Internet Engineering
Task Force (IETF), its Areas, and its Working Groups. Note that other
groups may also distribute working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet
Drafts as reference material or to cite them other than as a "working
draft" or "work in progress".
The list of current Internet-Drafts can be accessed at
http//www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http//www.ietf.org/shadow.html.
1. Contributors
A large number of people contributed to this draft; we've tried to
include all of them here (but might have missed a few). From Cisco,
James Ng, Tim Gage, Alvaro Retana, and Dave Cook.
White, et. all [Page 1]
INTERNET DRAFT Secure Origin BGP (soBGP) October 2002
2. Abstract
There is a great deal of concern over the security of routing systems
within the Internet, particularly in relation to the Border Gateway
Protocol [BGP], which is used to provide routing information between
autonomous systems. This draft addresses various deployment scenarios
and options using the extensions to BGP outlined in [SOBGP-BGP] in
conjunction with [SOBGP-KEY] (which is not yet completed or
published) and [SOBGP-RADIUS]. Each section of this draft discusses a
different deployment situation or deployment option. The final
section discusses how private key rollovers can be accomplished with
no loss of routing information within soBGP deployments.
3. Overview of the Deployment Scenarios
Each section below discusses a possible deployment option for soBGP;
each could be seen as a separate deployment option, or they could be
seen as a set of incremental steps from a very simple soBGP
deployment in a small network to a large soBGP deployment across an
internetwork.
4. Deploying soBGP within Single Devices Along Autonomous System Edges
In it's simplest form, soBGP can be deployed entirely within BGP
speakers at the edge of an Autonomous System (AS).
+-(eBGP)-+ +-(eBGP)-+
| | | |
v v v V
A--------B-----C-----D--------E
^ ^
| |
+--(iBGP)---+
In this network, A is sending all the ECs, SCs, and ACs
(certificates) it has learned from other sources to B using the
SECURITY message type. It is passing these certificates to D via
iBGP, and D is passing these certificates to E via eBGP. Suppose that
B receives from A an EC for some AS, say 65400, which has been signed
by a third party that B trusts. B would insert this EC from AS 65400
into its local EC database.
B can also use the connected transit AS information contained within
White, et. all [Page 2]
INTERNET DRAFT Secure Origin BGP (soBGP) October 2002
the SCs to build a directed graph of the internetwork's topology,
with each AS being a node on the graph.
Suppose A also advertises an AC authorizing AS 65400 to advertise
addresses within the 10.1.0.0/16 block. B would:
o Look up the authorizing AS within the AC in the EC data-
base, and retrieve the validated public key for that AS.
Verify the signature on the AC using this public key.
o Verify that the serial number on the AC falls within the
range defined by the start AC serial and end AC serial
within the EC.
o If all of these checks pass, enter this AC in its local
database as being verified and valid.
Suppose that A advertises some prefix to B, 10.1.1.0/24, sourced from
AS 65400. B would:
o Look up the prefix within the AC database.
o Examine the origin AS within the route, verifying it against the
authorized AS within the AC database.
o Examine the AS path included with the route, validating that it is
actually a valid path through the internetwork between the source
and the local AS.
o If each of these tests are verified, install the route in the Adj-
RIB-In.
5. Deploying soBGP with EC Distribution Within the BGP Protocol and
Reflection within an AS
A slightly more complex deployment would continue to distribute the
entity and authorization certificates through the BGP protocol, using
the SECURITY message type outlined in [SOBGP-BGP], but would offload
the work of validating the information to a locally reachable server
running RADIUS.
+--(iBGP)--+
+-(eBGP)-+| |+-(eBGP)-+
| || || |
v vv vv V
A--------B-----C-----D--------E
White, et. all [Page 3]
INTERNET DRAFT Secure Origin BGP (soBGP) October 2002
/
^ / ^
| / |
| +-F-+ |
| (Server) |
| ^ ^ |
| | | |
(iBGP)-+ +-(iBGP)
In this network, A is sending soBGP certificates towards B, along
with routing updates and other information. While B is peering
through iBGP with D, it is not sending soBGP certificates through
this iBGP session; it does not negotiate sending the SECURITY message
type to D. B is peering through iBGP to F, a server, but only nego-
tiates carrying the SECURITY message type along this session, so that
F only receives soBGP certificates, and no routing updates. F
reflects these soBGP certificates to D, which then transmits them to
E.
As F receives ECs from B, it will validate the information carried in
the EC using the signature from a third party it already trusts, and
places them in a local EC database. F can use the attached transit AS
information contained in each PC to build a directed graph represent-
ing the internetwork's topology.
Suppose A transmits an AC authorizing AS 65400 to advertise prefixes
within the 10.1.0.0/16 block:
o B would forward this AC on to F.
o F would examine its local EC database, and find the EC of the AS
which authorized 65400 to advertise this block of addresses.
o F would use the public key contained within that EC to verify
the signature on the AC.
o F would then check the serial number of the AC against the start
AC serial number and the end serial number found in the EC.
o If these checks succeed, F would place this AC in a local data-
base of verified ACs.
Suppose A advertised reachability to 10.1.1.0/24 to B:
o B would build an authorization request, as described in [SOBGP-
RADIUS], and transmit it to F.
o F would examine it's local AC database to determine if it has a
White, et. all [Page 4]
INTERNET DRAFT Secure Origin BGP (soBGP) October 2002
valid AC which covers this address space.
o On finding such an AC, F would then examine the origin AS in the
advertisement, and determine if the route is, in fact, being
originated by an authorized AS.
o F may also examine the AS path contained in the route and deter-
mine if this is a valid path through the internetwork.
o If the checks succeed, F will build a reply, as described in
[SOBGP-RADIUS], and transmit this to B.
o On receiving the reply, B will install the route in the Adj-
RIB-In.
It is also possible to bypass the edge routers in distributing the
soBGP certificates within the SECURITY message type.
+--(iBGP)--+
+-(eBGP)-+| |+-(eBGP)-+
| || || |
v vv vv V
A--------B-----C-----D--------E
/
^ / ^
| / |
| +-F-+ |
| (Server) |
| ^ ^ |
| | | |
+-----(eBGP)-+ +-(eBGP)-----+
Here, A and B are peering using eBGP, but are only exchanging route
information, and not the SECURITY message type. A and F are peering
over a multihop eBGP session, and exchanging only the SECURITY mes-
sage type. B and D no longer have any security information at all;
they request information on the validity of any received route from F
using the method described in [SOBGP-RADIUS].
Since F is relying only on the interior routing within the local AS
to reach the edge of the AS (to reach the link between A and B), the
eBGP multihop session is not relying on routes learned from BGP
itself to secure BGP.
The eBGP session which F is learning from could also be multihop to
another soBGP server in an adjacent AS, rather than to an edge
router.
White, et. all [Page 5]
INTERNET DRAFT Secure Origin BGP (soBGP) October 2002
+-(iBGP)-+ +--(iBGP)--+
| |+-(eBGP)-+| |+-(eBGP)-+
| || || || |
v vv vv vv V
G---------A--------B-----C-----D--------E
| /
| / ^
H / |
(Server) +-F-+ |
^ (Server) |
| ^ ^ |
| | | |
+---------------(eBGP)-+ +-(eBGP)-----+
Now, H, A, B, C, D, and E are all exchanging NLRI information only,
while F and G are exchanging only SECURITY messages. In this case, B
must be manually configured to trust the route to G learned from A,
and A must be manually configured to trust the route to F learned
from B (or they must use static routing, or some sort of temporary
acceptance of the learned routes until the SECURITY messages are all
exchanged), to prevent the circularity problem mentioned above. This
is more complex than the previous deployment options discussed above.
6. Deploying soBGP with EC Distribution Outside the BGP Protocol
It is also possible to deploy sobGP without carrying any of the ECs
or SCs within the SECURITY message type within BGP.
(-----)
(AS65401)
( )
+----C D----+
| (-----) |
(---------) | | (---------)
( AS65400 ) | | ( AS65402 )
( B-+ +-E )
( Server A ) ( Server F )
(---------) (---------)
Suppose AS65400 issues an EC signed by a third party, and then issues
an AC issued by a separate third party (in this case, most likely
AS65401), authorizing it to advertise addresses within the
10.1.0.0/16 block. B advertises the AC, in which is embedded a URL to
the EC which resides on A, to C. C passes this AC through AS65401,
and advertises it to AS65402 through E. E passes this AC to F.
White, et. all [Page 6]
INTERNET DRAFT Secure Origin BGP (soBGP) October 2002
F examines this AC, and determines that in order to retrieve the EC
which is needed to verify it, it must attach to A. The problem here
is that F cannot reach A at this point; in fact, this is the very
route it is attempting to verify. Thus, the circularity problem
prevents soBGP from being deployed in this manner. We can resolve
this problem by placing a server in AS65401.
(-------)
( AS65401 )
( Server G )
( )
+---- C D----+
| (-----) |
(---------) | | (---------)
( AS65400 ) | | ( AS65402 )
( B-+ +-E )
( Server A ) ( Server F )
(---------) (---------)
Now, AS 65401 can provide, as a service to AS65400, the service of
storing the correct ECs on G. When AS65400 advertises its AC, it can
place a URL on A and G as the locations of the EC which will validate
this AC.
If E and D are configured to trust the path to G and the path to F,
respectively, then the sequence of events would be:
o F receives the AC from AS65400 though iBGP peering with E; E has
received this AC from D, which obtained it through AS65401's
peering with AS65400.
o F examines this AC, and then attempts to reach the first URL
listed as a location to retrieve the appropriate EC. Suppose
this is a URL which resides on A.
o After some time, F then attempts to access the second URL, which
resides on G.
o Since the path to and from G are manually configured as trusted
paths, F reaches G, and retrieves the appropriate EC to validate
this AC.
o Once the EC is retrieved, it is validated by checking the third
party signature, either from another EC already in the local EC
database, or through some manually configured local information.
o Once the retrieved EC is validated, the AC is validated using
the public key contained in the EC.
White, et. all [Page 7]
INTERNET DRAFT Secure Origin BGP (soBGP) October 2002
7. Deploying soBGP with Mixed EC Distribution
The problem with the above deployment mode is readily apparent; there
could be many such servers as A, F, and G within a large internet-
work, so it could take a large amount of manual explicit trust confi-
guration in the various networks to make such a scheme work.
(---------) (---------)
( AS65401 ) ( AS65402 )
( E--------F )
( Server D ) ( Server G )
(---C---) (---H---)
| |
| |
(---B---) (---K---)
( ) ( )
( Server A ) ( Server L )
( AS65400 ) ( AS65403 )
(-------) (-------)
For instance, if AS 65400 advertises its AC with a URL which resides
on D, routers K, H, and F would all need to maintain manual confi-
guration to prevent circularity. This appears to be unacceptable.
Instead, however, suppose that AS65401 and AS65402 both advertise the
ECs necessary to validate the ACs required to reach servers D and G
through the SECURITY message type in BGP, to their peers. These ECs
would then propagate to each AS in this internetwork, and could be
used to validate the ACs required to reach servers D and G.
Once these paths are validated, A and L could then reach the URLs
necessary to retrieve other ECs, and validate the remainder of the
ACs they have received through the SECURITY message type from BGP
peering sessions. This deployment provides a maximum amount of flexi-
bility, allowing the amount of information carried within the BGP
protocol itself to be minimized, and still allowing the routing sys-
tem to be secured.
White, et. all [Page 8]
INTERNET DRAFT Secure Origin BGP (soBGP) October 2002
8. Incremental Deployment of soBGP
As the previous sections point out, there are multiple ways to deploy
soBGP as outlined in [SOBGP-BGP] and [SOBGP-RADIUS]. Each of these
deployment options may be appropriate in a different stage of deploy-
ment within an internetwork. In an initial rollout, where few enti-
ties within the routing system are participating in soBGP, carrying
all the information within BGP itself, and processing the information
either on the BGP speakers or on a separate device may work.
As the entities participating increases, however, it may not be
advantageous to carry all the ECs available within BGP itself, since
this could be a very large amount of information. In this case, a
minimal number of ECs could be carried through BGP, enough to provide
a framework through which the remaining ECs necessary to secure the
routing system could be carried.
9. Multihoming Deployment
Multihoming presents a special challenge to the deployment of soBGP
within a large scale internetwork.
(---------) (---------)
( AS65401 ) ( AS65402 )
( ) ( )
( ) ( )
(---A---) (---B---)
| |
/
-----+ +-----/
| |
(--C------D--)
( )
( No AS )
(----------)
Assume No AS has obtained a block of addresses, 10.1.1.0/24, from
AS65401, and would like to advertise that same block of addresses
through AS65402. Since NOAS has no AS number, it cannot generate any
soBGP certificates, and must rely on its upstream providers to work
out the security impact in some way. The simplest solution would be,
of course, for NOAS to obtain an AS number, and fully participate in
soBGP, but barring that, what other solutions are there?
AS65401 could issue an AC allowing AS65402 to originate just the pre-
fix in question, 10.1.1.0/24, or AS65401 could simply list AS65402 in
the AC covering 10.1.1.0/24 as an authorized originator for this
White, et. all [Page 9]
INTERNET DRAFT Secure Origin BGP (soBGP) October 2002
address space (as multiple authorized originators are allowed).
10. Private Key Rollover
One of the most complicated problems facing the deployment of a large
scale internetwork wide security system of this type is in the abil-
ity for an entity to change private keys without losing routing
information, or to revoke certain authorized ACs without revoking all
the ACs it currently has outstanding. This problem is solved in soBGP
through a set of interlocking serial numbers contained in the various
soBGP certificates.
o Each EC has a serial number
o Each EC has a lowest valid serial number
o Each EC has a start valid AC serial number
o Each EC has an end valid AC serial number
o Each PC has a serial number
o Each AC has a serial number
Assume an AS has the following soBGP certificates:
o An EC with a serial number of 10, a lowest valid serial number
of 9, a start valid AC serial number of 20, and an end valid AC
serial number of 100, and public key A.
o An SC with a serial number of 10.
o ACs with serial numbers between 20 and 30.
To replace the current public/private key pair the AS is using:
o Generate a new public/private key pair, B, and build an EC from
the public key and other information required. Assume the new EC
is given serial number 15, with a new lowest valid serial number
of 9.
o Assume the a start AC serial number is set to 31, and the end AC
serial number is set to 100.
o Have the new EC signed by a trusted third party.
o Distribute this new EC.
White, et. all [Page 10]
INTERNET DRAFT Secure Origin BGP (soBGP) October 2002
o Generate a new set of ACs with serial numbers of 31 through 40.
o Once sufficient time has passed for the new EC to be distributed
throughout the internetwork, advertise the new ACs.
o As the ACs are received by systems running soBGP, they will be
validated against the new EC which they've previously received,
and the prefixes advertised by the AS can be revalidated without
being removed and reinstalled from the Loc-RIB in each device.
o Finally, to totally invalidate the older public key (if neces-
sary), the AS can generate another new EC, using the same
public/private key pair, B, with a serial number of 16, and a
lowest valid serial number of 15.
o As this EC is distributed throughout the internetwork, the older
EC, with public key A, will be invalidated as well.
10.1. Revoking Specific Authorization Certificates
Within each Policy Certificate, it is possible to list Authorization
Certificates which should no longer be honored. As with all revoca-
tion lists, however, the revocation list can grow, over time, to
become unreasonable in size. To resolve this, soBGP allows the ori-
ginating AS to "clean out" the revocation list while rolling over a
proviate key. To clean out the revocation list, the originating AS
must:
o Issue a new Entity Certificate with a new private key.
o Issue new Authorization Certificates with serial numbers higher
than the current highest numbered Authorization Certificate.
o Once the new Authorization Certificates are issued, issue a new
Entity Certificate with the same public key, but with the same
Begin Authentication Certificate Serial as the lowest serial
numbered Authorization Certificate issued above.
o Issue a new Policy Certificate with an empty revocation list.
12. References
[BGP]Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 (BGP-4)",
RFC 1771, March 1995.
White, et. all [Page 11]
INTERNET DRAFT Secure Origin BGP (soBGP) October 2002
[SOBGP-BGP]
Ng J (editor), " Extensions to BGP to Support Secure Origin BGP
(soBGP)", Draft-ng-sobgp-deployment-00.doc, October 2002
12. Editor's Address
Russ White Cisco Systems 7025 Kit Creek Road Research Triangle
Park, NC 27709 riw@cisco.com INTERNET DRAFTsoBGP DeploymentOc-
tober 2002
White, et. all [Page 12]
