Overview:
--------

Randy kicked off the workshop, welcoming people and describing the motivation for the meeting.  The community has been hearing about S-BGP and getting widely differing assessments.  Is it hogwash or a viable solution?

1. Are the security aspects OK? What is the "threat model"? Does S-BGP address the threats?
2. Is S-BGP deployable?
3. Will S-BGP scale?

Steve Kent presented a general overview of the architecture and Charlie Lynn went into more detail on aspects such as the repository, address and route attestations, etc.  These presentations were informal and served as a springboard for questions and discussions that went from about 9am until 3:30pm with a break for lunch.  More detail is appended below on the issues that were discussed.  A number of new requirements/issues were identified (more detail is provided in the following sections):

• Workshop participants indicated that they wanted to protect iBGP routes.
• The workshop participants would like to have their own local repositories.  This could mean one for each of 100-150 ISPs and another 100 or so for exchanges.  Also, some ISPs would want to have a second repository for redundancy.
• The workshop participants would like to have incremental download capabilities.
• To prevent potential hijacking, a prefix-owner needs to be able to specify that more specific prefixes than the prefix listed in the AA are not allowed.  This will mean that S-BGP speakers receiving an UPDATE with a prefix that is more specific than what is listed in the appropriate AA, will reject the route.

We then spent about 15 minutes walking through the screens/menus of the CHATS Certificate Management System (CMS) showing how one might process certificate requests if one were running a CA.  The consensus was that the system was far too general and offered options that should not be on the screen.  The CMS supports "profiles" which can be used to limit what is shown to just the desired/allowed options. BBN can provide those (given some additional funding). Better error messages are also needed.  The CHATS CMS is an open source, general purpose CA that will be available to anyone and thus can be customized for environments such as support for the S-BGP PKI.

BBN was not able to get the NOC tools and the CHATS CMS integrated into the demo configuration (multiple ASes on a single laptop).  So we walked through the high-level menu mentioning the various tools and how they'd be used.  All agreed that the software needed work, especially the software installation procedure.  The participants asked if this software would be made available to play with.  BBN said yes.  We expect to have a version ready by the end of November.

The last 45 minutes was spent in a free-for-all of folks bringing the router software up on their laptops or on demo laptops.  There was a pre-configured network topology available.  Most folks were able to ping/talk to at least one or two neighbors but we ran out of time before any attacks could be demonstrated. However we did demonstrate how the software rejected UPDATEs from a neighbor AS that was supposed to be sending S-BGP UPDATEs and how when the policy was changed on that router, the UPDATEs were then accepted.

BBN was asked to post papers/specs to the download site.  (This has been done and they're also on the web site -- http://www.ir.bbn.com/projects/s-bgp.)

Concerns/Questions
------------------
Here is the list of topics/issues that we recorded.  We grouped them somewhat to make it easier to find topics so they're not in the order in which they came up in the meeting.  The table of contents (without page numbers) is:

1. What is the "threat model"?
2. Route Attestations
   1. What do RAs protect -- what is signed?
   2. What is the granularity of the expiration date in an RA
   3. Can an AS sign only some UPDATEs?
   4. Can S-BGP handle aggregation of routes?
   5. What time synchronization do you require among routers?
   6. How S-BGP accomodate proxy aggregation?
3. Can S-BGP be used to protect exchanges within an AS?
   1. IPsec?
   2. Origin authentication at the AS-level
   3. Origin authentication at the router level?
   4. Can S-BGP handle route reflectors?
4. How does S-BGP handle route withdrawals?
5. How does S-BGP interact with local filtering?
6. S-BGP handling of address and AS number spaces
   1. How does one specify the IP addresses in the S-BGP extension?
   2. How does S-BGP interact with sub-allocation of IP addrs and AS #s
   3. Can S-BGP handle BGP VPNs ala RFC 2547 bis?
   4. Can S-BGP handle private address space usage within and among cooperating ISPs?
   5. How does one handle "private" ASes if you're using S-BGP.
   6. What happens with regard to address space that is included in S-BGP PKI Root certificates but will NEVER be assigned to an organization, e.g., net 0, net 127.
   7. What happens with regard to address space that is included in the S-BGP PKI Root certificates but has not yet been assigned to an organization such as an RIR?
   8. What happens with regard to address space that is included in the S-BGP PKI Root certificates and has been assigned to an organization such as an RIR or ISP?
   9. What happens when a new RIR comes into existence?  Suppose you start with N RIRs and add 1....
   10. How does one handle the case of a customer that does not run S-BGP but has its own AS # (obtained say from Jon Postel) and address space:
   11. How does S-BGP handle multicast addresses?
   12. Can S-BGP handle hierarchical assignment of ASes (as opposed to just from an RIR)?
   13. What is the format for the AS number?
   14. What happens when an organization (A) obtains new addresses or AS numbers?
   15. Prevention of hijacking
7. IPsec
   1. S-BGP uses IPsec between peers -- What does this buy over MD5?
   2. Is the size of the certificates for IPsec going to cause a problem, i.e., are they too big?
8. Key Management
   1. How is key management handled?
   2. Should there be a key pair per router or 1 key pair for all routers in a given AS?
9. Certificate Revocation Lists (CRLs)
   1. Does S-BGP use CRLs?
   2. Is there an attack vector via the CRL chain?
   3. How often does one need to check CRLs?
10. Re: Distributed repository system for S-BGP certificates, CRLs, and Address Attestations
    1. How often would repositories be accessed (uploaded to and downloaded from)?
    2. How does an ISP/DSP know that the information in a repository is correct?
    3. Is the repository vulnerable to replay attacks?
    4. Where should repositories be located?  Who will run them? How many will there be?
    5. How does the synchronization between repositories work?
    6. Can one do incremental downloads and uploads?
    7. Could one build access control lists and prefix filters from the data in the repository?
    8. How well will the distribution process for S-BGP certs/CRLs/AAs meet the timing requirements for the activation of new addresses?
11. Multi-homed customers
    1. Multi-homed to more than one ISP
    2. Multi-homed to one ISP -- Customer is using a portion of the ISP's address space and a private AS is being used -- RFC 2270
    3. Multi-homed to one ISP -- Customer owns the addresses being advertised and a private AS is being used
    4. Multi-homed to one ISP -- Customer is using a legitimate AS number and either owns the address space or uses a portion of the ISP's address space.
12. How well will S-BGP scale?
    1. What processing demands will S-BGP place on the routers?
    2. What memory requirements will S-BGP have for the routers?
    3. Would S-BGP demands affect the frequency of router hardware upgrades?
    4. How does S-BGP impact routers upon initialization/start up?
13. Transition from BGP to S-BGP
    1. How does S-BGP handle incremental deployment into the Internet?
    2. How long do we anticipate it will take to fully deploy S-BGP?
    3. What benefits can one obtain from S-BGP before it is being used by most of the ISPs?
    4. Use of AS cert in repository to facilitate transition
14. What is the granularity of the expiration date in an AA and certificate?
15. Does an operator cert need to be reissued whenever a netblock is added?
16. CHATS CMS system -- open source software that's been enhanced to know about S-BGP certificate extensions.

Detailed Discussion
-------------------

1. What is the "threat model"?
   • motivated capable adversaries (in addition to operators who accidentally misconfigure a router)
   • an adversary could engage in active wiretapping attacks from anywhere in the Internet, including via links between BGP peers where the adversary can observe and modify all traffic (a man-=in-the-middle attack capability)
   • an adversary could compromise personnel (e.g. operators) in an AS, in a transmission provider, etc.
   • an adversary could compromise one or more BGP routers in an AS, or a workstation used to manage the routers in an AS, or a route reflector in an AS, etc.
   • the adversary is motivated to alter paths so as to permit diversion of traffic flows, e.g., to create black holes or to allow the adversary to monitor or tamper with traffic by causing it to flow through an AS that the adversary controls.
   • S-BGP focuses on eBGP exchanges, i.e., enabling an AS to protect itself from bad UPDATES issued by a compromised AS.  This could be a single router, multiple routers, a NOC operator, etc.
2. Route Attestations -- These are added to an UPDATE by the AS "exit" router, 1 per AS through which the UPDATE passed including the originating AS.  An RA specifies the next hop AS for the UPDATE, which could be a single AS or a set of AS's.
   1. What do RAs protect -- what is signed?
      • An S-BGP speaker that is sending an UPDATE to a peer, will add a Route Attestation that contains (among other things) a signature that covers whatever path attributes the speaker has been configured to protect (as indicated by a bit mask in the route attestation) -- ORIGIN, AS_PATH, NRLI, etc.
      • Note that the signature covers not only the information being advertised but also the receiving AS(es).  This prevents cut and paste attacks.
      • There's a bit mask that indicates which attributes have been included in the signature.
   2. What is the granularity and format of the expiration date in a Route Attestation?
      • yyyy/mm/dd
      • granularity = 1 day
   3. Can an AS sign only some UPDATEs?
      • For UPDATES "received", an AS using S-BGP would sign only UPDATEs that have a continuous set of signatures from the originating AS to the one in question.
      • For UPDATES "originated", an AS should sign all UPDATEs that are sent to neighbor AS's that are known to be running S-BGP. (This is configurable.)
   4. Can S-BGP handle aggregation of routes?
      • Yes, if talking about address (NRLI) aggregation.
      • Yes, if one aggregates routes that have the same path attributes, except for the Route Attestations (since those will never be the same).
      • For an AS receiving an UPDATE containing route aggregation, BBN observed that with S-BGP there won't be a benefit (in terms of space savings in the UPDATE) until after 1 AS-hop from the point where the aggregation took place.  If an S-BGP speaker did not aggregate N routes, then it would send the original data from the N routes in N separate UPDATEs and would append 1 Route Attestation to each one (for N RAs).  And if the BGP speaker were to aggregate the N routes, it would add just one Route Attestation. However, when a speaker aggregates, S-BGP requires that the "protected" path attributes and NRLI be copied into the RA.   In the cases that we analyzed, that data was often larger than the N RAs but less than 2N RAs. So you gain from the aggregation after about 1 AS-hop.)
      • In the '90s, there was talk about doing aggregation in the middle of a path.  But it is unclear whether very many ISPs do this.
   5. What time synchronization do you require among routers?
      • Coarse since the route attestation validity is at a 1 day granularity, and we would expect certs to be issued with validity intervals that are truncated at the day, vs. the hour/minute/second granularity that certs permit.
   6. How does S-BGP accomodate proxy aggregation?
      • If an AS's speaker aggregates routes into an UPDATE and claims to be the originator of the UPDATE, then S-BGP will reject the UPDATE unless the address "owners" have created/signed AAs attesting to the AS's right to originate UPDATEs for these addresses.
3. Can S-BGP be used to protect exchanges within an AS?
   • Workshop participants said that an ISP can have more internal routes than external routes.
   • Workshop participants indicated that they wanted to protect iBGP routes.  That there could be both mistakes and compromise within an AS.  The ISP's do not control a large percentage of the routers within their ASes. Several notions were discussed -- see following details.
   1. IPsec?
      • S-BGP currently uses IPsec to protect all iBGP and eBGP sessions.  However, just using IPsec for the transfers would provide protection against wiretapping attacks, but not against compromise of one of the BGP speakers.
   2. Origin authentication at the AS-level
      • In the current S-BGP architecture, UPDATEs originated by a BGP speaker are not signed before being advertised to another BGP speaker in the same AS.  UPDATEs are only signed when they exit an AS.  S-BGP could be easily modified to make iBGP receivers verify that prefixes in an UPDATE are authorized to be originated by some router in the same AS. This would prevent a router in this AS from falsely claiming connectivity to a prefix which is actually in some other AS. In this case, all iBGP speakers would have to run S-BGP.
      • If S-BGP is used internal to an AS for protection of iBGP propagation of routes, it would be possible to strip off the added, internal RA(s) before forwarding the routes externally, in a fashion invisible to the external AS peers.  This is analogous to confederation processing.
   3. Origin authentication at the router level?
      • Do folks want to be able to verify the mapping between prefixes and specific routers within an AS?  At present, the AA contains an AS.  The AA format would support the use of the BGP id of a router instead; but that would make it more difficult to move a customer's addresses from one router to another (within the same AS) and would probably increase the number of AAs.
   4. Can S-BGP handle route reflectors?
      • In the current architecture, there is no problem with route reflectors.  If a route reflector is used, then having it peer with each eBGP router would not dramatically change the load on those routers.
      • If S-BGP is modified to provide additional protection for iBGP sessions, there would still be no problem.
4. How does S-BGP handle route withdrawals?
   • It doesn't do anything beyond normal BGP processing
   • Participants observed that withdrawals can delay route convergence and that if S-BGP were to slow down withdrawal processing this would make this problem worse.
   • NOTE: S-BGP does not slow down withdrawal processing.
5. How does S-BGP interact with local filtering?
   • Local filtering will continue unchanged
   • S-BGP security mechanisms may filter out additional routes.
6. S-BGP handling of address and AS number spaces
   1. How does one specify the IP addresses in the S-BGP extension?
      • for each AFI/SAFI, there is a list of IP address ranges or prefixes.
   2. How does S-BGP interact with sub-allocation of IP addresses and AS numbers?
      • The ISP has to issue a certificate assigning the IP addresses or AS numbers to the subordinate organization.
      • If the subordinate organization is going to run S-BGP, it has to run a CA to issue the S-BGP end-entity certificates or outsource this function.
   3. Can S-BGP handle BGP VPNs ala RFC 2547 bis?
      • BBN is looking into this.
   4. Can S-BGP handle private address space usage within and among cooperating ISPs?  (This is address space that does not appear in the S-BGP PKI Root certificates.)
      • Yes. Cooperating ISPs need to create a trust anchor CA to issue certificates covering the private address space to be used.
      • The CA cert for the above trust anchor needs to be installed in the NOC tools.
      • The certificates and AAs from this hierarchy need to be processed by the NOC tools and the resulting extracts uploaded to the routers.  But these certs and AAs are not uploaded to the global S-BGP repository.
   5. How does one handle "private" ASes if you're using S-BGP.
      • A multi-homed customer has to run BGP and hence has to have an AS that is assigned to it. The ISPs assign a private AS to such customers and place them in a confederation. Then whenever an ISP externally advertises such customer's prefixes, the confederation software strips out the private AS from the UPDATE.
      • The current S-BGP software does not implement the Route Attestation processing needed to support confederations. But it would be straightforward to add this.
   6. What happens with regard to address space that is included in certificates but will NEVER be assigned to an organization, e.g., net 0, net 127.
      • There should not be any advertisements for these addresses. S-BGP speakers will reject them.
   7. What happens with regard to address space that is included in the S-BGP PKI Root certificates but has not yet been assigned to an organization such as an RIR?
      • There should not be any advertisements for these addresses. S-BGP speakers will reject them.
   8. What happens with regard to address space that is included in the S-BGP PKI Root certificates and has been assigned to an organization such as an RIR or ISP?
      • S-BGP speakers will reject an advertisement for any address for which an AA has not been created.
   9. What happens when a new RIR comes into existence?  Suppose you start with N RIRs and add 1....
      • A root CA is created whose self-signed cert has the same IP addresses and AS numbers in its S-BGP extensions as the certs of the other root CAs. (1 cert)
      • An RIR CA is created which is assigned blocks of addresses and AS numbers.  Every Root (N+1) issues it a certificate with the Addresses and AS numbers in the S-BGP extensions. (N+1 certificates with the same subject + 1 CRL)
      • The new Root issues a certificate to all the other RIRs (N) (N certificates with the same issuer + 1 CRL)
      • The above 2N+2 certs + 2 CRLs are inserted by a repository administrator into the repository system.
   10. How does one handle the case of a customer that does not run S-BGP but has its own AS # (obtained say from Jon Postel) and address space:
       • Case A: Customer does NOT run a CA.  In this case, its address prefixes and AS number are not protected by S-BGP
       • Case B: Customer either runs or outsources a CA.  In this case, certs and AAs can be created and S-BGP can be used to verify that appropriate ASes are originating advertisements for the customer's address prefixes.  Further
         • If the customer is not running BGP, then the ISP is originating the routes for the customer and the routes will be protected (assuming the ISP is running S-BGP).
         • If the customer is running BGP, then it will be originating the routes and they will NOT be protected even if the ISP is running S-BGP.
   11. How does S-BGP handle multicast addresses?
       • The issue of how to handle multicast addresses is still the subject of debate.  So we don't yet have a defined process for handling them.  However, in general, there should be a separate PKI parallel to the IP address/AS number PKI.
   12. Can S-BGP handle hierarchical assignment of ASes (as opposed to just from an RIR)?
       • Yes, S-BGP can handle this in the same manner that it handles hierarchical assignment of IP addresses (RIR --> ISP --> ISP --> end customer)
   13. What is the format for the AS number?
       • 4 byte AS numbers
   14. What happens when an organization (A) obtains new addresses or AS numbers?
       • The organization (B) assigning the address blocks or AS numbers to (A), re-issues one cert with updated S-BGP extensions. The key does not need to be changed.  Consequently, the certs that have already been issued by (A) do not need to be re-issued.  (The new cert has to be installed in the NOC tools and S-BGP repository.)
   15. Prevention of hijacking
       • In the diagram below, the route followed between Customer and ISP-A (in either direction) will depend on the policy in the routers of the source ISP.  Specifically, the route will be selected based on whether or not potentially longer but protected routes are preferable to unprotected routes. ISP-A
         (S-BGP)
         /     \
         /       \
         /         \
         ISP-B       ISP-C
         (BGP)      (S-BGP)
         \         /
         \       /
         \     /
         Customer
         (BGP)
         
       • * To prevent potential hijacking, a prefix-owner needs to be able to specify that more specific prefixes than the prefix listed in the AA are not allowed.  This will mean that S-BGP speakers receiving an UPDATE with a prefix that is more specific than what is listed in the appropriate AA, will reject the route.
7. IPsec
   1. S-BGP uses IPsec between peers -- What does this buy over MD5?
      • Automated key management
      • Better crypto for integrity
      • No exposure of the TCP stack to attacks because of the lower layer crypto protection
      • Participants observed that IPsec was more difficult to set up. This was for other scenarios, e.g., road warriors, VPNs.  This experience may not apply to using IPsec for S-BGP, where, for example, the SPD policy will be much simpler.
   2. Is the size of the certificates for IPsec going to cause a problem, big?
      • Those certificates typically won't have any S-BGP extensions. If constructed  with size in mind, an IPsec cert will be small enough to not cause fragmentation.
8. Key Management
   1. How is key management handled?
      • The CA creates its own key pair and manages it.
      • The NOC tools create key pairs and manage the end-entity certs (SSL, operator, ASes, network).
      • If the router vendor's implementation supports it, the router will generate its own key pair and export the public key for inclusion in a certificate.
      • All these keys can be rolled over as often as the ISP wishes.
      • The ISP also chooses the CRL issuance frequency
   2. Should there be a key pair per router or 1 key pair for all routers AS?
      • This is up to the ISP.  The PKI will support either.
      • A key pair per router involves more work to set up but limits the impact of a compromise
      • A key pair for all routers in an AS is easier to set up but increases the impact of a compromise.  This might be reasonable for example if the routers have hardware support for protecting the keying material.
      • One would have to work with the router vendors on how to provide support in the routers for managing the keying material.
9. Certificate Revocation Lists (CRLs)
   1. Does S-BGP use CRLs?
      • Yes.  The certificates are revoked, not the keys.
   2. Is there an attack vector via the CRL chain?
      • An attacker could break into the repository and remove CRLs from the repository thus preventing certificate path validation.  However, each ISP issues its CRL on a periodic basis, established by that ISP. If an attacker removed CRLs from a repository (or tampered with them), it would be detected by all other ISPs who download the repository data. Then the ISPs would have to decide whether to proceed with the old CRLs that they had, or to contact the ISP in question to get the CRL, etc. Ultimately an ISP can choose to work with old data (CRLs and certs) if it cannot get new data from a repository, in whole or part.
      • An attacker could steal a CA's private key and revoke a certificate which should NOT be revoked. This is at least a readily detectable event, by the CA whose key has been stolen, and the recovery mechanism entails reissuance of the CA cert.
      • An ISP could mistakenly revoke a certificate.  This could only be done to the ISP's own customers.
      • A certificate could be revoked deliberately, e.g., due to non-payment of a bill.  This could happen to an ISP or an ISP's customer.
   3. How often does one need to check CRLs?
      • (Per SMB) You trade off the length of the CRL with the expiration date of the certificates.  It's probably not large in any event, but if it starts growing, you start issuing shorter-lived certificates, with an easy -- and automated -- certificate renewal process. As noted above, each ISP can determine the frequency at which it issues a CRL. The date for the next CRL is always contained in the previous CRL, so all the other ISPs know when to look for a new one. A daily CRL issuance model would probably be reasonable and would not unduly burden the repository system.
10. Re: Distributed repository system for S-BGP certificates, CRLs, and Address Attestations
    1. How often would repositories be accessed (uploaded to and downloaded from)?
       • This is a function of how quickly information about an IP address or AS number needs to be propagated throughout the Internet, e.g., when an IP address is being activated.  BBN had anticipated that this would be on the order of once to a few times a day.
       • NOTE: S-BGP, puts the intrinsically more static data (certs, address attestations) in its repositories and the more dynamic data (current routes) in route attestations in the UPDATEs.  The goal was to enable S-BGP to be as responsive as BGP itself.  If you use the IRRs as repositories of authorization info, changes in authorized routing involve significant delays --> routing policies have to be changed, placed in the registries, propagated to other ISPs (via downloading from the IRRs), etc.  With S-BGP, a change in authorized routing can be implemented by generating new Route Attestations that then travel with the relevant UPDATEs.
    2. How does an ISP/DSP know that the information in a repository is correct?
       • There is access control on who can connect to the repository (SSL certificates).  NOTE: SMB asked if SSL can handle full certificate path validation (chains of certs).  OpenSSL handles certificate chains and supposedly CRLs, though we have not tested the CRL processing. The NOC tools pass the certificate path to the repository and vice a versa. Without this, the client/server and server/client authentication fails, i.e., OpenSSL is not looking in the repository database to find the certificates in the chain.
       • There is additional access control (operator certificate) on who can change the repository contents via adds/deletes. An ISP's operator can upload certificates/CRLs/AAs ONLY for IP addresses and AS numbers that his certificate shows he has been authorized to manage.
       • All items in the repository are signed.
       • All data downloaded from the repository is validated by the ISP doing the downloading BEFORE it is processed for uploading to the ISP's routers.
    3. Is the repository vulnerable to replay attacks?
       • NOC access to the repository uses SSL which prevents replay attacks in uploads to the repository.
       • The code for inter-repository synchronization hasn't been completed yet.  It's currently possible for a compromised repository to replay old transactions.  We will fix this if funding permits.
    4. Where should repositories be located?  Who will run them?  How many will there be?
       • They need to be in locations where they can be accessed even if inter-domain routing isn't working.
       • BBN had originally thought there would be a half a dozen to a dozen or so and that they would be at network exchange points where many ISPs have a BGP speaker.
       • The workshop participants pointed out that most traffic between the major ISPs is being exchanged via private peering agreements and that only the smaller ISPs/DSPs are using the exchanges.
       • The workshop participants would like to have their own local repositories.  This could mean one for each of 100-150 major ISPs and another 100 or so for exchanges.  Also, some ISPs would want to have a second repository for redundancy. Although the repositories were not assumed to be 24/7 available, there was a concern that any prolonged outage would have adverse consequences and that it is preferable to not introduce a third party (e.g., RIRs) into the management of these system. Having more repositories is conceptually simple to accommodate, and it reduces the load on any one repository re: local uploads and downloads, but increases the inter-repository traffic for synchronization.
    5. How does the synchronization between repositories work?
       • BBN was anticipating daily exchanges amongst the repositories.
       • Given the requirement to have 200+ instead of the originally planned dozen or so, this would require additional design, evaluation of existing database products, etc.
       • There isn't any inherent hierarchy or precedence amongst the repositories.
    6. Can one do incremental downloads and uploads?
       • If S-BGP is deployed widely, there will be very large number of certs for netblocks (120,000+ based on today's routing table). Downloading them from registry every day could present problems
       • NOC tools currently does incremental uploads.
       • NOC tools currently support only full downloads.
       • The workshop participants would like to have incremental download capabilities.  This is feasible, but will require some additional sophistication in the repository data structure and in the clients. We probably will not be able to implement this under current funding.  It was not part of the current repository design, just to keep things simple.
    7. Could one build access control lists and prefix filters from the data in the repository?
       • Yes.
    8. How well will the distribution process for S-BGP certs/CRLs/AAs meet the timing requirements for the activation of new addresses?
       • The certs/CRLs/AAs can be downloaded whenever an ISP wishes to do so.  As mentioned in 10a, BBN had assumed on the order of one to a few times a day.
       • The participants said that a customer gets a new address and typically wants to use it immediately.  The customer views the process as having started when he makes the initial request, NOT when he has completed the required paperwork, etc.
       • This is probably best handled by managing customer expectations.
       • If the customer wants to use an address immediately, it can be advertised without S-BGP protection and thus subject to potential rejection by other ASes.  Or the customer will have to create/sign an AA.
11. Multi-homed customers
    1. Multi-homed to more than one ISP
       • If customer does not run S-BGP, see above 6-10.
       • If customer does run S-BGP (and presumably is creating certs and AAs), then
         • the routes that go through the contiguous S-BGP clouds of ISPs are protected.
         • the routes that go through non-SBGP ISPs are not protected.
         This means that the routes through S-BGP paths will probably be favored by the set of contiguous AS's that run S-BGP, but parts of the Internet that do not run S-BGP would not have a basis for choosing the authorized paths vs. the other paths.
       Multi-homed to one ISP -- Customer is using a portion of the ISP's address space and a private AS is being used -- RFC 2270
       • ISPs use 1 AS for customers multihomed to a single AS (see diagram below) -------  ISP -------
         /     ---- 7018 -----    \
         /  /                  |  |                  \  \
         /  /                   |  |                   \  \
         /  /                    |  |                    \  \
         Customer 1   Customer 2   Customer 3
         2386              2386              2386
         
       • RFC 2270 says that the ISP originates the advertisements for the portion of the ISP's address space being used by these customers. If the AS# dedicated to these customers is a private AS, it is stripped from the UPDATEs sent by the ISP. In this case, the ISP will be the originator of the UPDATEs and nothing special needs to be done to ensure that S-BGP will protect the route.
    2. Multi-homed to one ISP -- Customer owns the addresses being vertised and a private AS is being used
       • Customer will need to create an AA and specify that the ISP's AS is authorized to advertise the customer's IP addresses.
    3. Multi-homed to one ISP -- Customer is using a legitimate AS number and either owns the address space or uses a portion of the ISP's address space.
       • If the ISP/Customer agree that the customer's AS will originate advertisements then the customer will create an AA saying that its AS is authorized to advertise the customer's IP addresses.
       • If the ISP/Customer agree that the customer's AS will NOT be appearing in UPDATEs, then the customer will create an AA saying that the ISPs AS is authorized to advertise the customer's IP addresses.
12. How well will S-BGP scale?
    • The workshop participants estimated that approximately 10% of customers run BGP.  The big ISPs have BGP speakers numbering in the 100's (not thousands). The goal would be to have all ISPs and all BGP peers run S-BGP.
    • The number of routes is already in the 100's of thousands.
    • A router can have in the 100's of peers.
    1. What processing demands will S-BGP place on the routers?
       • BBN's analysis with MERIT data indicated that at the steady state and peak loads seen at a NAP with 25-30 peers, the processing load was manageable.  Because the processing load is per peer, routers with dozens (or hundreds) of peers might need a crypto processor.
       • Workshop participants pointed out that when an AS/router/etc is under attack, the load will NOT be steady state.
       • The use of IPsec makes it easy to reject any BGP traffic that is not from an authorized peer, and to reject replays of legitimate traffic. So the only traffic that will make it through for S-BGP processing will be from legitimate, S-BGP peers.  If one of these peers is compromised, then it might send "bad" UPDATEs that require signature checking that will consume crypto resources until a bad signature is encountered. When an S-BGP router detects this, it can track the number of bad UPDATEs it is receiving from that peer, and can decide to stop accepting UPDATEs from that peer, since it is reasonable to assume that the peer has been compromised (or is otherwise seriously screwed up). An ISP would have to decide what threshold to use for shutting off a peer, and alerting NOC personnel under these circumstances. Note that a correctly functioning S-BGP peer would not forward bad UPDATEs that it received, so the fault lies in that peer if one receives bad UPDATEs from it.
    2. What memory requirements will S-BGP have for the routers?
       • BBN's analysis of 2 years ago indicates that the memory requirements will be on the order of
         • 10's of Mbytes for the certificate and AA extracts. (The certs/CRLs/AAs are validated at the NOC and only the required info is uploaded to the routers)
         • 10's of Mbytes per peer (ADJ-RIB) for Route Attestations, etc.
       • BBN should redo the analysis with current numbers -- funding permitting.
       • If you have BGP software that doesn't aggregate NLRIs so that you have 1 UPDATE per NLRI, then you would need more storage.
    3. Would S-BGP demands affect the frequency of router hardware upgrades?
       • No.  There would need to be an initial upgrade, then the routers would be upgraded at the normal rate.
       • Workshop participants said that the general upgrade model is to field the new systems in the middle and push older equipment to the edges.
    4. How does S-BGP impact routers upon initialization/start up?
       • The NOC needs to upload the "extracts" of the certs/AAs.
       • The router needs to build up its routing table (LOC-RIB and ADJ-RIBs) information.  If it has to process all the Route Attestations upon start up this could add hours to the process -- clearly unacceptable.  Therefore, a number of optimizations have been examined and are possible:
         • The router has non-volatile memory and keeps a a copy of all routing table data to support fast reboot.  It was noted that the cost of flash memory is not a barrier, if router vendors choose to make use of it for this purpose, e.g., today a gigabyte of flash memory is probably a $250 part.
         • The router obtains a copy of the routing info from a peer (within the AS).  This assumes that one is not worrying about internal compromise. One should protect the session against link-level attacks, e.g., with IPsec.
         • The router does S-BGP route validation only as time permits, i.e., initially uses routes that have been obtained via BGP but not validated and then validates them (withdraws them as needed) when time permmits or when a route is about to be used.  This would expose the router to accepting bad routes, but the bad routes would not be forwarded.
         • The router obtains a copy of the routing info from the NOC.
       • Participants observed that eBGP sessions can come up more quickly than iBGP sessions, so that the optimization of using an iBGP session to obtain routing info might not be as effective as at first expected.
13. Transition from BGP to S-BGP
    1. How does S-BGP handle incremental deployment into the Internet?
       • BBN noted that deployment should be done in contiguous ASes.  Only contiguous S-BGP-using ASes benefit from the S-BGP counter measures.  We tried to work out a policy system that could accomodate islands of S-BGP separated by non-S-BGP ASes, but this resulted in too much complexity for reasonable operations.
       • S-BGP can't be used to protect an AS if it is deployed in only some of the AS's speakers.
       • S-BGP can be deployed in a subset of an AS's speakers in "test" mode to enable an ISP to gain experience, facilitate rollout, detect unauthorized UPDATEs, etc.
    2. How long do we anticipate it will take to fully deploy S-BGP?
       • We may never achieve "full deployment" but if major ISPs deploy and pressure downstream providers to deploy, significant coverage might be achieved in a few years (more than 2, less than 5) from the time the RIRs and router vendors come on board.
    3. What benefits can one obtain from S-BGP before it is being used by most of the ISPs?
       • In the initial phase of deployment of S-BGP into the Internet, it would be useful to have "grandfather" certs and AAs.  These are certs and AAs generated from the best available information rather than by the authoritative source, e.g.,:
         • using the ARIN database to generate certificates on behalf of the organizations who were assigned IP addresses and AS #'s prior to S-BGP deployment. This will require significant effort by ARIN to clean up this data; ARIN has been working on this for the past year.
         • generating AAs based on Routing Registry data or observed UPDATEs. (ARIN does not keep data on which addresses are advertised by which ASes.)
       • For UPDATES that originate and stay within an island of S-BGP-using ISPs, the routes are protected.
       • For UPDATEs that originate or travel through non-S-BGP-using ISPs, the route is not protected.  But, an S-BGP router could use either real or grandfather certs and AAs to detect incorrect originating ASes.  However an attacker could construct an UPDATE that looked as if it originated in the correct AS but actually didn't and this would not be detected.
    4. Use of AS cert in repository to facilitate transition
       • S-BGP can use the presence of an AS cert in the repository as an indicator that the AS in question is running S-BGP. This allows S-BGP policies to be automatically set to require UPDATEs to have S-BGP countermeasures from ASes deemed to be running S-BGP.
       • S-BGP policy can be set up to not reject UPDATEs with bad S-BGP countermeasures data from an AS that is not yet deemed to be running S-BGP.
14. What is the granularity of the expiration date in an AA and certificate?
    • AAs -- 1 day
    • certificates -- a second, but if you're downloading certs 1 to a few times a day, the effective granularity is however often you wish to upload this data to the routers, i.e., basically once a day.
    • As noted above in the discussion on CRLs (item 9), one can constrain certs and CRLs to be issued with daily granularity.
15. Does an operator cert need to be reissued whenever a netblock is added?
    • One could do that; but it is also possible to set a bit in the operator's certificate to "inherit" the values for the S-BGP IP address and AS number extensions from a higher-level certificate, e.g., from the issuer of the operator's cert, i.e., the ISP's CA.
16. CHATS CMS system -- open source software that's been enhanced to know about S-BGP certificate extensions.
    • creens need to be simplified to show just the appropriate options
    • Need better error messages