securing networks guy leduc chapter 6: secure routing · 5 secure routing 9 bogus as paths (1)...

1

Secure routing 1

Some references used:

RFC 6094 – Summary of Cryptographic Authentication Algorithm Implementation Requirements for Routing Protocols

RFC 7454 – BGP Operations and SecurityRFC 6480 – An infrastructure to support

secure Internet routingRFC 8205 – BGPsec Protocol Specification

Securing Networks

Guy Leduc

Chapter 6:Secure routing

Secure routing 2

Secure routing

Chapter goals: ❒  learn how intradomain routing can be secured❒  understand the possible attacks on BGP routing❒  understand why Prefix filtering and RPKI are not

sufficient❒  learn how BGP has been extended to secure

interdomain routing (BGPsec)

2

Secure routing 3

Chapter Roadmap

❒  Secure routing❍ Securing intradomain routing❍ BGP vulnerabilities❍ BGP with Prefix filtering❍ RPKI❍ BGPsec

Intra-AS routing❒  OSPF, IS-IS, RIP are

intra-AS routing protocols❒  Router exchange routing

packets to learn topology and compute least-cost paths

❒  Routing traffic remains within AS, and is not really confidential

❒  Encryption of routing packets is usually not considered mandatory

Possible attacks on routing:❒  Message insertion❒  Message deletion❒  Message modification

❒  How does a router know if a received routing packet is authentic?

Secure routing 4

3

Authentication matters❒  Many routing protocols

(OSPFv2, IS-IS, RIP) used to provide 3 “authentication” choices❍  No authentication❍  Shared password:

inserted in clear in authentication field in routing packet

❍  Cryptographic hash: typically a MAC initially based on MD5, and use of symmetric keys

•  SHA-1, SHA-2 now also possible in some protocols

❒  Cryptographic hash:❍  hash is run over a

concatenation of the routing packet and the shared secret key

❍  authentication field should include cryptographic sequence number to detect replays

❍  MAC then appended to routing packet

❍  keys should be renewed regularly

Secure routing 5

Routing protocols over IPsec❒  Most “recent” versions of routing protocols have been

revised to also support IPv6, e.g.❍  OSPFv3 (aka OSPF for IPv6)❍  RIPng

❒  and IPsec is a mandatory component of IPv6

❒  Therefore built-in authentication has been removed from these routing protocols, and instead they rely on IPsec AH or ESP to ensure integrity and authentication❍  When using ESP, the null encryption algorithm is typically used,

because confidentiality is not really required and creates overhead

Secure routing 6

4

Secure routing 7

Chapter Roadmap


Secure routing 8

Data plane attacks on BGP❒  BGP sessions run over TCP

❍  Thus making BGP vulnerable to attacks on TCP❒  No confidentiality: e.g. attacker could

❍  learn business relationships between ASes, or ❍  analyze route stability

❒  No integrity: e.g. attacker could ❍  modify advertized AS-PATHs, leading BGP neighbor to learn

bogus routes, e.g. add/remove an AS in/from an AS-PATH❒  Little DoS resistance: e.g. attacker could

❍  overflow links, or ❍  flood network with TCP SYN segments (SYN flooding), or ❍  reset TCP connection (send FIN/RST segments) leading to

transient routing changes (loss of connectivity between the ASes, bringing down BGP peering)

5

Secure routing 9

Bogus AS Paths (1)❒  Remove an AS from an AS-PATH

❍  e.g. turn AS1-AS2-AS3 into AS1-AS3❍  makes an AS-PATH look shorter than it is❍  attracts sources that normally (try to) avoid AS2❍  not obvious to tell that path is bogus: maybe AS1 does

connect to AS3 directly!❒  Add an AS to an AS-PATH

❍  e.g. turn AS1-AS3 into AS1-AS2-AS3❍  triggers loop detection in AS2❍  makes AS2 look like it has richer connectivity❍  AS2 could tell this route is bogus (if it could see the route)

❒  Add AS at the end of a bogus path❍  makes path look plausible if last AS hop really holds the

announced prefix!

Secure routing 10

Bogus AS Paths (2)

❒  AS exports a route that it shouldn’t (because not a “valley-free” route)❍  e.g. customer forwards path from one provider to

another❍  consequence: customer becomes transit AS

between its 2 providers!❒  AS announces inconsistent paths on several

links to same neighbor AS❍  to force the neighbor AS to send all its traffic

through one particular link (“cold” potato)

6

Secure routing 11

Data plane protectionsThese attacks are not easy to carry out though, because:❒  eBGP sessions over a single link (not IXPs) are not easy to

tap❒  TCP SYN cookies could be used❒  TCP authentication option could be used❒  Access to BGP port (179) could be denied from sources not

supposed to be BGP speakers (requires ACLs)❒  Routing packets could receive higher priority scheduling in

routers❒  eBGP could use TTL security (GTSM) on directly connected

eBGP peerings: ❍  eBGP sends packet with TTL = 255, and checks that received

packets have TTL = 255 (both eBGP speakers are on same subnet!)❒  BGP sessions could run over IPsec

Secure routing 12

Control plane attacks❒  Main attack: Prefix hijacking❒  Example: Pakistan Telecom

❍  On 24 Feb. 2008, Pakistan Telecom (AS 17557) started an unauthorized announcement of the prefix 208.65.153.0/24 (i.e., a subset of YouTube prefix 208.65.153.0/22). One of Pakistan Telecom’s upstream provider, PCCW Global (AS 3491), forwarded this announcement to the rest of the Internet, which resulted in the hijacking of YouTube traffic on a global scale

❍  Configuration mistake of Pakistan Telecom, which had received a government order to block access to YouTube ☺

❍  Another error of Pakistan Telecom’s upstream provider, PCCW Global, which has not filtered this route announcement

❍  for details, watch https://www.youtube.com/watch?v=IzLPKuAOe50

7

Secure routing 7-13

https://www.youtube.com/watch?v=IzLPKuAOe50

Secure routing 14

BGP Prefix hijacking

❒  Depending of BGP policies, AS3 will prefer/select one of the two received routes

❒  Assume AS3 prefers AS-PATH AS2,AS1 to reach X❍  AS3 then advertises this path to AS4❍  But AS4 will prefer AS-PATH AS666 (because AS666 is its customer)

❒  In this scenario, hijacking has only “local” impact (in AS4)❒  Note: this is how IP anycast is implemented!

AS1

AS2

AS3

€

AS4AS666,X

AS666 pretends to be the owner of prefix X

AS4,AS666,X

AS1 is the real owner of prefix X

AS1,X

AS2,AS1,X

€€

€AS666

AS2,AS1,X

I promise I’ll forward your traffic towards Xthrough path AS2,AS1

8

Secure routing 15

BGP Sub-Prefix hijacking

❒  Y is “sub-prefix of” X, means same IP but longer mask❍  i.e., Y is a more specific prefix than X

❒  Longest prefix match prevails in routers, so all ASes will store a bogus AS-PATH to Y in their RIB, in addition to the correct AS-PATH to X

❒  In this scenario, hijacking has “global” impact❒  To be more effective AS666 could advertize all sub-prefixes

of X to attract all traffic destined for X

AS1

AS2

AS3

€

AS4AS666,Y

AS666 pretends to be the owner of sub-prefix Y

of prefix X

AS4,AS666,Y


AS1,X

AS3,AS4,AS666,Y

€€

€AS666

Secure routing 16

How to hijack a prefix?❒  The hijacking AS must

❍  establish an eBGP session with at least one of its neighbor ASes❍  originate the hijacked IP prefix

❒  It could be the result of❍  a configuration mistake by the AS operator❍  an attack by a disgruntled AS operator❍  an outsider taking control of some AS router❍  an attacker masquerading a BGP router

❒  Detection technique?❍  Deploy multiple vantage points in the Internet❍  Analyze BGP updates at, or launch traceroute probes from, the

vantage points

9

Secure routing 17

Why hijacking a prefix?❒  Traffic interception:

❍  hijacking AS sees traffic sent to hijacked prefix❒  DoS attack:

❍  hijacking AS discards traffic sent to hijacked prefix❒  Leveraging IP spoofing attacks:

❍  attacker picks IP address from an unused (unallocated) address block for spoofing its IP address

❍  attacker hijacks this prefix•  but doesn’t steal traffic to anyone else, so unnoticeable by other ASes

❍  then it launches its attack (e.g. sends spams) with a spoofed source IP address from this block, thus receiving useful return traffic to the spoofed address!

❍  finally it withdraws its BGP announcements for the hijacked prefix

Secure routing 18

Chapter Roadmap


10

Secure routing 19

BGP Prefix filtering❒  Prefix filtering: controlling the prefixes that are

received and advertised on the BGP peerings❒  Prefixes exchanged between BGP peers are

controlled with inbound and outbound filters:❍  Inbound filter: discard BGP prefixes received from

provider/peer/customer ASes❍ Outbound filter: don’t announce some known prefixes to

provider/peer/customer ASes

Secure routing 20

Basic prefix filtering rules

❒  Inbound and outbound filtering of:❍  non globally routable prefixes❍  too specific prefixes (e.g. longer than /24 in IPV4, /48 in

IPv6)❒  Inbound filtering of:

❍ AS-PATH containing the local AS number, to avoid routing loops

❍  prefixes belonging to the local AS, to prevent local traffic from leaking over an external peering

❍  default route (0.0.0.0/0) from peer or customer ASes

11

Secure routing 21

Filtering rules based on registries❒  Existing registries:

❍  Internet Assigned Numbers Authority (IANA) ❍  5 Regional Internet Registries (RIR), one per continent❍  Internet Routing Registry (IRR): where network operators

publish their routing policies/announcements❒ Registry-based filtering rules:

❍  filter unallocated (essentially IPv6) prefixes❍  check that first AS hop in AS-Path actually holds the

announced prefix❍ whois tool

❒ Caution: These databases will vary over time and are not always accurate❍ Need to refresh the filters regularly

Secure routing 22

BGP Policies (Valley-Free routing)

Updates received ( ) only forwarded along links, to avoid costly transit traffic

Customer

Provider

Local ASPeer

Update from provider:

Customer

Provider

Peer

XXX

Customer

Provider

Local ASPeer

Update from peer:

Customer

Provider

Peer

XX

X

Customer

Provider

Local ASPeer

Update from customer:

Customer

Provider

Peer

12

Secure routing 23

Prefix filtering based on policies (1)❒  Prefix announcement received from a customer AS:

❍  Valley-free routing: customer AS will normally never announce to provider AS a prefix received from another provider or from a peer

❒  Two cases:1. If local AS has assigned address space to its customer AS:

BGP border router checks that prefix originated by customer AS is from that space

2. If local AS has not assigned address space to its customer AS: BGP border router checks in the Regional Internet Registries (RIR) to see if prefix originated by customer has been assigned to that customer AS

❒  Stops all attacks from stub ASes❒  Note: customer AS may also propagate updates received

from its own customers

Secure routing 24

Prefix filtering based on policies (2)❒  Prefix announcement received from a peer AS

❍  Valley-free routing: to a peer an AS will normally only announce a prefix received from one of its customers (neither prefixes received from another peer, nor from a provider)

❍  In peering agreements, peers exchange/update their allocated address ranges

❍  AS can also check the Internet Routing Registries regarding address blocks allocated to its peers

❒  When receiving a prefix announcement from a peer, BGP border router checks that announcement matches this knowledge

13

Secure routing 25

Prefix filtering based on policies (3)❒  Prefix announcement received from a provider AS

❍ Provider AS is paid to give access to the whole Internet❍ So normally provider AS announces all known routes to

its customer ASes❒  Therefore setting a default route (0.0.0.0/0) to the

provider AS may be enough❍  If so, provider announcements not even needed!❍ Sometimes customer AS desires full routing table from

provider

Secure routing 26

BGP Best Common Practices (BCPs)❒  Filtering routes by prefix or AS path

❍  already bars 80% of attacks (if used everywhere)❒  + Securing the BGP sessions❒  + Packet filters to block unexpected BGP traffic… are all fine, but not good enough

❍  depends on vigilant applications of BCPs❍  and not making configurations mistakes

❒  BCPs do not address fundamental problems:❍  can’t fully tell (i.e. verify) who owns IP address block❍  can’t tell (i.e. verify) if AS path is bogus or invalid❍  can’t be sure the packets follow the chosen route

14

Secure routing 27

Chapter Roadmap


Secure routing 28

Resource Public Key Infrastructure (RPKI) - 2012❒  It’s a PKI, used to certify resource allocations❒ Resources: IP prefixes, AS numbers❒ Resource certificate:

❍  allows an entity to verifiably (cryptographically) assert that it is the legitimate holder of a (set of) IP prefix(es) or AS(es)

❒ RPKI is a “white list”❍  does not preclude to assign the same prefix to several

ASes (e.g. for anycast, for AS confederations)❒ No changes to BGP messages

❍ Easier to deploy❒ Resource certificates are handled out-of-band

15

Secure routing 29

RPKI hierarchy

IANA

RIR2 (e.g. APNIC)

NIR

ISP3 ISP4 ISP5

IANA’s self-signed root certificate

RIR’s certificate signed by IANA

NIR’s certificate signed by RIR

RIR1 (e.g. RIPE)

ISP1 ISP2ISP’s certificate

signed by NIR or RIR

ISP7 ISP8 ISP’s certificate signed by provider ISP

ISP6

= sub-allocation

Secure routing 30

Resource certificates❒  Allocation of both IP addresses and AS numbers

can be expressed by the same PKI❍  except that AS numbers are not sub-allocated by ISPs

❒ Resource certificate❍ Binds the public key of an entity to the IP prefix(es), or

AS number(s), this entity legitimately holds❍ Unlike in most PKIs, it is the issuer that adds the

subject name in the certificate❍ An important property of this PKI is that certificates do

not attest to the identity of the subject. Therefore, the subject names used in certificates are not intended to be “descriptive”. That is, the resource PKI is intended to provide authorization, but not authentication

16

Secure routing 31

Route Origination Authorization (ROA)❒  A ROA is an attestation

that the holder of a set of prefixes has authorized an AS to originate routes for those prefixes

❒  The validity of the ROA depends on the signer of the ROA being the holder of the prefix(es) in the ROA❍  This is asserted by an end-

entity (EE) certificate the ISP issues to itself (in RPKI)

❍  Same prefixes in ROA and EE certificate

❍  K-EE used only once

(i.e. to sign this ROA only)❍  Max sub-prefix length also

stated in ROA

RIR CA

ISP CA

ISP’s EE certificate:K-

ISP(K+EE, {P})

ROA:K-

EE (ASx is authorized to originate routes for {P})

ISP’s certificate:K-

RIR(K+ISP, {P})

RIR’s certificate:K-

IANA(K+RIR, {P})

=

subsetof

subsetof

{P}: set of prefixes

Secure routing 32

Back to BGP Prefix hijacking

❒  With RPKI, AS4 can verify that AS666 is not authorized to originate a route to prefix X❍  No existing ROA stating it❍  So, AS4 filters the received announcement

AS1

AS2

AS3

€

AS4AS666,X

AS666 pretends to be the owner of prefix X

AS3,AS2,AS1,X


AS1,X

AS2,AS1,X

€€

€AS666

AS2,AS1,X

I promise I’ll forward your traffic towards Xthrough path AS2,AS1

X

17

Secure routing 33

Prefix hijacking still possible with RPKI

❒  Called 1-hop hijack attack❒  Here AS666 appends AS1 at the end of the AS-PATH

❍  AS1 is authorized to originate a route to prefix X❍  The RPKI check validates the announcement

❒  AS4 prefers path AS666-AS1 to path AS3-AS2-AS1❒  Here local impact only (AS3 may still prefer AS2-AS1)❒  But if AS666 announces to AS4 a subprefix Y of X…

AS1

AS2

AS3

€

AS4AS666,AS1,X

AS666 announcesbogus path to prefix X

AS3,AS2,AS1,X


AS1,X

AS2,AS1,X

€€

€AS666

Non existing peering

Secure routing 34

Chapter Roadmap


18

Secure routing 35

BGPsec❒  Address attestations provided by RPKI are very

useful

❒  But route attestations are also needed to verify that a received AS-PATH is valid:❍  no AS was added or removed❍ AS path indicates the order ASes were traversed

Secure routing 36

BGPsec announcements: first try

❒  AS1 signs, with its private key K-1, the announcement (AS1,X)

❍  RPKI should contain an EE certificate stating that K+1 is the public key

of AS1: so-called Router certificate❍  RPKI check at AS2 is successful

❒  AS2 signs, with its private key K-2, the announcement

(AS2,AS1,X)❒  Any issue?

AS1

AS2

AS3


K-1 (AS1,X)

K-2 (AS2,AS1,X)

19

Secure routing 37

Problem is …

❒  Does not stop the 1-hop hijack attack!❒  AS3 cannot verify that AS1 had indeed announced AS

path (AS1,X)

AS1

AS3


K-666 (AS666,AS1,X) AS666

Non existing peering

Secure routing 38

BGPsec announcements: second try

❒  Now AS2’s announcement contains:❍  its own signed (by K-

2) announcement (AS2,AS1,X), as before❍  the proof that AS1 had indeed announced path (AS1,X)

❒  Issue?

AS1

AS2

AS3


K-1 (AS1,X)

K-2 (AS2,AS1,X)

K-1 (AS1,X)

20

Secure routing 39

Problem is …

❒  Still does not stop the 1-hop hijack attack!❒  AS666 could have a copy of the valid announcement that

AS1 sent earlier to AS2❒  AS3 wrongly believes that AS1 had indeed announced AS

path (AS1,X) directly to AS666

AS1

AS3


K-666 (AS666,AS1,X) AS666

Non existing peeringK

-1 (AS1,X)

AS2K-1 (AS1,X) K

-1 (AS1,X)

K-2 (AS2,AS1,X)

Secure routing 40

BGPsec announcements: correct version

❒  AS1 signs, with its private key K-1, the announcement

(AS1,X)❍  Note that AS2 (the receiving AS) is also indicated in the signed part❍  AS2 verifies (RPKI check) that AS1 is authorized to originate a

route to X❒  AS2’s announcement contains:

❍  its own signed (by K-2) announcement (AS2,AS1,X) sent to AS3

❍  the proof that AS2 had indeed received announcement (AS1,X) from AS1

AS1

AS2

AS3


K-1 (AS2: (AS1,X))

K-2 (AS3: (AS2,AS1,X))

K-1 (AS2: (AS1,X)) : BGPsec_Path

attribute

21

Secure routing 41

BGPsec announcements (2)

❒  AS3 can verify that❍  there is a chain of valid announcements from AS1 to AS2 to AS3 (and

therefore a valid route) to prefix X❍  AS1 was authorized to originate a route to prefix X, by checking the

RPKI repository❒  Note: A BGPsec UPDATE message must advertise a route

to only a single prefix❍  otherwise a BGPsec speaker receiving an UPDATE message with

multiple prefixes would be unable to construct a valid BGPsec UPDATE message (i.e., valid path signatures) containing a subset of the prefixes in the received update

AS1

AS2

AS3


K-1 (AS2: (AS1,X))

K-2 (AS3: (AS2,AS1,X))

K-1 (AS2: (AS1,X))

Secure routing 42

Secure BGP deployment challenges❒  Need complete, accurate RPKI deployment❒  Cryptographic operations now performed by BGPsec

❍  to verify digital signatures in BGP messages❍  to sign BGP messages

•  need private key in router! •  compare to DNSsec: no private keys stored in DNS servers

❒  Need to perform operations quickly❍  To avoid delaying response to routing changes❍  May be slow when router boots: lot’s of crypto operations!

❒  Difficulty of incremental deployment❍  Hard to have a “flag day” to deploy BGPsec

22

Secure routing 43

Back to data plane attacks❒  Even if the control plane is secure, are we sure

the IP packets are forwarded along the sequence of ASes listed in the selected AS-Path?

❒ Malicious ISPs (or adversaries controlling a router within ISP) could still drop packets or send packets in a different destination (controlled by attacker)❍ Could be detected by traceroutes❍ Could be detected by end-to-end security checks

(transport/application layer security)

Secure routing 44

Summary: Secure routing❒  BGP is not secure, while it is the glue that holds

the Internet together❒  Attacks are not easy to detect and have global

consequences❒  BGP prefix filtering stops 80% of the attacks,

but is not enough❒  Adding RPKI stops 90% of the attacks and

requires no changes in BGP❒ Need BGPsec and RPKI and prefix filtering to

achieve full security❒ Remaining issue is deployment

securing networks guy leduc chapter 6: secure routing · 5 secure routing 9 bogus as paths (1)...

Documents