Route Security for Inter-domain Routing

Transcription

1

2 Route Security for Inter-domain Routing Alvaro Retana Distinguished Engineer, Cisco Services

3 3

4 This could happen to YOUR network 4

5 This could happen be happening to YOUR network 5

6 Agenda Review of problem to solve Resource Public Key Infrastructure as the base for a secure inter-domain routing solution BGP Origin AS Validation Call for action Summary and take-aways 6

7 Agenda Review of problem to solve Resource Public Key Infrastructure as the base for a secure inter-domain routing solution BGP Origin AS Validation Call for action Summary and take-aways 7

8 This presentation is NOT about traditional BGP Security and Stability problems Peering Authentication Goal: Verify that my peer is in fact my peer. The TCP Session can be Authenticated instead: MD-5 and TCP-AO in the future Error Correction Error detection results in resetting of the peering session! The IETF is working on related solutions Rich Policy BGP is a very policy rich protocol Each AS is in fact autonomous when making policy and forwarding decisions Result may be undesired flows from policy application This session IS about BGP Update Content Validation, particularly BGP AS-PATH attribute 8

9 AS-PATH is the attribute that records ASes transited by BGP UPDATE message AS 10 AS 20 AS 40 R2 R4 R1 R6 R3 R5 AS 30 9

10 The problem has been narrowed down to two statements Problem Statement 1: BGP Secure Origin AS Is the origin AS authorized to originate the BGP announcement? Problem Statement 2: Path Validation Can I trust the list of ASes in the AS-PATH attribute in that particular order? 10

11 AS-PATH is the attribute that records ASes transited by BGP UPDATE message AS 10 AS 20 AS 40 R2 R4 R1 From R2 Perspective: - Problem Statement 1 (BGP Secure Origin AS): Is AS40 authorized to originate an announcement for /16? R3 R5 - Problem Statement 2 (Path Validation): Does the route AS40 -> AS20 represent the exact path the BGP UPDATE message took*? AS 30 R6 11

12 Problem 1: BGP Secure Origin AS AS 10 AS 20 AS 40 R2 R4 R1 R6 R5 AS 30 AS30 ends up hijacking route /16 12

13 Problem is too common for comfort - FCC CSRIC 2013* - Main cause are normally attributed to typos, software glitches or bad operational practices - Some incidents are more suspicious than others Ref: * 13

14 Incidents can be geographically contained IXP Route Server: Open Peering Some provider incident in a big country: 1- AS1 generates BGP announcements to Route Server by redistributing IGP with especial tag X AS1 AS2 2- AS1 re-distributed Full Internet Table and mistakenly assigning tag X AS1 IGP 3- AS1 announces full BGP table to IXP Route Server with ASPATH AS1 (length=1) 4- Route Server distribute all routes to all participants 5- All Internet traffic through IXP to AS1 Full Internet Table 6- ebgp session from AS1 to Route-Server turned down due to traffic conditions 7- Repeat 14

15 Solving Inter-domain routing security dimensions are smaller compared to other global security challenges Inter-Domain Routing 2013(*): Number of Address Registries: 15 Total Number of Prefixes: Total ASes present in Table: Origin Only ASes: / Transit Ases: 5962 ASes announcing only one IPv4 prefix: Average prefixes per AS: Unregistered ASNs in the Routing Table: 274 DNS 2010 (**): Number of DNS Registries: 100s Total Number of domain names: Total Number of organizations running DNSSEC validation server.every home in the world? (*) Ref: Global Routing Table report: - Nov 2013 (**) Ref:ICANN Dashboard 2010 stats: 15

16 Problem 2: Incorrect Path Announcement AS 10 originates a prefix and only announces it to AS 15 AS 20 inserts itself in the ASPATH and incorrectly announces AS 10 s prefix to AS 40, AS 60, and AS 50 who ends up choosing path from AS 20 instead of AS / /16 AS 30, AS15, AS 10 AS 20, AS 10 AS 30 AS 15 AS 10 AS 40 AS /16 Fake Origin: AS /16 AS40, AS 30, AS 15, AS 10 AS 20, AS 10 AS 60 AS /16 AS 30, AS 15, AS 10 AS 20, AS 10 AS 20 ends up hijacking route announced by AS 10 16

17 Problem 2: Incorrect Path Announcement Man in the middle example: Stealing the Internet, Defcon 16. Alex Pilosov and Tony Kompela Targeting: AS50 & AS60 traffic toward AS /16 AS 30, AS15, AS 10 AS 20, AS 10 AS /16 AS 40, AS 30, AS 15, AS 10 AS 20, AS 10 no-export AS 60 Do not poison AS40 and use it for return path TTL Manipulation to enable stealth Packets forwarded to AS /16 AS 30 AS 15 AS 10 AS 20 AS 50 AS 20 ends up hijacking traffic from AS50 & AS60 towards AS 10 and traceroutes do not detect them 10.1/16 AS 30, AS 15, AS 10 AS 20, AS 10 no-export 17

18 Securing inter-domain routing has three components RPKI Infrastructure Offline repository of verifiable secure objects based on public key cryptography Follows resources (IPv4/v6 + ASN) allocation hierarchy to provide right of use You only validate the Origin AS of a BGP UPDATE BGP Secure Origin AS Solves most frequent incidents (*) No changes to BGP nor router s hardware impact Standardization almost finished and running code BGP PATH Validation BGPSEC proposal under development at IETF Requires forward signing ASPATH attribute Changes in BGP and possible routers (*) Ref: How Secure are Secure BGP Protocols, Sharon Goldberg, Microsoft Research & Boston University, NANOG 49 18

19 Agenda Review of problem to solve Resource Public Key Infrastructure as the base for a secure inter-domain routing solution BGP Origin AS Validation Call for action Summary and take-aways 19

20 Solution Space for Resource Authentication VS Hierarchical CA Chain: SMIME, TLS Web of Trust: PGP 20

21 How does Resource allocation work in the Internet? Central Registry: 0/0, ::/0 and all ASNs Allocations available here: Regional Registries receive large resource blocks from IANA: 21

22 Solution Space for Resource Authentication VS Hierarchical CA Chain: SMIME, TSL Web of Trust: PGP RPKI implements a resource certification chain of trust based on X.509 certificates 22

23 X509 as the base technology for RPKI ITU standard issued in 1988 Assumes a hierarchy system of Certificate Authorities (CAs) for issuing certificates. A certificate is a ASN.1 document, which profile is defined by RFC5280 Each CA issues certificates and which may be publically available in a repository Each CA will also issue a Certificate Revocation List (CRL) listening all certificates that have been revoked A Relaying party is an entity that performs the validation of X509 certificates Example applications for X509: Mail Authentication (SMIME), Web Server Authentication (TLS), User Authentication (TLS, SSO), etc. 23

24 X.509 most relevant certificate fields Version = 3 Serial Number Algorithm ID Issuer Validity: Not Before Not After Subject Unique ID in a CA for certificate. Used to identify certificate in CRL Creates Hierarchy: Parent CA to Child CA CA to End Entity (EE) Subject Information Access (SIA): URI for CA s publication point CRL Distribution Points: URI with CRL location Subject Public Key Extensions (optional) Certificate Signature 24

25 RPKI profile of X509 certificates RPKI is not an identity PKI. Names are meaningless. RFC 3779 creates an extensions to encode IP addresses and ASNs in an X509 certificate. Version Serial Number Signature Algorithm Issuer Subject Subject Public Key You can include either a prefix or an address range without CIDR boundary RFC 3779 extensions could be inherited from issuer to subject Extensions: Subject Information Authority (SIA) Access Authority Information (AIA) Addr: ASid:

26 Complete RPKI framework Issuer: IANA Subject: IANA Public Key IANA 0/0 Signed by IANA CA Trust Anchor IANA private key Issuer: IANA Subject: RIPE Public Key RIPE 193/8 Signed by IANA CA RIPE NCC private key Issuer: RIPE NCC CA Subject: ISP/LIR Public Key ISP/LIR /16 Signed by RIPE ISP/LIR private key 26

27 RPKI Signed Objects Cryptographic Message Syntax (RFC 5652) allows the signature/encryption of arbitrary data using ASN.1 format Examples of CMS use include: secure [RFC5751], key management [RFC5958], and firmware updates [RFC4108] Each Signed Object needs to be signed by an End-Entity Certificate and not by a CA certificate In RPKI an EE certificate is normally created for each signed object and it is included in the CMS wrapper. RPKI objects based on CMS: - Route Origin Authorizations (.roa) - Ghostbusters Record (.gbr) - Manifests for the Resource Public Key Infrastructure (.mft) 27

28 Route Origin Attestation (ROA) It is the End Goal for BGP Origin AS that ties IP address to Origin AS Validation only happens based on IP address hierarchy and NOT on Origin AS You can insert any AS number In a same ROA you can make several assertions. No need for one prefix=one ROA for the same origin AS. Important Fields: - ROAIPAddress: Prefixes/Prefix Legnth) - maxlength (optional): maximum length of the IP address prefix that the AS is authorized to advertise. If not available maxlength=prefix Length 28

29 Route Origin Attestation (ROA) Each AS publishes a cryptographically signed ROA that declares association of its prefixes with an Origin AS ROA /20-22 AS 3130 Signature The ROA says I m authorizing AS <3130> to be the origin for prefix < /20-22> and you can prove this by verifying the signature on this ROA With max-length=22, I do not need to enumerate every /20, /21 and /22 for these address block (similar as le statement in ip prefix lists ) 29

30 Complete RPKI framework Issuer: IANA CA Subject: IANA Public Key IANA 0/0 Signed by IANA OrgX_EE EE Issuer: IANA CA Subject: RIPE Public Key RIPE 193/8 Signed by IANA Issuer: RIPE NCC CA Subject: ISP/LIR Public Key ISP/LIR /20 Signed by ISP/LIR ROA /20-22 AS 3130 Signed by ISP/LIR /16 Signed by RIPE 30

31 RPKI Repository Infrastructure RIPE NCC s Repository Certificates RPKI Validator ROA Validation outcome: VALID: The ROA is conforming with validation process ROAs ROAs INVALID: The ROA is not conforming with validation process (*) Picture taken from RIPE RPKI training material 31

32 RPKI Infrastructure Management Hosted Model: Most entities (Hosted by RIR) RIR implements the certification application to create and maintain signed objects for the entities RIR publishes the entities s signed object in a public and highly available repositories RIR hosts the members private key Delegated model: National registries or entities that needs to keep business logic RIR only signs and publishes CA certificate for the entity The entity implements application for generation of additional signed objects The entity mantains repository for those additional signed objects Delegated entity can sub-delegate to other child-cas Communication between CAs is performed via the RPKI provisioning protocol (UP/DOWN) Open Source tool available at: 32

33 RPKI adoption growing particularly in LATAM and Europe since launch in 2012 There is not IANA root yet, each region has its own self-signed CA All regions have hosted services offering for IPv4/IPv6 since 2012 Currently 4% of global prefixes covered but growing extremely fast (300% yearly) Picture taken on Jan 6 th 2014 at: 33

34 Agenda Review of problem to solve Resource Public Key Infrastructure as the base for a secure inter-domain routing solution BGP Origin AS Validation Call for action Take-aways Summary and take-aways 34

35 Deeper Look at RPKI Infrastructure Parent CA RPKI Infrastructure Publication protocol repository rsync Verified ROA Payloads (VRPs) using rpki-router protocol Peering Router ebgp BGP Peer Provisioning Protocol (up/down) RPKI Validator & Cache ibgp Parent CA Publication protocol repository rsync VRPs via RTR Peering Router Configure your ROA: Authorize the use of your prefixes and publish to the rest of the word ISP Infrastructure (relaying party) ebgp Configure your trust anchors: Who to you trust to set your policies? BGP Peer 35

36 Cisco: adding BGP Origin AS validation to routers Parent CA RPKI Infrastructure Publication protocol repository rsync Verified ROA Payloads (VRPs) using rpki-router protocol Peering Router ebgp BGP Peer Provisioning Protocol (up/down) RPKI Validator & Cache ibgp Parent CA Publication protocol repository rsync VRPs via RTR Peering Router Configure your ROA: Authorize the use of your prefixes and publish to the rest of the word ISP Infrastructure (relaying party) ebgp Configure your trust anchors: Who to you trust to set your policies? BGP Peer 36

37 Cache Validator & Router Interaction ee - Receive prefixes from IBGP & EBGP peers - Inline origin validation by looking up validation database - Event-based validation on cache updates AF specific Validated ROA Payload (VRP) database Cache-to-router protocol (TCP, TCP with authentication, or SSH) RPKI Validator Server AF Specific BGP tables ebgp peering /9 origin BGP Speaker IPv4 Unicast VRP Database Prefix Max Length Origin AS ibgp peering (origin validation extended community) / IBGP Neighbor Router (ex. Route Reflector) BGP Table with Validation State (removing additional BGP attributes) Possible states: valid / invalid / not found No Crypto in the router. Only control plane software update required Prefix Origin AS RPKI State EBGP Neighbor Router / Valid 37 37

38 BGP Modifications Prefix Validation Logic 1. query key = <BGP prefix, masklen>, data = origin AS 2. result = BGP_PFXV_STATE_NOT_FOUND 3. walk prefix VRP table to look for the query key 4. for each matched entry node in VRP table, 5. prefix_exists = TRUE 6. walk all records with different maxlength values 7. for each record within range (query masklen <= maxlength) 8. if query origin AS == record origin AS 9. result = BGP_PFXV_STATE_VALID 10. return (result) 11. endif 12. endfor 13. endfor 14. if prefix_exists == TRUE, 15. result = BGP_PFXV_STATE_INVALID 16. endif 17. return (result) 38 Geek - o - meter

39 BGP Modifications Path Validation State Path Validation States (in order of preference) BGP_PFX_STATE_VALID (Lookup Successful) BGP_PFX_STATE_NOT_FOUND (None in the table) BGP_PFX_STATE_INVALID (Lookup invalid maybe a wrong origin AS or masklength not in the range) Path validation state computed for EBGP paths 39

40 Setting up the validation states in routers Validated ROA Payload (VRP)unique entry: Prefix= /20, max_length=22, origin AS=3130 Received Announcements in ebgp session: /19 Origin AS /20 Origin AS /20 Origin AS /22 Origin AS /24 Origin AS /22 Origin AS /24 Origin AS 3131 Green = valid Orange = not found Red = invalid 40

41 Setting up the validation states in routers Validated ROA Payload (VRP)unique entry: Prefix= /20, max_length=22, origin AS=3130 Received Announcements in ebgp session: /19 Origin AS /20 Origin AS /20 Origin AS /22 Origin AS /24 Origin AS /22 Origin AS /24 Origin AS Green = valid Orange = not found Red = invalid 41

42 Setting up the validation states in routers Validated ROA Payload (VRP)unique entry: Prefix= /20, max_length=22, origin AS=3130 Received Announcements in ebgp session: /19 Origin AS /20 Origin AS /20 Origin AS /22 Origin AS /24 Origin AS /22 Origin AS /24 Origin AS Green = valid Orange = not found Red = invalid 42

43 Setting up the validation states in routers Validated ROA Payload (VRP)unique entry: Prefix= /20, max_length=22, origin AS=3130 Received Announcements in ebgp session: /19 Origin AS 3130 Origin AS Violation /20 Origin AS /20 Origin AS 3130 Max-Length Violation /22 Origin AS /24 Origin AS /22 Origin AS /24 Origin AS Origin AS and Max-Length Violations Green = valid Orange = not found Red = invalid 43

44 Setting up the validation states in routers Validated ROA Payload (VRP)unique entry: Prefix= /20, max_length=22, origin AS=3130 Received Announcements in ebgp session: /19 Origin AS /20 Origin AS /20 Origin AS /22 Origin AS /24 Origin AS /22 Origin AS /24 Origin AS Green = valid Orange = not found Red = invalid 44

45 BGP Modifications for Origin AS Validation EBGP update Perform origin validation Apply inbound policy (policy _may_ match on validity state and set arbitrary attributes) Add to ADJ- RIB-IN Run BGP Bestpath Router Install Route in RIB & FIB IBGP update (advertised with the attributes modified by outbound policy and/or with an origin validation extended community) 45

46 Cisco Implementation of BGP Origin Validation Cisco has been testing engineering code since 2009 in public and private testbeds Implementation of the following features in IOS/XE and IOS-XR: RPKI/Router Protocol (RFC 6810) - Tested with publicly available RP software BGP Prefix Origin Validation (RFC 6811) - Load much less than ACLs: 10us per Update - Full policy control for valid/invalid/not found prefixes BGP Prefix Origin Validation State Extended Community (draft-ietf-sidr-originvalidation-signaling) - Only valid for Internal BGP peers 46

47 Some Configuration details (IOS) Setting up a connection to a cache server: router bgp bgp rpki server tcp port 2222 refresh 60 Do not deny invalid routes: router bgp address-family ipv4 bgp bestpath prefix-validate allow-invalid Enabling Extended Community for ibgp neighbor: router bgp address-family ipv4 neighbor announce rpki state 47 47

48 Some Configuration details (IOS) Policy management using Route-Maps and RPKI states: router bgp address-family ipv4 unicast neighbor route-map localpref out exit route-map localpref permit 10 match rpki valid set local-preference 200 Policies can be set for valid / invalid /not found 48 48

49 Some troubleshooting details (IOS) RPKI cache servers status: route#show ip bgp rpki servers BGP SOVC neighbor is /2222 connected to port 2222 Flags 448, Refresh time is 60, Serial number is 3, Nonce is InQ has 0 messages, OutQ has 0 messages, formatted msg 2 Session IO flags 3, Session flags 4000 Neighbor Statistics: Prefixes 1317 Connection attempts: 1 Connection failures: 0 Errors sent: 0 Errors received:

50 Some troubleshooting details (IOS) RPKI table status: route#show ip bgp rpki table 989 BGP sovc network entries using bytes of memory 1061 BGP sovc record entries using bytes of memory Network Maxlen Origin-AS Source Neighbor / / / /2222. router#show bgp ipv6 unicast rpki table 239 BGP sovc network entries using bytes of memory 256 BGP sovc record entries using 5120 bytes of memory Network Maxlen Origin-AS Source Neighbor 2001:608::/ / :610::/ /

51 Some troubleshooting details (IOS) BGP Origin validation summary information: router#show ip bgp summary BGP router identifier , local AS number BGP table version is , main routing table version Path RPKI states: 3214 valid, not found, 2504 invalid BGP Origin validation in BGP table: router#show ip bgp.. RPKI validation codes: V valid, I invalid, N Not found Network Next Hop Metric LocPrf Weight Path *> N / I.. *> N / i 51 51

52 Some troubleshooting details (IOS) Prefix validation state: router#show ip bgp /18 BGP routing table entry for /18, version Paths: (1 available, best #1, table default) Not advertised to any peer Refresh Epoch , (received & used) from ( ) Origin IGP, localpref 100, valid, external, best path 0D1AE740 RPKI State valid 52 52

53 IOS-XR Policy and Path Validation State RPL extended to modify policies based on path validation state IOS-XR RPL example: route-policy rpki if validation-state is invalid then set local-preference 50 else if validation-state is valid then set local-preference 200 else pass endif end policy 53 53

54 IOS-XR Config Commands router bgp bgp router-id rpki cache transport tcp refresh-time 120! neighbor remote-as

55 IOS-XR Show Commands IOX#sh bgp origin-as validity [snip] RPKI validation codes: V valid, I invalid, U unknown, d disabled, n not-applicable Network Next Hop Metric LocPrf Weight Path V*> / i I* / i U*> / ? Processed 3 prefixes, 3 paths 55 55

56 IOS-XR Records (RPKI) Table IOX#show bgp rpki table Network Maxlen Origin-AS Cache / / * / / / * * Source cache is down / ROAs are pending removal Processed 5 RPKI entries 56 56

57 IOS-XR Show Commands Valid Prefix IOX#show bgp /25 Mon May 16 02:07: PDT BGP routing table entry for /25 Versions: Process brib/rib SendTblVer Speaker Last Modified: May 15 14:22: for 11:44:38 Paths: (1 available, best #1) Advertised to peers (in unique update groups): Path #1: Received by speaker from ( ) Origin IGP, localpref 100, valid, external, best, group-best Received Path ID 0, Local Path ID 1, version 23 Origin-AS validity: valid 57 57

58 Agenda Review of problem to solve Resource Public Key Infrastructure as the base for a secure routing solution BGP Origin AS Validation Call for action Summary and take-aways 58

59 Call for action 1. Create your ROAs at the RIR Portal! 1. Check if your current software releases support RPKI 2. Test validator server, qualify traffic without modifying routing policies 3. Start applying routing policies in islands of trust 59 59

60 Call for action Evangelize a more secure inter-domain routing in your network operators community 60 60

61 An RPKI island of trust in Ecuador (Sept 2013) Near closed inter-domain routing community where full community decides to implement RPKI in an island of trust 100% 90% 80% 70% 60% 50% 40% 30% 20% 10% RPKI Evolution for Ecuador % IPv4 space covered 0% 7/19 7/26 8/2 8/9 8/16 8/23 8/30 9/6 9/13 9/20 61

62 Take-Aways Problem too common for comfort Origin validation as first outcome from standardization bodies solves most frequent problems RPKI is the off-line trust infrastructure based on x.509 certificates that follows address allocation hierarchy Cisco supports BGP Origin AS Validation in IOS/XE and IOS-XR. Your current release may support it! Go and create your ROAs in 2 minutes today! 62

63 Complete Your Online Session Evaluation Give us your feedback and you could win fabulous prizes. Winners announced daily. Complete your session evaluation through the Cisco Live mobile app or visit one of the interactive kiosks located throughout the convention center. Don t forget: Cisco Live sessions will be available for viewing on-demand after the event at CiscoLive.com/Online 63

64 Continue Your Education Demos in the Cisco Campus Walk-in Self-Paced Labs Table Topics Meet the Engineer 1:1 meetings 64

65

66

67 RPKI Router Protocol Protocol to distribute *digested* RPKI information in form of (prefix range, Origin AS) Routers avoid dealing with RPKI complexity Has a client and a Server side functionality Use SSHv2 as a transport layer Distributes *digested* RPKI information using fix length Protocol PDUs IOS has currently implemented the Client side functionality Initial IOS release plans to run TCP as a transport. Eventually will be replaced with SSHv2. IOS-XR supports SSHv2. 67

68 RPKI Router Protocol PDUs Serial Notify Local Cache informs router about new data Serial Query Router requests Cache for updates Uses End Of Data PDU to signal end of transfer Reset Query Router requests Cache to send its entire database Cache Response Cache replies to Reset Query by announcing its entire database End of Data PDU Cache signals end of database announcements 68

69 RPKI Router Protocol PDUs (cont d) IPv4 PDU Local Cache informs router of ipv4 prefix range and its associated origin AS IPv6 PDU Local Cache informs router of ipv6 prefix range and its associated origin AS Cache Reset Local Cache informs router about its inability to provide an incremental update for a particular Serial Query Error Report Use to signal errors detected while parsing PDUs Internal Errors: memory exhaustion, code assertion failures, etc No Data Available: Cache cannot provide an incremental update to a particular Serial Query. 69

70 RPKI Router Protocol Typical Exchange Cache Router ~ ~ <----- Reset Query R requests data Cache Response -----> C confirms request IPvX Prefix > C sends zero or more IPvX Prefix > IPv4 and IPv6 Prefix IPvX Prefix > Payload PDUs End of Data > C sends End of Data and sends new serial 70

71 RPKI Router Protocol Incremental Exchange (cont d) Cache ~ ~ Router Notify > (optional) <----- Serial Query R requests data Cache Response -----> C confirms request IPvX Prefix > C sends zero or more IPvX Prefix > IPv4 and IPv6 Prefix IPvX Prefix > Payload PDUs End of Data > C sends End of Data and sends new serial ~ ~ 71

72 References Current IETF Related Work: BGP Error Correction: - Operational Requirements for Enhanced Error Handling Behaviour in BGP-4 (draft-ietf-grow-ops-reqs-for-bgp-error-handling) - Revised Error Handling for BGP UPDATE (draft-ietf-idr-error-handling) - Graceful BGP session shutdown (draft-ietf-grow-bgp-gshut) BGP Rich Policy: - Making BGP filtering a habit: Impact on policies (draft-cardona-filtering-threats) 72

73 Code Availability RPKI Certificate Authority RPKI.NET: Cache Validator Software - RPKI.NET: - RIPE NCC Validation software: - Relying Party Security Technology for Internet Routing (BBN): 73