Network Security slide set

## Internet Structure
![](https://images.techhive.com/images/article/2014/12/networked_globe-100537357-large.3x2.jpg)
- The internet is split into *autonomous systems* (AS)
  - An AS is a series of IP addresses (a sub-net) managed by one entity
  - UVA is such an autonomous system
- Each is assigned an *autonomous system number* (ASN)
  - UVA is ASN # 225
- ASN and AS seem to be used interchangeably

## Internet connections
![](https://www.networkstraining.com/wp-content/uploads/2023/06/ASN-diagram.jpg)
- Internet-wide connections are between one ASN and another
- Most ASNs have a small number of connections to other ASNs; some have many
  - UVA has two
- Routing *within* the ASN is called IGP (Interior Gateway Protocol) via: OSPF, RIP, IGRP, etc.
- Routing *between* ASNs is called EGP (Exterior Gateway Protocol)
  - BGP (Border Gateway Protocol) is the only widely used one

## Transit vs Stub ASNs
![](http://www.cs.virginia.edu/~asb2t/duimg/n12/image16.png)
- Transit ASNs allow routing *through* the ASN to another ASN
  - They provide "transit services" (for a fee)
- Stub ASNs do not provide transit to others
  - End customers, such as universities and companies
  - Some may be connected to multiple ASNs (called multi-home ASNs)
    - But still do not provide transit services to others

## Transit ASN in NY
![](http://www.cs.virginia.edu/~asb2t/duimg/n12/image14.png)
This is NYSERNET, primarily for educational domains

## Public Peering
![](http://www.cs.virginia.edu/~asb2t/duimg/n12/image8.png)
- When two ASNs have a connection with each other, it is called *peering*
- Public peering: 
  - A link from an ASNs router to a (high throughput) switch
  - Usually happens at an *Internet Exchange Point* (IX)
  - Not all the ASNs on the switch on the public part of the diagram are peers!
    - The two ASNs have to agree to peer
  - UVA has one public peer: Level 3 communications

## Private Peering
![](http://www.cs.virginia.edu/~asb2t/duimg/n12/image8.png)
- When two ASNs have a connection with each other, it is called *peering*
- Private peering:
  - A direct connection between two (stub) ASNs routers
  - Can be a wire run between the routers, or occur at a co-location center
  - UVA has one private peer: vt.edu

## UVA's ASN
- The virginia.edu domain is [ASN # 225](https://www.ip2location.com/as225)
  - You can see more info via [bgp.he.net](https://bgp.he.net)
    - UVA's page is [here](https://bgp.he.net/AS225); also see the graph
- Notice our connections (all upstreams):
  - [ASN # 3356: Level 3](https://www.ip2location.com/as3356)
    - Note how many upstream (mostly transit ASNs) and downstream (mostly stub ASNs) connections it has
  - [ASN # 40220: vt.edu](https://www.ip2location.com/as40220)

## BGP
- The BGP *speaker* is the device or process that communicates routing information with peers
- The BGP *router* does the actual routing
- They are separate entities, but often in the same physical machine
- Each ASN controls some set of IP prefixes, and must announce them to the rest of the Internet

## BGP
![](http://www.cs.virginia.edu/~asb2t/duimg/n12/image16.png)
- UVA could be ASN # 150 in this diagram
  - VT would be AS # 151, and Level 3 would be AS # 11
- Router A announces to router D that it is ASN #150, and controls IP ranges 10.150.0.0/24
  - Shorthand: A -> D: 10.150.0.0/24 150
- For this example:
  - ASN # 150 is a stub
  - ASN # 151 can provide transit services
  - ASN # 11 does provide transit services

## BGP example
[![](http://www.cs.virginia.edu/~asb2t/duimg/n12/image16.png)](http://www.cs.virginia.edu/~asb2t/duimg/n12/image16.png)
1. A -> D: 10.150.0.0/24 150
2. A -> B: 10.150.0.0/24 150
3. B -> D: 10.150.0.0/24 151 150
   - B propagates the routing information it received
   - B tells D that it can route to ASN # 150
   - Note that it prepended its ASN # 151

## BGP example
[![](http://www.cs.virginia.edu/~asb2t/duimg/n12/image16.png)](http://www.cs.virginia.edu/~asb2t/duimg/n12/image16.png)
1. A -> D: 10.150.0.0/24 150
2. A -> B: 10.150.0.0/24 150
3. B -> D: 10.150.0.0/24 151 150
4. D -> B: 10.150.0.0/24 11 150
   - D also propagates the routing information it received
   - D tells B that it can route to ASN # 150
   - Note that it prepended its ASN # 11

## BGP example
[![](http://www.cs.virginia.edu/~asb2t/duimg/n12/image16.png)](http://www.cs.virginia.edu/~asb2t/duimg/n12/image16.png)
1. A -> D: 10.150.0.0/24 150
2. A -> B: 10.150.0.0/24 150
3. B -> D: 10.150.0.0/24 151 150
4. D -> B: 10.150.0.0/24 11 150
5. D -> E & F: 10.150.0.0/24 150
   - D tells the other border routers in its ASN that it can route to ASN # 150
   - This is via one of the IGP (Interior Gateway Protocol) protocols that it uses internally

## BGP example
[![](http://www.cs.virginia.edu/~asb2t/duimg/n12/image16.png)](http://www.cs.virginia.edu/~asb2t/duimg/n12/image16.png)
1. A -> D: 10.150.0.0/24 150
2. A -> B: 10.150.0.0/24 150
3. B -> D: 10.150.0.0/24 151 150
4. D -> B: 10.150.0.0/24 11 150
5. D -> E & F: 10.150.0.0/24 150
6. F -> G: 10.150.0.0/24 11 150
7. E -> C: 10.150.0.0/24 11 150
   - The other two border routers tell their peers that they can route to ASN # 150
   - Again, notice that they prepend their ASN #

## BGP & Learning IP prefixes
- How does the BGP router learn the IP prefixes?
  - Likely via static file, since it's not likely to change much
    - Likely how UVA does it, since the address ranges don't change
  - Discovery of the nodes in the ASN
  - From the IBGP (internal BGP) protocol

## `whois`
```
$ whois -h whois.radb.net -- '-i origin AS225'
...
route:          128.143.0.0/16
descr:          TelCove BGP Customer netblock
tech-c:         TC1-LEVEL3
origin:         AS225
member-of:      rs-19094-CUSTOMER
remarks:        University of Virginia
mnt-by:         MAINT-AS19094
changed:        mike.fletcher@telcove.com 20040813
source:         LEVEL3
rpki-ov-state:  not_found # No ROAs found, or RPKI validation not enabled for source
...
$ whois -h whois.radb.net 128.143.0.0
route:          128.143.0.0/16
descr:          TelCove BGP Customer netblock
tech-c:         TC1-LEVEL3
origin:         AS225
member-of:      rs-19094-CUSTOMER
remarks:        University of Virginia
mnt-by:         MAINT-AS19094
changed:        mike.fletcher@telcove.com 20040813
source:         LEVEL3
rpki-ov-state:  not_found # No ROAs found, or RPKI validation not enabled for source
...
```

## BGP Peering
- Requires that the routes be physically connected
- This is the process any time by which two BGP routers establish a connection
  - When they have already been configured to do so
- Peers exchange information via 5 different message types:
  - Open message to establish a connection
  - Update
  - Keepalive: every 30 seconds (tunable)
  - Notification: error notification
  - Route-refresh: supports the route-refresh capability
- BGP is unique among routing protocols by using TCP for this

## BGP Withdrawal
[![](http://www.cs.virginia.edu/~asb2t/duimg/n12/image18.png)](http://www.cs.virginia.edu/~asb2t/duimg/n12/image18.png)
- When a connection to a peer is broken
  - All the routes to/from that ASN are invalid
- A Route Withdrawal message is sent
  - This is propagated to other BGP peers
- Can cause a chain reaction of updates to routes

<h2 class="r-fit-text">Facebook / Instagram outage: Oct 4, 2021</h2>

- Meta's backbone network was accidentally taken down
  - It was restored quickly, but before it came back up...
- Meta's DNS servers realized that they could not reach the data centers
  - So the corresponding BGP speakers withdrew the routes
- Without the ability to contact DNS, not much worked

## BGP Update
[![](http://www.cs.virginia.edu/~asb2t/duimg/n12/image18.png)](http://www.cs.virginia.edu/~asb2t/duimg/n12/image18.png)
- When a new route becomes available
  - A connection was added or restored
  - A new peer
- Then the BGP router will advertise this to its peers
- If the peer decides this is the new best route, it will advertise it to its peers
  - If not, then it does not
- Setting TTL to 1 ensures only the directly connected peers receive the update

## Attacks Overview
- There is no security built into the BGP protocol
- Thus, unable to tell if a packet is spoofed or not
- One would need physical access to a data center or cable
  - But this could be a BGP router anywhere on the Internet

## Routing Rule: Longest Match
- What if two routes have IP ranges that overlap?
  - A class B address and a class C address
  - Ex: 128.143.0.0/16 and 128.143.67.0/24
- The class C address (/24) has a more bits than the class B address (/16)
- Thus, the class C is a "longer match"
  - Meaning a more specific sub-net
- The longest match is chosen over the other one

## Hijacking attack
![](https://www.networkstraining.com/wp-content/uploads/2023/06/ASN-diagram.jpg)
- Imagine that victim ASN # 100 had address prefix 1.2.0.0/16
- Attacking ASN # 200 advertises a route of 1.2.3.0/24
  - Or a spoofed packets causes this route update
- It's more specific, so it will be chosen over the previous
  - It then discards those packets

## Youtube Hijack: Feb 24, 2008
- The Pakistani gov't ordered Pakistan Telecom Corp Ltd (PTCL) ([ASN # 17557](https://www.ip2location.com/as17557)) to block Youtube
  - Youtube's IP address was in the 208.65.153.0/24 address range
- PTCL sent a BGP announcement of that to it's peers
  - Update msg: route 208.65.153.0/24 to ASN # 17557 (PTCL)
- Their transit ASN was Hong Kong based PCCW Global ([ASN3491](https://www.ip2location.com/as3491))
  - PCCW was supposed to catch this fake announcement, but failed to do so
  - And broadcast it to the wider Internet

## Youtube Hijack: Feb 24, 2008
- Youtube ([ASN # 36561](https://www.ip2location.com/as36561)) broadcasts 208.65.152.0/22 to its peers
  - But 208.65.153.0/24 is more specific, so that was used
- So it was all routed to PTCL in Pakistan
  - And then discarded
- This caused a near global blackout for about 2 hours

## Youtube Hijack: Feb 24, 2008
- Meta (then just Google) attempted to broadcast an update
  - Update msg: route 208.65.153.0/24 to ASN # 36561 (Youtube)
- But this is not *more specific* than the previous one
  - 208.65.153.0/24 to ASN # 17557 (PTCL)
  - So it was ignored
- Solution: get more specific, and send two updates:
  - Update message: route 208.65.153.0/25 to ASN # 36561 (Youtube)
  - Update message: route 208.65.153.128/25 to ASN # 36561 (Youtube)
- These, being more specific, worked
- Eventually PCCW (the PCTL's transit) withdrew the invalid updates

## BGP Hijacking Defenses
- Perhaps filtering
  - If an update arrives, check if the route is owned by the peer
  - Can check in the [Internet Routing Registry (IRR)](https://irr.net)
- Challenges with this:
  - IRR is not always complete or up-to-date
  - Some private peering is not disclosed, making route verification more complicated (if even possible)

## BGP Hijacking Defenses
- Use cryptography to prove ownership of the IP sub-net range
- Method: [Resource Public Key Infrastructure (RPKI)](https://en.wikipedia.org/wiki/Resource_Public_Key_Infrastructure)
  - A specialized public-key infrastructure for BGP routing information