Appunti del corso di Reti di Calcolatori 1

A->B FIN

A<-B FIN ACK

A->B ACK

È necessaria un’attesa temporizzata.

Infatti A non può sapere se B ha avuto la conferma di chiusura.

In fase di apertura dopo il 3 messaggio il mittente (chi ha iniziato la connessione) sa che il

destinatario ha ricevuto il pacchetto perché inizia a mandargli dei dati, cosa che non avviene in

chiusura.

22 nov. 18

Come si gestiscono i controlli di flusso e di congestione?

Ci sono due parametri da considerare

• Finestra di ricezione

Data dalla capacità con la quale il ricevente svuota il buffer

o

• Finestra di congestione

Basata su una stima della capacità della rete

o

Man mano che le reti diventano più veloci il controllo di congestione e quindi TCP diventa più

utile.

Il controllo di flusso è la capacità che deve avere il mittente di non inviare i pacchetti perché il

ricevente ha il buffer pieno. Ciò causa una perdita di pacchetti e una ritrasmissione.

Viene realizzato mediante lo scambio di informazioni riguardo lo stato della finestra di ricezione.

Il controllo di congestione è la capacità che deve avere il mittente di non inviare i pacchetti con

frequenza elevata quando lo stato della rete è troppo congestionato.

Nel primo caso si perdono pacchetti presso il destinatario, nel secondo si perdono presso il

mittente.

Dobbiamo considerare il numero di byte trasmessi pari alla minima tra le due finestre.

Lo scopo di TCP è triplice

1) Non mettere la rete in difficoltà

2) Non perdere pacchetti

3) Non mettere il destinatario in difficoltà

Trasmettere ad oltranza in caso di reti congestionate sempre alla massima velocità non fa altro

che causare una maggiore congestione della rete e una inevitabile perdita di pacchetti.

Il ricevente, per evitare che il mittente invii più pacchetti di quanti ne entrano nel buffer, quando

manda l’ACK invia la dimensione dello spazio disponibile (finestra).

Questa è l’implementazione del controllo di flusso di TCP.

Se il buffer è pieno, il destinatario manderà al mittente un ACK con spazio libero 0, e sarà sua cura

inviare un ACK con lo spazio disponibile quando avrà liberato lo spazio dal buffer.

Questo algoritmo soffre della Silly Window Sindrome.

Il destinatario non deve informare il mittente che il buffer è vuoto se non c’è spazio sufficiente per

almeno MSS o non si è svuotato almeno per metà, questo perché TCP, come descritto in un RFC in

caso di buffer pieno non si ferma ma continua a inviare 1 byte di payload alla volta, questo

significa che aumenta l’overhead della rete.

Immaginiamo che il buffer si svuoti 1 byte alla volta, il mittente invia un pacchetto applicativo di 1

byte con un header TCP di 20 byte e un header IP di 20 byte e un header ethernet…

Allo stesso tempo il mittente deve avere un buffer e inviare i dati non quando vengono prodotti

dall’applicazione ma appena ha una quantità sufficiente, pari almeno a MSS per minimizzare

l’overhead della rete e dare il tempo al destinatario di svuotare il buffer e passare i dati

all’applicazione.

Il controllo di congestione invece è la capacità che deve avere un mittente di non inviare sempre

alla massima velocità in caso di congestionamento perché questo non fa altro che aumentare il

ritardo e comunque il congestionamento della rete.

Sulla rete c’è un numero elevatissimo di sorgenti che competono sull’utilizzo delle risorse.

Possono esserci pezzi di rete sovraccarichi.

La congestione è dovuta a

• Numero elevato di sorgenti di traffico

• Sorgenti di traffico che inviano troppi dati

• Traffico inviato ad una frequenza troppo elevata

E queste cose causano

• Perdita di pacchetti

Buffer overflow nei router

o

• Ritardi nell’inoltro dei pacchetti

Accodamenti nei buffer dei router

o

• Scarso utilizzo delle risorse di rete

Se un protocollo gestisce le ritrasmissioni, come TCP, deve preoccuparsi delle ritrasmissioni e

quindi introduce nuovi dati che vengono trasmessi.

Continuando a ritrasmettere senza criterio non si fa altro che peggiorare lo stato della rete

diminuendo il goodput (throughtput effettivo).

La prima idea su come implementare questo è un feedback diretto dalla rete, un router

congestionato invia alle sorgenti un messaggio chiedendo di rallentare.

Può avvenire in due modi possibili

• Feedback diretto dal router

• Modifica di un bit in un pacchetto destinato all’host mittente effettuata dal router

È completamente inaccettabile perché il controllo non può essere della rete e quindi di un’entità

centralizzata, infatti potrebbero i router comunicare ad alcuni host che la rete è congestionata per

fornire più banda altri!

La soluzione va fatta ai bordi della rete.

Il mittente non riceve nessuna segnalazione, ma sulla base dei ritardi e delle perdite dei pacchetti

decide come comportarsi riguardo la ritrasmissione.

L’approccio va fatto per tentativi, si inizia a trasmettere fino a quando non si notano ritrasmissioni.

La finestra di congestione aumenta fino a che il mittente si accorge di aver perso un pacchetto (o

arrivano i 3 ACK duplicati o scade il timeout).

Gli ack duplicati indicano una congestione temporanea della rete, lo scadere dei timeout indica

una perdita dei pacchetti.

Il mittente dideve autoregolare trasmettendo alla velocità massima possibile in base alle

condizioni della rete.

Per testare le condizioni della rete TCP utilizza i timeout e gli ack.

In particolare quando riceve un sintomo di un evento di perdita (timeout o ack duplicati) riduce la

finestra di congestione e quindi diminuisce il rate dei dati inviati perché si rende conto che la rete

è congestionata, viceversa quando riceve ack non duplicati aumenta la finestra di congestione e

quindi il rate dei dati inviati.

Il controllo di congestione di TCP ha due fasi

• Partenza lenta (Slow Start)

Aumento fino ad una certa soglia

o

• Congestion avoidance (AIMD)

Incremento additivo

o Decremento moltiplicativo

o

Ad ogni RTT si ha una crescita esponenziale della trasmissione fino a che non si raggiunge la soglia.

Quando ci si avvicina alla soglia la crescita trasmissiva è lineare, appena il mittente si rende conto

di un ritardo dimezza la soglia (considerando il valore della finestra che ha raggiunto) e riparte da

zero (SS).

Nel caso del timeout TCP Tahoe e Reno si comportano allo stesso modo, nel caso dei 3 ACK

duplicati Reno non riparte da 0 con lo SS ma parte dal valore dimezzato della soglia raggiunta

sempre con AIMD.

In particolare le due versioni di TCP sono identiche se consideriamo il timeout come evento di

interruzione per SS, mentre la seconda ha anche una terza fase detta fast recovery.

TCP Tahoe quando riceve ack duplicati come sintomo di congestione si comporta come con il

timeout, mentre TCP Reno riparte dal valore della soglia invece che da zero, partendo però già in

modalità congestion avoidance e non con slow start.

Per entrambi la fase di slow start procede fino ad una soglia e in caso di timeout il valore della

soglia viene messo pari alla metà del valore in cui hanno rilevato un timeout.

27 nov. 18

Sicurezza nella comunicazione in rete.

La sicurezza della comunicazione coinvolge 4 aspetti fondamentali

1) Riservatezza

a. Nessuno senza autorizzazione può andare a leggere e comprenderne il contenuto

del messaggio

b. Si utilizzano delle tecniche crittografiche

c. Il mittente effettua una cifratura

d. Il destinatario mediante un segreto condiviso e conoscendo un modo può decifrare

il messaggio

2) Integrità dei messaggi

a. I messaggi devono arrivare integri al destinatario, non nel senso degli errori

introdotti dalla rete, nel senso che non ci deve essere una terza parte che possa

modificare la semantica del messaggio (arriva un messaggio diverso al destinatario)

3) Autenticazione

a. Mittente e destinatario si scambiano l’identità

b. Si deve essere certi dell’identità dell’altra parte

4) Accessibilità e disponibilità dei servizi

a. I servizi in rete devono essere protetti da eventuali attacchi (es. DoS)

b. Una terza parte potrebbe interrompere il servizio offerto dal destinatario

Le entità possono essere sia due host che due router.

Gli attacchi che trudy può effettuare sul canale per rendere la comunicazione tra alice e bob non

sicura sono diversi

• Eavesdropping

Intercettare i messaggi scambiati

o Inserire dei messaggi fasulli nel flusso della comunicazione

o Se sono cifrati non si riesce a comprendere il risultato

o Se non si conosce la chiave questi messaggi non vengono compresi

o Se i messaggi sono inviati in chiaro non posso capire chi sia effettivamente il

o mittente

• Spoofing Inviare dei messaggi con il campo source address fasullo (si finge un’altra

o controparte)

• Hijacking MIM

o Intercettare i messaggi inviati da alice a bob andando poi a compiere operazioni

o malevole

• DoS Impedire la comunicazione tra alice e bob andando a sovraccaricare le loro risorse

o

Le tecniche di crittografia si basano sulla tecnica di cifrare un messaggio in chiaro, combinare

(algoritmo) questo messaggio con una chiave (segreto).

Gli algoritmi di cifratura sono pubblici.

Il messaggio cifrato non deve essere leggibile senza chiave.

La chiave può essere

• A chiave Simmetrica

Alice e bob condividono la stessa chiave

o Si parla di segreto condiviso

o

• A chiave Asimmetrica o a chiave Pubblica

Il messaggio viene cifrato attraverso una chiave pubblica

o Viene decifrato mediante una chiave privata

o

La tecnica di crittografia simmetrica presenta numerosi problemi tra cui “come fanno alice e bob a

scambiarsi la chiave?”

Per cifrare o decifrare il messaggio possono essere utilizzati algoritmi differenti, questo diminuisce

la probabilità che trudy riesca a leggere il messaggio.

Il messaggio viene inviato sulla rete cifrato mediante un algoritmo con la chiave KAB, il messaggio

deve essere leggibile mediante l’algoritmo di decifratura e la chiave KAB.

Se i due algoritmi coincidono (di encryption e decryption) ovviamente funziona.

Il problema è come si scambiano la chiave alice e bob in modo sicuro? È banale accorgersi che se

una terza parte legge la chiave mediante un attacco di hijacking riesce a leggere i messaggi ed

eventualmente modificarli ecc… e quindi lo sforzo per cifrare il messaggio è stato inutile!

La tecnica funziona nel seguente modo

I cifrari a blocchi sono simili ai cifrari monoalfabetici solo che lavorano su blocchi del messaggio

invece che sull’in