Security III: Availability, DDoS, sli.do time and Routing Security - PowerPoint PPT Presentation

3/28/19 Security III: Availability, DDoS, sli.do time… and Routing Security 15-441 Spring 2019 (yell at me if I don’t notice?) Profs Peter Steenkiste & Justine Sherry & (Guest Lecturer) Sannan Slides almost entirely copied from Vyas Sekar who in turn borrowed them from other professors. What do we need for a secure comm channel? • Availability (Can I reach the destination?) What were the four requirements for • Authentication (Who am I talking to?) a secure communications channel? • Confidentiality (Is my data hidden?) • Integrity (Has my data been modified?) 1

3/28/19 http://www.computerworld.com/article/2516953/enterprise-applications/a-chinese-isp-momentarily-hijacks- the-internet--again-.html 2

3/28/19 Goals of this lecture Two classes of attacks on availability we will discuss today • Routing Attacks • We’ll talk about flaws in BGP • Understand attacks on availability in the network. • Resource Exhaustion • Many attacks at the application layer — bugs in code — go take • DDoS 18-487 to learn more about those. • SYN Floods • This class focuses on attacks on availability in the network. • There are so many kinds of attacks we’re not discussing though! • Take 18-487 with Prof. Sekar! Recall: Internet routing • Internet relies on hierarchical routing • An Interior Gateway Protocol (IGP) is used to route packets within an AS: Intra-domain routing What kind of routing algorithm is • An Exterior Gateway Protocol (EGP) to maintain Internet connectivity among ASs: Inter-domain routing BGP? AS400 BGP AS100 BGP AS300 BGP BGP IGP AS200 3

3/28/19 How does BGP work? Internet routers communicate using the Border Gateway Protocol (BGP): • Destinations are prefixes (CIDR blocks) What are the other kinds of routing Example: 128.2.0.0/16 (CMU) • • Routes through Autonomous Systems (ISPs) algorithms we discussed in this • Each ISP is uniquely identified by a number Example: 25 (UC Berkeley) class (not BGP)? • • Each route includes a list of traversed ISPs: Example: 9 ← 5050 ← 11537 ← 2153 • Principles of operation • Exchange routes • AS100 announces 128.1.1.0/24 prefix to AS200 and AS300, etc Recap by doing! • Incremental updates 192.208.10.2 AS200 AS400 192.208.10.1 AS100 129.213.1.2 128.1.1.0/24 AS300 129.213.1.1 4

3/28/19 BGP UPDATE message UPDATE message example • Announced prefixes (aka NLRI) NLRI: 128.1.1.0/24 Nexthop: 192.208.10.1 • Path attributes associated with annoucement ASPath: 100 192.208.10.2 AS200 • Withdrawn prefixes AS400 192.208.10.1 192.208.10.2 AS200 AS100 AS400 192.208.10.1 129.213.1.2 128.1.1.0/24 AS300 AS100 129.213.1.1 NRLI:128.1.1.0/24 Nexthop: 129.213.1.2 129.213.1.2 128.1.1.0/24 AS300 ASPath: 100 129.213.1.1 All you need is one Route propagation compromised BGP speaker NLRI: 128.1.1.0/24 Nexthop: 190.225.11.1 NLRI: 128.1.1.0/24 ASPath: 200 100 Nexthop: 192.208.10.1 ASPath: 100 192.208.10.2 190.225.11.1 AS200 AS400 192.208.10.1 AS100 150.211.1.1 129.213.1.2 128.1.1.0/24 AS300 129.213.1.1 NLRI: 128.1.1.0/24 NRLI:128.1.1.0/24 Nexthop: 150.212.1.1 Nexthop: 129.213.1.2 ASPath: 300 100 ASPath: 100 5

3/28/19 Here’s what should have happened…. Pakistan Telecom: Sub-prefix hijack Pakistan Telecom: Sub-prefix hijack February 2008 : Pakistan Telecom hijacks YouTube Hijack + drop packets going to YouTube “The Internet” “The Internet” X Pakistan Pakistan I’m YouTube: I’m YouTube: YouTube Telecom YouTube Telecom IP 208.65.153.0 / 22 IP 208.65.153.0 / 22 Multinet Multinet Telnor Telnor Pakistan Pakistan Pakistan Pakistan Aga Khan Aga Khan University University Block your own customers. Potential attack objectives But here’s what Pakistan ended up doing… Pakistan Telecom: Sub-prefix hijack No, I’m YouTube! IP 208.65.153.0 / 24 “The Internet” • Blackholing – make something unreachable • Redirection – e.g., congestion, eavesdropping Pakistan Pakistan I’m YouTube: YouTube Telecom Telecom • Instability IP 208.65.153.0 / 22 Multinet Telnor • But more often than not, just a mistake! Pakistan Pakistan Aga Khan University 6

3/28/19 Unauthorized origin ISP (prefix theft) AS-path truncation Destination Route Destination Route Destination Route Destination Route Google M Google G←B Google G←B←M Google G←B←C G B C M G B C E M Destination Route M’s route to G is D M’s route to G is better than B’s Google G←B←D better than D’s AS path alteration Destination Route Destination Route How can we fix this problem? Google G←B←X←M Google G←B←C G B C M E M’s route avoids C 7

3/28/19 BGP Security Requirements • Verification of address space “ ownership ” What tools from the last two • Authentication of Autonomous Systems (AS) • Router authentication and authorization (relative to an AS) lectures might we use? • Route and address advertisement authorization • Route withdrawal authorization • Integrity and authenticity of all BGP traffic on the wire • Timeliness of BGP traffic Resource Public Key Infrastructure (RPKI): Certified mapping from ASes to public keys and IP prefixes. Securing the Internet: RPKI RPKI: Invalid! ? X Level3, VZW, 22394 ChinaTel 66.174.161.0/24 66.174.161.0/24 ISP 1 Why is this solution insufficient? Level 3 Verizon China Wireless Telecom RPKI shows China Telecom is not a 22394 valid origin for this prefix. 66.174.161.0/24 8

3/28/19 Resource Public Key Infrastructure (RPKI): Certified mapping S-BGP [1997]: RPKI + Cannot announce a path from ASes to public keys and IP prefixes. that was not announced to you. But RPKI alone is not enough! VZW: (22394, Prefix) Level3: (VZW, 22394, Prefix) ? ISP 1: (Level3, VZW, 22394, Prefix) Level3, VZW, 22394 ChinaTel, 22394 66.174.161.0/24 66.174.161.0/24 ISP 1 ISP 1 Level 3 Level 3 Verizon Verizon China Wireless VZW: (22394, Prefix) China Wireless Telecom Telecom Level3: (VZW, 22394, Prefix) 22394 Malicious router can pretend to connect to 22394 VZW: (22394, Prefix) the valid origin. Public Key Signature: Anyone with 22394’s public key can validate that the message was 66.174.161.0/24 sent by 22394. S-BGP [1997]: RPKI + Cannot announce a path S-BGP Secure Version of BGP that was not announced to you. VZW: (22394, Prefix) Level3: (VZW, 22394, Prefix) • Address attestations ISP 1: (Level3, VZW, 22394, Prefix) • Claim the right to originate a prefix • Signed and distributed out-of-band ISP 1 • Checked through delegation chain from ICANN Level 3 • Route attestations Verizon • Distributed as an attribute in BGP update message China Wireless • Signed by each AS as route traverses the network Telecom • Signature signs previously attached signatures • S-BGP can validate Malicious router can’t announce a direct path to 22394 • AS path indicates the order ASes were traversed 22394, since 22394 never said • No intermediate ASes were added or removed ChinaTel: (22394, Prefix) 9

3/28/19 S-BGP Deployment Challenges • Complete, accurate registries • E.g., of prefix ownership What might be hard about • Public Key Infrastructure • To know the public key for any given AS upgrading BGP to S-BGP? • Cryptographic operations • E.g., digital signatures on BGP messages • Need to perform operations quickly • To avoid delaying response to routing changes • Difficulty of incremental deployment • Hard to have a “flag day” to deploy S-BGP S-BGP Deployment Challenges We need path validating protocols • S-BGP: Secure BGP • Need ISPs to agree on and deploy a new protocol! • Each AS on the path cryptographically signs its announcement • Guarantees that each AS on the path made the announcement in the path. • These are competing organizations! • soBGP: Secure origin BGP • Economic incentives? • Origin authentication + • …Trusted database that guarantees that a path exists • Doesn’t improve performance • ASes jointly sign + put their connectivity in the DB • Hard to convince customers to pay more for security • Stops ASes from announcing paths with edges that do not exist • What challenges might soBGP face for deployment? • Origin authentication + • No benefit to unilateral deployment • …Trusted database that guarantees that a path exists • Need entire path to deploy SBGP/soBGP before you get any benefit! • ASes jointly sign + put their connectivity in the DB • Like IPv6…. But worse • Stops ASes from announcing paths with edges that do not exist • What challenges might soBGP face for deployment? 10