Introduction to Internet Protocols

class: title, smokescreen, shelf, bottom, no-footer
background-image: url(images/SRI.jpg)

# 181U Spring 2020
### Introduction to Internet Protocols

<style>

h1 {
  border-bottom: 8px solid rgb(32,67,143);
    border-radius: 2px;
    width: 90%;
}

.smokescreen h1 {
    border-bottom: none;
}

.small {font-size: 80%}
  .smaller {font-size: 70%}
  .small-code.remark-slide-content.compact code {font-size:1.0rem}
  .very-small-code.remark-slide-content.compact code {font-size:0.9rem}

.line-numbers{
  /* Set "line-numbers-counter" to 0 */
  counter-reset: line-numbers-counter;
}

.line-numbers .remark-code-line::before {
  /* Increment "line-numbers-counter" by 1 */
    counter-increment: line-numbers-counter;
    content: counter(line-numbers-counter);
    text-align: right;
    width: 20px;
    border-right: 1px solid #aaa;
    display: inline-block;
    margin-right: 10px;
    padding: 0 5px;
}

</style>

---
layout: true
.footer[
- 181U
- See acknowledgements
]

---
class: compact
# Agenda

* Review
  - Network structure
  - Encapsulation
* Network Applications
  - Processes, sockets
* Transport Layer
  - TCP, UDP
* Network Layer
  - IP
---
class: compact
# What's a protocol ?

A Human protocol and a computer network protocol

![](images/space.png# w-2-12th)
![](images/protocol1.png# w-70pct)

---
class: compact
# A closer look at network structure

![](images/nutsandbolts.png# w-33pct fr)

* **network edge**
    - hosts: clients and servers
    - servers often in data centers
* **access networks, physical media**
    - wired, wireless communicaiton links
* **network core**
    - interconnected routers
    - network of networks

---
class: compact
# Host: sends *packets* of data

![](images/hostpacket.png# w-50pct fr)

Host sending function:
* Breaks application message into smaller chunks known as *packets* of length *L* bits.
* Transmits packets into access network at transmission rate *R*

\\[ \\text{transmission delay } = \\frac{L (bits)}{R (\\frac{bits}{sec})}\\]

---
class: compact
# Packet-switching: store-and-forward

![](images/space.png# w-2-12th)
![](images/packetswitching.png# w-70pct )

* Takes L/R seconds to transmit L-bit packet into link at R pbs
* **store and forward**: entire packet must arrive at router before it can
be transmitted on next link
* For N hops, end-to-end delay is NL/R (assuming no propagation delay)

---
class: compact
# The network core

![](images/networkcore.png# w-30pct fr)

* Mesh of interconnected routers
* Packet-switching: hosts break application-layer messages
into *packets*
    - forward packets from one router to the next, across links on path from source to destination
    - each packet transmitted at full link capacity

---
class: compact
# Two key network-core functions

* **routing:** determines source-destination taken by packets (routing algorithms)
* **forwarding:** moves packets from router's input to appropriate router output

![](images/space.png# w-2-12th)
![](images/route-forward.png# maxw-70pct )

---
class: compact
# Internet protocol stack

![](images/ipstack.png# maxw-20pct fr)

* **application** : supports network applications
  * FTP, SMTP, HTTP
* **transport** : process-process data transfer
  * TCP, UDP
* **network** : routing of packets from source to destination
  * IP, routing protocol
* **link** : data transfer between neighboring network elements
  * Ethernet, Wifi, PPP
* **physical**: bits "on the wire"

---
class: compact
# Encapsulation

![](images/space.png# w-3-12th)
![](images/encapsulation.png# maxw-50pct)

---
class: compact
# Writing a network application

![](images/netapp.png# maxw-33pct fr)

Write programs that:

* run on different end systems
* communicate over network
* e.g. web server/browser

---
class: compact
# Client-server architecture

![](images/clientserverapp.png# maxw-33pct fr)

Server:

* always-on host
* permanent IP address

clients:

* communicate with server
* may be intermittently connected
* may have dynamic IP addresses
* do not communicate directly with each other
  - may communicate through server

---
class: compact
# Peer-to-Peer (P2P) Architecture

![](images/p2parch.png# w-33pct fr)

* No *always-on* server
* Arbitrary end systems directly communicate
* Peers request/provide service from/to other peers
* Peers are intermittently connected and may change IP addresses

---
class: compact, col-2
# Processes communicating

**process**: program running within host

* within same host, processes communicate
using **inter-process** communication (through OS)
* processes in different hosts communicate by exchanging
**messages*

clients,servers
* **client process:** process that initiates communication
* **server process:** process that waits to be contacted.

---
class: compact
# Sockets

* Process sends/receives messages to/from its **socket**
* socket analagous to door
    - sending process shoves message out door
    - sending process relies upon transport infrastructure on the other side
of door to deliver to message to socekt at receiving process

![](images/space.png# w-10pct)
![](images/sockets.png# w-80pct)

---
class: compact
# Addressing Processes

* To receive messages process must have **identifier**
* Host device has unique 32-bit IP address
* **Q:** Does IP address of host on which process runs suffice for identifying process ?
   - **A:** No, many processes can be running on the same host
* **identifier** includes both **IP** address and **port numbers** associated with process on host
* Example port numbers:
    - HTTP server: 80
    - HTTPS server: 443
    - mail server: 25

---
class: compact, col-2
# Application-layer protocol defines

* **types of messages exchanged**
    - e.g. request, response
* **message syntax**
    - fields in messsages and how they are defined
* **message semantics**
    - meaning of information in fields

* **rules** for when and how processes send and respond to messsages
* **open protocols**
    - defined in RFCs
    - allow for interoperability
    - e.g. HTTP, SMTP
* **proprietary protocols**
    - e.g. Skype

---
class: compact,col-2
# What transport services does an app need ?

**data integrity**
* some apps (file transfer, web transactions) require 100% reliable data transfer
* others (e.g. audio) can tolerate some loss

**timing**
* Internet telephony, games, etc. require low delay to be "effective"

**throughput**

* Multimedia (video streaming) may require some minimum throughput  to be effective

**security**
* encryption, data integrity, ...

---
class: compact
# Transport service requirements: common apps

![](images/space.png# w-10pct)
![](images/transportrequirements.png# w-80pct)

---
class: compact,col-2
# Internet transport protocol services:

**TCP service**
* **reliable transport** 
* **flow control:** receiver can throttle sender
* **does not provide:** timing, minimum throughput,
security
* **connection oriented:** setup required between client and server

<br>

**UDP service:**
* **unreliable data transfer**
* **does not provide:** reliability, flow control,
timing guarantee, security
* **does not require:** connection setup

---
class: compact
# Internet apps: protocols

![](images/space.png# w-2-12th)
![](images/apptransports.png# w-70pct)

---
class: compact col-2
# Securing TCP

**TCP & UDP**

* no encryption
* cleartext passwords sent into socket
traversed Internet in cleartext

**SSL**
* Provides encrypted TCP connection
* data integrity
* end-point authentication

<br>

**SSL is at app layer**
* app use SSL libraries that "talk" to TCP

**SSL socket API**
* cleartext passwords sent into socket traverse Internet encrypted.

---
class: compact
# Web and HTTP

*A review*
* **web page** consists of **object**
* object can be HTML file, JPEG image, Java applet, audio file ...
* web page consists of base HTML-fil which includes referenced objects
* each object is addressable by a **URL**

![](images/space.png# w-2-12th)
![](images/url-example.png# w-60pct)

---
class: compact
# Example HTTP
![](images/httpapp.png# w-40pct fr)

**HTTP: hypertext transfer protocol**
* Web's application protocol
* client/server model
    - **client:** browser that requests/receives web pages
    - **server:** sends objects in response to requests

---
class: compact,col-2
# HTTP Overview

**uses TCP**

* client initiates TCP conection (creates socket) to server, port 80
* server accepts TCP connection from client
* HTTP messages (applicattion-layer protocol) exchanged between browser and (HTTP) server
* TCP connection closed

**HTTP**  is **stateless** -- server maintains no information about past client requests

**Two Variants**
* Non-persistent - at most one object sent over each TCP connection
* Persistent - multiple objects sent over a single TCP connection

---
class: compact
# (non-persistent) HTTP

![](images/space.png# w-20pct)
![](images/http1.png# w-60pct)

---
class: compact
# (non-persistent) HTTP
![](images/space.png# w-20pct)
![](images/http2.png# w-60pct)

---
class: compact
# Non-persistent HTTP Response time

![](images/nonpersistent-http-rtt.png# w-40pct fr)

**RTT:** (round trip time) time for a small packet to travel from client to server and back

**HTTP response time:**
* one RTT to initiate TCP connection
* one RTT for HTTP request and start of response to return
* file transmission time
* non-persistent HTTP = 2RTT + file transmission time

---
class: compact
# HTTP Request message

* Two types of HTTP messages: **request**, **response**
* HTTP request -- (human-readable format)
![](images/space.png# w-20pct)
![](images/httpreq.png# w-60pct)

---
class: compact
# HTTP Request message
![](images/space.png# w-20pct)
![](images/httpreq2.png# w-60pct)

---
class:compact
# Electronic Mail

![](images/email.png# w-33pct fr)

Three major components:
* User agents (outlook, thunderbird, etc)
* Mail servers
  * mailbox contains incoming messages for user
  * message queue of outgoing messages
* simple mail transfer protocol: SMTP
  * client: sending mail server
  * server: receiving mail server

---
class:compact
# Electronic Mail: SMTP (RFC 2821)

* Uses TCP to reliably transfer email message from client to server port 25
* Direct transfer: from sending server to receiving server
* Three phases of transfer
  * handshake (greeting)
  * transfer of messages
  * closure
* command/response interaction (like HTTP)
  * commands: ASCII text
  * response: status code and phrase
* messages in 7-bit ASCII

---
class: compact
# Example: Alice sends Bob a message

![](images/space.png# w-2-12th)
![](images/email-scenario.png# w-60pct)

1. Alice composes message in her mail program (UA)
1. Alice's mail app sends message to her mail server
2. Alice's mail server opens TCP connection to Bob's mail server
3. Message is transferred between SMTP server
4. Bob's mail server transfers message to his mail program
5. Bob reads message

---
class: compact
# Sample SMTP Interaction

```
     S: 220 hamburger.edu 
     C: HELO crepes.fr 
     S: 250  Hello crepes.fr, pleased to meet you 
     C: MAIL FROM: <alice@crepes.fr> 
     S: 250 alice@crepes.fr... Sender ok 
     C: RCPT TO: <bob@hamburger.edu> 
     S: 250 bob@hamburger.edu ... Recipient ok 
     C: DATA 
     S: 354 Enter mail, end with "." on a line by itself 
     C: Do you like ketchup? 
     C: How about pickles? 
     C: . 
     S: 250 Message accepted for delivery 
     C: QUIT 
     S: 221 hamburger.edu closing connection
```

---
class: compact,col-2
# SMTP

* SMTP uses persistent connections
* SMTP requires message to be 7-bit ASCII
* SMTP server uses CRLF.CRLF to determine message end

**comparison with HTTP

* HTTP : pull, SMTP : push
* Both have ASCII command/response interaction, status codes
* HTTP: each object encapsulated in its own response message
* SMTP: multiple objects sent in multipart message

---
class: compact, col-2
# DNS: Domain name system

**Internet hosts, routers:**
* IP address used for addressing
* "name", e.g. www.pomona.edu used by humans
**Q:** how to map between IP address and name (and vice versa) ?

<br>
**Domain Name System**
* **distributed database** implemented in hierarchy of **name servers**
* **application-layer protocol:** hosts, name servers communicate to **resolve** names

---
class: compact
# DNS: distributed, hierarchical database
![](images/space.png# w-20pct)
![](images/dnsdatabase.png# w-60pct)

**Client wants IP for www.amazon.com** (first approximation
* client queries root serer to find .com DNS server
* client queries .com DNS server to get amazon.com DNS server
* client queries amazon.com DNS server to get IP address for www.amazon.com

---
class: compact
# DNS Root name servers

* Contacted by local name server that cannot resolve name
* Root name server
  * contacts authoritative name server if mapping ot known
  * gets mapping
  * returns mapping to local server
* 13 logical root name servers worldwide (each is replicated many times)

![](images/space.png# w-4-12th)
![](images/rootnameservers.png# w-50pct)

---
class: compact
# TLD, authoritative servers

**top-level domain (TLD) servers:**
* Responsible for com, org, net, edu, ... and country domains (uk,fr,ca)
* Nework solutions maintains servers for .com TLD
* Educause for .edu TLD

**authoritative DNS Servers:**
* Organization's own DNS server(s) providing IP mappings to organization's named hosts
* Can be maintained by organization or service provider

---
class: compact
#  DNS name resolution example

![](images/dnsresolution.png# w-33pct fr)

* host at cis.poly.edu wants IP address for 
gaia.cs.umass.edu

** Iterated query:**

* contacted server replies with name of server to contact.

---
class: compact
# Attacking DNS

**DDoS attacks**
* Bombard root servers with traffic
  * Not successful to date
  * Traffic filtering
* Bombard TLD servers
  * a problem

**Redirect attacks**
* Man-in-middle
  * Intercept queries
* DNS poisoning
  * send bogus replies to DNS server infecting cache

---
class: compact
# Summary

![](images/kurosecover.jpg# w-33pct ba fr)

* Review
* Network Applications
* Transport Layer
* Network Layer
* Overview of TCP/IP https://www.garykessler.net/library/tcpip.html
* Cover Image: By Author unknown - Computer History Museum, Public Domain, <a href="https://commons.wikimedia.org/w/index.php?curid=78988842">Link</a>
* Source Material : Much of the content of these slides adapted from the slides provided for
 "Computer Networking: A Top Down 
Approach" 7th edition by Jim Kurose and Keith Ross.  That material is copyright 1996-2016 J.F Kurose and K.W. Ross.