Securing BGP - A Literature Surveycaia.swin.edu.au/talks/CAIA-TALK-100318A.pdf · Securing BGP - A Literature Survey Geoff Huston, Mattia Rossi, Grenville Armitage [email protected],

Securing BGP - A LiteratureSurvey

Geoff Huston, Mattia Rossi, GrenvilleArmitage

[email protected], [email protected], [email protected]

Centre for Advanced Internet Architectures (CAIA)Swinburne University of Technology

OutlineIntroductionThe Architecture of IP RoutingThe Design and Operation of BGP

BGP MessagesBGP Route Selection Process and Routing Policies

The BGP Threat ModelSecuring the BGP sessionVerifying BGP IdentityVerifying Forwarding Paths

Securing BGPThe Security ToolsetSecurity RequirementsApproaches to Securing BGPSecuring the Data PlaneState of BGP Security

ConclusionsCaia Seminar http://www.caia.swin.edu.au [email protected], [email protected], [email protected] 18, 2010 2

mailto:[email protected]



http://www.caia.swin.edu.au




What is routing?

Internet is decentralised networkEnd hosts and routersHosts generate IP packets, routers direct packets todestinationInternet topology changes continuously, routing needs to bedynamicRouters propagate location of addresses to each other inorder to allow consistent and optimal packet forwardingdecisionsRouting protocols are used to perform this informationpropagation

Caia Seminar http://www.caia.swin.edu.au [email protected], [email protected], [email protected] 18, 2010 4

Some BGP background

Intra-domain routing (RIP, OSPF) within AutonomousSystem (AS) vs. inter-domain routing (BGP) between ASBGP is the sole Inter-domain routing protocol since the late1980’sBGP is crucial for the operation and security of the InternetBGP relies on informal trust models to provide reliable andcorrect resultsDesign was based on homogeneous and mutually trustingInternet of the 80’sNot designed for negotiated trust models and for robustnessagainst hostile actors










A trust problem

BGP is vulnerable as Internet grows and risk of hostilityincreasesBGP trust model lacks of:

explicit presentation of credentialspropagation of instruments of authorityany reliable means of verifying the authenticity of theinformation being propagated through the routing system

Possible hostile actions are difficult to detect:false routing information may be injectedvalid routing information removedinformation altered to cause traffic redirection


What could happen?

Aims of attacks:prevent the correct operation of applicationsconduct fraudulent activitiesdisrupt the operation of part (or even all) of the network invarious ways

Effects of attacks:from relatively inconsequentialthrough to catastrophic

Real examples:“7007 Incident”, 1997“Con Edison steals the Net”, 2006“Youtube Accident”, 2008“The Internet’s Biggest Security Hole” Wired Magazine, 2008










Requirements to resist to subversion of integrity

BGP speaker needs:Sufficient information to verify the authenticity andcompleteness of the information receivedThe ability to generate authoritative information for others toverify the authenticity of routing information

BGP scalability has to be considered!


How the Internet works

Internet is based on the Internet Protocol (IP)Decoupled framework consisting of:

IP addressesforwarding system (data plane)routing system (control plane)routing protocols

Addresses are identity not location, numerical adjacency 6=topological adjacencyForwarding system selects the interface on a local routerdepending on information from the routing system (localview)Routing system provides information of address locationbetween ASes using inter-domain routing protocols (globalview)ASes can be single routers or a complex system of routers(peers) using an intra-domain routing protocol










Routing Protocols

Different routing protocols:Intra-domain: Interior Gateway Protocols (IGPs) - RIP,RIPng, OSPF, OSPFv2, IS-ISInter-domain: BGP

Two types of BGP:iBGP for BGP peering between edge routers of an ASeBGP for inter-AS peering

iBGP 6= IGP!iBGP needs full mesh to maintain BGP informationconsistentFull mesh has scalability problem => route reflector


An example topology

eBGPAS2-AS3

eBGPAS3-AS4

eBGPAS1-AS4

eBGPAS1-AS3

AS1AS2

AS3

AS4

RIPv2

iBGPfull mesh

OSPF

iBGPfull mesh

IS-IS

iBGP w/Route Reflector










History of BGP

Current Version: BGP-4 - Current Standard: RFC4271(January 2006)Version 1: RFC1105 - 1989, Version 2: RFC1163 - 1990,Version 3: RFC1267 - 1991Version 4: RFC1771 - March 1995, refined in RFC4271Grown from 20000 routes to 300000 routes

50k

100k

150k

200k

250k

300k

89 90 91 92 93 94 95 96 97 98 99 00 01 02 03 04 05 06 07 08 09

Activ

e BG

P En

tries

(FIB

)

Date


BGP and TCP

BGP uses TCP to exchange routing updatesAssumption of the existence of a functional IP forwardingenvironment at link levelAllows to operate across logical connections on the samesub-net, LAN or InternetBGP messages use markers for identification and arebetween 19 and 4096 bytes longUse of TCP omits overhead of ensuring reliable packetdelivery by the routing protocolUse of reliable transport protocol also omits the need toperiodically refresh the routing tableOnly incremental updates are needed after sending theinitial routing table.










BGP Messages

5 message types using a common Header:OPEN - to start a BGP peering sessionUPDATE - to exchange reachability informationNOTIFICATION - used to convey a reason code prior totermination of the BGP sessionKEEPALIVE - to confirm the continued availability of the BGPpeerROUTE-REFRESH - to request a resend of the routinginformation

BGP common header:

Marker (16 Octets)

Length (2 Octets) Type (1 Octet)1 - OPEN2 - UPDATE3 - NOTIFICATION4 - KEEPALIVE5 - ROUTE-REFRESH


OPEN Message

Marker (16 Octets)

Length (2 Octets) Type = 1 (Open)Version (1 Octet)

My AS (2 Octets) Hold Time (2 Octets)

BGP Identifier (4 Octets)

Opt Length (1 Octet) Optional Parameters ...










UPDATE Message

Marker (16 Octets)

Length (2 Octets) Type = 2 Update

Withdrawn Prefixes Length (2 Octets)

Withdrawn Prefixes List (variable) ...

Path Attributes Length (2 Octets)

Path Attributes List (variable) ...

Update Prefixes List = Network Layer Reachability Information – NLRI (variable) ...

Prefix List Entry

Length (1 Octet)

Prefix (variable) ...

Attribute List Entry

Flags (1 Octet)

Length (1 or 2 Octets)

Type (1 Octet)

Value (variable) ...


NOTIFICATION Message

Marker (16 Octets)

Length (2 Octets) Type = 3 (Notify) Code (1 Octet)

Subcode (1 Octet) Optional Data ...










KEEPALIVE Message

Marker (16 Octets)

Length = 19 Type = 4 Keepalive


ROUTE-REFRESH Message

Marker (16 Octets)

Length = 19 Type = 5 Route-Refresh










Route selection

BGP can receive announcements for the same prefix fromdifferent peersBest path needs to be selected through decision process:

Select the route object with the highest value forLOCAL-PREF attribute valueSelect the route object shortest AS_PATH attribute lengthSelect the lowest MULTI_EXIT_DISCRIMINATOR attributevalueSelect the minimum IGP cost to the NEXT_HOP addressgiven in the route objectSelect eBGP over iBGP-learnt routesIf iBGP select the lowest BGP Identifier value.

General rule: more specific prefix is preferred over acovering prefixBehaviour can be changed by network administrator


Analysing BGP communication

How do we talk?Whom am I talking to?What are you saying?Should I believe you?How recent is your information and is it still valid?










Attacks over the communication channel

BGP peer session is a long-held TCP session and thusvulnerable to

eavesdroppingsession resetsession capturemessage alterationdenial of service attacks

BGP has no enforced minimum level of message protection


Attacks over the communication channel

Possible attacks are:Man in the middle attack: filter traffic from both sides andalter messagesMessage injection: inject false routing informationDelay messages: timing is important, BGP peer could fall outof sync and start distributing bogus routing informationReplay Attack: Replay withdrawals after announcements andtrigger route flap damping (RFD)Saturation Attack: insert bogus TCP messages, causingDenial of Service (even worse if MD5 or IPSEC is used dueto decryption overhead)










Verifying BGP Identity

Verify the authenticity and completeness of the routinginformationA local BGP speaker believes everything sent from a remotepeer, unable to detect bogus informationThreats:

Suppression of routing informationAlteration of the route object that is passed onInvention of spurious route objects.Assertion that an AS Path is genuine when it reflects anartificial pathOriginate an advertisement for a prefix when, in fact, no suchauthority exists (prefix hijacking)


Prefix Hijacking

Origin: AS 1123.123.0.0/16

Attacker: AS 6123.123.0.0/24

:123.123.254.0/24

AS 2AS 3

AS 4 AS 5

Hijacked:Prefix 123.123.0.0/24

:Prefix 123.123.254.0/24

AS Path: 4,3,2,6

Correct:Prefix 123.123.0.0/16

AS Path: 4,3,2,1

Prefix hijacking types:Stealing a whole prefix by announcing it with specialattributes to bias the route selection processAnnouncing more specific prefixes which together completelycover the larger prefixAnnouncing an unallocated prefix

May happen due to operational misconfigurationDifficult to detect, specially if sub-prefix is hijackedBGP cannot verify the authenticity of prefixes and attributes










Attacks to the Data Plane

Forwarding table is usually generated by lookups to therouting tableForwarding table can be inconsistent with routing tableBGP is missing a mechanism to verify the consistencyPossible threats:

subversion of local policiestheft of carriage capacitydeliberate denial of servicepotential to eavesdrop on a conversationsupport the interception and alteration of application leveltransactionspotential to masquerade, steal addresses and obscureidentity (fake DNS, generate SPAM)

Secure control plane = secure routing but routing 6=forwarding


BGP is vulnerable

Vulnerable and exposed to previously listed threatsRouters can be compromised (in 2001 some deployeddefault passwords)Not possible to prevent routers from generating falsemessages, if routers can be compromisedConsequence: there is no mechanism that limits the extentto which a misbehaving router can make false claims aboutreachability










Securing BGP - Basics

Tools protecting the TCP session (implementations exist):Generalized TTL security mechanism (GTSM): Limits theradius of an attacker and can protect against SYN-floodingand similar attacks

AttackerA

B C

TTL 255

TTL 255

TTL 254

TTL 253

TCP-MD5: potentially dangerous and weaker as IPSEC, butfasterIPSEC: potentially dangerous, slower than MD5, but has keyrollover capacity, thus more secure


Securing BGP - Basics - continued

Securing the routing information (implementations do notexist):

Use of shared secrets is not possible, as information onlypartially transitive and can changeDigital signatures needed - X.509 certificatesAuthority needed to verify signatures - Public KeyInfrastructure (PKI)










What are the requirements for secure routing?

Secure the payload data:Ensure the packet has not been tampered with while on thewire

Secure the semantics:Selected fields of the BGP messages need to be signed andauthenticated (prefix, AS path)

Allow piecemeal deployment:Unsigned messages might not necessarily be wrong

Make sure to avoid routing loopsDo not delay convergence


Some approaches to secure BGP

Full security suites:Most complete solution: Secure BGP (sBGP) - usessignatures and PKI - puts high load on routersSecure Origin BGP (soBGP) - Cisco - signatures and PKIPretty Secure BGP (psBGP) - tries to avoid hierarchical PKI,but assumes its existence... inconsistentInter-domain Route Validation (IRV) - uses Internet routingregistries

Partial security solutions and Research:Pretty Good BGP (PG-BGP) and Quarantine BGP (Q-BGP)Prefix Hijacking Alert System (PHAS)Multiple Origin Autonomous System (MOAS) detection andmore...

Lots of security mechanisms (Chained Hash Functions,Secure Path Vector routing (SPV),...)










sBGP

Very complete and elaborated, uses signature on UPDATEmessages and complex system for authenticationIssues:

Puts high load on routersHigh load on session restartPiecemeal deployment impossibleRequirement that the BGP UPDATE message has to traversethe same AS sequence as that contained in the UPDATEmessage


sBGP

Repository Repository

ISP Noc

RegionalRegistry

ISP Noc

Exchange uploads

Get ISP certificate

Get ISP certificate

Upload self

Upload self

Download everything

Download everything

Push Extract

Push Extract

SBGProuter

SBGProuter

SBGProuter

SBGProuter

SBGProuter

BGP Updates










soBGP

Less complicated than sBGP - ensures originator of prefix isauthenticatedChecks AS-Path only for feasibility - AS peer checkuses EntityCerts (AS), AuthCerts (Prefix) and ASPolicyCerts(AS peer check)Issues: Does not tell how to establish trust anchors forvalidation of Certificates


soBGP

EntityCertAS key signature

EntityCertAS1 key signature

EntityCertAS2 key signature

AuthCertAS addrBlockauthorizesignatureAS1 10.0.0.0/8 AS signature

AuthCertAS addrBlockauthorizesignatureAS2 10.1.0.0/16 AS 1 signature

AuthCertAS addrBlockauthorizesignatureAS3 10.1.0.0/24 AS 2 signature

AS connected toASPolicyCert

1 AS2

ASASPolicyCert

connected to

3

AS connected to5 AS2,AS4

AS connected to6 AS2

AS connected toASPolicyCert

4

ASASPolicyCert

connected to2 AS1,AS3,AS5

ASPolicyCertASPolicyCert

AS3,AS5

AS4










IRV

Uses Internet routing registries (IRR) to verify authenticityvia IRV serverDoes not modify the BGP protocolOne IRV server per ASDNSSEC isomorphismSame problem:

RIR192/8

LIR192/8

DNS192

allocates

ISP192.1/16

DNS1.192

suballocates

ISP192.1.1/24

DNS1.1.192

suballocates

End User192.1.1/24

suballocates “in full” ?


IRV

AS2

AS3AS4

AS Path verification

BGP information exchange

AS1

IRV IRV

IRV IRV

Origin AS verification

BGP router – IRV information lookup










Anomaly detection

Only implementation: PG-BGP and Q-BGP:Detection of prefix hijacking and sub-prefix hijackingDetection of anomalous routes by analysing update data ofone weekDelaying of suspect/anomalous updates for 24h (PG-BGP)Anomalous updates are sent but not implemented for 24h(Q-BGP)


Securing the Data Plane

Status of BGP forwarding table is not always consistent withrouting table (8% inconsistency)Providers can steal traffic - pretext of “Traffic Engineering“No real solutionSecure Traceroute:

Checks the data path and compares to AS path in routingtableofcontentsUses PKI and signaturesIncremental deployment impossible

Fatih:Uses traffic summary functions and compares the results ofneighbouring ASesNot feasible on routers with billions of packets per second

Listen and Whisper:Combination of control plane security (Whisper) and dataplane anomaly detection (Listen)“Just too late” type of detectionNot feasible as it follows TCP flowsCaia Seminar http://www.caia.swin.edu.au [email protected], [email protected], [email protected] 18, 2010 52









The current Status

System Type Implemented DeployedGTSM session sec. Yes (Quagga) YessBGP crypto Yes (old) NosoBGP crypto/anomaly No NopsBGP crypto No NoIRV crypto/anomaly No NoSPV crypto No NopgBGP anomaly Yes (Quagga) YesiSPY anomaly No NoPHAS anomaly No NoSec. Traceroute crypto No NoFatih anomaly No NoListen&Whisper crypto/anomaly No No


Conclusions

BGP has proved surprisingly resilient in terms of itslongevity of useful operational lifeEarly predictions favoured IDRP over BGP - (The OSIInter-Domain Routing Protocol)BGP Security: Some network operators use TCP-MD5,some GTSMOverall picture of BGP security is unchangedAmple evidence of use of unregistered addresses andspammingBGP is abused in various waysCurrent efforts to mitigate problems are inadequateDeployment of PKI seems to be a good startBGP routing system is at risk - Internet is at risk!










Questions

THANK YOU FOR YOUR ATTENTIONQuestions?






Documents

Securing BGP - A Literature Surveycaia.swin.edu.au/talks/CAIA-TALK-100318A.pdf · Securing BGP - A Literature Survey Geoff Huston, Mattia Rossi, Grenville Armitage [email protected],