BGP could be vulnerable L

MARIO ROSI
Senior System Engineer
MPLS/ISP and CISCO ACI/VXLAN infrastructure solution expert

© copyright 2022, Mario Rosi | All rights reserved www.linkedin.com/in/mariorosi71

1
 Agenda

ü BGP best practice for eBGP

ü TTL security for eBGP
ü BGP RPKI

© copyright 2022, Mario Rosi | All rights reserved 2

 BGP best practice for eBGP
ü BGP can be attacked and weakness exploited
ü DoS (Denial of Service)
ü Man in the Middle (sniffing)
ü False BGP information propagation (fakes news J) à BGP RPKI
ü BGP unexpected prefixes propagation à prefix-lists required In and Out on ISPs
ü “Bogons/Martians networks” (bogus or invalid network not been officially assigned to an entity by an internet registration
institute, such as the Internet Assigned Number Authority (IANA), or belonging to a pool of reserved IANA addresses, e.g.
127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16… https://bgp.he.net/report/bogons)
ü Many prefixes around on Internet > /24 mask à aggregation at most /24 required on ISPs (https://www.cidr-
report.org/as2.0/#General_Status)
ü RFC 7980 (https://www.rfc-editor.org/rfc/rfc7908.txt): “Problem Definition and Classification of BGP Route Leaks” (June 2016)
(https://book.reissromoli.com/product/bgp-dalla-teoria-alla-pratica)

© copyright 2022, Mario Rosi | All rights reserved 3

 What should ISPs do?
ü Don’t send junk networks Control Plane
ü Filter your own advertisements (using prefix-lists) in Egress to ISP peers
ü Only RIRs assigned IP addresses should be visible and used on Internet
(https://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xhtml)
ü Don’t accept junk networks from customers and upstream peers
ü Filter your customers’ advertisements
ü ISPs should only accept assigned/allocated prefixes from their downstream customers (e.g. if
the ISP assigned 201.50.200.0/29 to customer, accept only that from it)
ü Filter your Upstream ISP peers
ü Configure the maximum number of prefixes would be received in Ingress
ü Don’t accept prefixes longer than /24 in Ingress (using prefix-list; e.g. ip prefix-list x permit
0.0.0.0/0 le 24)
ü Don’t accept your own prefixes in Ingress
ü Don’t accept ingress traffic with spoofed IP source addresses (using access-lists)
Data Plane
© copyright 2022, Mario Rosi | All rights reserved 4
 What should ISPs do… an example!
ü Use prefix-list to avoid propagation of (https://team-cymru.com/community-
services/bogon-reference/bogon-bit-notation):
ü RFC1918, Martian prefixes
ü RFC3330 Bogon prefixes (https://www.rfc-editor.org/rfc/rfc3330)

ü DoS and DDoS attacks use spoofed addresses from un-allocated IPv4 space (routing
doesn’t check source IP address of malicious packet but only destination IP address)

© copyright 2022, Mario Rosi | All rights reserved 5

 What should ISPs do… another example!
ü Use AS-path filters using regular expressions
ü Applied some way as prefix-list filters

ü Regular expressions

© copyright 2022, Mario Rosi | All rights reserved 6

What should ISPs do… last example, I promise! J
ü BGP MD5 authentication
ü The neighborship is established only if the password matches
ü The password is not transmitted (messages are transmitted in clear)
ü Each router calculates the “hash MD5” – 128bit (and transmitted as TCP
optional header field with kind=19) based on:
ü Local password, IP source add, IP destination add, Protocol Type, packet
length…

© copyright 2022, Mario Rosi | All rights reserved 7

 eBGP peering weakness
ü By default, any received eBGP packets with TTL value > 0, is accepted from
eBGP peer
ü By default, BGP messages for directly connected eBGP peers, are sent with
TTL = 1
TTL=1 BGP notification: CEASE!
Guess I need to kill my eBGP RID 12.12.12.12 Dest. IP 1.2.1.1?
peering with 12.12.12.12 Dest. IP 1.2.1.1 Source IP 1.2.1.2 I can forward it

R1 TTL=1 R2 L0: 12.12.12.12

L0: 11.11.11.11
1.2.1.1 1.2.1.2
TTL=2 TTL=4 BGP notification: CEASE!

AS#1 eBGP peeringX AS#2

TTL=3
RID 12.12.12.12
Dest. IP 1.2.1.1 Source IP 1.2.1.2

ü TTL = 1 leaves it open to attack!

© copyright 2022, Mario Rosi | All rights reserved 8
 eBGP multi-hop peering
ü eBGP multi-hop peering, requires the following commands:
ü (router_x)# neighbor a.b.c.d update-source loopback 0
ü (router_x)# neighbor a.b.c.d ebgp–multihop <hops> (hops: 1-255)
R1 TTL=<hops> R2
L0: 11.11.11.11 L0: 12.12.12.12
1.2.1.1 1.2.1.2

Without “ebgp-multihop” command I

AS#1 eBGP peering AS#2 couldn’t even start the TCP process
because my peer is not directly
connected!

ü It still exposes the eBGP peering to external attack à instead using

ebgp-multihop use ttl-security hops (cannot be used together)
© copyright 2022, Mario Rosi | All rights reserved 9
 TTL security for eBGP
ü TTL security is a mechanism to enforce TTL values to prevent DoS (only for eBGP)
ü (router_x)# neighbor a.b.c.d ttl-security hops <1-254>
ü By using “ttl-security” command, BGP packets are sent always with TTL = 255
ü How is “HOPs” used?
ü 255 - <hops> = X
ü All incoming eBGP packets must have TTL >= X
255 – 1 = 254 à BGP packets received with TTL >= 254 are processed
TTL=252 BGP notification: CEASE! And what about if the Hacker
TTL = 252 so silently discarded
RID 12.12.12.12
Dest. IP 1.2.1.1 Source IP 1.2.1.2
is directly connected?

R1 TTL=255 R2 TTL=255 BGP notification: CEASE!

L0: 11.11.11.11 L0: 12.12.12.12 RID 12.12.12.12
Dest. IP 1.2.1.1 Source IP 1.2.1.2
1.2.1.1 1.2.1.2 TTL=253 TTL=254

AS#1 eBGP peering AS#2

© copyright 2022, Mario Rosi | All rights reserved 10

 TTL security for eBGP
ü eBGP peering via Loopback with“ttl-security hops 2”
ü even though routers are directly connected, loopbacks require static/dynamic
routing to be reachable – “not on the same /30 subnet” - (eventually if you want
to use “ttl-security hops 1”, pretending they are directly connected, add the
command (router_x)# neighbor a.b.c.d disable-connected-check too)

255 – 2 = 253 à BGP packets received with TTL >= 253 are processed
TTL=252 BGP notification: CEASE! And what about if the Hacker
TTL = 252 so silently discarded RID 22.22.22.22 is directly connected?
Dest. IP 11.11.11.11 Source IP 22.22.22.22

R1 TTL=255 R2
L0: 11.11.11.11 L0: 22.22.22.22 TTL=255 BGP notification: CEASE!
RID 22.22.22.22
1.2.1.1 1.2.1.2 TTL=253 TTL=254 Dest. IP 11.11.11.11 Source IP 22.22.22.22

AS#1 eBGP peering AS#2

© copyright 2022, Mario Rosi | All rights reserved 11

 …TTL security for eBGP, one more!
ü …and what about if in the middle between eBGP router peers are other
ones? A real multi-hop eBGP session?
255 – 2 = 253 à BGP packets received with TTL >= 253 are processed
And what about if the Hacker
TTL = 250 so silently discarded TTL=251 TTL=252
is directly connected?
TTL=250

R1 TTL=253 TTL=254 TTL=255 R2 L0: 22.22.22.22

L0: 11.11.11.11
1.2.1.1 1.2.1.2 TTL=253 TTL=254
TTL=255 BGP notification: CEASE!
RID 22.22.22.22
Dest. IP 11.11.11.11 Source IP 22.22.22.22

AS#1 eBGP peering AS#2

ü…however BGP is based on TCP session, not so easy to ack the TCP
(TCP sequence number should be guessed), BUT, you could overload the
CPU of router with many TCP SYNs à DDoS over router R1!!
© copyright 2022, Mario Rosi | All rights reserved 12
 BGP: prefix hijacking
ü Let’s see a couple of cases:

© copyright 2022, Mario Rosi | All rights reserved 13

 BGP prefix hijacking real case
ü On 2008 (https://bit.ly/36Od4Cw) the Pakistan Telecom (AS 17557) started an unauthorized
announcement of the prefix 208.65.153.0/24, belonging to AS 15169 (GOOGLE), causing the
hijacking of YouTube traffic on a global scale (have a look at https://bgpstream.com)

ü News on October 2020: «Major ANZ (Australia & New Zeland) operators at risk of traffic hijack as
they lag on RPKI» (https://www.manrs.org/2020/10/major-anz-operators-at-risk-of-traffic-hijack-as-
they-lag-on-rpki)
ü Just an example “live”: https://bgpstream.crosswork.cisco.com/event/295916
© copyright 2022, Mario Rosi | All rights reserved 14
 What’s BGP RPKI
ü Resource Public Key Infrastructure (RPKI), has been developed by Regional Internet Registries
(RIRs) in 2011 controlled by Internet Assigned Numbers Authority (IANA)
ü It’s a standards-based approach for providing cryptographically secured registries of internet resources
and routing authorizations, offered as service by RIRs à defines an out-of-band mechanism such that
the information that are exchanged by BGP updates can be validated or not
ü The RPKI certification chain follows the same allocation hierarchy valid per each of the 5 RIRs: the
Internet number resources (INRs), such as IPv4/IPv6 prefixes and AS# are bound to a Public Key
Infrastructure (PKI) via certificates that define the ISP ownership of INRs

Each RIR has an independent

trust anchor (TA) for RPKI
certification services per region

Each ISP or Enterprise is linked to a Digital

Certificate which identifies uniquely its INRs
and recognize their ownership.

© copyright 2022, Mario Rosi | All rights reserved 15

 What’s BGP RPKI
ü The resource owner (ISP) can generate objects called Route Origin Authorizations
(ROAs), IPv4/IPv6 prefixes, AS number and digital certificates which authorize itself
to announce IPv4/Pv6 prefixes belonging to its AS
ü The creation of a ROA is tied to the IPv4/IPv6 prefixes that are listed on the
certificate and not to the AS numbers. The holder of the certificate can authorize any
AS to originate their prefix, not just their own autonomous systems
ü The digital certificates that sign the ROAs, are managed by the RIRs and stored in
the RPKI repositories
ü The RPKI repository is a database containing ROAs information

© copyright 2022, Mario Rosi | All rights reserved 16

 What’s BGP RPKI
ü RPKI data are accessed through Relying Parties (RPs), also named RPKI Validating Server
using either the rsync protocol or the RPKI Repository Delta Protocol (RRDP)
ü The BGP ASBR router accesses the required ROA data from one or more RPKI cache
servers stored on RPs through RPKI-to-router protocol
ü There are various open-source Relying Party sw tools available to perform RPKI validation

As RPKI validator have a look at one of

these two:
https://www.nlnetlabs.nl/projects/rpki/routinator

or

https://fortproject.net/en/validator#:~:text=FORT%2
0Validator%20is%20an%20open,in%20router%20con
figuration%20and%20resolution

For RP sw installation: https://blog.apnic.net/2019/10/28/how-to-installing-an-rpki-validator

© copyright 2022, Mario Rosi | All rights reserved 17
 Route Origin Validation (ROV) process
ü Routers use RP software to download and validate RPKI objects locally
1) RP software cryptographically verifies RPKI entries contained on RPKI repository and extracts
the following information called Validated ROA Payloads (VRPs):
- IPv4/IPv6 prefix
- Prefix length
- Max_Length
- AS number
2) Validating ASBR routers fetch the VRPs to validate received BGP announcements (basically,
download the ROA entries present in the RPKI cache of RPs)
“When a BGP announcement is received from an eBGP peering, it attempts to
validate the announcement using VRPs, it determines if the announced IP prefix is
covered by any VRP (there is a match for all bits specified by the VRP IP prefix
length between IP prefix address received and the VRP IP prefix address)”
ü ROV validation process interferes with the BGP best path selection algorithm and the forwarding of
information concerning the Best path for a BGP prefix received by an ASBR router (valid ones first,
not found ones second, invalid ones not installed by default in routing table)
© copyright 2022, Mario Rosi | All rights reserved 18
 ROV algorithm
ü Three different outcomes can be achieved (let’s suppose to have the ROA entry set as
[Pfx_ROA/Mask_ROA; Max_Length_ROA; AS_ROA] and let’s name the BGP announcement
received as [Pfx_BGP/Mask_BGP; AS_BGP])

• Valid: the prefix is covered by at least one ROA entry, i.e. the prefix in the route announcement is equal, or more specific than the prefix in
the VRP

o AS_BGP = AS_ROA
o Pfx_BGP/Mask_BGP is equal or a more specific prefix of Pfx_ROA/Mask_ROA and Mask_BGP ≤ Max_Length_ROA

• Invalid: the prefix is announced from an unauthorized AS or the announcement is more specific than the allowed by the maximum length
set in a ROA that matches the prefix and AS

o Pfx_BGP/Mask_BGP is equal or a more specific prefix of Pfx_ROA/Mask_ROA but AS_BGP ≠ AS_ROA or AS_BGP = AS_ROA
and Mask_BGP > Max_Length_ROA

• Not Found: the prefix in this announcement is not covered

o Doesn’t exist any prefix Pfx_ROA/Mask_ROA for which Pfx_BGP/Mask_BGP matches him or its subnets (independently by AS
number)
© copyright 2022, Mario Rosi | All rights reserved 19
 Step by step… smothly!!!
ü The introduction of RPKI can be planned smoothly and split in more steps:
1. Ignoring: during the acceptance test activity, the outcome of ROV could be ignored disabling
the validation process. The router will still connect to the RPKI server and download the
validation information, but will not use the information
2. Allow Invalid: Invalid prefixes participate in the BGP best path algorithm, they are not dropped
but only marked as (I); in the comparing of Valid prefix vs Invalid prefix, by default the Valid one
ALWAYS wins!
3. Drop Invalid: Invalid prefixes are dropped and not propagated to iBGP peers à RPKI is 100%
working now!
The Not Found prefixes are obviously always forwarded to iBGP peers.
ü Look here https://isbgpsafeyet.com to check if your upstream eBGP peers are implementing BGP
RPKI so if you are safe or... ... then BGP RPKI is necessary! J

© copyright 2022, Mario Rosi | All rights reserved 20

© copyright 2022, Mario Rosi | All rights reserved 21