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]