Advanced Network Security BGP Joeri de Ruiter
Agenda ● BGP recap ● BGP security RPKI / ROA ● BGPsec ● ● Startng (almost) from scratch 2
Autonomous systems (AS) Internet is divided into Autonomous Systems (AS) ● Controlled by a single entty ● Difgerent types of AS ● Stub ● – Can be mult-homed Transit ● ASes can connect using peering or transit relatonships ● Internet exchanges (IX) ● Basically a big switch ● 3
Border Gateway Protocol (BGP) BGP-4, RFC 4271 ● Used to route trafc between ASes ● Glues together the Internet ● Exchange routng informaton between autonomous systems ● Once connected to a peer, the full BGP routng tables are exchanged ● Afuerwards updates are sent when table changes ● 4
BGP BGP route consists of ● Prefx ● Origin ● – How the prefx was introduced into BGP AS Path ● – Used for loop detecton and selecton of route Next hop ● – Where to send packets for the advertsed prefx next Optonal parameters ● 5
BGP example AS1 AS2 AS3 A C B D Prefx x m n k l ● Router D announces prefx x to router C using eBGP: AS-PATH: AS3, NEXT-HOP: n ● ● Router B learns about new path through iBGP ● Router B announces prefx x to router A using eBGP: AS-PATH: AS2 AS3, NEXT-HOP: l ● 6
BGP example C D AS1 AS2 AS3 A m n B E Prefx x F k l o p ● Two peering links between AS2 and AS3 ● Router D announces prefx x to router C using NEXT-HOP n ● Router F announces prefx x to router E using NEXT-HOP p ● Router B learns about new paths through iBGP Using intra-AS routng determines cost of the path to both n and p ● Store cheapest path in local routng table ● 7
BGP 8
BGP 9
BGP security BGP plaintext and unauthentcated ● Hijacking or intercepton of prefxes ● Announce longer prefx or shorter path ● Incidents occur on a daily basis ● 10
11
Atacking Tor BGP hijacking or intercepton can be used to de-anonymise users using trafc ● analysis RAPTOR: Routng atacks on privacy in Tor by Sun et al. ● Atacker only needs to observe any directon of trafc at both ends ● 12 Source: RAPTOR: Routng Atacks on Privacy in Tor, Sun et al., 2015
Atacking Tor Feasability shown in experiment ● Source: RAPTOR: Routng Atacks on Privacy in Tor, Sun et al., 2015 13
BGP security What security propertes do we want? ● Origin authentcaton ● You can only announce prefxes that are assigned to you ● Path authentcaton ● The complete path to the origin is verifable ● 14
Resource PKI (RPKI) Deployment started in 2011 ● Described in RFC 6480 ● Makes use of existng standards ● E.g. X.509 certfcates, extended with atributes to include IP prefxes ● Certfcates used to assign prefxes ● Root CAs called Trust Anchor ● Leaf certfcates called End-Entty Certfcates ● Route Origin Authorizaton (ROA) ● Bind prefx to AS ● Signed owner of the prefx ● One-to-one mapping between End-Entty Certfcate and ROA ● 15
RPKI hierarchy IANA AFRINIC APNIC RIPE NCC LACNIC ARIN LIR LIR LIR ISP ISP ISP 16
Origin authentcaton Described in RFC 6493 ● Cryptographic verifcaton performed by RPKI Cache (local or at service provider) ● Download records from repository (e.g. RIRs such as RIPE) ● Verify chain, including assigned resources ● Assigned resources should be a subset of the parent’s resources ● Verifcaton against BGP announcement performed by routers ● Router retrieves stripped ROAs from RPKI Cache ● Match BGP announcements against published ROAs ● – Valid / Invalid / NotFound Verifcaton results used in policy ● Atacks stll possible ● Depends on how routes are chosen ● 17
Path authentcaton BGPsec ● RFCs published last September ● RFC 8205 ● Uses RPKI ● AS-Path authentcated using signature in BGPsec-Path ● Every AS adds signature over previous signature and newly added path ● informaton Including next AS ● 18
Path authentcaton - example Prefx: 131.155.0.0/16 AS2 AS-Path: AS1 BGPsec: (key1, signature1) key2 BGPsec: (key2, signature2) signature1 AS1 Prefx: 131.155.0.0/16 AS2, AS3 AS-Path: AS1 key1 BGPsec: (key1, signature1) 131.155.0.0/16 AS1, AS2 AS3 19
Startng from scratch Main problem is legacy ● Adopton of new standards is very slow ● Can we do beter if we start (almost) from scratch? ● Scalability, Control, and Isolaton On Next-generaton Networks (SCION) ● Started in 2009 at CMU ● 20
SCION - Architecture Autonomous systems grouped into Isolaton domains (ISDs) ● ISD core ● Trust Root Confguraton (TRC) ● – Version number – List of trusted root public keys Within AS ● Path server ● Beaconing server ● Certfcate server ● 21
SCION - Architecture 22 Source: The SCION Internet Architecture: An Internet Architecture for the 21st Century, Barrera et al., 2017
SCION – Intra-ISD path discovery Path Constructon Beacons (PCBs) sent using mult-path fooding ● Initalised by core nodes ● Extended and forwarded by receiving ASes ● Add incoming and outgoing interface and optonal peerings ● Eventually all nodes know how ISD core can be reached ● AS registers preferred down-segments (path from core to AS) with path ● server in the core 23
SCION – Path discovery 24 Source: The SCION Internet Architecture: An Internet Architecture for the 21st Century, Barrera et al., 2017
SCION – Path discovery 25 Source: The SCION Internet Architecture: An Internet Architecture for the 21st Century, Barrera et al., 2017
SCION – Path Constructon Beacons Path Constructon Beacons are signed by every AS along the path ● Can be verifed within ISD ● Hop-felds (HF) can be used to later select paths ● Contain MAC computed using hop-feld key ● Only processed locally ● 26
SCION – Path Constructon Beacons 27 Source: SCION: A Secure Internet Architecture, Perrig et al., 2017
SCION - Routng Path constructon performed by end nodes ● Path informaton included in packet headers ● No forwarding informaton necessary at routers ● Packet-carried forwarding state (PCFS) ● Sender decides on the path ● Typically use multple paths ● Recipient address no longer used to route between autonomous systems ● Only used by the destnaton AS ● 28
SCION - Routng Path can consist of three parts ● Up-segment ● Core-segment ● Down-segment ● Segments retrieved from local path server ● Local path server queries core path server for unknown segments ● Hop-felds are for selected path are combined and included in the SCION ● packet header 29
SCION - Routng 30 Source: SCION: A Secure Internet Architecture, Perrig et al., 2017
SCION - Routng 31 Source: SCION: A Secure Internet Architecture, Perrig et al., 2017
SCION - Security Trust within ISD ● Compromise is kept locally → root key can only be used to compute ● certfcates for local ISD ISD signs Trust Root Confguraton of connected ISDs ● Provides global verifability through chain of trust ● Update to the TRC propagates within minutes ● Three PKIs ● Control-plane ● Name-resoluton ● End-entty ● 32
SCION - Security Control-plane ● Comparable to RPKI ● Short-lived certfcates for ASes ● Name-resoluton ● Comparable to DNSSEC ● Typically ISD will delegate name resoluton to TLDs ● End-entty ● Comparable to TLS ● Certfcates need to be signed by multple CAs and registered at publicly ● verifable log server 33
SCION – Name-resoluton security 34 Source: SCION: A Secure Internet Architecture, Perrig et al., 2017
SCION – Data plane authentcaton So far, authentcaton was provided in the control place ● Authentcaton can also be provided in the data plane. ● For example using: ● OriginValidaton, packet originates from source ● PathTrace, packet followed indicated trace ● Origin and Path Trace (OPT) ● 35
SCION - OriginValidaton Source shares a symmetric key with every AS on the path ● Additonal informaton in header ● DataHash: hash over payload ● SessionID: session identfer picked by source ● List of OV values: MAC over DataHash with key shared between source ● and AS or destnaton Every intermediate AS and the destnaton verify its corresponding OV value ● Overhead linear in number of ASes on the path ● 36
SCION - PathTrace Source and destnaton share a symmetric key with every AS on the path ● Additonal informaton in header ● DataHash: hash over payload ● SessionID: session identfer picked by source ● PVF: MAC over DataHash and previous value of PVF ● Every intermediate AS updates the PVF value ● Overhead constant ● Destnaton can compute MAC over data hash and fnal PVF for source to ● verify path Verifcaton can be performed later: retroactve-PathTrace ● 37
Summary BGP provides no secure by default ● Hijacking and intercepton possible ● Origin authentcaton provided by RPKI and RAOs ● BGPsec introduces path authentcaton ● SCION introduces a new architecture that provides more security by design ● 38
Recommend
More recommend
