Upload
thomas-todd
View
213
Download
0
Embed Size (px)
Citation preview
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
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
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
Checking Origin AS : Comparison of AlgorithmsChecking Origin AS : Comparison of Algorithms
Enhanced trace-Enhanced trace-data-based data-based AlgorithmAlgorithm
Green: Good
Red: Suspicious
White: Not found in trace data
28
Enhanced Enhanced Hybrid Hybrid AlgorithmAlgorithm
Checking Origin AS : Comparison of AlgorithmsChecking Origin AS : Comparison of Algorithms
Green: Good / FC
Light Green: Good / PC
Red: Suspicious
White: Not found in trace data
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>
• # signatures = # prefixes in update * # ASes in AS path
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>
• # signatures = # prefixes in update * # ASes in AS path
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
{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
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
{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>
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
{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: 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.
[2] Geoff Huston, “BGP in 2008,” http://www.potaroo.net/ispcol/2009-03/bgp2008.html
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.
[2] Geoff Huston, “BGP in 2008,” http://www.potaroo.net/ispcol/2009-03/bgp2008.html
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
W/O AttestationsSPP SPP-E SPP-E-SAS SPU-EPA
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
W/O AttestationsSPP SPP-E SPP-E-SAS SPU-EPA
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