Protocol stack: network layer

• Is charged with routing a single packet of data from one computer to another (via the next layer down)
• In TCP/IP, called the "Internet" or "Internet Protocol" (hence "IP") layer
• Example protocols: IPv4, IPv6, ICMP (used for 'ping'), IPsec (for VPNs)

Internet Protocol version 4

• Addresses are 32 bits, represented as 4 decimal numbers, period-separated
• Note the TTL & protocol fields; we'll see these shortly

IP Address Ranges

• Class D and class E addresses are reserved (multicast & "research purposes")
• Consider the range of addresses from 127.0.0.0 to 127.255.255.255
  • That's $2^{24} \approx 16$ million addresses
• That range is referred to as: 127.0.0.0/8
  • Meaning the first 8 bits are fixed, and the last 24 bits can be anything
  • So any address that starts with 127.
• UVA's range is 128.143.0.0/16

IPv4 Addresses

• There are also private IP address ranges:
  • 10.0.0.0/8 (class A)
  • 127.0.0.0/8 (class A)
  • 169.254.0.0/16 (class B)
  • 172.16.0.0/16 to 172.31.0.0 (class Bs)
  • 192.168.0.0/24 to 192.168.255.0/24 (class Cs)
• Primary usage:
  • 127.0.0.1 is used as the localhost IP
  • 192.168.0.0/16 are used as router private IPs

IPv4 limitations

• With only 32 bits, there are at most $2^{32} \approx 4$ billion addresses
  • There are about 30 billion connected devices in 2024 (source)
• How to connect them all?
• Solution 1: Network Address Translation (NAT)
• Solution 2: IPv6 (128 bit addresses)

Network Address Translation (NAT)

NAT in Practice

• UVA
  • UVA has many tens of thousands of connected devices
    • Most student, faculty, and staff (30k people) have a computer and a cell phone
    • Thousands of lab computers throughout UVA
    • Thousands of servers in the data centers
  • Yet only 64k (aka $2^{16}$) publicly addressable IP addresses
  • Any non-public facing computer is NAT'ed
• Your home router
  • May or may not have a public IP address
  • Likely dozens of devices connecting to it

IP version 6 (IPv6)

IPv6 Addresses

IPv6 Usage

• Essentially all IPv6 hosts have a IPv4 address as well
  • Often NAT'ed
• Some places have not yet enabled IPv6
  • As IPv4 w/NAT is fine for now
• IPv4 are much easier for us to use
• Thus, we won't be seeing any more IPv6 in this course

gateway's routing table

• The routing table routes are in bold
• This routing table is hard coded in our docker setup
  • Via the nws-exec.sh script run upon container startup

Hops (TTL)

• When a packet is routed through a network, it passes through a number of nodes
  • Each node is a hop
• There is maximum number of hops before the packet times out (is discarded)
  • This is time-to-live (TTL), and is decremented each hop
  • It's a counter, not a duration

Traceroute in Python w/Scapy

File is traceroute.py (src)

import sys
from scapy.all import *

dest ='142.250.80.100' # google.com

for TTL in range(1,40):
  response = sr1(IP(dst=dest,ttl=TTL)/ICMP(type=8), 
                 timeout=2, verbose=0)
  if response is None:
    print("%2d * * *" % TTL)
  else:
    print("%2d %s" % (TTL,response.src))
  if ( response is not None and response.src == dest ):
    break;

Traceroute in Python w/Scapy

$ sudo python3 traceroute.py
 1 192.168.14.1
 2 96.120.18.197
 3 96.108.129.85
 4 96.108.141.249
 5 96.110.42.133
 6 96.110.34.118
 7 66.208.216.218
 8 108.170.246.33
 9 108.170.246.49
10 142.251.49.73
11 142.251.69.26
12 142.251.69.0
13 108.170.248.97
14 142.251.65.115
15 142.250.80.100
$ 

Note the sudo

What about www.cs.virginia.edu?

$ sudo python3 traceroute.py
 1 192.168.14.1
 2 96.120.18.197
 3 96.108.129.85
 4 96.108.141.249
 5 96.110.42.129
 6 96.110.32.122
 7 162.252.69.145
 8 163.253.1.144
 9 192.122.175.58
10 192.35.48.33
11 128.143.236.6
12 128.143.236.89
13 * * *
14 * * *
15 * * *
16 * * *
^C
$

Traceroute security

• Traceroute can be used to map the internals of a company's network
  • By the ICMP time-exceeded packet response
• Many firewalls block these packets
  • Hence the * * * output, as no response was received

Reverse Path Filtering

• Attack idea: send a packet to a node
  • Have the return address be a different node on the local network
• The to and from are on different interfaces
  • OS kernels will drop this message entirely

ping.py (src) in Scapy

from scapy.all import *
ip = "128.143.67.11" # www.cs.virginia.edu
pkt = IP(dst=ip) / ICMP(type=8)
reply = sr1(pkt)
print ("Reply from", reply[IP].src, "with destination", 
     reply[IP].dst)

$ sudo python3 ping.py 
Begin emission:
Finished sending 1 packets.
...........*
Received 12 packets, got 1 answers, remaining 0 packets
Reply from 128.143.67.11 with destination 128.143.67.84
$

ICMP Tunneling

from scapy.all import *
ip = "192.168.100.101" # outer1
pkt = IP(dst=ip) / ICMP(type=8) / \
    b"the condor is in flight"
reply = sr1(pkt)
print ("Reply from", reply[IP].src, "with destination", 
       reply[IP].dst)
print ("Message:", reply.load)

root@outer2:~# python3 ping.py
Begin emission:
Finished sending 1 packets.
..*
Received 3 packets, got 1 answers, remaining 0 packets
Reply from 192.168.100.101 with destination 192.168.100.102
Message: b'the condor is in flight'
root@outer2:~# 

ICMP Tunneling Server

from scapy.all import *

def icmp_cnc(pkt):
  #print(pkt.show())
  print("From",pkt[IP].src,"received:",pkt[Raw].load)

filter = "icmp"
pkt = sniff(iface='eth1', filter=filter, prn=icmp_cnc)

root@outer1:/mnt# python3 icmp_cnc.py 
From 192.168.100.102 received: b'the condor is in flight'
From 192.168.100.101 received: b'the condor is in flight'
^C
root@outer1:/mnt# 

Virtual Private Network (VPN)

• A firewall differentiates between 'inside' and 'outside' to allow more access to those 'inside'
  • How, then, does a (valid) user have that level of access from the 'outside'?
  • Example: using UVa's library's access for online books and what-not
    • It's allowed on-grounds (technically, for any computer in the virginia.edu domain)
    • But not off-grounds (such as from va-67-76-91-214.dyn.embarqhsd.net)
• The answer: VPNs

Normal (non-VPN) usage

• A normal connection has your data being routed to the website through your ISP's servers (red lines)
• The ISP sees who you are routing to, and any unencrypted traffic

Using a VPN

• A VPN creates an encrypted "tunnel" to UVA's VPN server
  • The only thing the ISP sees is the encrypted data going to/from UVA
• The VPN provider (UVA) sees who you are routing to (green lines), the ISP does not

Virtual Private Network (VPN)

• A VPN makes potentially vastly separated IP addresses appear to be a single (virtual) private network
  • Then, the access is provided to that private network
• Keeps one from having to construct one's own private network (expensive)
• It matters not what type of ISP the user is on
• Typically requires a setting or two in a residential 'gateway' (specifically, IPsec)

VPN Network Details

Types of NICs

• TAP/TUN: NIC connects directly to software
  • TAP: link-level connection
  • TUN (tunnel): connection to network level

So many VPN types

VPN Types

• Implemented at the IP level using IPsec

VPN Types

• Implemented at the application level using TLS/SSL, DTLS, or even SSH
• Network packets are "intercepted" by the application, sent over the link, and then re-sent from the other side

VPN type: IP Security (IPsec)

• IPsec is a protocol suite designed to allow encryption of IP packets (at the Network level)
  • Other similar ones exist: TLS (Transport Layer Security) does something similar at the Transport level
    • SSL (Secure Sockets Layer) is the predecessor to TLS
• Allows for authentication, exchange of cryptographic keys, and encryption/decryption of IP data packets
  • Encryption is via AES
• For our purposes, we'll say it works like TLS (which we'll see later)

IPsec Tunnel vs Transport

• AH = Authentication Header
• And "Authenticated" means encrypted also

VPN type: TLS

• TLS (aka SSL/TLS): establishes a TLS link (encrypted TCP), then intercepts the transport-layer packets (TCP or UDP) and sends them over the TLS link
  • Rephrased: TCP packets are encrypted, then put into a TCP packet (!)
• Pro: relatively easy to implement
• Pro: avoids IPsec issues, such as firewall problems
• Pro: application level, so less kernel complexity
• Con: extra overhead and delays due to putting a TCP packet in a TCP packet

VPN type: SSH

• ssh can redirect a port through an ssh connection; usage:

$ ssh -L 8080:server:80 user@server

• Connecting to port 8080 on the localhost machine will connect, through the ssh tunnel, to port 80 on the remote server
• Pro: easy for anybody to setup and use
• Pro: does not need a VPN application
• Pro: application level, so less kernel complexity
• Con: does not redirect all traffic
• Con: slower than other methods

VPN Scams

• Do you trust your VPN provider?
• Consider:
  • Are Commercial VPNs still Trustworthy?
  • US Lawmakers Want FTC to Crack Down on Overpromising and Dishonest VPNs
• Consider their claims:
  • Stop hackers, adds, malware
  • Are faster than without
  • Claim: your ISP spies on you, and a VPN prevents that
  • Truth: correct, but with a VPN, then the VPN provider spies on you, and they often have poor privacy policies
• VPNs are good, just do your research on which one to use

Is IPsec secure?

• As part of the Snowden leaks (2013), it was revealed that NSA was actively working to insert security vulnerabilities into IPsec
  • Part of the larger Bullrun program
• Logjam attack (2015): a weakness in the selection of random primes for DHE made it crackable
  • The NSA claimed around then, in leaked papers, that they could break much of current cryptography; this is consistent with this DHE weakness
• The NSA-tied Equation group, around 2016, was believed to have used zero-day exploits against VPN equipment
  • The Cisco PIX and ASA firewalls had vulnerabilities that the NSA exploited for warantless wiretapping