Re: [ml] icmp e checksum

billiejoex wrote:

> Parto con le domande.
vai

> 1 - in un pacchetto icmp generico come può essere quello generato da un
> ping, quanti checksum ci sono in tutto? Solo quello applicato a icmp o 
> anche
> altri applicati ai protocolli inferiori ovvero ip ed ethernet?

icmp = si
ip = si
ethernet = no

> 2- nel caso di ip ed ethernet il checksum può essere applicato al solo
> header in quanto il payload è rappresentato dall'header del protocollo
> immediatamente superiore? E' esatto?
In ip e icmp checksum = header checksum. x ethernet vedi sopra.

> 3 - la funzione di checksum di icmp si riferisce al solo header icmp o 
> anche
> al suo payload?

vedi sopra

> 4 - cosa accade se il checksum di A spedito a B non collima? Se il 
> checksum
> controlla l'integrità del dato chi controlla checksum?

?????????
La checksum E' il controllo.
Quando si riceve un pacchetto si calcola la checksum (ovviamente 
escludendo dall'header la checksum stessa). Se il risultato collima con 
la checksum dell'header allora il pacchetto non e' corrotto (o almento 
e' improbabile che lo sia) viceversa si suppone che sia corrotto e lo 
stack di rete lo cestina.

> 5 - conoscendo natura e algoritmo del checksum si potrebbe affermare 
> che il
> meccanismo sia infallibile? Può capitare che un insieme di dati venga 
> preso
> per corrotto quando non lo è e vice versa?

Certo. Se ti leggi l'algoritmo per il calcolo della checksum capirai che 
e' un'operazione molto semplice, assolutamente non sicura e non 
affidabile. E' poco piu' che una somma in colonna :). Non per nulla MAI 
ci si affida a questa ck in applicazioni di sicurezza. Se vuoi avere 
affidabilita' devi usare metodi crittografici a bassa probabilita' di 
collisione.

> 6 - Nel caso in cui i dati del pacchetto siano corretti e la parte "mal
> trasmessa" sia proprio il valore di checksum cosa accade?

Che il controllo sulla ck banalmente fallisce.

> 7 - In caso di checksum errato come gestisce la cosa icmp? Manda 
> indietro un
> pacchetto di  avviso? Se si di che tipo?

Questo e' piu' difficile... A naso direi che lo stack lo cestina senza 
dire nulla, ma mi riservo di controllare e di rispondere con certezza.

> 8 - la differenza tra checksum e hash riguarda la sola accuratezza di
> verifica? A leggere le varie definizioni di checksum non mi è parsa 
> lampante
> alcuna differenza tra hash e checksum a parte quella sopra menzionata.
Sono due metodi diversi, con algoritmi diversi. Con la ck la 
probabilita' che 2 messaggi generino la stessa ck e' alta, con l'hash 
invece e' molto basso.

> Due domande riguardo ICMP generico:
>
> 9 - ho effettuato delle prove provando a pingare differenti host con
> pacchetti ICMP aventi buffer variabili abbastanza grandi (1000, 5000, 
> 10000,
> 20000 bytes e oltre) e ho notato che ogni host si comporta in modo
> differente. Ad esempio google risponde solo a pings con buffer < 1500 
> bytes,
> altri hosts arrivano a rispondere anche a ping da 10000 bytes.  Tale 
> blocco
> chi lo applica? Un eventuale firewall posto sulla macchina remota o il 
> kernel della
> macchina stessa?
A priori non lo puoi dire con certezza. In generale e' lo stack del 
S.O., ma puo' essere fatto anche da un fw.

> 10 - sparsi in giro per internet posso incappare in determinati 
> routers che
> negano il passaggio di pacchetti icmp aventi un buffer superiore a un 
> certo
> numero di bytes?  Esiste uno "standard internet" secondo cui un icmp non
> debba superare una certa soglia?
Lo "standard internet" a cui fare riferimento sono i relativi RFC, ma 
non mi risulta che ci sia un limite per pacchetto. In generale (forse 
anche memori di un vecchio attacco chiamato "ping of death") non si 
giustifica un payload molto grosso in pacchetti di echo request, quindi 
si sceglie di scartarli. Devi anche tenere conto che aumentando oltre 
1500 la dimensione del pacchetto icmp esso verra' frammentato da IP, 
quindi giungera' a destinazione come un burst di pacchetti frammentati e 
non come 1 pacchetto singolo. Il fatto potrebbe essere li' e non nella 
dimensione in se'. Questi esperimenti e' opportuno condurli in "campo 
amico" per poter esaminare le varie parti, sia mittente che destinatario.

ahahah:~# ping -s 65000 -c 3 NETBSD
PING NETBSD (x.x.x.x) 65000(65028) bytes of data.
65008 bytes from NETBSD (x.x.x.x): icmp_seq=1 ttl=255 time=12.4 ms
65008 bytes from NETBSD (x.x.x.x): icmp_seq=2 ttl=255 time=12.3 ms
65008 bytes from NETBSD (x.x.x.x): icmp_seq=3 ttl=255 time=12.4 ms

--- NETBSD ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2001ms
rtt min/avg/max/mdev = 12.399/12.411/12.423/0.091 ms

ahahah:~# ping -s 65000 -c 3 LINUX
PING LINUX (x.x.x.x) 65000(65028) bytes of data.

--- LINUX ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2060ms

ahahah:~# ping -s 65000 -c 3 WINDOWS2000
PING WINDOWS2000 (x.x.x.x) 65000(65028) bytes of data.

--- WINDOWS2000 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2001ms

Come vedi si comportano diversamente.



Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia S.p.A.

====================================================================
CONFIDENTIALITY NOTICE
This message and its attachments are addressed solely to the persons
above and may contain confidential information. If you have received
the message in error, be informed that any use of the content hereof
is prohibited. Please return it immediately to the sender and delete
the message. Should you have any questions, please send an e_mail to 
MailAdmin@xxxxxxxxxx Thank you
====================================================================