Re: [ml] icmp e checksum

On Thursday 24 November 2005 02:38, billiejoex wrote:

> A questo punto, sapendo che i ckecksum si applicano a tutti e tre i
> protocolli, il discorso comincia a farsi complicato dato che devo gestire 3
> possibili errori + 1 rappresentato dal payload di icmp. Uhm, uhm, uhm...
> Cosa mi converrebbe fare? Creare manualmente una funzione di checksum
> applicata all'intero pacchetto (eth+ip+icmp) ed integrarla nel payload di
> icmp?
> Non sapendo come si comportano i 2 strati in caso di checksum pervenuto
> errato mi pare la soluzione più sensata, anche se non sono sicuro sia
> fattibile nella pratica.
> E' possibile disabilitare i flag inerenti il checksum di ethernet ed ip? So
> che con ICMP è possibile farlo.
> [...]
> ICMP non garantisce alcuna sicurezza di integrità dei dati, è vero, ma si
> potrebbe
> sempre implementarla manualmente...
> Per creare una spartana forma di controllo sul recapito, ad esempio, ho
> sfruttato con successo i pacchetti di ritorno generati da un ICMP_ECHO. Il
> problema rimane quindi solamente uno e apparentemente, almeno per ora, mi
> pare risolvibile, mediante qualche sotterfugio.

Sempre dal RFC792:

"The checksum is the 16-bit ones's complement of the one's complement sum of 
the ICMP message starting with the ICMP Type (che è il primo campo --nota 
mia). [...]"

Il checksum ICMP è quindi il checksum dell'intero messaggio!

Se vuoi implementare il tuo protocollo di trasferimento file con ICMP di tipo 
8 e 0 (echo request/reply), potresti farlo affidando l'integrità dei dati nel 
payload (per quanto possibile) al normale campo checksum ICMP.
In pratica, se ho capito bene, tu vorresti sfruttare il ritorno di un ICMP 
reply per assicurarti che:
	1. il destinatario ha ricevuto il messaggio;
	2. i dati nel payload ricevuto erano integri.

Qui sorgono alcuni problemi. Dovresti comunque, a meno che tu non voglia 
addentrarti nelle amenità di un protocollo a finestra scorrevole (quale ad 
esempio è il TCP), realizzare quello che viene definito un protocollo 
"simplex per canale rumoroso":
il mittente prepara il pacchetto, aggiunge un numero di sequenza, aggiunge un 
controllo per la rilevazione degli errori (nel caso tuo un checksum) e si 
mette in attesa, con timeout, di un ack da parte del destinatario. L'ack, 
ovviamente deve riportare il numero di sequenza.
Se l'ack arriva, ed è corretto, allora il mittente può passare al prossimo 
pacchetto, altrimenti ristrasmette lo stesso pacchetto.
Mi sento di consigliarti questo approccio anche perchè cosi' non devi gestire 
il riordino dei dati.
Il numero di sequenza ce l'hai già negli ICMP echo. In realtà hai anche un bel 
identificatore che potresti usare per realizzare una sorta di protocollo 
connesso (siamo lontani dal TCP, però potrebbe funzionare allo scopo).

Arriviamo ora al punto dolente: la frammentazione. :-O
Non hai un meccanismo che ti permetta di ridurre, a ragion veduta, la 
dimensione dei pacchetti: TCP usa il pathMTU discovery, tecnica che fa uso 
dei pacchetti ICMP "Destination Unreachable / Fragmentation needed and DF 
set". Tu non puoi usare lo stesso sistema nemmeno se metti a 1 il campo DF di 
IP: non avrai mai un ICMP per un altro ICMP :-(

Inoltre ti consiglio di evitare comunque la frammentazione mettendo il campo 
DF di IP a 1 per sfuggire ai i problemi dovuti alle regole di qualche fw 
(btw: prega affinchè il fw non droppi gli echo :-S ). Tuttavia, dovesse 
succedere che il pacchetto sia troppo grande per qualche link, rischi 
comunque che il destinatario non lo veda mai arrivare.

Se posso consigliarti ancora, direi che dovresti prevedere comunque misure 
cautelative perchè rischi che il protocollo vada in loop tentando di 
ritrasmettere lo stesso pacchetto :-P
Io, molto semplicemente, metterei un controllo sui pacchetti ritrasmessi come 
segue:
parti da 1500 byte e, se dopo un tot di ritrasmissioni non ricevi l'ack, 
scendi con la dimensione e rimani su quella fino alla fine o fino al prossimo 
intoppo. 
Comunque, se non ricevi un ack entro un tot di ritrasmissioni o, 
equivalentemente, se la dimensione ti scende troppo, esci con un fallimento.
Se proprio vuoi "fa' er sofisticato" (come se dice dalle parti mia :-P) 
periodicamente puoi provare a ritentare trasmissioni con dimensione maggiore 
per compensare quelle situazioni nelle quali i problemi di ricezione non 
erano dovuti alla frammentazione.

Spero di esseti stato utile. Fammi sapere se riesci ad implementare la cosa e 
se ti serve ancora aiuto :-)  
Non so se il thread è off-topic  quindi, se credi, contattami pure in privato.
(anche se in sostanza stiamo parlando di un covert-channel... se poi 
"offuscassi" i dati... sarebbe fichissimo)

Però ti prego: falla open 'sta cosa che voglio divertirmici anche io quando 
l'hai finita :D

Sciuazzz,
   Can't dig that daddy.