Complementi Di Reti

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 [email protected]

Docente: Prof. Alberto Bartoli

1

COMPLEMENTI DI RETI

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 CONGESTION CONTROL:

3

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 in . 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.