Università degli Studi di Trieste

Piazzale Europa 1, 34100 Trieste

Facoltà di INGEGNERIA
Corso di Laurea in

INGEGNERIA INFORMATICA

Anno Accademico 2005/2006

Complementi di reti

Studente: Giorgio Davanzo Docente:

giorgio.davanzo@gmail.com Prof. Alberto Bartoli
 COMPLEMENTI DI RETI 1
di Giorgio DAVANZO
IMPLEMENTAZIONE TCP:
RFC: 793, 1106, 1122, 1323 specificano una interfaccia di programmazione Æ non parlano di socket.
TCP vs IP: IP comunica tra nodi, connetionless, unreliable e message-oriented. TCP comunica tra processi, è
connection oriented, reliable e byte oriented.
Header IP: circa 20 byte Header TCP: circa 20 byte

MTU: Maximum Transmission Unit, dimensione massima del pacchetto. Sulla stessa rete vale di solito 1436,
su reti diverse 576.
MSS: Maximum Segment Size, dimensione massima del payload; viene negoziato all’inizio prendendo il più
piccolo dei proposti; ogni nodo deve accettare
MSS > 536.
Buffers: il buffer di ricezione ha i puntatori
rcv.User (prossimo byte da consegnare) e
rcv.Next (prossimo byte da ricevere); il valore di
ack inviato è rcv.Next.
Il buffer di trasmissione si basa su snd.Ack (prossimo byte
da riscontrare Æ ho ricevuto tutto fino a Ack-1), snd.Next
(prossimo byte da trasmettere) e snd.User (prossimo byte
che l’applicazione deve trasmettere.
RTO: Retransmission Time-Out è il tempo da aspettare prima di rinviare un segmento per il quale non si è
ricevuto l’ACK. Si usa un contatore, inizializzato a 0 all’inizio e quando snd.ack=snd.next; alla scadenza di
RTO lo si incrementa di 1 e si raddoppia RTO. Se counter = Max_Count (in Windows = 5) si chiude la conn.
RTT: Round Trip Time, tempo tra trasmissione e ricezione dell’ack.
Dead Gateway Detection: quando counter> Max_Count / 2 si cambia il gateway di default per quella
connessione; se avviene nel 25% delle connessioni si cambia il gateway di tutto il nodo Æ TCP conosce alcuni
pezzi di IP!!
Selective Ack: si usa in caso di gap nel buffer di ricezione; permette al receiver di descrivere accuratamente il
proprio buffer.
Fast Retransmit: implementato sia su server che receiver per velocizzare la velocità di eliminazione dei gap.
• Receiver: se ricevo un segmento accettabile ma fuori ordine o che riempie parte o tutto un gap, invio
subito un ack al sender
• Sender: se ricevo K ack uguali (in windows è 2, su RFC è 3) re-invio subito il segmento che sembra
mancante.
FLOW CONTROL:
Receive Window: deve essere sempre soddisfatta l’invariante rcv.buffer ≤ rcv.Next – rcv.User
Windos Size: è pari a rcv.buffer – (rcv.Next – rcv.User) e indica il numero di byte liberi nel buffer; viene
inviato al receiver tramite gli ack e viene usato solo se si riceve un ack corretto. Quindi, nel sender si deve
avere sempre snd.Next – snd.Ack ≤ snd.winSize.
Tempo trasferimento dati: winSize = M * MSS, l’applicazione ha N * MSS dati da trasmettere, t1 = tempo tra
invio e ricezione del primo pacchetto. Tempo = N / M * t1 * 2
Scelta di rcv.BufSize: conviene prendere un multiplo di MSS, in modo che quando il server trasmette a full
speed deve usare meno pacchetti e perché il costo è lo stesso. In win2k si sceglie il primo multiplo di [16kb, 64]
2 COMPLEMENTI DI RETI
Persistence Timer: quando non si può trasmettere per il flow control, fa partire il pers.timer e, quando scade,
invia un segmento senza dati per scoprire la window (magari l’ack che lo diceva è andato perso…)
Delayed Acknowledgment: quando sul receiver l’appl.layer preleva dati o riceve un segmento, dovrebbe
inviare un ack per informare il sender, ma invece di farlo subito aspetta un certo periodo (200ms su Win2k); in
questo modo cerco di conglobarne più d’uno (fa eccezione il Fast Retransmit).
Algoritmo di Nagle: il sender non trasmette finché tutti i dati non sono stati riscontrati; serve a limitare
l’overhead delle applicazioni interattive: aumenta la latency media, ma migliora l’efficienza. Per le applicazioni
non interattive non costa niente.
SWS Avoidance: Silly Window Syndrome Avoidance: lo stato della window size viene inviata solo quando è
pari a MSS; altrimenti, se l’app.layer legge pochi dati alla volta verrebbe inviata di continuo.
Accettazione segmenti: se è accettabile, scarta i dati che non rientrano nel buffer o si sovrappongono ad altri e
invia il delayed ack; altrimenti lo scarta e invia il delayed ack.
Wrap Around: i numeri di sequenza hanno 32 bit (4gb) e si rischia di passare oltre lo 0 Æ bisogna fare
attenzione quando il wrap-around è all’interno del buffer.
Gestione di RTO: l’ottimo è di poco superiore a RTT. Di solito, i valori di RTT sono costanti per certi
intervalli e hanno bruschi cambiamenti. Lo calcolo come RTO (n+1) = stimaRTT (n+1) + tolleranza.
• stimaRTT: stimaRTT(0) = 0 e stimaRTT(n+1) = stimaRTT(n) + (misura (n) – stimaRTT(n)) / 8
• tolleranza: tolleranza = dev(n+1) / 4
• dev: dev(0) = 12 e dev(n+1) = dev(n) + (|misura (n) – stimaRTT(n)| – dev(n)) / 4
Backoff: il raddoppiare RTO alla sua scadenza serve a portarlo al di sopra del’RTT che ha causato il suo
fallimento, tanto poi scende e si adegua rapidamente.
Algoritmo di Karn: se eseguo una misura errata di RTT (es: mando 1(1), scade RTO, rimando 1(2), ricevo ack
1(1) e penso che sia ack 1(2)) rovino la stimaRTT Æ quando scade RTO si sospendono le stime fino a quando
non ricevo l’ack di un segmento non ritrasmesso.
TCP Timestamps: soluzione alternativa a Karn; ogni segmento ha un time stamp a 32 bit, e l’ack lo riporta. E’
un’opzione negoziata all’apertura della comunicazione.
MSL: Maximum Segment Lifetime: IP può far circolare pacchetti per molto tempo, e rischio di trovarne uno
relativo ad una vecchia connessione. Per evitare questo, TCP assume che se riceve un pacchetto allora è fresco;
questo lo si risolve assumendo che un pacchetto TCP non può vivere più di 2minuti nel sistema (a 100Mbit il
wrap around arriva dopo 5,4 minuti).
Time Wait State: per evitare problemi con il wrap around, chi chiude una connessione deve aspettare almeno 2
MSL prima di poter riusare la porta.
Quiet Time: se cade una connessione e entrambi i nodi subito ripartono, prima di trasmettere si aspetta MSL.
GESTIONE DELLE CONNESSIONI:
ISS: Initial Sending sequence Number: numero di seq del primo byte da trasmettere.
IRS: Initial Receiving sequence Number: numero di seq del primo byte che il receiver manderà.
Generatore di ISN: il contatore viene incrementato ogni 4 micro secondi con incrementi casuali (per
protezione).
3-way Handshake: S invia CR(seq=ISS) usando il flag SYN, R invia ACK(seq=IRS, ack=ISS) con il flah
SYN e ACK, e S invia ACK(seq=ISS, ack=IRS): ora S inzia a mandare dati. Se ci sono errori uno dei due invia
il messaggio Reject (flag RST).
Gestione RST: RST viene inviato quando la richiesta di apertura non è valida; se si riceve il duplicato di un
ACK per l’apertura di una connessione già in corso, NON viene inviato ma si manda un ACK.
Chiusura di connessioni: la chiusura può essere normale (protocollo eseguito interamente) o anormale (se
spontanea in caso di guasti, o protocollo non completato). Se la chiusura è normale, allora i dati di tutte le
send() sono stati ricevuti dal TCP layer remoto, ma non è detto che siano stati passati all’app layer. Se A vuole
chiudere: su A inibisco send() e receive(), e A invia un segmento con il flag FIN. B inibisce il send(), invia
l’ack per FIN(A) e invia FIN(B). Tutto termina quando B riceve l’ack per FIN(B) – a questo punto A applica il
Time Wait State.
Keep-alive timer: se un nodo non riceve nulla per tanto tempo, invia un segmento senza dati: se non ottiene
risposta effettua una chiusura unilaterale.
 COMPLEMENTI DI RETI 3
CONGESTION CONTROL:
Congestion Window: si cerca di capire se la send window è eccessiva per la internetwork; la CW è la quantità
di bytes inviabili senza sovraccaricare la rete. Inizialmente è 2*MSS e si trasmette basandosi sul minimo tra CG
e winSize. Per decidere l’algoritmo ci si basa sulla costante send.ssThresh = 64KB.
• snd.CongWin < snd.ssThresh: si usa l’algoritmo slow start (crescita rapida della CongWin)
• snd.CongWin > snd.ssThresh: si usa il congestion avoidance (crescita lenta della CongWin)
Alla scadenza di RTO, congWin = MSS e ssThresh = max (2*MSS, (snd.Next-snd.Ack)/2)
Slow Start: CongWin cresce di MSS ogni volta che arriva un ACK in tempo
Congestion Avoidance: CongWin cresce di MSS quando arrivano tutti gli ACK in tempo
Velocità: il controllo della congestione rende inizialmente lente le connessioni; infatti:
• flow control: velocità = M * MSS / RTT
• congestion control: se ricevo K segmenti di fila, velocità = (K+1) * MSS / (2 * RTT)
Idle connections: se non trasmetto per molto tempo la stima della CongWin non vale più; percui, se non
trasmetto per RTO si riparte con lo slowstart: CongWin = MSS
Fast Recovery: se si deve effettuare il fast retransmit si ritrasmette senza slow start.
Fairness: il controllo della congestione tende a dare equità nell’uso delle risorse condivise. Problemi:
• web: molte connessioni verso lo stesso nodo
• applicazioni multimediali: il TCP è educato, ma l’UDP cerca di andare a tutta velocità (usano sempre la
stessa velocità)
SICUREZZA:
IPSEC: l’autenticazione viene effettuata sul livello IP per ogni datagram.
NTLM: è unilaterale del client, riferita alla sola connessione. C invia al server la richiesta di connessione; S
manda una challenge che C deve restituire criptata con il MD (si usa MD4) della chiave di C. IL MD è di
16Byte, se ne aggiungono 5 di padding e si hanno 3 chiavi da 56bit, usate per crittare con DES.
Dominio NT: la coppia <nome,
MD(pw)> viene salvata in
memoria, e se nessuna di quelle
memorizzate funziona interroga
l’utente. Mondando un remote
folder, i dati vengono richiesti
solo la prima volta.
Authentication in Win2K:
all’avvio si comunicano i metodi
disponibili e si sceglie il più
forte.
HTTP Authentication: client manda use e password in chiaro (la pw è in base 64)
HTTP con NTLM: S chiede NTLM [www-Authenticate: …]; C dice il suo nome [Authorization: NTLM …]; S
manda la challenge [www-Authenticate: …]; C la cripta con il MD(pw) [Autorization: NTML …]. Non si
autenticano le connessioni, ma le sessioni http!
Kerberos: si basa su ticket contenenti
l’informazione sulla loro durata (momento di
emissione e tempo di vita), una chiave, il nome
del client, il nome del server, l’IP del client
criptati con KS. AS è l’authentication server,
che conosce le chiavi di KC e KS.
Interazione con TCP:
• fortissima: tutto viene protetto
• forte: solo le richieste sono criptate
• debole: solo l’autenticazione usa kerberos.
Sessione: è la durata di un ticket; infatti, ogni ticket può essere usato per più connessioni TCP.
4 COMPLEMENTI DI RETI
Kerberos vero: esiste un nodo super protetto detto Key Distribution Center (KDC), contenente due servizi:
Authentication Service (AS), che genera ticket di ≈ 10ore di durata per il TGS e il Ticket Granting Service
(TGS), che genera ticket per i server S di ≈ 5 minuti di durata.

AS e TGS condividono le chiavi Ks per permettere ai server di autenticarsi a loro volta. Sdoppiando in AS e
TGS si limita l’uso di Kc.
Kerberos V5: AS risponde solo se C, nel passo 1, invia anche un time stamp fresco crittato con Kc Æ non si da
la possibilità di fare attacchi do forza bruta per individuare le password.
NAT, NAPT e VPN:
NAT: Network Addres Translation; si compra un indirzzo IP pubblico + uno per il router. Associa all’indirizzo
interno IP-C quello di destinazione IP-X e sostituisce i campi nell’header di conseguenza.
DNS NAT: Se si cerca di accedere ad un server che ha solo IP-C privato, il router incorpora anche un DNS che
associa <nome, IP-C>. Alla richiesta di nome risponde con IP-E e associa IP-C con IP-X
NAPT: Network Addres Port Translation; trasforma <IP-I, port I> in <IP-E, port E>. Per i server interni si
creano associazioni fisse nella nat table.
Problema: quando dati relativi all’indirizzo IP o port number sono inseriti nel payload del TCP. Es: risposta
http con porta speciale o FTP (il comando PASV serve a cambiare porta).
VPN: Virtual Private Network per connettere reti molto distanti purché abbiano indirizzi privati unici (solo i
routers li hanno pubblici); si possono realizzare leased line (linea dedicata, molto cara). Di solito, si preferisce
invece far criptare ai routers i dati indirizzati alla rete remota e far passare tutto su internet.
Tunneling: invio di un datagram IP come payload di un altro.
PPTP: Point-To-Point Tunneling Protocol; permette ad un nodo di accedere ad una internetwork. Dopo
l’autenticazione, i pacchetti vengono criptati, gli si aggiunge uno header GRE (Generic Routing Encapsulation)
e viene inserito come payload di un altro pacchetto; il GRE contiene l’informazione PPP (P2P Protocol) perché
permette più tipi di payload oltre a IP.