BGP Security The Human Threat

(1)

BGP Security –

The Human Threat

RIPE / Amsterdam

2011.05.02

(2)

Assume RPKI

98.128.0.0/16 Public Key 98.128.0.0/20 Public Key 98.128.16.0/20 Public Key 98.128.32.0/19 Public Key 98.128.16.0/24 98.128.17.0/24 Cert/ARIN Cert/RGnet Cert/UUNET Cert/RIPE Cert/APNIC Cert/IANA CA CA CA CA CA CA SIA 98.128.32.0/24 Cert/IIJ CA

(3)

Assume RPKI-RTR

RPKI Engine Repository Mgt Publication Protocol RCynic Gatherer to Rtr RPKI Protocol BGP Decision Process Cache django RPKI Repo

(4)

Assume Origin Validation

R3#sh ip bg 98.128.0.0/24

BGP routing table entry for 98.128.0.0/24, version 94 Paths: (2 available, best #2, table default)

65000 3130

10.0.0.1 from 10.0.0.1 (65.38.193.12)

Origin IGP, localpref 100, valid, external path 6802D4DC RPKI State invalid

65001 4128

10.0.1.1 from 10.0.1.1 (65.38.193.13)

Origin IGP, localpref 100, valid, external, best path 6802D7C8 RPKI State valid

(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.

(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

(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

(8)

Path Shortening Attack

X Z W $ $ $ A B $ $

Expected Path – A->X->W->B

Diverted Path - A->X->Z->W->B

There Are Many Many Other Attacks

ZB XZB

(9)

Forward Path Signing

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))))

X Z W $ $ $ A B ZB XWB WB B X

(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

(11)

Replay Attack

R0 R1 R2 R3 R4 0 1 0 3 1 0

(12)

Replay Attack

R0 R1 R2 R3 R4 0 1 0 3 1 0 0 2 0

X

(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

(14)

Hash Signed (To & Te) by Router Key AS0-Rtr-xx

^RtrCert

Origination by AS0 to AS1

NLRI AS0 AS1

• 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

Signed Forward Reference Sig0 New Optional Transitive Attribute

(15)

Announcement AS1 to AS2

AS1 ^RtrCert AS2

• 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

Signed Forward Reference

^RtrCert

NLRI AS0 AS1 Sig0

Hash Signed (To & Te) by Router Key AS0.rtr-xx

Sig1

Hash Signed by Router Key AS1-rtr-yy

(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

(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

(18)

Informal BGPsec Group

chris morrow (google) dave ward (juniper) doug maugham (dhs)

doug montgomery (nist) ed kern (cisco)

heather schiller (uunet) jason schiller (uunet) john scudder (juniper) kevin thompson (nsf) keyur patel (cisco)

kotikalapudi sriram (nist) luke berndt (dhs)

pradosh mohapatra (cisco) randy bush (iij)

rob austein (isc) ruediger volk (dt)

russ housley (vigilsec) russ mundy (sparta) sam weiler (sparta)

sandy murphy (sparta)

sharon goldberg (boston uni) steve bellovin (columbia uni) steve kent (bbn)

(19)

(20)

RPKI Reliability

Do you want bet your reachability on all these being reliable?

RCynic Gatherer Validated Cache Trust Anchor IANA _IANA

ARIN _ARIN _APNIC APNIC

UUNET _UUNET PSGnet _PSGnet

UUcust _UUcust IIJ IIJ SIA SIA SIA SIA

(21)

UUcust

Reliability Via Hosted Publication

Reducing the

Number of Publication Points Improves Things

But … Repository with Multiple Publication Points IANA _IANA

ARIN _ARIN _APNIC APNIC

UUNET _UUNET PSGnet

PSGnet

UUcust

IIJ

(22)

Think DNS

Root Anycast &

ccTLD Anycast

(23)

Global RPKI

Asia

Cache NoAm Cache Cache Euro

in-PoP

Cache in-PoP Cache in-PoP Cache in-PoP Cache Cache in-PoP in-PoP Cache in-PoP Cache in-PoP Cache in-PoP Cache

Cust

Facing Facing Cust Facing Cust Facing Cust Facing Cust

High Priority

Do Not Overload

Global RPKI

(24)

Covering a Customer

My Infrastructure

Unused

Static (non BGP) Cust

BGP Cust

I Issue a ROA for the Covering Prefix

I need to do this to protect

(25)

Covering a Customer

My Infrastructure

Unused

BGP Cust

But if I Issue a ROA for the Covering Prefix

Before My Customers issue ROAs for These

(26)

Covering a Customer

My Infrastructure

Unused

BGP Cust

If I Issue a ROA for the Covering Prefix

Before My Customers issue ROAs for These

(27)

0/0 Public Key 98.0.0.0/8 Public Key 98.128.0.0/16 Public Key RGnet ARIN IANA 98.128.0.0/1724 ROA 98.128.0.0/17 Public Key EE Cert CA CA CA

Up-Chain

Expiration

98.128.0.0/17 Public Key PSGnet CA Sloppy Admin Cert Soon to Expire!

These are not Identity Certs So Who Do You Call? So My ROA will become Invalid!

(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

(29)

0/0 Public Key 98.0.0.0/8 Public Key 98.128.0.0/16 Public Key RGnet ARIN IANA 98.128.0.0/17-24 ROA 98.128.0.0/17 Public Key EE Cert CA CA CA

Ghostbusters!

98.128.0.0/17 Public Key PSGnet CA 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: +1-666-555-1212 TEL;TYPE=FAX,WORK:+1-666-555-1213 EMAIL;TYPE=INTERNET:human@example .com END:vCard Ghostbusters Record draft-ietf-sidr-ghostbusters

(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

(31)

Grandparent

Rescue

98.128.0.0/17 Public Key PSGnet CA Sloppy Admin Cert Soon to Expire! Saved by Grandparent Deep Policy & Liability Issues

(32)

Authoritarian

Expiration

98.128.0.0/16 Public Key PSGnet CA So My Cert is Soon to Become Invalid!

Who Do You Call? Cert Task Force

Address Policy Rob’s New Policies

Authoritarian Issuer

(33)

And if You Believe

“Them is Us”

Read the ARIN PPML

Mailing List

(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?

(35)

BGP Security The Human Threat

BGP Security –

Origin Validation is Weak

Full Path Validation

ZB XZB

Forward Path Signing

X Z W $ $ $ A B ZB XWB WB B X

Capability Negotiation

Replay Attack

Origination by AS0 to AS1

NLRI AS0 AS1

Announcement AS1 to AS2

Signed Forward Reference

Only at Provider Edges

Simplex End Site

Receives Unsigned & Trusts Up-streams to Validate Signs Own Prefix(es) Signs Own Prefix(es)

Informal BGPsec Group

RPKI Reliability

Do you want bet your reachability on all these being reliable?

Reliability Via Hosted Publication

Reducing the

Think DNS

Global RPKI

Do Not Overload

I Issue a ROA for the Covering Prefix

Covering a Customer

But if I Issue a ROA for the Covering Prefix

Covering a Customer

If I Issue a ROA for the Covering Prefix

Up-Chain

These are not Identity Certs So Who Do You Call? So My ROA will become Invalid!

ROA Invalid but I Can Route

Passage;Deep Cavern; WA; 98666;U.S.A. TEL;TYPE=VOICE,MSG,WORK: +1-666-555-1212 TEL;TYPE=FAX,WORK:+1-666-555-1213 EMAIL;TYPE=INTERNET:human@example .com END:vCard Ghostbusters Record draft-ietf-sidr-ghostbusters

What if No Answer

Authoritarian

Who Do You Call? Cert Task Force

And if You Believe

THIS WORK IS SPONSORED IN PART BY THE DEPARTMENT OF HOMELAND SECURITY UNDER AN INTERAGENCY AGREEMENT WITH THE AIR FORCE RESEARCH LABORATORY (AFRL).