1 Next Generation Internet Design with Robust Scalability and Security Features Talk at IIIT, Hyderabad July 22, 2009 K. Sriram Co-authors: D. Montgomery,

1

Next Generation Internet Design with Next Generation Internet Design with Robust Scalability and Security Robust Scalability and Security

FeaturesFeatures

Talk at IIIT, HyderabadTalk at IIIT, Hyderabad

July 22, 2009July 22, 2009K. SriramK. Sriram

Co-authors: D. Montgomery, O. Borchert, O. Kim, P. GliechmannCo-authors: D. Montgomery, O. Borchert, O. Kim, P. Gliechmann

National Institute of Standards and TechnologyNational Institute of Standards and TechnologyGaithersburg, MD 20878Gaithersburg, MD 20878

Contacts: Contacts: [email protected]

This research was supported by the Department of Homeland Security under the Secure This research was supported by the Department of Homeland Security under the Secure Protocols for the Routing Infrastructure (SPRI) program and Protocols for the Routing Infrastructure (SPRI) program and the NIST Information the NIST Information Technology Laboratory Trustworthy Networking ProgramTechnology Laboratory Trustworthy Networking Program..

Tru

stw

ort

hy N

etw

ork

ing P

rogra

m

2

s/16

s1/24 = 128.230.79.0/24s2/28

s3/24

s4/20

s5/24

SU owns IP address space: 128.230.0.0/16 = 128.230.0.0 - 128.230.255.255

eBPG

Prefixes

SU Network(Example)

AS11872

• AS = Autonomous System = A network of routers and hosts

• BGP = Border Gateway Protocol

• eBGP = external BGP

• IGP = Internal Gateway Protocol

• Internet is a network of ASes

s = 128.230.0.0

Autonomous System (AS)

BGP BasicsBGP Basics

3

AS2

AS4

AS3

AS5

s/16

b/8

d/18

c/16

e/14

s1/24 = 128.230.79.0/24s2/28

s3/24

e2/16

e1/16

e3/16

s4/20

s5/24

e4/16

c1/18

c2/18

AS1 a/12s/16

Internet

SU Network(Example)

eBPG

AS11872

Example of route aggregation

BGP BasicsBGP Basics

4

Functions of BGPFunctions of BGP

• BGP Updates are used to make network reachability announcements:

– Announce paths or routes to prefixes

– Announce withdrawal of prefixes

– Announce path changes

– Announce new attributes for a previously announced path

Example BGP Path announcement:

AS4 - AS1- AS11872 - 128.230.0.0/16

• Each BGP speaker processes received BGP updates:

Computes/updates its best path to the prefix

Or, withdraws the prefix in the event of a withdrawal

Updates the prefix information in its routing table

Propagates its routes to other peers

5

Routing TablesRouting Tables

• Each AS has at least one (may be multiple) BGP routers or speakers

• BGP routers connect the AS to other neighboring ASes

• BGP routers in different ASes that speak BGP to each other are called

peers

• A BGP path is a path over one or more ASes to a prefix

• Each BGP router receives path information from its neighbors about routes

to “announced” prefixes all over the Internet

• Each BGP router computes its best path to each prefix and stores that path

in the Routing Information Base (RIB)

• The BGP router also maintains a Forwarding Information Base (FIB) which

is stored on the line card for line speed packet forwarding

• The FIB maps each prefix in the table to a next hop router

• The FIB and RIB are called routing tables

6

Observed IPv4 + IPv6 Internet Observed IPv4 + IPv6 Internet Routing StateRouting State

7

Part 1:Part 1:Routing Table Scaling Routing Table Scaling Problem and Proposed Problem and Proposed

Solutions Solutions

8

Routing Table Scaling Problem and Proposed Routing Table Scaling Problem and Proposed Solutions Solutions

References:References:

D. Farinacci, V. Fuller, and D. Oran, “Locator/ID Separation Protocol D. Farinacci, V. Fuller, and D. Oran, “Locator/ID Separation Protocol (LISP), IETF ID draft-farinacci-lisp-00.txt, January 2007.(LISP), IETF ID draft-farinacci-lisp-00.txt, January 2007.

X. Zhang et al., “Scaling IP Routing with the Core Router-IntegratedX. Zhang et al., “Scaling IP Routing with the Core Router-IntegratedOverlay,” IRTF RRG meeting, March 2007. Overlay,” IRTF RRG meeting, March 2007. http://www1.tools.ietf.org/group/irtf/trac/wiki/RRG

V. Fuller, “Scaling issues with Routing and multihoming,” IRTF RRG V. Fuller, “Scaling issues with Routing and multihoming,” IRTF RRG meeting, March 2007. meeting, March 2007. http://www1.tools.ietf.org/group/irtf/trac/wiki/RRG

G. Huston and G. Armitage, “Projecting Future IPv4 Router G. Huston and G. Armitage, “Projecting Future IPv4 Router Requirements Trends in Dynamic BGP Behaviour,” Proc. of the Requirements Trends in Dynamic BGP Behaviour,” Proc. of the Australian Telecommunication Networks and Applications Conference, Australian Telecommunication Networks and Applications Conference, December 2006. December 2006.

9

FIB and RIB Table GrowthFIB and RIB Table Growth• The routing table sizes are growing rapidly due to:

– Traffic engineering related prefix deaggregation

– Multihoming of customer ASes and related deaggregation

– Virtual Private Networks (VPNs)

– Mobility-related deaggregation

– IPv6 deployment (with corresponding Traffic Eng. (TE), multihoming, mobility, etc.)

• BGP routers are projected to be unable to keep up with this growth even with upgrades

– Such rapid rise has not happened before

– Concern: New routers or upgrades could become prohibitively expensive

– T-CAM memory in which FIB and route filters (Access Control Lists [ACLs]) are stored are very expensive

– New designs for Inter-domain routing protocols are being investigated to keep table sizes manageable for core routers

10

Observed and Projected IPv4 + IPv6 Observed and Projected IPv4 + IPv6 Internet Routing StateInternet Routing State

11

Some AcronymsSome Acronyms

– VP: Virtual Prefix (collection of aggregatable prefixes)

– TS: Tunnel Startpoint– TE: Tunnel Endpoint– ITR: Ingress Tunnel Router– ETR: Egress Tunnel Router– PE: Provider Edge– PA: Provider Allocated addresses– PI: Provider Independent addresses– EID: End-point ID– LISP: Locator and ID Separation– CRIO: Core Router-Integrated Overlay

12

A Proposed SolutionA Proposed Solution

• Solution approach:– Decouple address hierarchy and physical topology– Use Virtual Prefixes (VP) and tunneling– Tradeoff: Reduced routing table size for increased path length (stretch)

R1 R2

R4

R3

R5

a/8 b/8

d/8

c/8

e/8

a1/16a2/16

a3/16

e2/16

e1/16

a6/16

a4/16

a5/16

a7/16

a8/16

a9/16

Packet destined

for prefix a7/16

VP prefix based forwarding

Tunneling to TE for this prefix

13

How Do You Bootstrap ThisHow Do You Bootstrap This

• Mapping Distribution Protocol:

– This is still work-in-progress (for researchers & industry)

– Generate a distribution of VPs and assign them to various VP routers (also called Ingress Tunnel Routers [ITRs])

– Major ISPs (Tier 1 and Tier 2) have to agree to this

– Have the ITRs set up the necessary tunnels to appropriate Egress Tunnel Routers (ETRs)

– Map-and-Encap – as this approach is generally referred to –mapping followed by encapsulation of end-point ID (inner header) in the tunnel ID (outer header)

• Prefix migration scenarios: details of signaling protocol for

updating VP mappings – RRG presentation by Sriram et al.

14

Performance Induced PrefixPerformance Induced Prefix

• An ISP (e.g., Router R4) can have heavy traffic to, say, prefix a8/16 and thus decide

to make an exception to VP-based routing and map a shortest-path route in its table. This is called Perf-Induced prefix mapping.

R1 R2

R4

R3

R5

a/8 b/8

d/8

c/8

e/8

a1/16a2/16

a3/16

e2/16

e1/16

a6/16

a4/16

a5/16

a7/16

a8/16

a9/16

15

Performance Induced PrefixPerformance Induced Prefix• Routing table entries for Perf-induced prefix can be entered

selectively only for prefixes that collectively carry 80% or 90% of ingress traffic at the router

• It is said that top 10% or so of prefixes carry 80% to 90% of the traffic

• So the routing table size can still significantly shrink even if perf-induced prefixes are used only for the heavy-traffic prefixes

16

Routing Table EntriesRouting Table EntriesPrefix type Router Action (when destination address in incoming

packet belongs to this prefix type)Type of table entry

1. Virtual prefix Route to next hop for the VP BGP

2. TE prefix Route to next hop for the TE prefix (forwarding within a tunnel)

BGP

3. TE-induced prefix

Detunnel and based on the inner IP address route to the next hop for the TE-induced prefix (destined to an address in the domain for which the TE is a PE router)

BGP/ Mapping

4. VP-induced prefix

Map to the TE and add the outer address for the TE and route to the next hop for that TE

Mapping

5. Perf-Induced prefix

Route to the next hop for that perf-induced prefix Mapping

17

Local Traffic Not Routed Locally !Local Traffic Not Routed Locally !

• VPs are distributed randomly over the AS-level topology• Packets originating in an AS and destined for an address

within the same AS are not detected as such and may be routed to their VP-TS in another AS and then routed back to a TE in the originating AS

• Results in increased path length inflation (stretch)• Random+TP and Random+VP enhancements try to

address this problem in two different ways (next slide)

Random scheme:

18

Routing Local Traffic LocallyRouting Local Traffic Locally

• Every router in each AS maintains routes (internal to the AS) for all its TE-induced prefixes as well as those of other routers in the same AS

• Packets originating with in the AS and destined for any of said TE-induced prefixes are routed locally and optimally within the AS

Random+TP: (Random + TE-induced prefixes)

Random+VP: (Random + VP-TS arrangement)• There are one or more VP-TS’s in each AS

• Each VP is covered by at least one VP-TS

• Each packet originating anywhere in the AS is first routed to the appropriate of the VP-TS

• The VP-TS determines if the destination address belongs to a local prefix

• Compared to Random+TP case, the internal routing in this case may be sub-optimal, but the table size is smaller

Alternatively -

AS

VP-TSVP-TS

AS

Random+TP

Random+VP

19

Table Size vs. Path Length Table Size vs. Path Length TradeoffTradeoff

• Increase the percentage of shortest path traffic by increasing # of Perf-induced prefix entries

Increasing Perf-induced prefixes

20

Locator ID Separation ProtocolLocator ID Separation Protocol

21

Open Issues and Areas for Further Open Issues and Areas for Further StudyStudy

• Comparative evaluation using simulations of the different proposals that are under study in RRG

• Help build security into the address mapping (creation and distribution) protocol which would be a central piece of the new architecture

Security should include authentication of prefix ownership and route originations

• Analyze deployment issues (potential consequences during transition)

Study the routing behavior under dynamic conditions, e.g., link and node failures

Investigate methodologies for alternate routing

• Help develop a comprehensive set of performance metrics, e.g., table size reduction, path length stretch, stability, and re-convergence time

• Identify performance and security trade-offs for making design choices

• Study focused overload issues due to extensive use of tunneling

• Anticipate and resolve design issues under prefix migration/mobility scenarios

• Propose and analyze the details of signaling protocol for updating address mappings.

22

Part 2: Registry and History (or Monitoring)

Data Driven BGP Robustness Algorithms

Tru

stw

ort

hy N

etw

ork

ing P

rogra

m

23

Anomaly / /// Attack

BGP Robustness Problem SpaceBGP Robustness Problem Space

129.6.*.*

False origin announcement

129.6.*.*129.6.*.*

240.18.*.*Unauthorized

announcement

Shortest path to NIST addresses (129.6.*.*) changes for ASes on this side

NIST (MD)AS49

NIST (CO)AS2648

AS701

AS203

AS89

AS42

AS613

AS3

AS28

24

Data Driven BGP RobustnessData Driven BGP RobustnessWhat are the Data Sources?What are the Data Sources?

• Addressing Registries– global databases of address

block and autonomous system number assignments.

• Routing Registries– loosely maintained global

databases of contractual relationships for routing services.

• Monitoring Data– public BGP monitoring and

measurement projects that collect BGP protocol exchanges at various spots around the Internet.

Why is this hard?Why is this hard?

• Registries – known to be incomplete and

inaccurate, and are maintained in differing formats, by differing processes in different regions of the world.

• Robustness Algorithms – to be effective, must make precise

policy decisions from highly imperfect data.

• Needle in a Hay Stack– millions of BGP update messages

per day, millions of registry entries, rare but potent threats.

25

Solution ComponentsSolution Components

Addressing / Routing

Registries

(ARIN, RIPE, APNIC, AFRINIC, LACNIC, RADBs,

etc)

Information Synthesis and

Quality Analysis

(Quality metrics, decision algorithms, privacy, accessibility,

availability)

Routing Policies

(Alarms, ACLs, BGP filter lists, path

preference, parameter tuning).Other Routing

Information Services

(Bogon lists, etc) Global BGP Routing DynamicsGlobal BGP Routing Dynamics

Measured Data

DeclarativeData

Other Info.

Synthesized Data?

Global Route Monitoring

(Routeviews, RIPE RIS, PHAS, PCH, CAIDA, Renesys,

etc)

26

Checking Origin AS : Comparison of AlgorithmsChecking Origin AS : Comparison of Algorithms

Registry-based Registry-based AlgorithmAlgorithm

Green: Good / FC

Light Green: Good / PC

Red: Suspicious

White: Not found in trace data

27


Enhanced trace-Enhanced trace-data-based data-based AlgorithmAlgorithm

Green: Good

Red: Suspicious


28

Enhanced Enhanced Hybrid Hybrid AlgorithmAlgorithm


Green: Good / FC

Light Green: Good / PC

Red: Suspicious


29

Part 3: Cert-Based Path Validation

Approaches for BGP Updates

Tru

stw

ort

hy N

etw

ork

ing P

rogra

m

30

Origin Only ValidationOrigin Only Validation• Prefix and AS owners are provided digital

certificates of ownership of resources• Prefix owner registers which origin ASes can

originate the prefix• Validation algorithm creates a white list of prefixes

and their valid origins

31

Whole Path Validation ApproachesWhole Path Validation Approaches(some candidate options)(some candidate options)

• SPP: Signature Per Prefix– No need for Explicit Path Attribute (EPA) – Attestation overhead multiplicative with # prefixes in an update

• SPP-E: SPP with Economization – Attestation overhead shared over all prefixes in an update

• SPP-E-SAS: SPP-E with Sequential Aggregate Signature (SAS) – SAS – to be described shortly – Attestation size is invariant to # ASes the update goes through

• SPU-EPA: Signature Per Update with EPA– Signature coverage includes announced prefixes and AS path – EPAs convey changes made to announced prefix set along the AS

path– This approach is closest to S-BGP – Possible concerns:

• ISP may be concerned about revealing (in the EPA) about the prefixes they decided not to forward

• Prefix re-insertion by upstream ASes based on information in the EPAs

32

Path Validation with Signature Per Prefix (SPP) Path Validation with Signature Per Prefix (SPP)

• Origin AS provides one signature per prefix and the signature covers the prefix and the AS path (including all attributes)

• As many signatures in an update as there are prefixes

• ASes upstream add their signatures also on a per prefix basis covering individual prefixes together with the modified AS path

• AS path predictability works in this case; so there is no need for ExplicitPAs

• # signatures = # prefixes in update * # ASes in AS path

33

Path Validation with One Signature per Prefix Path Validation with One Signature per Prefix

AS-B

p1

p2AS-C

p3

AS-A

Sig 1A

Sig 2A

Sig 3A

Sig 1B

Sig 2B

Sig 3B

Sig 1A

Sig 2A

Sig 3A

AS-D

Sig 1B

Sig 2B

Sig 3B

Sig 1A

Sig 2A

Sig 3A

Sig 1C

Sig 2C

Sig 3C

{p1, p2, p3}<A> {p1, p2, p3}<B,A> {p1, p2, p3}<C,B,A>

AS-B

p1

p2AS-C

p3

AS-A

Sig 1A

Sig 2A

Sig 3A

Sig 2B

Sig 3B

Sig 2A

Sig 3A

AS-D

Sig 2B

Sig 3B

Sig 2A

Sig 3A

Sig 2C

Sig 3C

{p1, p2, p3}<A> {p2, p3}<B,A> {p2, p3}<C,B,A>


Special case (Example 2): Possibility of dropped prefixes

Normal case (Example 1): All prefixed are carried through

34

Path Validation with One Signature per Prefix Path Validation with One Signature per Prefix

AS-B

p1

p2AS-C

p3

AS-A

Sig 1A

Sig 2A

Sig 3A

Sig 2B

Sig 3B

Sig 2A

Sig 3A

AS-D

{p1, p2, p3}<A> {p2, p3}<B,A> {p2, p3, p4, p5}<C,B,A>


p4

{p4, p5}<A>

Sig 4A

Sig 5A

p5 Sig 4B

Sig 5B

Sig 4A

Sig 5A

{p4, p5}<B,A>

Sig 2B

Sig 3B

Sig 2A

Sig 3A

Sig 2C

Sig 3C

Sig 4B

Sig 5B

Sig 4A

Sig 5A

Sig 4C

Sig 5C

Special cases (Example 3): Prefixes may be dropped or added

35

Path Validation with One Signature per Prefix: Path Validation with One Signature per Prefix: Signature Sizes for SPP and SPP-E Signature Sizes for SPP and SPP-E

One signature per prefix without overhead economization (SPP)

One signature per prefix with shared attestation overhead in each update

(SPP-E)

….

(1)

(p)

(p)

….

(1)

Signature component Size UnitsAttestation object 8 BSigner 8 BSignature description 7 BSignature - 1 40 BExpiry 8 BTarget 8 BSignature size 79 B

Signature component Size UnitsAttestation object 8 BSigner 8 BSignature description 7 BSignature - p 40 BExpiry 8 BTarget 8 BSignature size 79 B

Set of p such signatures added at each AS along the path

One such extended signature added at each AS along the path

Signature component Size UnitsAttestation object 8 BSigner 8 BSignature description 7 BNumber of Signatures 2 BSignature - 1 40 BSignature - 2….Signature - p 40 BExpiry 8 BTarget 8 BTotal signature size 40*n + 41 B

36

Path Validation with SPP-E and Path Validation with SPP-E and Sequential Aggregate Signature (SPP-E-SAS)

AS-B

p1

p2AS-C

p3

AS-A

Sig 1A

Sig 2A

Sig 3A

Sig 2B*

Sig 3B*

AS-D

{p1, p2, p3}<A> {p2, p3}<B,A> {p2, p3, p4, p5}<C,B,A>

p4

{p4, p5}<A>

Sig 4A

Sig 5A

p5 Sig 4B*

Sig 5B*

{p4, p5}<B,A>

Sig 2C*

Sig 3C*

Sig 4C*

Sig 5C*

• In SAS [1], each AS (other than the origin AS) in the path incorporates into its signature the signature from previous AS in a retractable way

• Hence, # signatures carried in an update becomes independent of # ASes in AS path

• SAS can be applied to any of the proposals we consider here• An overview of SAS is provided at the end (Appendix A)

[1] Y. Mu, W. Susilo, and H. Zhu, “Compact sequential aggregate signatures,” Proceedings of the ACM Symposium on Applied Computing (2007), pp. 249-253.

37

U = Update message size without attestations (bytes)

Ua = Update message size with attestations (bytes)

p = # prefixes in a prefix set (per update message; p > 1)

h = # ASes in an AS path

Sig = Signature size (e.g., 40 bytes for DSS; 128 bytes for RSA)

Aoh = Attestation overhead (attestation object, signer, sig description, expiry, target) = 39 bytes

k = path attribute overhead = 3 or 4 bytes (function of attribute size)

m = bytes required to specify # of signatures = 2 bytes (in SPP-E and SPP-E-SAS)

Size estimation of update with attestations received at the Collector:

AS-B

p1

p2AS-C

p3

AS-A

{prefix set 1}<A> {prefix set 2}<B,A> {prefix set 3}<C,B,A>

pn

….

AS-D AS-E

{prefix set 4}<D,C,B,A>

Collector

{prefix set 5}<E,D,C,B,A>

Estimation of Update Size with Attestation: Estimation of Update Size with Attestation: SPP, SPP-E, SPP-E-SASSPP, SPP-E, SPP-E-SAS

Contd. next page …

38

For SPP: Total size of signatures = p*h*(Sig + Aoh + k) bytes

Ua = U + p*h*(Sig + Aoh+ k) bytes

For SPP-E: Total size of signatures = (p*Sig + Aoh + k+ m)*h bytes

Ua = U + (p*Sig + Aoh + k+ m)*h bytes

For SPP-E-SAS: Total size of signatures = p*Sig + h*(Aoh + k) bytes

Ua = U + p*Sig + h*(Aoh + k) bytes

Size estimation of update with attestations received at the Collector:

AS-B

p1

p2AS-C

p3

AS-A


pn

….

AS-D AS-E


Collector


Estimation of Update Size with Attestation: Estimation of Update Size with Attestation: SPP, SPP-E, SPP-E-SASSPP, SPP-E, SPP-E-SAS

39

Path Validation Using Signature Per Update and Path Validation Using Signature Per Update and Explicit Path Attributes (SPU-EPA) Explicit Path Attributes (SPU-EPA)

• Signature provides coverage over prefixes and AS path• Assume each AS along the path drops some prefixes and thereby

makes a change to the prefix set it includes in its repacked update• So each AS along the path has to add an ExplicitPA to the signed

update it sends to its next hop neighbor AS• Assume dropping prefixes is allowed but adding them is not allowed

(in S-BGP)• This is a conservative approach – because we are not assuming

perfect predictability, which happens if the prefix set were not changing along the path – there would have been no need to add ExplicitPA if only this predictability were true

AS-B

p1

p2AS-C

p3

AS-A


pn

….

AS-D AS-E


Collector


40

U = Update message size without attestations (bytes)

Ua = Update message size with attestations (bytes)

p = # prefixes in a prefix set (per update message)

A = Bytes needed to represent an ASN = 4 bytes

L = Size of a prefix representation (up to 4 bytes for quad + 1 byte for mask + 1 byte to specify length)

h = # ASes in an AS path

Sig = Signature size = 40 bytes

Aoh = Attestation overhead (attestation object, signer, sig description, expiry, target) = 39 bytes

k = path attribute overhead = 3 or 4 bytes (function of attribute size)

Total size of ExplicitPAs = Epa = (h-1)*p*L bytes

Ua = U + h*(Sig + Aoh) + Epa = U + h*(Sig + Aoh + k) + (h-1)*p*L bytes

Size estimation of update with attestations received by the Collector:

AS-B

p1

p2AS-C

p3

AS-A


pn

….

AS-D AS-E


Collector


Estimation of Update Size with Attestation: Estimation of Update Size with Attestation: SPU-EPASPU-EPA

41

RIB Size Modeling RIB Size Modeling • Update sizes with attestations are computed accurately for

each of the four schemes (using Routeviews data)– When AS prepending is detected, we collapse the repeated

ASes into one AS for the purpose of attestation overhead computation

• Projections are made regarding growth in # prefixes in BGP speakers

• Suitable modeling assumptions are made regarding other modeling parameters (request BGPSEC team’s feedback / refinements)

• The model is highly parameterized and can be tuned to reflect more accurate assumptions or measurements

• RIB sizes are estimated and compared for four path validation approaches (others can be included)– Sensitivity to key parameters and assumptions

42

Update Size with Attestations Update Size with Attestations

• We assume DSS with 320-bit signature is used in all method except the SPP-E-SAS method where RSA is used with1024-bit signature in conjunction with SAS

• By attestation, we mean the signature bytes and attestation related overhead bytes

• The attestation overhead (Aoh) is assumed to be the same (39B) in all cases

• When AS prepending is detected, we collapse the repeated ASes into one AS for the purpose of attestation overhead computation

• Routeviews Oregon collector; 1.8M updates; Feb. 1-26, 2009

W/O AttestationsSPP SPP-E SPP-E-SAS SPU-EPA

Avg. Update 78 1314 856 745 476Std Dev Update 65 4655 2303 2119 278Min Update 44 126 126 214 126Max Update 4080 416947 205692 135537 24632

Avg. Attestation -- 1236 779 667 399Std Dev Attestation -- 4593 2242 2055 223Min Attestation -- 82 82 170 82Max Attestation -- 412870 201615 131457 20555

With Attestations

43

1

10

100

1000

10000

100000

100 1000 10000 100000

MESSAGE SIZE w/ ATTESTATIONS (BYTES)

# U

PD

AT

E A

NN

OU

NC

EM

NE

TS

Distribution of Size of Update Announcements Distribution of Size of Update Announcements Including AttestationsIncluding Attestations (Signature + Overhead)(Signature + Overhead)

(SPU-EPA)(SPU-EPA)

• Prob. {Message < 1200 B} = 99.02%• Prob. {Message < 4000 B} = 99.92%

44

Comparison of Update Message Size:Comparison of Update Message Size:With and Without AttestationsWith and Without Attestations

(SPU-EPA)(SPU-EPA)

1

10

100

1000

10000

100000

10 100 1000 10000 100000

MESSAGE SIZE (BYTES)

# U

PD

AT

E A

NN

OU

NC

EM

EN

TS

1

10

100

1000

10000

100000

100 1000 10000 100000

MESSAGE SIZE w/ ATTESTATIONS (BYTES)

# U

PD

AT

E A

NN

OU

NC

EM

NE

TS

Without Attestations With Attestations

• Prob. {Message < 1200 B} = 99.02%• Prob. {Message < 4000 B} = 99.92%

• Prob. {Message < 224 B} = 99.00%• Prob. {Message < 854 B} = 99.90% • Prob. {Message < 4000 B} = 99.994%

45

Distribution of Size of Update Announcements Distribution of Size of Update Announcements Including AttestationsIncluding Attestations (Signature + Overhead)(Signature + Overhead)

(SPP-E)(SPP-E)

• Prob. {Message < 4000 B} = 97.81% • Prob. {Message < 6792 B} = 99.00%• Prob. {Message < 29044 B} = 99.90 %

0.00001

0.0001

0.001

0.01

0.1

1

100 1000 10000 100000 1000000

Update Message Size in Bytes (X)

Pro

b.

{Up

dat

e M

ess

age

Siz

e <

= X

}

1

10

100

1000

10000

100000

100 1000 10000 100000 1000000

Update Message Size (Bytes)

# U

pd

ate

An

no

un

cem

ents

Histogram CDF

46

Ratio of Update Size for Path Validation Ratio of Update Size for Path Validation Approaches over Current BGP Update SizeApproaches over Current BGP Update Size

0

2

4

6

8

10

12

14

16

18

SPP SPP-E SPP-E-SAS SPU-EPA

RA

TIO

OF

UP

DA

TE

SIZ

E W

ITH

AT

TE

SA

TIO

N O

VE

R

UP

DA

TE

SIZ

E W

/O A

TT

ES

TA

TIO

N

• We assume DSS with 320-bit signature is used in all method except the SPP-E-SAS method where RSA is used with1024-bit signature in conjunction with SAS

47

Parameters for Estimation of RIB Size Parameters for Estimation of RIB Size

• Plug in the avg. attestation size per update (from slide 28) for each of the four methods in consideration, and the model predicts the impact on the RIB size due to attestations (i.e., path validation)

[2] Geoff Huston, “BGP in 2008,” http://www.potaroo.net/ispcol/2009-03/bgp2008.html

Parameters for Estimation of RIB Size in a BGP Router Value Units CommentAverage update size (w/o attestations) 78 B Measured (2/09)Average RIB data structure overhead per update 5% AssumptionAverage memory requirement per update in RIB 82 B Computed from aboveNumber of peers for EBGP speaker 200 Ball park for core routersAvg. fraction of peers from which update is received for each EBGP prefix 10% AssumptionAvg. number of peers from which update is received for each EBGP prefix 20 AssumptionNumber of peers from which update is received for each internal prefix 10 AssumptionAvg. attestation overhead in RIB per update 1236 B Measured (2/09)Average # ASes in AS path 4.743 Measured (2/09)Average # prefixes per update announcement 3.832 Measured (2/09)Growth rate per year for Internal prefixes 5% Assumption

Growth rate per year for External prefixes 15%

To extend growth projections further out from G. Huston's [2] time window

Include Internal prefixes? 1 1 = YES; 0 = NO

48

Growth in # Prefixes with Routes in RIB Growth in # Prefixes with Routes in RIB

0

200000

400000

600000

800000

1000000

1200000

2009 2010 2011 2012 2013 2014 2015 2016 2017 2018

YEAR

# P

RE

FIX

ES

WIT

H R

OU

TE

S

Internal Prefixes

External (EBGP) Prefixes

• Growth in EBGP prefixes assumed to be the same as in [2] from 2009 to 2013, and then they are assumed to grow at 15% annual rate.


49

Methodology for RIB Size Estimation Methodology for RIB Size Estimation

Parameters for Estimation of RIB Size in a BGP Router Symbol Units Equation (Model)

Average update size (w/o attestations) U BAverage RIB data structure overhead per update xAverage memory requirement per update in RIB Ur B Ur = U*(1+x)Number of peers for EBGP speaker NAvg. fraction of peers from which update is received for each EBGP prefix fAvg. number of peers from which update is received for each EBGP prefix Nu Nu = N*fNumber of peers from which update is received for each internal prefix mAvg. attestation overhead in RIB per update S BAverage # prefixes per update announcement pTotal # Internal Prefixes with routes in the BGP speaker PiTotal # EBGP Prefixes with routes in the BGP speaker PeRIB memory consumed by internal prefixes Ri GB Ri = (Pi/p)*m*Ur/10^9RIB memory consumed by external prefixes (w/o attestations) Re GB Re = (Pe/p)*Nu*Ur/10^9Average memory requirement per update in RIB for signatures only Us BAverage memory requirement per update in RIB including signatures Ua B Ua = U + UsRIB memory consumed by signatures for external prefixes Rs GB Rs = (Pe/p)*Nu*Us*(1+x)/10^9RIB memory consumed by EBGP updates with attestations Rue GB Rue = (Pe/p)*Nu*Ua*(1+x)/10^9Total RIB memory consumed by Internal routes + EBGP routes with attestations R GB R = Ri + Rue

50

RIB Size for SPP Approach RIB Size for SPP Approach

Year# Internal Prefixes

# External (EBGP) prefixes

Total # Prefixes with Routes

RIB Requirement for Internal prefixes (GB)

RIB Requirement for External (EBGP) prefixes (GB)

RIB size w/o attestations (GB)

RIB size for signatures alone for EBGP routes (GB)

RIB size for EBGP routes (GB)

Total RIB size with attestations (GB)

2009 700000 285000 985000 0.15 0.12 0.27 1.84 1.96 2.112010 735000 335000 1070000 0.16 0.14 0.30 2.16 2.30 2.462011 771750 388000 1159750 0.16 0.17 0.33 2.50 2.67 2.832012 810338 447000 1257338 0.17 0.19 0.36 2.88 3.07 3.252013 850854 512000 1362854 0.18 0.22 0.40 3.30 3.52 3.702014 893397 588800 1482197 0.19 0.25 0.44 3.80 4.05 4.242015 938067 677120 1615187 0.20 0.29 0.49 4.37 4.66 4.862016 984970 778688 1763658 0.21 0.33 0.54 5.02 5.36 5.572017 1034219 895491 1929710 0.22 0.38 0.60 5.78 6.16 6.382018 1085930 1029815 2115745 0.23 0.44 0.67 6.65 7.08 7.31

RIB size with attestations (GB)

• Growth in EBGP prefixes assumed to be the same as in [2] from 2009 to 2013, and then they are assumed to grow at 15% annual rate.


51

RIB Size for SPP Approach RIB Size for SPP Approach

SPP Method

0

1

2

3

4

5

6

7

8

2009 2010 2011 2012 2013 2014 2015 2016 2017 2018

Year

RIB

Mem

ory

Usa

ge

(GB

)Internal Prefixes

EBGP w/o Attestations

Total RIB w/o Attestations

EBGP Signatures only

Total EBGP with Signatures

Total RIB with Signatures

52

RIB Size Comparison for the Four Path RIB Size Comparison for the Four Path Validation Approaches Validation Approaches


2009 285000 0.12 2.05 1.34 1.16 0.742010 335000 0.14 2.41 1.57 1.37 0.872011 388000 0.17 2.79 1.82 1.58 1.012012 447000 0.19 3.22 2.10 1.83 1.172013 512000 0.22 3.69 2.40 2.09 1.342014 588800 0.25 4.24 2.76 2.40 1.542015 677120 0.29 4.88 3.18 2.76 1.772016 778688 0.33 5.61 3.65 3.18 2.032017 895491 0.38 6.45 4.20 3.66 2.342018 1029815 0.44 7.42 4.83 4.20 2.69


2009 285000 0.12 2.20 1.49 1.31 0.892010 335000 0.14 2.57 1.73 1.52 1.032011 388000 0.17 2.96 1.99 1.75 1.182012 447000 0.19 3.39 2.27 2.00 1.342013 512000 0.22 3.87 2.58 2.27 1.522014 588800 0.25 4.43 2.95 2.59 1.732015 677120 0.29 5.08 3.38 2.96 1.972016 778688 0.33 5.82 3.86 3.39 2.242017 895491 0.38 6.67 4.42 3.88 2.562018 1029815 0.44 7.65 5.06 4.44 2.92

With AttestationsTotal RIB size (GB) -- Only EBGP Prefixes

Total RIB size (GB) -- Both EBGP and Internal PrefixesWith Attestations

53

0

1

2

3

4

5

6

7

8

200000 300000 400000 500000 600000 700000 800000 900000 1000000 1100000

# EBGP PREFIXES

RIB

ME

MO

RY

US

AG

E (

GB

) SPP

SPP-ESPP-E-SAS

SPU-EPA

RIB Size Comparison for the Four Path RIB Size Comparison for the Four Path Validation Approaches Validation Approaches

Total RIB Size for Only the EBGP Prefixes with Attestations

Note: SPP-E-SAS uses 1024-bit RSA signature while other methods use only a 320-bit DSS signature

54

Request for Feedback / Information Request for Feedback / Information to Refine the RIB Modelingto Refine the RIB Modeling

• Several assumptions / modeling parameters can be refined with feedback / inputs from the group

• Modeling assumptions for internal prefixes– # internal prefixes and their growth rate– Size per update in the RIB– Attestation not needed for internal prefixes – OK?

• Signature over AS path only vs. AS path plus prefix– We assumed the latter makes sense and modeled

accordingly• RIB data structure overhead (per update) and how does it

scale with # updates in RIB

55

Potential Future Enhancements/Complications for Potential Future Enhancements/Complications for Signature SchemesSignature Schemes (proposed for discussion in the group)(proposed for discussion in the group)

• What happens if someone upstream prepends a downstream ASN? – Signatures should remain unaffected as long they are performed over the

collapsed AS path

• Pre-compute signed objects for 1st and 2nd choice routes for each prefix and cache them

– Saves computation time when path selection switches between 1st and 2nd choices (failure/recover scenarios)

• Caching validations to save processing• Use of BGP sequence numbers – Variation of BGP Graceful Restart

– Use IPsec to prevent replay attacks– Then use a sequence number in BGP so that peer can look at the

sequence number in the update to know if the same update was previously validated

– This is a sort of BGP graceful restart (in the presence of attestations)– Avoid validation of thousands of attestations upon recovery of a BGP

session with a peer

Documents

1 Next Generation Internet Design with Robust Scalability and Security Features Talk at IIIT, Hyderabad July 22, 2009 K. Sriram Co-authors: D. Montgomery,