# Computer Networking - Capítulo 1

# Introducción

La internet es una red de redes que conecta dispositivos que llamamos *hosts* o
*end systems* (computadoras, celulares, servidores, IoT, etc.). Están conectados
por redes de comunicación (cable coaxial, fibra óptica, espectro de radio, etc.) y
*packet switches*. Su *tasa de transmisión* se mide en bits/segundo. Cuando un end
system tiene que enviar data, la segmenta en paquetes y agrega bytes de header a
cada segmento. Los paquetes resultantes se llaman *packets* en la jerga, y se
reasemblan en el destino.

Un packet switch deriva paquetes a redes de comunicación. Los más comúnes son
routers y link-layer switches. Los switches suelen usarse en redes de acceso, y los
routers en el núcleo de la red. Esta secuencia de comunicaciones se conoce como la
*ruta* de la red.

Los end systems acceden a la internet a través de ISPs. Cada ISP es a su vez una
red de packet switches y redes de comunicación. A su vez estas se conectan por ISPs
nacionales e internacionales de mayor nivel, que luego se conectan entre sí. Cada
ISP se maneja independientemente, ejecuta el protocolo IP y sigue ciertas
convenciones de nombre y dirección.

Protocolos que control el movimiento de información: TCP e IP son dos de los más
importantes. IP especifica el formato de los paquetes que se envían y reciben entre
routers y hosts. Colectivamente se conocen como TCP/IP. Otros incluyen HTTP, SMTP,
etc. Otros estándares como IEEE 802 también definen Ethernet y WiFi.

## Servicios

También podemos pensar a la internet de manera distinta, como una infraestructura

que provee servicios a aplicaciones (e-mail, juegos, streaming, etc.). A estas apps
les decimos *aplicaciones distribuídas*. Corren en end systems.

Los end systems proveen una *socket interface* que especifica cómo un programa le
solicita a la infraestructura de Internet que envíe datos a un programa destino
específico corriendo en otro end system.

## Protocolos

Un protocolo define el formato y órden de los mensajes intercambiados entre dos o

más entidades comunicativas, y las acciones tomadas al transmitir y/o recibir un
mensaje u otro evento.

# Extremo de la Red

Los hosts (clientes, servidores) se conectan a través de *redes de acceso* al

primer router ("edge router") en la ruta a otro host.

Los tipos más comunes de acceso residencial son DSL (digital subscriber line) y
cable. El acceso DSL suele obtenerse a través de la compañía telefónica (que
también actúa de ISP). El modem DSL intercambia datos con el DSLAM (digital
subscriber line access multiplexer) de la compañía. El modem toma datos digitales y
los traduce a tonos de alta frecuencia para transmitirse por cables de teléfono. El
DSLAM vuelve a traducirlas a formato digital.

- Telefonía: 0-4 kHz

- Canal de subida: 4-50 kHz
- Canal de bajada: 50 kHz - 1 MHz
El acceso de cable, por otro lado, requiere un modem de cable. Al final del cable,
el CMTS (cable modem termination system) sirve una función equivalente al DSLAM.
Los modems de cable difiven la red HFC (hybrid fiber-coax) en canales de subida y
bajada.

El acceso por cable es un medio de transmición compartido. Cada paquete enviado por
la red baja por cada link a cada hogar. Esto ocasiona congestiones (con servicios
de stream, e.g.) que reducen el ancho de banda real de la red. Como el canal de
subida también es compartido, hace falta un protocolo de acceso multiple
distribuído para coordinar transmisiones.

La nueva tecnología FTTH (Fiber to the Home) provee un cable de fibra óptica
directo de la oficina central al hogar. Varias conecciones viajan por un sólo cable
y se dividen antes de llegar al hogar. Esa división se puede manejar con dos
arquitecturas de red: AONs (Active optical networks) y PONs (passive). También
existe el 5G fijo inalámbrico.

Otras redes de acceso: Ethernet, WiFi, 3G/4G, etc.

# Núcleos de la Red

## Packet-switching

En una aplicaciones de red, los hosts intercambian mensajes, que pueden realizar
funciones de control (Como el handshake) o contener datos. Los packet switches una
transmisión *store-and-forward* en los inputs con los links, i.e., el switch debe
recibir el paquete entero antes de comenzar a transmitir el primer bit. Ignorando
el delay de propagación, el router tarda $L/R$ segundos en recibir el paquete
completo, empezando a transmitirlo y tardando otros $L/R$ segundos en enviarlo al
destino ($L =$ n° de bits, $R =$ tasa de transferencia). Ergo, el delay total es
$2L/R$. Para enviar tres paquetes por un sólo link, el tiempo total sería $4L/R$.
Entonces, el delay end-to-end es:

$d_{end-to-end} = (N+P-1) \frac{L}{R}$

Donde $N$ es el número de links entre la fuente y el destino (o sea, la cantidad de

routers es $N-1$, i.e. los nodos del grafo), y $P$ la cantidad de paquetes.

Si el switch enviara los bits en cuanto llegan, el delay total sería $L/R$; pero
los routers necesitan recibir, almacenar y *procesar* el paquete entero antes de
redirigirlo.

### Packet Loss

Cada packet switch tiene varios links conectados, cada uno con un output buffer (o
output queue) que almacena los paquetes a punto de enviarse. Si un link se
encuentra ocupado cuando llega un paquete, debe esperar en el buffer, lo cual
agregar *queuing delays* al envío del paquete.

### Forwarding y Routing

En la internet, cada host tiene una dirección IP. La IP tiene una estructura
jerárquica, cada segmento lee su dirección siguiente. Cada router tiene una tabla
de forwarding que mapea direcciones de destino (o porciones de la dirección) a los
links salientes del router.

Los protocolos de ruteo definen automaticamente las tablas de forwarding.

### Switching

En circuit switching, se reserva una ruta para enviar comunicaciones entre dos
hosts (e.g. teléfono). En packet switching no se reservan (e.g. Internet).

## Red de redes

Una vez que los usuarios se conectan a un ISP de acceso, los ISPs mismos deben
conectarse, creando una red de redes que forma lo que llamamos Internet.

Las ISP de acceso se conectan a una ISP regional, que a su vez se conectan a las
ISPs tier-1, cada una pagando a la siguiente por usar su servicio. Esta estructura
es variable: Una ISP de acceso podría conectarse directamente a la Tier-1, o varias
ISPs regionales podrían conectarse a una ISP regional mayor, etc.

Una red cliente se conecte a un grupo de routers en la red del proveedor (PoP -
Points of presence). Una ISP puede eligir hacer multi-home, conectándose a dos o
más ISPs proveedoras para continuar funcionando en caso de que una falle.

Dos ISPs cercanas en el mismo nivel de jerarquía pueden emparejarse, compartiendo

conección entre ellas directamente. Lo que hacen las ISPs tier-1 al conectarse
también es emparejamiento. También pueden emparejarse varias ISPs en un IXP
(Internet Exchange Point), un edificio particular con sus propios switches.

Por último, la internet tiene redes de proveedores de contenido (Google). Los

servidores de estas redes están separados de la internet pública, pero
interconectados entre sí via la red TCP/IP privada de Google. Si bien a veces esto
requiere comunicarse entre tier-1 ISPs, los proveedores de contenido minimizan el
tránsito por ISPs mayores.


# Packet-Switched Networks

## Delay

Tipos principales de delay: nodal processing delay, queuing delay, transmission

delay y propagation delay. En total nos dan el *total nodal delay*.


- Processing Delay: El tiempo necesario para examinar el header del paquete y

determinar a donde enviarlo. También puede incluir el tiempo necesario para
chequear errores. Luego de procesarse, se envía el paquete a la cola.

- Queuing Delay: Si no hay otros paquetes esperando ser transmitidos, es cero. Si

no, depende de la cantidad de paquetes previos en cola.

- Transmission Delay: Tiempo necesario para transmitir todos los bits del paquete
al link. $L/R$, donde $L$ es el largo del paquete y $R$ la tasa de transferencia
del router.

- Propagation Delay: Tiempo necesario para propagar el paquete al router destino.

La velocidad de propagación es casi igual a la velocidad de la luz, por lo que el
delay de propagación es $d/s$, donde $d$ es la distancia entre los routers.

Luego, $d_{nodal}=d_{proc}+d_{queue}+d_{trans}+d_{prop}$.

### Queuing Delay

$La/R$ es la *intensidad del tráfico*, donde $a$ es la cantidad de paquetes por
segundo que llegan ala cola. Si $La/R>1$, los paquetes llegan a la cola en promedio
más rápido de lo que pueden ser transmitidos, por lo que la cola tiende a crecer
sin límite, por lo tanto los sistemas deben diseñarse para que esto no ocurra.

Si $La/R\leq 1$, el delay de cola depende del tipo de tráfico que llega. Si los
paquetes llegan de manera periódica, cada paquete va a encontrarse con una cola
vacía. Si los paquetes llegan en grupos, el delay sube. Si llegan $N$ paquetes al
mismo tiempo cada $(L/R)N$ segundos, el enésimo paquete transmitido tiene un delay
de $(n-1)L/R$ segundos. El delay promedio es $(L/R)N/2$ (?).

En la realidad, el proceso de llegada a la cola es aleatorio.

### Packet Loss

La cola de un router no tiene capacidad ilimitada. Si la intensidad del tráfico

excede a 1, el paquete nuevo se encuentra con una cola llena, y el router lo
pierde. La performance de un nodo se mide no sólo en términos de delay, sino
también como la probabilidad de que un paquete se pierda.

### Delay End-to-End

Para una conección con $N-1$ routers entre fuente y destino, asumiendo que la red
no está congestionada, la acumulación de delays nodales nos da el delay end-to-end:

$d_{end-to-end}=N(d_{proc}d_{trans}+d_{prop})$

[Ver Traceroute/PingPlotter]

### Otros delays

Packetization, end system delays.

## Throughput

Para un archivo de $F$ bits con un tiempo de transferencia total de $T$ segundos,
el *throughput promedio* es $F/T$ bits/seg. Para algunas aplicaciones es mejor
tener delay bajo y throughput instantáneo (streaming). Para otras, como
transferencia de archivo, es mejor tener el throughput máximo posible, y el delay
importa menos.

Para una red con varios links, el throughput es igual a la tasa de transmisión del
link más débil, $F/min\{R_1,...,R_N\}$ para una conección con $N$ links. En la
realidad, el cuello de botella suelen ser las redes de acceso, ya que el núcleo de
la internet tiene link de muy alta velocidad. Si muchas conecciones pasan por un
mismo link, ese link podría volverse el cuello de botella.


# Protocolos y Modelos de Servicio


## Layers

### Application Layer

Es donde residen las aplicaciones de red y sus protocolos. En la internet incluye

protocolos como HTTP, SMTP y FTP. La traducción de nombres propios a direcciones de
red de 32-bits se hace con el protocolo DNS (domain name system) de la app layer.

Un protocolo dado se distribuye entre varios hosts; la fuente usa el protocolo para
enviar paquetes y el destino para recibirlos. Los paquetes de información en la
capa de aplicación los llamamos *mensajes*.

### Transport Layer

Son dos: TCP y UDP, los cuales se dedican a transportar los mensajes entre
endpoints.

TCP es un servicio que garantiza la entrega del mensaje a destino y realiza el

control de flujo (matchear la velocidad de emisor y receptor), además de romper
mensajes largos en segmentos cortos y proveer un mecanismo de control de gestión:
reducir la tasa de transmisión de una fuente cuando la red está congestionada.


UDP es un protocolo que provee un servicio sin conección: no garantiza ninguna de

las propiedades anteriores.

Llamamos *segmentos* a los paquetes en la capa de transporte.

### Network Layer

Se encarga de mover paquetes de la capa de red, *datagrams*, de un host a otro. El

protocolo de la capa de transporte pasa un segmento y una dirección de destino a la
capa de red. La capa de red luego envía el segmento.

Incluye el protocolo IP, que define los campos del datagrama y cómo actúan los
routers y hosts con estos campos. También incluye los protocolos de ruteo que
determinan la ruta que toma el datagrama entre fuente y destino.

A toda la capa de red junta también se la suele llamar *IP layer*.

### Link Layer

La capa de red utiliza al link layer para mover un datagrama de un nodo a otro.
Algunos protocolos del link layer proveen deliveries garantizados de nodo a nodo.
E.g.: Ethernet, WiFi, PPP, DOCSIS. Llamamos *frames* a los paquetes del link layer.

### Physical Layer

Mueve bits individuales dentro del frame de un nodo a otro. E.g.: cable óptico,
cable de cobre, etc.

## Encapsulación


# Seguridad

Ataques DoS (Denial-of-service):

[Ver Digital Attack Map]

- Ataque de vulnerabilidad: Enviar una secuencia específica de mensajes a una

aplicación o sistema operativo del host para parar o colgar el servicio.
- Bandwidth flooding: Enviar un aluvión de paquetes para tapar el link de acceso.
DDoS (Distributed DoS) attack: Utilizar una gran cantidad de hosts para enviar
tráfico a un server igual o mayor a $R$, donde $R$ es la tasa de
transferencia/acceso del servidor.

- Conection flooding: Establecer un gran número de conecciones TSP abiertas o

semiabiertas hasta que el host no puede aceptar conecciones legítimas.

Packet Sniffers: Leer paquetes enviados por LAN o compañías de cable.

IP spoofing: Una de la maneras de disfrazar a un usuario de otro usuario. Consiste

en inyectar paquetes a la internet con una dirección de fuente falsa. Se soluciona
con end-point authentication.

# Computer Networking - Capítulo 2

# Principios

## Arquitecturas de Aplicaciones de Red

Arquitecturas de red: Cliente-servidor, P2P.

## Cliente y Servidor

Una aplicación de red tiene dos procesos que se envían mensajes entre sí: Web
server y explorador, clientes de torrent, etc.

Un proceso envía y recibe mensajes a través de una interfaz de software llamada

*socket*, que sirve de puente entre la capa de aplicación y la de transporte dentro
de un host. También llamado *API*.

Los hosts se identifican a través de un valor único de 32-bits que llamamos

*dirección IP*. También se utiliza un *número de puerto* para identificar el
proceso de red que recibe el mensaje (ver [Link]).

## Servicios de Transporte p/ Aplicaciones

Servicios que puede proveer un protocolo de transporte a la aplicación:

- Reliable Data Transfer: Garantizar que no va a haber perdida de paquetes entre

procesos. Necesario para algunas aplicaciones (mensajería, transferencia de
archivos) y no para otras (multimedia).
- Throughput: Garantizar un throughput mínimo constante para la aplicación. Útil
para apps multimedia que no usen adaptive encoding.
- Timing: Garantizar que cada bit enviado por el sender llegue al receiver en $x$
mseg o menos. Útil en teleconferencias, juegos online, etc.
- Security: Encriptar y desencriptar datos antes de que lleguen a un proceso,
proveer autenticación, integridad de datos, etc.

### Protocolo TCP

- Connection-oriented service: TSP intercambia información de control entre hosts

antes de que la aplicación empiece a enviar mensajes (*handshaking*). Luego de
handshaking, se dice que existe una *conección TCP* entre dos sockets de dos
procesos. La conección es full-duplex, y debe cerrarse cuando las aplicaciones
terminen.
- Reliable data transfer: Ver arriba.
- Mecanismo de control de congestión: Ayuda al flujo de internet, frenando un
proceso de envío cuando la red está congestionada.
- TLS: Versión mejorada de TCP que implementa medidas de seguridad.

### Protocolo UDP

- Sin handshaking
- No garantiza arribo del mensaje ni arribo en orden.

## Application-Layer Protocols

Define cómo los procesos de un aplicaciones se envían mensaje: los tipos de

mensajes, los campos del mensaje, la semántica de los campos, y reglas para
determinar cuándo y cómo se envían y responden los mensajes.

E.g.: HTTP, SMTP, FTP, DASH, etc.

# Web

## HTTP

HTTP utiliza TCP como protocolo de transporte. Primero inicia una conección TCP, y
luego el servidor y el cliente envían y reciben mensajes a través de su socket.

El servidor no almacena datos sobre sus clientes, por lo que se dice que es un
protocolo *sin estado*.

## Formato de Mensajes HTTP


### Mensaje de Request

Ejemplo:

```
GET /somedir/[Link] HTTP/1.1
Host: [Link]
Connection: close
User-agent: Mozilla/5.0
Accept-language: fr
```

La primera linea es el *request line*. Tiene tres campos: el método, la URL, y la

versión de HTTP. El método puede ser GET/POST/HEAD/PUT/DELETE.

Las otras lineas son headers: La segunda es el host donde reside el objeto; si bien
la conección ya está establecida, los caches de Web requieren esta linea.

La tercera indica que la conección no necesita ser persistente; el explorador le

dice al servidor que puede cerrar la conección luego de enviar el objeto.

La cuarta y quinta es el tipo e idioma del explorador que está enviando la

solicitud al servidor, permitiéndole enviar distintas versiones para distintos
exploradores. Existen otros headers para negociar el contenido del objeto en HTTP.

El campo "Entity body" se utiliza cuando el método es POST. Un mensaje de método

POST *también es una solicitud al servidor*, sólo que además envía información, y
el contenido específico de la página solicitada puede depender de lo enviado.

En la práctica, el cliente también puede enviar datos en un método GET,

concatenándolos a la URL solicitada (como hace PHP, ASP, etc.).

Otros métodos: HEAD es igual a GET pero sin enviar el objeto solicitado (e.g. para
debuggear), PUT es para subir archivos a una dirección del servidor, y DELETE para
eliminarlos.

### Mensaje de Respuesta

Ejemplo:

```
HTTP/1.1 200 OK
Connection: close
Date: Tue, 18 Aug 2015 15:44:04 GMT
Server: Apache/2.2.3 (CentOS)
Last-Modified: Tue, 18 Aug 2015 15:11:03 GMT
Content-Length: 6821
Content-Type: text/html
[data]
```

## Cookies

Las cookies permiten a un servidor HTTP mantener estados de sus usuarios,

almacenándolos en el cliente.

## Cache Web

Entidad de red que satisface solicitudes de HTTP en lugar del servidor Web. Los
exploradores se configuran para que las solicitudes HTTP se dirigan primero al
caché web; la conección TCP sólo se establece una vez que el caché confirma no
tener la página solicitada en el almacenamiento local (generalmente instalado por
la ISP, o a través de CDNs (Content Distribution Networks)).

### Get Condicional

Para evitar que el objeto traído del caché esté desactualizado, se lleva a cabo un
GET condicional. Cuando un caché solicita una página, almacena su contenido además
de la fecha de última actualización. Luego, incluyendo el mensaje *If-Modified-
Since*, el caché solicita una copia del servidor *sólo* si el objeto fue
modificado; de lo contrario el servidor devuelve mensaje 304 sin el contenido del
request.

## HTTP/2

HTTP/2 no cambia los métodos, headers o códigos de estado de HTTP/1.1, sino que
reduce latencia, habilitando multiplexing de requests y respuestas sobre una sola
conección TCP, y mejorando compresión de campos.

Si bien las conecciones TCP persistentes permitían enviar una página web sobre una
sola conección TCP, esto puede ocasionar *HOL* (Head of Line) blocking, cuando un
archivo grande bloquea la carga de otros pequeños.

El control de congestión TCP también se beneficia de paralelismo, ya que al abrir

varias conecciones en paralelo, el explorador puede hacer "trampa" y adquirir más
conección. Con HTTP/2, no hace falta usar conecciones paralelas, así que el control
de congestión puede funcionar como corresponde.

### Framing
HTTP/2 soluciona el HOL blocking dividiendo a todos los objetos en *frames*
pequeños de igual tamaño, luego entretejiendo el envío de los frames de cada
objeto. La supcaba de framing tabién codifica los frame en binarios, reduciendo el
tamaño y la tasa de error.

# DNS

Su tarea principal es proveer un directorio que traduzca hostnames a direcciones

IP. DNS es (1) Una base de datos distribuída y (2) un protocolo de la capa de
aplicación que permite a los hosts hacer queries a (1); las queries se realizan por
UDP al puerto 53, y pueden ser *iterativas* o *resursivas* (solicita a un servidor
DNS hacer una query en representación del cliente).

Otros servicios incluyen:

- Aliasing de hosts: Un host puede tener un hostname *canónico* y uno simplificado.

El cliente puede invocar DNS para obtener el canónico además de la IP.
- Aliasing para servidores de mail.
- Distribución de carga: Para servidores replicados en múltiples servidores, se
almacenan un conjunto de IPs junto con un hostname. El DNS responde al cliente con
todas las IPS, pero rotadas en orden, para distribuir el tráfico de manera pareja.

### Distribución de Servidores


### DNS Caching

En la práctica, los servidores DNS suelen guardar direcciones en caché y enviarlas

directamente al cliente, aunque no sean el DNS autoritativo. Esta dirección en
caché debe descartarse cada cierto tiempo. También pueden guardarse en caché las
direcciones de TLDs, permitiendo a un DNS local saltearse el servidor raíz (La
mayoría de las requests suelen salteárselo).


## Registros y Mensajes

Los servidores DNS almacenan *RRs (resource records)*, incluyendo aquellos que
mapean hostnames a IPs. Cada RR está formado por:

```
(Name, Value, Type, TTL)
```

TTL (Time to Live) indica cuándo el recurso debe ser removido del caché. El
contenido de Name y Value depende del tipo:

- $A$: Name es hostname y Value es la IP del hostname. Mapeo estándar.

- $NS$: Name es un dominio y Value es el hostname del DNS autoritativo que sabe
como obtener la IP de los hosts de ese dominio. El DNS también almacena el registro
tipo $A$ que conecta el Name de un $NS$ con su IP.
- $CNAME$: Value es el hostname canónico del alias Name.
- $MX$: Value es el nombre canónico de un servidor de mail con un hostname alias
Name. Nótese que usar un registro MX permite usar el mismo alias para un servidor
de mail y otro servidor (e.g. [Link] es un registro, y el server de mail
@[Link] es otro registro).
### Mensajes DNS

Sólo hay dos tipos: queries y respuestas, con la misma estructura:


[Ver nslookup]

### Insertar Registros

Primero, los nombres de dominio se registran en un *registrar*, que verifica que

sea único y lo inserta en la base de DNS.

# Streaming

Dada la variación en anchos de banda entre distintos usuarios y formatos de

video/audio, se desarrolló el protocolo *DASH (Dynamic Adaptive Streaming over
HTTP)*, que codifica el video en varias versions con distinto bitrate,
permitiéndole al cliente solicitar de manera dinámica segmentos del video de un par
de segundos. El cliente puede solicitar segmentos de distinto bitrate según el
ancho de banda disponible; cada bloque es un mensaje GET distinto, que contiene el
rango de bytes solicitado.

En DASH, cada versión del video se almacena en un servidor HTTP, con una URL
distinta. El servidor también tiene un archivo *manifest*, que provee la URL de
cada versión junto con su bitrate.

## Redes de Distribución de Contenido (CDN)

Para poder servir enormes cantidades de clientes a la vez, evitar puntos de falla
únicos y cuellos de botella en la transmisión, los servidores grandes almacenan
copias de su contenido en varios servidores (que conforman la CDN) para luego
redirigir usuarios al servidor más cercano o con mejor conección [Ver Leighton '09,
Nygen '10]. Cada servidor no necesita copiar todo el contenido, sino quedarse con
lo más descargado y solicitar otras cosas que no estén almacenadas (como un caché
web).

### CDNs y DNS

Primero, el CDN debe interceptar las requests, para determinar a qué servidor
enviarlas, y luego redirigirlas. Específicamente, a través del DNS, el DNS
autoritativo reenvía la request a un proveedor de CDN; el DNS autoritativo sólo
devuelve el hostname del CDN al DNS local, que luego envía otra request a ese
servidor.

El CDN asigna clientes a un cluster basándose en cercanía geográfica, o llevando a

cabo medidas de delay periódicas entre clusters y clientes.

# Programación de Sockets


## UDP
### Cliente

```python
from socket import *

serverName = ’hostname’
serverPort = 12000
clientSocket = socket(AF_INET, SOCK_DGRAM)
message = input(’Input lowercase sentence:’)

[Link]([Link](),
(serverName, serverPort))

modifiedMessage, serverAddress = [Link](2048)

print([Link]())

[Link]()
```

### Server

```python
from socket import *

serverPort = 12000
serverSocket = socket(AF_INET, SOCK_DGRAM)
[Link]((’’, serverPort))

print(”The server is ready to receive”)

while True:
message, clientAddress = [Link](2048)
modifiedMessage = [Link]().upper()
[Link]([Link](),
clientAddress)
```

## TCP

### Cliente

```python
from socket import *

serverName = ’servername’
serverPort = 12000
clientSocket = socket(AF_INET, SOCK_STREAM)
[Link]((serverName,serverPort))

sentence = input(’Input lowercase sentence:’)

[Link]([Link]())

modifiedSentence = [Link](1024)
print(’From Server: ’, [Link]())

[Link]()
```

### Server

```python
from socket import *

serverPort = 12000
serverSocket = socket(AF_INET,SOCK_STREAM)
[Link]((’’,serverPort))

[Link](1)
print(’The server is ready to receive’)

while True:
connectionSocket, addr = [Link]()
sentence = [Link](1024).decode()

capitalizedSentence = [Link]()
[Link]([Link]())

[Link]()
```

# Computer Networking - Capítulo 3

# Introducción y Servicios

La función fundamental de los protocolos de transporte es extender el servicio IP

entre dos hosts a un servicio de datos entre dos procesos corriendo en los hosts.
Esto se llama *transport-layer multiplexing y demultiplexing*. UDP y TCP también
chequean la integridad de los segmentos mediante campos de detección de errores en
sus headers. TCP agrega otros servicios además de estos dos: *transferencia de
datos confiable* (Completa y en orden) y *control de congestión*.

# Multiplexing y Demultiplexing

*Demultiplexing* es el proceso de redirigir datos en un segmento de la capa de

transporte al socket correcto. *Multiplexing* es la tarea de juntar bloques de
datos de distintos sockets en el host fuente, crear segmentos y pasarlos a la capa
de red.

En UDP, el demultiplexing es tan sencillo como asignar un número de puerto a cada

socket. Generalmente el servidor asigna un número específico, y el cliente permite
a la capa de transporte asignarlo automaticamente.

En TCP, en cambio, dos segmentos entrantes con IPs o puertos fuente distintos se
redirigen a dos sockets distintos. Un socket TCP se identifica con cuatro valores:
el IP y puerto de origen y los de destino; sólo los segmentos con los mismos cuatro
valores se demultiplexean (?) al mismo socket.


[Ver scanners de puertos: [Link]]

# UDP

UDP [RFC 768] consiste en realizar el mínimo trabajo posible de un protocolo de

transporte: multiplexing, demultiplexing, y un mínimo chequeo de errores (via un
checksum en el header y un valor de largo del segmento). No hay handshaking, por lo
que se lo suele llamar un protocolo *connectionless*.

UDP es útil para aplicaciones en tiempo real, ya que no agrega delay a la

transmisión, y la posible perdida de datos es tolerable. Si la aplicación necesita
funcionalidad extra, puede implementarla por encima de UDP.

# Principios de Transferencia Confiable

Si bien TCP es un protocolo confiable, está implementado por encima de un protocolo
no confiable (IP).

## Errores de Bits

Los protocolos *ARQ (Automatic Repeat reQuest)* se basan en retransmisión de

mensajes de control para verificar la integridad del mensaje. Estos protocolos
necesitan implementar detecciones de errores, feedback positivo o negativo
(paquetes ACK y NAK) del receptor, y la capacidad de retransmitir paquetes enviados
con errores. En consecuencia, el enviador no puede mandar más datos hasta no
recibir un ACK.

Cómo contemplamos la posibilidad de que el paquete ACK o NAK mismo este corrompido?
La solución más común es agregar un nuevo campo al paquete con un *número de
secuencia*. Entonces el receptor puede chequear este número para determinar si el
paquete recibido es una retransmisión o no.

## Paquetes Perdidos

Para saber qué hacer cuando un paquete se pierde, basta con repetir el protocolo
anterior. Para saber si un paquete se perdió o no, el enviador puede esperar hasta
estar seguro de que un paquete se perdió, y simplemente retransmitirlo.

Cuánto tiempo debe esperar el enviador? Al menos un tiempo igual al delay round-
trip, más el tiempo que necesite le receptor para procesar el paquete. En la
práctica, este tiempo es demasiado largo y dificil de calcular, por lo que se usa
un tiempo menor, implementando un *timer* luego de enviar cada paquete. Esto
introduce la posibilidad de *paquetes duplicados* en el canal. Por suerte, el
header se secuenciamiento del paso anterior puede manejar este caso.

## Pipelining

El problema del protocolo anterior es que es stop-and-wait, por lo que su

performance no es ideal. Esto se soluciona con pipelines, permitiendo al sender
mandar varios paquetes juntos sin esperar. Esto trae las siguientes consecuencias:

- El rango de números de secuencia debe aumentarse, a una cantidad igual a al menos

el número de paquetes únicos que podría haber en tránsito en un momento dado. Este
numero también depende de cómo el protocolo responda ante paquetes
perdidos/corruptos/retrasados (Go-Back-N o selective repeat).

- Ambos lados de la comunicación necesitan un buffer para paquetes que ya se

transmitieron pero aún no fueron "reconocidos".


### Go-Back-N

En GBN, el emisor puede transmitir múltiples paquetes sin esperar un ACK, pero sólo
puede tener hasta $N$ paquetes no reconocidos en su pipeline. En consecuencia, el
emisor sólo debe responder tres tipos de eventos:

- Invocación: Al llamarse el send, deben chequearse que no haya $N$ paquetes no

reconocidos.
- Recepción de un ACK: En GBN, el reconocimiento de un paquete puede interpretarse
como reconocimiento de todos los paquetes con número de secuencia menor
(*reconocimiento acumulativo*).
- Timeout: En caso de timeout, el emisor reenvía todos los paquetes enviados pero
no reconocidos.


Por otro lado, en GBN el receptor descarta los paquetes desordenados. Por qué no
bufferearlo? Porque si llega el paquete $n+1$ pero no el $n$, el emisor reenviaría
toda la secuencia hasta $n+1$ de cualquier manera. El receptor sólo necesita
guardar el número de secuencia esperado del siguiente paquete.


### Selective Repeat

El problema de GBN es que, en caso de muchos errores, se retransmite una cantidad

alta de paquetes. Selective Repeat sólo retransmite los paquetes que sospecha
perdidos o corrompidos. Esto requiere que el receptor reconozca individualmente los
paquetes recibidos correctamente.

El receptor SR reconoce paquetes aunque no se hayan recibido en orden. Los paquetes

fuera de orden se guardan en buffer hasta que los de n° de secuencia menor sean
recibidos, y sólo ahí se entregan ambos a la capa superior.


# TCP

Al establecerse una conección TCP, ambos lados de la conección inicializan varias

variables de estado TCP. Este estado compartido es lo que conforma la "conección"
TCP. Las conecciones TCP son bilaterales entre un solo emisor y un solo receptor.

Al enviar datos, TCP empareja cada bloque con un header; el tamaño del bloque está
limitado por el *MSS* (Maximum Segment Size), el largo del frame de la link-layer
mayor posible, menos el largo necesario para el header TCP/IP (generalmente 20/40
bytes). En aplicaciones interactivas suelen transmitirse bloques menores.


## Segmentos TCP

Dos de los campos más importantes son el número de secuencia y el número de

reconocimiento. TCP ve los datos como una secuencia ordenada (pero
desestructurada).

Cuando se envían datos en una conección TCP, un host A incluye, al comienzo del
segmento, el número de reconocimiento que corresponde al número de secuencia
próximo que espera de B. Los reconocimientos son acumulativos, por lo que un
paquete que arribe fuera de orden suele guardarse en un buffer, y sólo reconocerse
cuando se suba upstream.

## Round-Trip Time

TCP usa un sistema de timeout/retransmit para recuperarse de segmentos perdidos. El

tiempo de timeout debe ser mayor al round-trip time. El RTT se calcula
aproximadamente de a un segmento por vez, no con todos los segmentos, y nunca se
computa con un segmento retransmitido. Con estos segmentos se mantiene un RTT
promedio actualizado de la siguiente manera:

$RTTEstimado = (1-\alpha)\cdot RTTEstimado+\alpha \cdot SampleRTT$

El valor recomendado de $\alpha$ es $1/8$. Nótese que este promedio pone más peso
en los samples recientes que en los viejos, lo que se llama EWMA (Exponential
weighted moving average).

TCP también tiene una medida de la variabilidad del RTT, calculado en base a la
desviación entre el nuevo sample y el RTT estimado:

$DesvRTT = (1-\beta ) \cdot DesvRTT + \beta \cdot |SampleRTT-RTTEstimado|$

El $\beta$ recomendado es $1/4$. Los valores pequeños de DesvRTT indican menor

desviación.

En consecuencia, el tiempo de timeout debe ser igual al RTTestimado, más un margen

que debe ser mayor cuanta más desviación haya en la red:

$Timeout = RTTEstimado + 4 \cdot DesvRTT$

El valor de timeout inicial se recomienda en un segundo, y cada vez que ocurre un

timeout, el intervalo se duplica para evitar timeouts prematuros causados por un
segmento subsecuente que pronto será reconocido. Una vez recibido, vuelve a
calcularse el timeout. Esto funciona como una forma de control de congestión: si la
fuente continuara retransmitiendo paquetes persistentemente y el timeout no
aumentara, la congestión se volvería peor.

También existe el *fast retransmit*, que retransmite un paquete antes del timeout
si tres ACKs posteriores son recibidos antes del ACK del paquete. Esto se toma como
una indicación de que el paquete se perdió

## Transferencia Confiable

```
NextSeqNum=InitialSeqNumber
SendBase=InitialSeqNumber

loop (forever) {
switch(event)
event: data received from application above
create TCP segment with sequence number NextSeqNum
if (timer currently not running)
start timer
pass segment to IP
NextSeqNum=NextSeqNum+length(data)
break;
event: timer timeout
retransmit not-yet-acknowledged segment with
smallest sequence number
start timer
break;
event: ACK received, with ACK field value of y
if (y > SendBase) {
SendBase=y
if (there are currently any not-yet-acknowledged segments)
start timer
}
break;
```

## Flow Control

Qué ocurre si el host tarda mucho en leer un paquete guardado en el buffer y se

sobrecarga con datos? TCP incluye un servicio de control de flujo para evitar que
esto ocurra: La tasa de envío del emisor se iguala a la tasa de lectura del
receptor. Nótese que esto es distinto el control de congestión, que refiere a
reducir la velocidad del emisor debido a congestiones en la red IP; Aunque muchas
veces se usan los términos de manera intercambiable.

El control flow se provee con un estado en el emisor llamado *receive window*,

igual al espacio libre en el buffer:

$rwnd = RcvBuffer - (UltimoByteRcbdo - UltimoByteLeido)$

$rwnd \geq UltimoByteRcbdo - UltimoByteLeido$

Qué ocurre si el buffer se llena pero B no tiene nada que enviar a A? Cuando tenga
algo que enviar, va a creer que el buffer sigue lleno y nov a a mandar nada. Por lo
tanto, TCP requiere que el host A continuar enviando segmentos de un byte cuando la
ventana de B sea cero.

## Manejo de Conección

El establecimiento de una conección TCP puede agregar delays significativos (por

ejemplo, en páginas web), y además, es un vector de ataque común [ver ataque SYN].


1. El TCP cliente envía un segmento especial al server, sin datos de aplicación y

con un *bit SYN* = 1. El cliente también elige un número de secuencia inicial al
azar (client_isn).

2. Al arrivar, el servidor extrae el segmento TCP SYN del datagrama, asigna el

buffer y variables de la conección. Luego envía un segmento de confirmación, sin
datos de aplicación y con tres tres campos especiales: El bit syn = 1, el campo ACK
del header TCP = client_isn + 1, y el un número de secuencia inicial elegido por el
servidor (server_isn); este segmento se llama *segmento SYNACK*.

3. Al recibir el SYNACK, el client también asigna buffers y variables. Luego envía

un segmento de reconocimiento con server_isn + 1 en su campo de reconocimiento, y
el bit SYN ya en 0.

Esto es lo que se conoce como *three-way handshake*. Una vez iniciada la conección,
cualquiera de los dos procesos puede terminarla, liberando los recursos de ambas,
con sólo enviar un segmento con el flag bit FIN = 1; el otro host reconoce el corte
y ambos liberan recursos.


### Syn Flood

Este sistema permite lo que se llama un SYN Flood Attack, por el cual se envían
muchos paquetes SYN al host sin confirmar o cerrar la conección; esto satura los
recursos del servidor. La manera de protegerse contra esto es con implementando SYN
cookies:

- Cuandoe l servidor recibe un segmento SYN, crea un HASH complicado con las IPs y
puertos del emisor y el receptor, más un número secreto, y las envía en un SYNACK
como número de secuencia inicial al cliente. Esto es la "cookie".
- Cuando el cliente legítimo envía un ACK, el servidor corre la función hash en las
IPs del cliente; si este hash es igual al ACK del sliente más uno, el servidor
concluye que el ACK corresponde a un segmento SYN válido anterior, y abre la
conección.

- Si el cliente no devuelve un segmento ACK, no hay ningún daño causado, ya que no

se asignó ningún recurso.

[ver Nmap]

# Principios de Control de Congestión

## Causas y Costos

### Caso 1: Dos emisores, router con buffers infinitos


### Caso 2: Dos emisores, router con buffers finitos

El overflow del buffer obliga al host a retransmitir paquetes para compensar por
los paquetes perdidos, por lo que en promedio sólo 0,333R bytes/seg son datos
originales, donde R es la velocidad máxima del router.


### Caso 3: Cuatro emisores, routers finitos, rutas con varios saltos

Como el túnel B-D accede a router 2 más rápido que el túnel A-C, la velocidad de A-
C llega asintóticamente a 0


## Metodologías

- Control End-to-end: La capa de red no provee ningún soporte explícito para

control de congestión, por lo que incluso la presencia de congestión de red debe
ser inferida por los hosts basándose sólo en el comportamiento de la red que
observan. Esta es la metodología que adopta TCP, tomando la pérdida de segmentos
como indicativo de una red congestionada, entre otras técnicas.

- Control asistido por red: Es cuando los routers proveen feedback explícito al
emisor y/o receptos sobre el estado de congestión de la red; podría ser un sólo
bit, o un feedback más complejo como el de *ATM Available Bit Rate (ABR)*, donde un
router informa a un emisor de la tasa de envío máxima que puede soportar en un link
saliente. IP y TCP pueden opcionalmente implementar control asistido por red.

# Control de Congestión TCP

## Control TCP Clásico

La metodología clásica consiste en que cáda emisor limite su tasa de transferencia

en función de la congestión percibida. Para esto necesita 1) limitar su tasa de
transferencia, 2) percibir si hay congestión, y 3) elegir un algoritmo para cambiar
la tasa en función de la congestión.
1) TCP mantiene una variable *ventana de congestión (cwnd)*, que limita la tasa de
transferencia; la cantidad de datos sin ACK no pueden exceder al mínimo entre la
ventana de congestión y la de recepción:

$UltimoByteEnviado - UltimoByteACKed \leq min\{cwnd, rwnd\}$

2) Cuando hay una congestión, uno o más buffers de routers en el trayecto tienen
overflows, lo que ocasiona pérdida de datagrams (que TCP percibe mediante timeouts
o tres ACKs duplicados, como se vio antes). Luego el emisor interpreta esto como
una congestión.

3) Para determinar cuánto debe cambiar la tasa de transferencia, TCP utiliza los
siguientes principios:
- Si un segmento se pierde, esto implica congestión, por lo que la tasa de envío
debe disminuirse.
- Si un ACK llega al emisor, quiere decir que la red está entregando
correctamente los paquetes, por lo que la tasa de transferencia puede aumentarse.

En consecuencia, la estrategía se conoce como bandwith probing: Aumentar la

tasa de transferencia al arribar los ACKs hasta que llegue una pérdida, y entonces
disminuirla. Nótese que esta método no requiere que los emisores TCP se sincronicen
de ninguna manera ni accedan a información global sobre el estado de la red.


## Algoritmo


El algoritmo tiene tres componentes: 1) Inicio lento, 2) prevención de congestión y

3) (opcionalmente) recuperación rapida.

### Inicio lento

Al iniciar una conección TCP, $cwnd$ se inicializa a un valor bajo de 1 MSS,

resultando en una tasa de envío inicial de $MSS/RTT$. Si MSS es 500 bytes y RTT 200
miliseg, la tasa inicial sería de 20 kbps. Dado que el ancho de banda disponible
podría ser mayor, el valor de $cwnd$ aumenta en 1 MSS cada vez que se reconoce un
segmento transmitido, duplicando la tasa de envío cada RTT.

Este crecimiento termina de distintas maneras. En caso de una perdida, el emisor

TCP reinicia $cwnd$ a 1 y fija una segunda variable, $ssthresh$ (slow start
threshold) a $cwnd / 2$. En subidas siguientes, el valor de ssthresh se usa como
pista para dejar de duplicar la tasa de transferencia en cada paquete: cuando
$cwnd$ sobrepasa a $ssthresh$, TCP entra en modo de prevención de congestion, donde
el $cwnd$ aumenta de manera más cuidadosa que antes.

Por último, en caso de triple ACK duplicado, TCP lleva a cabo una retransmisión
rápida y entra en fast recovery state.

### Prevención de Congestión

Al entrar a este estado, el valor de $cwnd$ es más o menos la mitad de su valor

cuando se encontró la última congestión, por lo que TCP empieza a aumentar el valor
en un solo MSS por RTT.

Una vez que se llega a un timeout, ocurre lo mismo que en slow start. En caso de
triple ACK duplicado, $cwnd$ se reduce a la mita, y se entra en fast-recovery.
### Fast Recovery

En fast recovery, $cwnd$ también sube de a un MSS por cada ACK duplicado recibido
for el segmento perdido que causó que TCP entre en fast recovery. Eventualmente el
ACK del segmento perdido llega, y TCP entra en prevención de congestión, o vuelve a
slow start en caso de timeout.


Dado que el control de congestión TCP aumenta de a 1 MSS por RTT y se reduce a la
mitad en ACKs duplicados, se lo suele llamar *AIMD (additive-increase,
multiplicative-decrease)*. El control de congestión AIMD resulta en el patrón de
sierra del gráfico anterior.

### TCP Cubic

TCP Cubic difiere levemente del método anterior en que es menos conservador al
detectar pérdida de paquetes: avanza más rápido al ancho de banda previo a la
pérdida y sólo ahí empieza a avanzar más lentamente.


Específicamente, la ventana de congestión aumentar como función cúbica de la

distancia entre el tiempo actual, y un timepo $K$ en el que la tasa de
transferencia llegaría a la tasa máxima antes de la última pérdida.

TCP Cubic es la versión default de TCP de Linux.

## Notificaciones y Control de Congestión Asistido por Red

Implementaciones recientes de IP y TCP prononen implementar una red que señale

congestión explícitamente al emisor y receptor TCP, además de variaciones en el
protocolo TCP que permiten inferir congestión midiendo el delay del paquete.

### Notificación de Congestión Explícita


### Control de Congestión Basado en Delay

En TCP Vegas, el emisor mide el RTT del trayecto fuente-destino para todos los
paquetes reconocidos. Dado un $RTT_{min}$, la tasa de transferencia no
congestionada sería $cwnd/RTT_{min}$

El Protocolo de congestión BBR expande las ideas de TCP Vega, incorporando

mecanismos que le permiten competir justamente con otros emisores TCP no-BBR. Otros
protocolos de congestión TCP basados en delay incluyen TIMELY, Compound TPC y FAST
para distintos tipos de redes.

# TLS (Cap. 8)

Aumenta TCP con:

- Confidencialidad
- Integridad de datos
- Autentificación de servidor
- Autentificación de cliente

Aunque generalmente se usa para transacciones sobre HTTP, puede ser empleado por
cualquier aplicación que corra sobre TCP. TLS provee una API con sockets análoga
ala API de TCP; aunque técnicamente en la capa de aplicación, desde el punto de
vista del desarrollador es un protocolo de transporte.


## Pasos de TLS

- Handshake: Primero se establece la conección TCP. El emisor envía una lista de

algoritmos que soporta junto con un nonce (para evitar replay-attacks) luego el
emisor envía un saludo TLS que el receptor contesta con un certificado, y
finalmente el emisor crea una pre-clave maestra (Encrypted Master Secret, EMS) en
base a la clave pública del certificado y la comparte con el receptor. Ambos
usuarios usan la pre-clave para computer la clave maestra. Finalmente, se envía un
HMAC de todos los mensajes enviados hasta ahora (para evitar que algún punto de la
conección se haya manipulado).
- Derivación de claves: Con la clave maestra, cada uno genera dos claves: Una clave
de encriptación para los datos que envían desde sí al otro, y una clave HMAC
(Standardized hashed message authentication code) para verificar la integridad de
los datos.
- Transferencia de datos: Los datos se encriptan y se envían. Ambos hosts almacenan
un contador de número de secuencia; al calcular el HMAC se utiliza también el
número de secuencia del paquete, evitando así que un intruso pueda cambiar paquetes
de orden o reenviarlos para dañar la conección.
- Registro TLS:
- Cierre de Conección: TLS no puede simplemente cerrarse con TCP FIN, ya que un
atacante podría cerrar la conección de antemano. En su lugar, todos los registros
TLS usan el campo Type para indicar si cierran la conección o no.

# Computer Networking - Capítulo 4

# Introducción


La función principal de la capa de red es mover paquetes entre hosts. Para eso
utiliza principalmente dos funciones:

- Forwarding (también llamado switching): Mover un paquete del link de entrada de

un router al link de salida siguiente que corresponda.

- Routing: La capa de red debe determinar la ruta que toman los paquetes de emisor
a receptor, usando *algoritmos de routing*.

Estos términos a veces se usan de manera intercambiable; aquí nos referimos por
forwarding a la acción local de un router que transfiere paquetes a otro, y routing
al proceso que abarca toda la red y determina la ruta total. También distinguimos
entre link-layer switches y network-layer switches (i.e. routers) aunque los dos
son tipos de packet switches.

Los routers de red poseen una *tabla de forwarding*. Cada router envía un paquete
examinando uno o más campos de su header, y usando ese valor del header para
indexar en la tabla de forwarding. Este tabla es generada por el algoritmo de
ruteo, que puede estar en cada router individual, o en un controlador remoto que se
encarga de computar y distribuir tablas de forwarding (generalmente un data center
manejado por la ISP o un tercero), lo que se conoce como *software-defined
networking (SDN)*.
## Modelo de Servicios de Red

La capa de red de la internet provee un sólo servicio, conocido como *best-effort

service*. No garantice que los paquetes sean recibidos en orden, ni que sean
recibidos, ni garantiza un delay o ancho de banda particular.

# Routers


- Puertos de entrada: Realiza la función física de terminar un link entrante al

router. También realiza funciones de link-layer. En la última fase del input port,
realiza un lookup que consulta a la tabla de forwarding.

- Switching fabric: Es una red interna del router que conecta los puertos de
entrada y los de salida.

- Puertos de salida: Almacena paquetes recibidos y los trasmite al link saliente,

realizando las operaciones de link-layer y capa física necesarias.

- Procesador de routing: En un router tradicional, ejecuta los protocolos de

routing, además de mantener las tablas de routing y computar la tabla de
forwarding. En un router SDN, se encarga de comunicarse con el controlador remoto.
También realiza funciones de administración de red [ver cap 5, 5.7].

## Input Processing


### Switching


Maneras de enviar un paquete de un puerto input a un puerto output (switching):

- Switching via memoria: En los routers más sencillos, el switching está bajo
control de la CPU, que copia los paquetes entrantes a la memoria para luego
copiarlos en el puerto de salida. Ergo, si la memoria permite enviar $N$ paquetes
por segundo, el ancho de banda es de hasta $N/2$ paquetes.

- Switching via bus: El puerto de input agrega un header interno para indicar el
puerto de salida local, y luego lo envía a todos los puertos de salida, donde sólo
el correcto lo conserva, removiendo el header.

- Switching via red de interconección: Ver ilustración. A diferencia de los

anteriores, estos switches para enviar multiples paquetes en paralelo (ya que,
e.g., la ruta B está libre cuando la A está abierta), aunque si dos paquetes van a
la misma salida, uno tiene que esperar en el input.

## Output Processing


## Queuing

Si el switching no puede transferir todos los paquetes que arriban sin delay, hay
queuing en la entrada. Si dos paquetes van al mismo output, uno debe esperar al
primero; pero, si el que espera tiene un paquete con otro destino detrás, este a su
vez se retrasa porque debe esperar a que el paquete de adelante se envíe. Esto se
llama *HOL (Head of the line) blocking*. En cuanto la tasa de routeo llegue a un
porcentaje bajo de la tasa de paquetes entrantes, la cola podría crecer sin limite.

Los puertos de salida también pueden causar congestionamiento, si muchos paquetes

están destinados al mismo puerto de salida.

Nótese que tener buffers más grandes no es necesariamente mejor: Un buffer muy
grande puede aumentar el delay end-to-end más que simplemente liberar paquetes y
reenviarlos; los emisores TCP responden más despacio si los buffers son muy
grandes.

El queuing puede ser FIFO, priority queuing (asignando prioridad según campos en el
paquete, e.g. tanto más prioridad a los protocolos de streaming que a HTTP, etc.),
round robin (como priority queue pero alternando paquetes de cada categoría), etc.

# Internet Protocol (IP)

## IPv4

Ver [Pomeranz 2010]


- Versión: 4 bits. Versión del protocolo IP.

- Header length: 4 bits. Determina el número de opciones que contiene este
datagrama, que puede variar. Esto permite, e.g., deducir donde comienza el segmento
de transporte encapsulado. La mayoría de los datagramas IP no tienen opciones, así
que el header suele ser 20 bytes.
- Tipo de servicio (TOS): Permite distinguir distintos tipos de datagramas (e.g.,
tráfico en tiempo real, como telefonía, vs no-tiempo real, como FTP). El nivel
específico de servicio proveído es una política configurada por el administrador de
red del router.
- Largo del datagrama: Largo total (header y datos) medido en bytes. Como este
campo es de 16 bits, un datagrama IP puede tener en teoría hasta $2^16$ bytes. En
la práctica no suelen exceder los 1500 bytes, lo que les permite entrar en el campo
payload de un frama de Ethernet.
- Identifier, flags y fragmentation offset: Estos campos se encargan/encargaban de
la fragmentación IP. IPv6 no permite fragmentación.
- Time-to-live (TTL): Se incluye para asegurar que un datagrama no circule por
siempre. El campo se decrementa cada vez que un router lo procesa. Si llega a 0, el
router libera el datagrama.
- Protocolo: Se utiliza cuando un datagramaIP llega a destino final. Indica el
protocolo de transporte al que debe pasarse el datagrama, como TCP o UDP (lista
completa en [IANA Protocol Numbers 2016]). Así como el número de puerto une a las
capas de transporte y aplicación, el número de protocolo une a la capa de red con
la de transporte.
- Header checksum: Permite identificar bit erróneos en el header IP del datagrama
recibido (a diferencia del checksum TCP/UDP, que se computa sobre todo el
segmento). Nótese que, al cambiar el campo TTL en cada router, y quizás el campo
opciones también, el checksum debe ser recomputado en cada router.
- IP fuente y destino.
- Opciones: Permite extender un header IP. Dados los inconvenientes que causa
(largo arbitrario de un datagrama IP, necesidad de procesar opciones) fueron
eliminados en IPv6.
- Data (payload): Contiene el segmento de transporte que debe entregarse. También
puede contener otros datos, como mensajes ICMP.

## Addressing IPv4
Tanto los routers como los hosts poseen una dirección IP por cada link, ya que la
misma está asociada con sus interfaces, no con el host o router que contiene la
interfaz.

Una dirección IP tiene 32 bits. Se escribe en decimal, con cada byte separado por
un punto (e.g. [Link]). Cada host y router en la internet debe tener una IP
globalmente única. Una porción de la IP está determinada por la subred a la que
está conectada.


Nótese que los primeros tres valores (24 bits) de cada subred son iguales, ya que
denotan la interfaz de router a la que están conectados (un switch Ethernet, un
punto de acceso inalámbrico, etc.). La subred de la izquierda tiene la dirección
[Link]/24, donde el "/24", a veces llamado máscara de subred, indica que los 24
bits izquierdos definen la dirección de subred.

La estrategia de asignación de IPs de la internet se conoce como *CIDR (Classless

Interdomain Routing)*, que generaliza la noción de máscaras de subred. A cada
organización se le asignan un bloque de direcciones continuas, con un prefijo
común. Los routers externos a la red de la organización sólo necesitan considerar
esos bits.

También existe la IP de broadcast [Link], que envía el datagrama a todos

los hosts de la misma subred.

### Obteniendo bloques de direcciones

Para obtener un bloque de direcciones para una subred, un administrador contactaría

primero a la ISP, que puede proveer IPs de un bloque mayor de direcciones que se le
asignaron. E.g., la ISP tiene el bloque [Link]/20 y asigna direcciones de
subred [Link]/23.

Las direcciones IPs son administradas por [ICANN 2020], que también maneja los
servidores DNS raíz.

### Obteniendo una dirección de host

Las direcciones IP pueden configurarse al router manualmente (usando una

herramienta de administración de redes). Las direcciones de host suelen
configurarse con el *Dynamic Host Configuration Protocol (DHCP)*, que permite a un
host obtener (ser alocado) una IP automaticamente. DHCP puee configurarse para que
un host reciba la misma IP cada vez que se conecta a la red, o no. DHCP también
provee al host información sobre su máscara de subred, la dirección del primer
router al que salta (*default gateway*) y la dirección del DNS local.

DHCP es un protocolo servidor-cliente. Cada ubred suele contener un servidor DHCP,

o en su defecto un agente de relay que conoce la dirección del servidor de la red.


## Network Address Translation (NAT)

Un router con NAT, tiene una interfaz que es parte de la red del hogar. El
addressing funciona igual, pero el espacio de direcciones que utiliza está
reservado para una *red privada*, cuyas direcciones sólo tienen sentido a
dispositivos dentro de esa red.

El router habilitado con NAT no se ve como un router afuera, sino que se comporta
como un sólo dispositivo con una sóla IP.

Para saber a qué IP destino enviar un datagrama, el router usa una *tabla de
traducción NAT*, e incluye números de puertos.

## IPv6

Remueve fragmentación, header checksums y opciones.

# Forwarding Generalizado y SDN

En el forwarding generalizado, la noción de match + acción se generaliza en una

tabla que permite llevar a cabo distintas decisiones, como load balancing,
descartar un paquete (firewall), reescribir headers (p/ NAT), etc.

Cada entrada en la tabla (conocida como *flow table* en OpenFlow) incluye:

- Conjunto de campos de header que serán matcheados.


- Contadores que registran el número de paquetes matcheados, el tiempo desde la

última actualización de una entrada, etc.

- Acciones a tomarse cuando un paquete matchea.

# Middleboxes

- NAT Translation, implementing direcciones de red privadas, reescribiendo IPs y

puertos de datagramas.
- Servicios de seguridad: Bloquean tráfico basado en headers o redirigen paquetes
(DPI). También IDSs que detectan patrones predeterminados y los bloquean, y filtros
a nivel aplicación, como los filtros de spam, etc.
- Mejoras de performance: Compresión, caches de contenido, load balancing, etc.

Estos servicios muchas veces se implementan con software común corriendo en

hardware estándar - lo que se conoce como *NFV (Network function virtualization)*,
o a veces con outsourcing a la nube.

# VPNs y IPsec (Cap. 8)

En lugar de deployar y mantener una red privada real, las instituciones suelen
crear VPNs (Virtual Private Networks) sobre la internet existente.


## Protocolos AH y ESP

Cuando una entidad IPsec (host, router, etc.) envía un datagrama seguro a una
entidad destino, usa los protocolos AH o ESP. AH provee autentificación de la
fuente e integridad de datos, pero no confidencialidad. ESP agrega
confidencialidad. De ahora en más veremos sólo ESP.

## Asociaciones

Antes de mandar datagramas IPSec, se debe crear una conección lógica en la capa de
red, llamada *SA (Security Association)*. Para una conección bilateral hay que
establecer dos SAs, una en cada dirección. Como hay que establecer dos SA entre
hosts, una conección end-to-end tiene en total $2+2n$ SAs, donde $n$ es la cantidad
de gateways entre endpoints (asumiendo que todo el tráfico sea IPsec).

Para encriptar y desencriptar datagramas, cada router mantiene la siguiente

información:

- Identificador de 32-bit para la SA, el *SPI (Security Parameter Index)*

- Interfaz origen de la SA y la interfaz destino.
- Tipo de encriptación usada (e.g. 3DES c/ CBC)
- Clave de encriptacion
- Tipo de chequeo de integridad (e.g. HMAC c/ MD5)
- Clave de autentificación

## Datagrama IPsec


Nótese que el resultado es análogo a un datagrama IPv4, pero en vez de payload

tiene el header y trailer ESP, con con el datagrama original en el medio y un campo
de autentificación ESP. Los nuevos headers de fuente y destino del datagrama IPsec
interfazan las dos punta del tunel del VPN. El número de protocolo en este
datagrama es 50, desginando a un datagrama IPsec con el protocolo ESP.