Enhancing Interdomain Routing Security Through Origin Authentication

1. Origin Authentication inInterdomain Routing Security Reading Group September 3, 2004 William Aiello, John Ioannidis, and Patrick McDaniel Proceedings of 10th ACM Conference on Computer and Communications Security (CCS'03) Presenter: Jonathan McCune Some slides borrowed from L. Gao, P. McDaniel

2. Interdomain Routing Security Issues • We don’t authenticate ASes • How can we tell Sprint from somebody who claims to be Sprint? • We don’t authenticate paths • How do we know a malicious party is not changing the route our traffic takes? • We don’t authenticate addresses • How do we know that an enterprise uses only those addresses is has the right to? • Origin Authentication: validation of an AS’s claim of address ownership

3. Overview • Background • Formalization • Semantics of address delegation • Origin authentication proof systems • Modeling • Address delegation graph • Evaluating resource costs • Feasibility of an online Origin Authenticationsystem

4. Interdomain Routing • The Internet consists of many routing domains: • Routing inside a domain is determined by an intradomain routing protocol (e.g., OSPF) • Routing between domains is governed by an interdomain routing protocol (e.g., BGP) • Intradomain and interdomain routing decisions are largely made independently • Reasons: • Scale • Administrative autonomy

5. BGP (Border Gateway Protocol) • BGP: • The interdomain routing protocol used on the Internet • Routing domains are called Autonomous Systems (ASes), e.g. AT&T. • ASes: • Announce the prefixes that they own (IP address ranges, e.g. 12.1.1.0/24) to their neighboring ASes. • Exchange prefix announcements with all one-hop neighbors

6. Intra-AS and Inter-AS Routing: Example The route from A.d to B.b: intra-AS and inter-AS path segments. Source: Computer Networking: A Top-Down Approach Featuring the Internet

7. Origin Authentication • Goal: • Provide evidence (cryptographically strong authentication tags) of the relations between organizations, ASes, and prefixes. BGP Speakers Address Advertisements Validated Address Advertisements Evidence

8. Address Delegation • Registries – ISPs – Customers • The IPv4 address space is governed by IANA • IANA delegates parts of the global address space to organizations • Each organization may further • Delegate some or all of the received address space to any organization it desires • Assign its address space to the AS in which the addresses reside • Logistical nightmare: how space was retrieved, by whom, and when is not well documented

9. Address Delegation: Example • AT&T delegates 12.1.1.0/24 to ALPHA • AT&T assigns 12.0.0.0/8 to AS7018 • Longest prefix matching for 12.1.1.0/24 • Address announcements: ASes advertise the set of prefixes that they originate (prefix, ASN)

10. Definition: Organization • ASN = { 1, 2, …, K }, where currently K = 216 • E.g. AS7018, AS29987 • S = { all BGP speaking organizations } • E.g. AT&T, ARIN, ALPHA, BETA • ASN(C) = { AS # currently assigned to C } • E.g. for C = ALPHA, ASN(C) = { AS29987 } • O = S  { IANA }  { other prefix registries }

11. IPA = { 0, 1 }l, where l = 32/64 for IPv4/IPv6 Address Prefixes: x/j x is a j bit number, and j  [ 0, l ], e.g. 128/8 x/j = { xy | y is a (l-j) bit number } IPA = /0 Definition: Prefixes x/j x1/(j+1) x0/(j+1) Disjoint Union Superset Subprefix and superprefix

12. /0 0/1 1/1 00/2 01/2 10/2 11/2 00/32 11/32 Prefix Tree of IPA

13. Delegation Semantics • An organization C in O delegates/assigns y/k by (C, y/k, x) • Where: • x = C’ in O (organization delegation) or • x = n in ASN (AS assignment) or • x = R (RESERVED) or • x = (UNAUTHENTICATED) • P (C) = delegations made by C in O

14. Definition: delegation policy • For a given prefix y/k and an organization C: • (C, y/k, n): C assigns y/k to an ASN n • (C, y/k, C’): C delegates y/k to C’ • (C, y/k, R): C declares y/k as RESERVED • (C, y/k, U): C’s delegation or assignment of y/k is UNAUTHENTICATED • C may perform zero, one, or more of the above options • The set of triples is C’s delegation policy for y/k

15. Delegation Graphs • A directed graph G = (V, E) • V=O  ASN  R  U   • E={(x, y/k, z)} • Example: • V = { IANA, AT&T, … } • E = {(IANA,12.0.0.0/8,AT&T), … } • Definition: • Ownership Source • Assignment Edge • ASN-respecting

16. Valid & Faithful • A directed path is valid for y/k if: • The ownership source is IANA • The path is monotonic (with respect to subprefix) • The path is acyclic • The assignment edge is labeled y/k and is ASN-respecting • C’s delegation policy is faithful for y/k if there is at most one triple in the form: • (C, y/k, n) • (C, x/j, C’), (C, x/j, U), or (C, x/j, R), where x/j is a superprefix of y/k

17. Verification of Origin Announcements • OAs are verified by Origin Authentication Tags (OATs): • A delegation path • A set of delegation attestations • one for each edge in the path • An ASN Ownership Proof • Assumption: certificate infrastructure (PKI) • Attestations are proofs of edges in the graph

18. Delegation Schemes • Simple Delegation Attestation (SDA) • Authenticated Delegation List (ADL) • AS Authenticated Delegation List (AS ADL) • Authenticated Delegation Tree (ADT)

19. Simple Delegation Attestation • A signature by C for a prefix x/j: • { ( C, x/j, FC(x/j) ) }C • A signed statement (by C’s key) binding the prefix (x/j) to an organization identifier (FC(x/j)) • The simple delegation attestation for D(C): { ( C, x1/j1, FC(x1/j1) ) }C, { ( C, x2/j2, FC(x2/j2) ) }C, …, { ( C, xs/js, FC(xs/js) ) }C

20. The delegation path for 12.1.1.0/24 is: (IANA, AT&T, ALPHA, AS29987) The delegation attestation for the path are: [(IANA, 12.0.0.0/8, AT&T)]IANA, [(AT&T, 12.1.1.0/24, ALPHA)]AT&T, [(ALPHA, 12.1.1.0/24, AS29987)]ALPHA SDA: An Example

21. Authenticated Delegation List • C creates a single list of all of its delegations and sign that list [ { ( C, x1/j1, FC(x1/j1) ) }, { ( C, x2/j2, FC(x2/j2) ) }, …, { ( C, xs/js, FC(xs/js) ) } ]C • If C delegates xi/ji to B • C signs all of the delegations it makes to everyone. • B advertises xi/ji and provides this attestation

22. The delegation path for 12.1.1.0/24 is: (IANA, AT&T, ALPHA, AS29987) The delegation attestations for the path are: [(IANA, 12.0.0.0/8, AT&T), (IANA, 64.0.0.0/8, ARIN)]IANA, [(AT&T, 12.1.1.0/24, ALPHA), (AT&T, 64.1.0.0/16, AS7018), (AT&T, 12.0.0.0/8, AS7018)]AT&T, [(ALPHA, 12.1.1.0/24, AS29987)]ALPHA ADL: An Example

23. AS Authenticated Delegation List • C breaks up the entire list into several lists and signs each of the smaller lists. • The list is split according to those prefixes: • delegated to the same organization or • assigned to the same AS number • If C delegates xi/ji to B • C signs all of the delegations it makes to B. • B advertises xi/ji and provides this attestation

24. The delegation path for 12.0.0.0/8 is: (IANA, AT&T, AS7018) The delegation attestation for the path are: [(IANA, 12.0.0.0/8, AT&T)]IANA, [(AT&T, 64.1.0.0/16, AS7018), (AT&T, 12.0.0.0/8, AS7018)]AT&T AS ADL: An Example

25. Authenticated Delegation Tree • C creates a Merkle hash tree: • The values of the leaves: ( C, x/j, FC(x/j) ) • The values of each internal node: H(L, R) • If C delegates xi/ji to B • C only signs the root [h0]C • C provides the value of the children of all of the nodes on the path in the Merkel tree from the root to (C, xi/ji, B) • B advertises xi/ji and provides this attestation

26. The delegation attestation for (C, x2/j2, B): {H(L12, R34)}C, H(L3, R4), (C, x1/j1, A) ADT: An Example H(L12, R34) H(L1, R2) H(L3, R4) (C, x1/j1, A) (C, x2/j2, B) (C, x3/j3, D) (C, x4/j4, E)

27. User Dictionary Query Attestations Yes/No + Proof Directory Authenticated Delegation Dictionaries - 1 • The model for an authenticated dictionary • An Authenticated Dictionary for C: • Element: (C, y/k, FC(y/k)) • The search key: address prefixes • Data Structure: balanced 2-3 trees, with leaves sorted based on the search key

28. x/j x0/(j+1) x1/(j+1) x00/(j+2) x01/(j+2) x10/(j+2) x11/(j+2) Authenticated Delegation Dictionaries - 2 • Prefix Tree rooted at x/j: • A total order of the prefixes: x/j < xy/(j+k) < z/j • The smallest element: x/j The largest element: x1l-j/l

29. k0H(L123,R45) k1 k2H(L1,M2,R3) k3H(L4,R5) (C, x1/j1, A) (C, x2/j2, B) (C, x3/j3, D) (C, x4/j4, E) (C, x5/j5, F)) Authenticated Delegation Dictionaries - 3 • ADD for C: • The delegation attestation for (C, x2/j2, B): • The signed root: {k0H(L123, R45)}C • The value of the children of the nodes of the path:k3H(L4, R5), (C, x1/j1, A), (C, x3/j3, D) • The search tree path

30. Approximating IP Address Delegation • Goal: • To understand how and by whom delegation occurs • Sources: IANA and BGP announcements • What do we learn? • Dense (16 orgs delegate 80% address space) • Stable (10-30% movement in 5 months)

31. Approximation Example

32. Delegation in the ApproximateDelegation Graph • The overwhelming majority of delegations are being performed by a relatively few ASes/organizations

33. Trace-Based Simulation • The OAsim simulator: • Models the operation of a single BGP speaker • Accepts timed BGP UPDATE streams • Computes bandwidth/computational costs • Implements four service designs • Dataset: • Obtained from RouteViews • A trace of BGP updates over a 24 hour period

34. Computational Costs

35. Bandwidth Costs

36. Conclusions • OA is important in inter-domain routing • Trace and validate the delegation of address usage • Formalization • Semantics of address ads & proofs of delegation • Modeling • Current IPv4 address delegation is dense & static • Performance Evaluation • Tree-based proof system has best computation / bandwidth trade-offs • Online origin authentication is now in the realm of possibility

37. Comments? Questions ?