BGP Security The Human Threat

Transcription

1 BGP Security The Human Threat RIPE / Amsterdam Randy Bush <randy@psg.com> The Human Threat 1

2 Assume RPKI Cert/IANA CA /16 SIA Cert/RIPE CA CA CA Cert/ARIN Cert/APNIC / / /19 CA Cert/UUNET Cert/RGnet CA Cert/IIJ CA / / / The Human Threat 2

3 Assume RPKI-RTR django RCynic Gatherer Cache RPKI to Rtr Protocol BGP Decision Process RPKI Engine Publication Protocol Repository Mgt RPKI Repo The Human Threat 3

4 Assume Origin Validation R3#sh ip bg /24 BGP routing table entry for /24, version 94 Paths: (2 available, best #2, table default) from ( ) Origin IGP, localpref 100, valid, external path 6802D4DC RPKI State invalid from ( ) Origin IGP, localpref 100, valid, external, best path 6802D7C8 RPKI State valid The Human Threat 4

5 Origin Validation is Weak Today s Origin Validation provides neither cryptographic assurance (announcements are not signed), nor assurance of the AS Path of the announcement. A malicious router may announce as any AS, i.e. forge the ROAed origin AS. This would pass ROA Validation The Human Threat 5"

6 Protocol Not Policy Policy on the global Internet changes every 36ms We already have a protocol to distribute policy or its effects, it is called BGP We can not know intent, should Mary have announced the prefix to Bob But Joe can formally validate that Mary did announce the prefix to Bob BGPsec validates that the protocol has not been violated, and is not about intent or business policy The Human Threat 6"

7 Full Path Validation Rigorous per-prefix AS path validation is the goal Protect against origin forgery and AS- Path monkey in the middle attacks Not merely showing that a received AS path is not impossible Yes, this is S-BGP-like not SO-BGP-like The Human Threat 7"

8 Path Shortening Attack X ZB $ $ Z XZB WB $ $ $ W B A B Expected Path A->X->W->B Diverted Path - A->X->Z->W->B There Are Many Many Other Attacks The Human Threat 8

9 Forward Path Signing ZB X Z XWB WB $ $ $ X W B A B cryptographically signs the message to W Sb(B->W) W signs messages to X and Z encapsulating B s message Sw(W->X (Sb(B->W))) and Sw(W->Z (Sb(B->W))) X signs the message to A Sx(X->A (Sw(W->X (Sb(B->W)))) Z can only sign Sz(Z->X (Sw(W->Z (Sb(B->W)))) B The Human Threat 9

10 Capability Negotiation It is assumed that consenting routers will use BGP capability exchange to agree to run BGPsec between them The capability will, among other things remove the 4096 PDU limit for updates If BGPsec capability is not agreed, then only traditional BGP data are sent The Human Threat 10"

11 Replay Attack R1 0 R4 R3 R0 R The Human Threat 11"

12 Replay Attack R1 X 0 R4 R R0 R The Human Threat 12"

13 Replay Reduction Announcement replay is a vulnerability Therefore freshness is critical So originating announcer signs with a relatively short signature lifetime Origin re-announces prefix well within that lifetime, AKA beaconing Suggested to be days, but can be hours for truly critical infrastructure The Human Threat 13"

14 Origination by AS0 to AS1 New Optional Transitive Attribute NLRI AS0 ^RtrCert AS1 Sig0 Hash Signed (To & Te) by Router Key AS0-Rtr-xx Signed Forward Reference To and Te are times of signature origination and expiration Signature has a well-jittered validity end time, Te, of days Re-announcement by origin, AKA beaconing, every ~(Te-To)/3 ROA is not needed as prefix is sufficient to find it in RPKI as today The Human Threat 14"

15 Announcement AS1 to AS2 NLRI AS0 ^RtrCert AS1 Sig0 AS1 ^RtrCert AS2 Sig1 Hash Signed (To & Te) by Router Key AS0.rtr-xx Hash Signed by Router Key AS1-rtr-yy Signed Forward Reference R1 signing over R0 s signature is same as signing over entire R0 announcement Non-originating router signatures do not have validity periods But when they receive a beacon announcement, they must propagate it The Human Threat 15"

16 Only at Provider Edges This design protects only inter-domain routing, not IGPs, not even ibgp BGPsec will be used inter-provider, only at the providers' edges Of course, the provider s ibgp will have to carry the BGPsec information Providers and inter-provider peerings might be heterogeneous The Human Threat 16"

17 Simplex End Site Receives Unsigned & Trusts Up-streams to Validate Signs Own Prefix(es) Signs Own Prefix(es) Only Needs to Have Own Private Key, No Other Crypto or RPKI Data No Hardware Upgrade!! The Human Threat 17"

18 Informal BGPsec Group chris morrow (google) pradosh mohapatra (cisco) dave ward (juniper) randy bush (iij) doug maugham (dhs) rob austein (isc) doug montgomery (nist) ruediger volk (dt) ed kern (cisco) russ housley (vigilsec) heather schiller (uunet) russ mundy (sparta) jason schiller (uunet) sam weiler (sparta) john scudder (juniper) sandy murphy (sparta) kevin thompson (nsf) sharon goldberg (boston uni) keyur patel (cisco) steve bellovin (columbia uni) kotikalapudi sriram (nist) steve kent (bbn) luke berndt (dhs) warren kumari (google) matt lepinski (bbn) The Human Threat 18"

19 The Real Threats The Human Threat 19"

20 RPKI Reliability Do you want bet your reachability on all these being reliable? IANA IANA Trust Anchor SIA ARIN ARIN APNIC APNIC SIA SIA UUNET UUNET PSGnet PSGnet IIJ IIJ SIA UUcust UUcust RCynic Gatherer Validated Cache The Human Threat 20"

21 Reliability Via Hosted Publication IANA IANA ARIN ARIN APNIC APNIC UUNET UUNET UUcust PSGnet IIJ PSGnet IIJ UUcust The Human Threat Repository with Multiple Publication Points Publication Protocol draft-ietf-sidr-publication Reducing the Number of Publication Points Improves Things But 21"

22 Think DNS Root Anycast & cctld Anycast The Human Threat 22"

23 Do Not Overload Global RPKI Global RPKI Asia Cache NoAm Cache Euro Cache in-pop Cache in-pop Cache in-pop Cache in-pop Cache in-pop Cache in-pop Cache in-pop Cache in-pop Cache in-pop Cache Cust Facing Cust Facing Cust Facing Cust Facing Cust Facing The Human Threat Have Cache in POP High Priority Lower Priority 23"

24 Covering a Customer I Issue a ROA for the Covering Prefix I need to do this to protect Static Customers and my Infrastructure My Infrastructure BGP Cust Static (non BGP) Cust Unused The Human Threat 24"

25 Covering a Customer But if I Issue a ROA for the Covering Prefix Before My Customers issue ROAs for These My Infrastructure BGP Cust Static (non BGP) Cust Unused The Human Threat 25"

26 Covering a Customer If I Issue a ROA for the Covering Prefix Before My Customers issue ROAs for These Their Routing Becomes Invalid! My Infrastructure BGP Cust Static (non BGP) Cust Unused The Human Threat 26"

27 Up-Chain Expiration IANA 0/0 CA ARIN CA /8 These are not Identity Certs RGnet /16 PSGnet CA CA Sloppy Admin Cert Soon to Expire! /17 So Who Do You Call? The Human Threat EE Cert /17 ROA /1724 AS 3130 So My ROA will become Invalid! 27"

28 ROA Invalid but I Can Route The ROA will become Invalid My announcement will just become NotFound, not Invalid Unless my upstream has a ROA for the covering prefix, which is likely The Human Threat 28"

29 Ghostbusters! IANA 0/0 CA ARIN CA /8 RGnet /16 CA Ghostbusters Record PSGnet CA /17 EE Cert /17 ROA BEGIN:vCard VERSION:3.0 FN:Human's Name N:Name;Human's;Ms.;Dr.;OCD;ADD ORG:Organizational Entity ADR;TYPE=WORK:;;42 Twisty Passage;Deep Cavern; WA; 98666;U.S.A. TEL;TYPE=VOICE,MSG,WORK: TEL;TYPE=FAX,WORK: END:vCard draft-ietf-sidr-ghostbusters /17-24 AS The Human Threat 29"

30 What if No Answer What if the threatening cert s maintainer does not answer or maintain their cert? Can I appeal up-stream of them? Will the grandparents take care of the children? The Human Threat 30"

31 Grandparent Rescue IANA 0/0 CA Sloppy Admin Cert Soon to Expire! ARIN /8 RGnet /16 CA CA PSGnet Deep Policy & Liability Issues CA /17 Saved by Grandparent EE Cert /17 ROA / The Human Threat AS "

32 Authoritarian Expiration ARIN /8 CA IANA 0/0 CA Authoritarian Issuer RGnet CA /16 PSGnet CA /16 EE Cert /16 ROA /16-24 So My Cert is Soon to Become Invalid! Who Do You Call? Cert Task Force Address Policy Rob s New Policies The Human Threat AS "

33 And if You Believe Them is Us Read the ARIN PPML Mailing List The Human Threat 33"

34 But in the End, You Control Your Policy Announcements with Invalid origins MAY be used, but SHOULD be less preferred than those with Valid or NotFound. -- draft-ietf-sidr-origin-ops But if I do not reject Invalid, what is all this for? The Human Threat 34"

35 THIS WORK IS SPONSORED IN PART BY THE DEPARTMENT OF HOMELAND SECURITY UNDER AN INTERAGENCY AGREEMENT WITH THE AIR FORCE RESEARCH LABORATORY (AFRL). we Take your Scissors Away and turn them into plowshares The Human Threat 35"