CS 3710: Intro to Cybersecurity (slides): Networking

# Networking
## CS 3710

===

## Networking: the protocol onion

</figcaption>
</figure>

---

## What's in a protocol?

The World-Wide Web is composed of many interlocking *protocols* that control how
data is sent and received by computers.

</div>
<div class="fragment" data-fragment-index=0>

Protocols exist at every level of communication. They control the addressing of
computers, how data is fragmented and sent across the wire, encoding,
encryption, semantics, and more.

</div>

---

## What's in a protocol?

</figcaption>
</figure>

---

## What's in a protocol?

Protocols have to optimize for various design considerations. For example:

- _**Overhead:**_ how much overhead (in terms of message size or round trips)
  does the protocol add to communications?

</div>
<div class="fragment fade-in-then-semi-out" data-fragment-index=0>

- _**Forwards and backwards compatibility:**_ how tolerant is the protocol to
  future revisions? Is it still compatible with old versions of the protocol?

</div>
<div class="fragment fade-in-then-semi-out" data-fragment-index=1>

- _**Security:**_ what security vulnerabilities might these protocols introduce?

</div>

---

## Packets

As we talk about different networking protocols, the _**packet**_ will be the
smallest unit of communication that we discuss.

</figcaption>
</figure>

---

## The OSI model

The _**open systems interconnection (OSI)**_ model provides an abstraction for
the different types of protocols that exist in networking stacks.

*Source:
[Cloudflare](https://www.cloudflare.com/learning/ddos/glossary/open-systems-interconnection-model-osi/)*

</figcaption>
</figure>

notes:

Layers:
- Physical layer
- Data link layer
- Network layer
- Transport layer
- Session layer
- Presentation layer
- Application layer

---

## Layer 1: Physical layer

The _**physical layer**_ encompasses network traffic at the hardware level.

_**Example protocols:**_ IEEE 802.11, USB, Bluetooth

</figcaption>
</figure>

</div>
  <div class="col">

</figcaption>
</figure>

</div>
</div>

notes:

References:
- [IEEE 802.11](https://en.wikipedia.org/wiki/IEEE_802.11)

---

## Layer 2: Data link layer

The _**data link layer**_ enables data transfer between two connected devices.

</figcaption>
</figure>

---

## Layer 3: Network layer

The _**network layer**_ is used to allow different networks to talk with one
another. Protocols at this layer make it possible to address computers and route
packets.

_**Protocols:**_ IP, ICMP, IPsec, OSPF

*Source:
[Cloudflare](https://www.cloudflare.com/learning/network-layer/internet-protocol/)*

</figcaption>
</figure>

---

## The Internet Protocol, IP

We've already seen IP addresses before; they make it possible to address a
computer and contact it over a network.

*Source: IETF RFC 791*

</figcaption>
</figure>

notes:

Some of the fields:

- Length: total packet size in bytes; max is 2^16 bytes
- Protocol field: specifies the protocol used in the data portion of the packet.
- TTL: limits the number of times a packet can be transferred between routers so
  that they don't go around the network forever in the event of a routing loop.

---

## Layer 4: Transport layer

The _**transport layer**_ consists of protocols used to handle how data is sent
between machines. Protocols in this layer break data into chunks and ensure that
the data is reliably sent across the network.

</figcaption>
</figure>

---

## Layer 4: Transport layer

Packets sent by your computer may arrive at different times and out of order;
some packets may be dropped entirely.

</div>
<div class="fragment fade-in-then-semi-out" data-fragment-index=0>

_**Packet loss**_ can occur as a result of network congestion, changes in
connectivity, bugs, and more.

</div>
<div class="fragment" data-fragment-index=1>

Protocols at the transport layer help to handle this packet loss and make sure
that the server receives data in the expected order.

</div>

---

## TCP vs UDP

**UDP:** _**User Datagram Protocol**_. A simple protocol that mostly just adds
source and destination ports; used for unreliable connections.

*Protocols that use UDP:* DNS, QUIC

*Source: [Wikipedia](https://en.wikipedia.org/wiki/User_Datagram_Protocol)*

</figcaption>
</figure>

---

## TCP vs UDP

**TCP:** _**Transmission Control Protocol**_. This is typically used for
reliable connections that need loss recovery.

*Protocols that use TCP:* HTTP, SSH

*Source:
[Wikipedia](https://en.wikipedia.org/wiki/Transmission_Control_Protocol)*

</figcaption>
</figure>

---

## Layer 5: Session layer

The *session layer* consists of various protocols for managing communications
sessions.

_**Examples:**_ SOCKS (used in some cases to facilitate communications between a
client and a forward proxy)

</figcaption>
</figure>

---

## Layer 5: Session layer

_**Reverse proxy:**_ handles connections from a client before directing it to
one of several webservers.

Used for various purposes: request redirection, load balancing, logging, WAFs,
compression, encryption, caching...

</figcaption>
</figure>

---

## Layer 5: Session layer

_**Forward proxy:**_ a proxy deployed by the client to handle its outbound
connections.

Can perform caching and audit requests coming from a machine or an internal
network.

</figcaption>
</figure>

---

## Layer 5: Session layer

_**Tor**_ (*The Onion Router*) runs a local SOCKS proxy on your machine so that
your browser and other applications can forward their traffic through the proxy
and access the Tor network.

</div>
<div class="fragment" data-fragment-index=0>

By encrypting and re-routing your traffic, Tor makes it more difficult for a
third party to track your HTTP requests back to you.

</div>

---

## Layer 5: Session layer

*Source: Article19*

</figcaption>
</figure>

notes:

Ref: https://catnip.article19.org/data/ARTICLE19-Catnip-Tor-Network-2021-web.pdf

---

## Layer 6: Presentation layer

The _**presentation layer**_ concerns serialization and deserialization of data
into various formats before it can be sent or parsed by the client/server.

*Source: W3C*

</figcaption>
</figure>

notes:

https://www.osi-model.com/presentation-layer/

---

## Layer 7: Application layer

The _**application layer**_ consists of protocols that are directly used by
clients to talk to servers.

_**Examples:**_ DNS, HTTP, SSH, etc.

</figcaption>
</figure>

===

## Case study: Transport Layer Security

---

## Case study: Transport Layer Security

The _**Transport Layer Security (TLS)**_ protocol runs over TCP and provides
encryption-related functionality for TCP-based connections. You probably know it
best for putting the "S" in "HTTPS".

</div>
<div class="fragment" data-fragment-index=0>

It doesn't fit particularly well in any single layer of the OSI model, but most
of its work is done in layers 5 (session) and 6 (presentation).

</div>

</figcaption>
</figure>

</div>

</figcaption>
</figure>

</div>
</div>

---

## TLS handshake

The protocol starts with a _**handshake**_ between the client and server, where
they agree on a cipher and an encryption key they will use to communicate with
one another.

</div>
  <div class="col">

*Source: IETF RFC 8446*

</figcaption>
</figure>

</div>
</div>

---

## TLS handshake

</figcaption>
</figure>

</div>

</figcaption>
</figure>

</div>

</figcaption>
</figure>

</div>

</figcaption>
</figure>

</div>

---

## TLS certificates

During the handshake process, the client has to verify that it's actually
talking to the server in order to avoid _**man-in-the-middle attacks**_.

</figcaption>
</figure>

---

## TLS certificates

Each certificate contains

- a public key
- information about who owns the certificate
- a signature from a _**certificate authority**_ (_**CA**_) who has verified the
  identity of the certificate holder.

---

## TLS certificates

Certificates form a chain of trust, where certificates are signed by
intermediate CAs, which in turn are signed by root CAs.

</figcaption>
</figure>

---

## TLS Client Authentication

Clients can present TLS certificates too!

_**TLS Client Authentication**_ can be used to verify the identity of a client
before starting communications.

</div>
  <div class="col">

*Source: [Cloudflare](https://blog.cloudflare.com/introducing-tls-client-auth/)*

</figcaption>
</figure>

</div>
</div>

---

## QUIC

_**QUIC**_ (originally, "Quick UDP Internet Connections") combines many of the
functionalities of both TCP and TLS.

*Source: [QUIC Working Group](https://quicwg.org)*

</figcaption>
</figure>

notes:

Some improvements of QUIC over TCP:
- All packets are individually encrypted. Since TCP doesn't have any concept of
  encryption, you don't have to wait for partial packets before you can decrypt
  and verify the integrity of a stream.

References:
- RFC 9000 (QUIC): https://datatracker.ietf.org/doc/html/rfc9000
- RFC 9001 (TLS over QUIC): https://datatracker.ietf.org/doc/html/rfc9001