Design and analysis of the secure border gateway protocol s bgp
This presentation is the property of its rightful owner.
Sponsored Links
1 / 24

Design and Analysis of the Secure Border Gateway Protocol (S-BGP) PowerPoint PPT Presentation


  • 79 Views
  • Uploaded on
  • Presentation posted in: General

BBN Technologies. A Part of. Design and Analysis of the Secure Border Gateway Protocol (S-BGP). Dr. Stephen Kent Chief Scientist - Information Security. Outline. BGP Model BGP security concerns & requirements S-BGP design S-BGP performance & scaling Related work What’s next. DSP-A.

Download Presentation

Design and Analysis of the Secure Border Gateway Protocol (S-BGP)

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Design and analysis of the secure border gateway protocol s bgp

BBN Technologies

A Part of

Design and Analysis of the Secure Border Gateway Protocol (S-BGP)

Dr. Stephen Kent

Chief Scientist - Information Security


Outline

Outline

  • BGP Model

  • BGP security concerns & requirements

  • S-BGP design

  • S-BGP performance & scaling

  • Related work

  • What’s next


Basic bgp model

DSP-A

DSP-B

DSP-C

BGP Router

non-BGP Router

Basic BGP Model

Org-X

ISP-2

ISP-1

NAP

Org-Z

ISP-4

ISP-3

Org-Y

- path vector inter-domain routing protocol

- UPDATEs generated in response to loss of connectivity or receipt of an UPDATE from a peer router, that results in a LOCRIB change


The bgp security problem

The BGP Security Problem

  • BGP is the critical infrastructure for Internet, inter-domain routing

  • Benign configuration errors have wreaked havoc for portions of the Internet address space

  • The current system is highly vulnerable to human errors, as well as a wide range of attacks

  • At best, BGP uses point-to-point keyed MAC (a poor algorithm) & no automated key management

  • Solutions must take into account the realities of Internet topology, size, update rates, ...


Attack model

Attack Model

  • BGP can be attacked in various ways

    • active or passive wiretapping of communications links between routers

    • tampering with BGP speaker software

    • tampering with router management data en route

    • tampering with router management workstations/servers

      (the last three can result in Byzantine failures)

  • Addition of the proposed countermeasures introduces a new concern

    • compromise of secret/private keying material in the routers or in the management infrastructure


Bgp security requirements

BGP Security Requirements

  • Address space “ownership” verification

  • Autonomous System (AS) authentication

  • Router authentication and authorization (relative to an AS)

  • Route and address advertisement authorization

  • Route withdrawal authorization

  • Integrity and authenticity of all BGP traffic on the wire

  • Timeliness of BGP traffic*


S bgp design overview

S-BGP Design Overview

  • IPsec: authenticity and integrity of peer-to-peer communication, automated key management

  • Public Key Infrastructures (PKIs): secure identification of BGP speakers and of owners of AS’s and of address blocks

  • Attestations --> authorization of the subject (by the issuer) to advertise specified address blocks

  • Validation of UPDATEs based on a new path attribute, using certificates and attestations

  • Distribution of countermeasure data: certificates, CRLs, attestations


S bgp residual vulnerabilities

S-BGP Residual Vulnerabilities

  • Failure to advertise route withdrawal

  • Premature re-advertisement of withdrawn routes

  • Erroneous application of local policy

  • Erroneous traffic forwarding, bogus traffic generation, etc. (not really a BGP issue, since BGP deals with routing, but not traffic forwarding)


Internet address space ownership

ISP-1

DSP-C

ORG-YY

Internet Address Space Ownership

ICANN/IANA

ARIN/RIPE/APNIC

DSP-A

ORG-X

ISP-2

ORG-Y

DSP-B

ORG-Z

DSP-D

ORG-XX

ORG-ZZ


Certificates and address space attestations

Certificates and Address Space Attestations

  • ICANN issues certificates for address space ownership to regional authorities and to entities that have direct address allocations (from IANA)

  • Each of these certificates contains an extension specifying the address space being delegated, so that certificate validation is address-constrained

  • Holders of address space certificates can create an address attestation, authorizing an AS (or a router) to advertise the specified address space

  • Only networks that execute BGP need certificates

  • All ISPs are BGP users, but only about ~10% of DSPs, maybe 5% of subscribers, are BGP users


Simplified pki for address blocks

Simplified PKI for Address Blocks


Certificates and route attestations

Certificates and Route Attestations

  • ICANN issues certificates for AS ownership to ISPs, DSPs, and organizations that run BGP

  • AS operators issue certificates to routers, as AS representatives

  • Holders of AS (or router) certificates generate route attestations, authorizing advertisement of a route by a specified next hop AS

  • Route attestations are used to express a secure route as a sequence of AS hops


Pki for speaker id as assignment

I

I

C

C

A

A

N

N

N

N

A

A

l

l

l

l

A

A

S

S

N

N

u

u

m

m

b

b

e

e

r

r

s

s

A

A

P

P

N

N

I

I

C

C

A

A

R

R

I

I

N

N

R

I

P

E

A

A

S

S

N

N

u

u

m

m

b

b

e

e

r

r

s

s

A

A

S

S

N

N

u

u

m

m

b

b

e

e

r

r

s

s

A

S

N

u

m

b

e

r

s

A

T

&

T

D

S

P

1

G

G

T

T

E

E

-

-

I

I

I

S

P

2

M

C

I

A

S

N

u

m

b

e

r

s

A

S

#

W

A

A

S

S

N

N

u

u

m

m

b

b

e

e

r

s

A

S

N

u

m

b

e

r

s

A

S

N

u

m

b

e

r

s

D

S

P

3

A

S

#

X

R

o

u

t

e

r

s

i

n

A

S

#

X

I

S

P

4

A

S

#

Y

A

S

#

X

,

R

o

u

t

e

r

B

G

P

I

D

A

S

#

Z

A

S

#

Z

R

o

u

t

e

r

s

i

n

A

S

#

Z

A

S

#

Y

R

o

u

t

e

r

s

i

n

A

S

#

Y

A

S

#

Z

,

R

o

u

t

e

r

B

G

P

I

D

A

S

#

Y

,

R

o

u

t

e

r

B

G

P

I

D

PKI for Speaker ID & AS Assignment

R

I

P

E

A

S

N

u

m

b

e

r

s

A

T

&

T

D

S

P

1

I

S

P

2

M

C

I

A

S

N

u

m

b

e

r

s

A

S

#

W

r

s

A

S

N

u

m

b

e

r

s

A

S

N

u

m

b

e

r

s

D

S

P

3

A

S

#

X

R

o

u

t

e

r

s

i

n

A

S

#

X

I

S

P

4

A

S

#

Y

A

S

#

X

,

R

o

u

t

e

r

B

G

P

I

A

S

#

Z

A

S

#

Z

R

o

u

t

e

r

s

i

n

A

S

#

Z

A

S

#

Y

R

o

u

t

e

r

s

i

n

A

S

#

Y

A

S

#

Z

,

R

o

u

t

e

r

B

G

P

I

A

S

#

Y

,

R

o

u

t

e

r

B

G

P

I


Securing update messages

Securing UPDATE messages

  • A secure UPDATE consists of an UPDATE message with a new, optional, transitive path attribute for route authorization

  • This attribute consists of a signed sequence of route attestations, nominally terminating in an address space attestation

  • This attribute is structured to support both route aggregation and AS sets

  • Validation of the attribute verifies that the route was authorized by each AS along the path and by the ultimate address space owner


An update with attestations

An UPDATE with Attestations


Simplified attribute format

Simplified Attribute Format

BGP Hdr: Withdrawn NLRI, Path Attributes, Dest. NLRI

RA: Issuer, Cert ID, Validity, Subject, Path, NLRI, SIG

RA: Issuer, Cert ID, Validity, Subject, Path, NLRI, SIG

RA: Issuer, Cert ID, Validity, Subject, Path, NLRI, SIG

AA: Owning Org, NLRI, first Hop AS, SIG

(usually omitted)


Distributing certificates crls aas

Distributing Certificates, CRLs, & AAs

  • Putting certificates & CRLs in UPDATEs would be redundant and make UPDATEs too big

  • Same is true for address attestations

  • Solution: use servers for these data items

    • replicate for redundancy & scalability

    • locate at NAPs for direct (non-routed) access

    • download options:

      • whole certificate/AA/CRL databases

      • queries for specific certificates/AAs/CRLs

  • To minimize processing & storage overhead, NOCs should validate certificates & AAs, and send processed extracts to routers


Distributing route attestations

Distributing Route Attestations

  • Distributed with BGP UPDATEs as path attributes

  • RAs have implicit encoding option to reduce size, avoid exceeding UPDATE size limit (4096b)

  • Cache with associated routes in ADJ-RIBs to reduce validation overhead

  • Expiration date present, but no revocation mechanism chosen yet


Bgp statistics from merit

BGP Statistics (from Merit)

  • ~ 1,800 organizations own AS numbers

  • ~ 44,000 own address prefixes (NLRI)

  • ~ 7,500 BGP speakers

  • ~ 75,000 routes in an ISP BGP database

  • Few AS sets (~100), little address aggregation

  • Average path length (NAP perspective) is 2.6 hops; 50% of routes ≤ 2 hops, 96% ≤4 hops

  • ~ 43,000 UPDATEs received each day at a BGP speaker at a NAP (30 peers)


S bgp storage statistics

S-BGP Storage Statistics

  • ~ 58,000 certificates in database (~550b each)

  • Certificate & CRL database ~35Mb

  • Address attestation database ~4 Mbytes

  • Extracted certificate & AA database (with data structure overhead in GateD) ~ 42Mb

  • Route attestations occupy ~16 Mb per ADJ-RIB: about 64 Mb (4 peers) to 480 Mb (at NAP)

  • ADJ-RIB caching for received UPDATEs increases storage requirements by about 50%, and yields about 53% validation savings


Route attestation overhead

Route Attestation Overhead

  • Transmission

    • RAs add ~450 bytes to a typical (3.6 ASes in path) UPDATE of 63 bytes, 700% overhead!

    • But UPDATEs represent a very small portion of all traffic, so steady state bandwidth for RA transmission is only ~ 1.4Kb/s

  • Processing

    • Average of 3.6 signature validations per received UPDATE and 1 generation per emitted UPDATE

    • Peak rates ~ 18/s validation and ~5/s generation w/o caching (peak estimated as ten times average)

    • UPDATE caching should reduce validation value by ~50%

    • Start up transient would overwhelm a speaker, thus NV storage or heuristics are required


Auxiliary s bgp device option

Auxiliary S-BGP Device Option

  • No changes required to router hardware or software, just re-configuration

  • Use PC to provide CPU, memory, and NV storage needed to handle BGP routing and S-BGP

  • Collocated with current border routers

    • auxiliary boxes peer with each other (boxes in same AS and boxes collocated with neighbor routers) and the border router

    • border router peers only with auxiliary box and internal BGP routers (in the same AS)

  • Downside: requires extra rack space, uses a router port, & increases the managed device count


Related work

Related Work

  • Link state (e.g., OSPF) security mechanisms

  • Distance vector routing security proposals

    • Some clever schemes developed, but not applicable to BGP, a path vector protocol (e.g., due to local policy processing)

    • Many designs assume signature processing, not memory, is the biggest performance problem to be solved

  • Routing Policy Specification Language (RPSL)

    • Product of IETF RPSL WG

    • Requires ISPs/DSPs to publish (local) policy info

    • Secures distribution of policy info, but relies on ISP/DSP staff to retrieve, interpret, and employ policy info for enforcement


What s next

What’s Next?

  • Tech transfer

    • Distribute S-BGP software to all interested parties

    • Work with ISPs and router vendors to develop implementations and operational experience

    • Work with ICANN, ARIN, etc. to establish PKIs and to deploy certificate/CRL/AA servers (other uses for parts of this PKI)

  • Testing and deployment issues

    • CAIRN test bed is small and tests were too short

    • ISP feed was not a good test for NAP router scenario, though probably representative of a feed to a DSP

    • Intra-domain distribution of S-BGP attribute options


  • Login