Chi frammenta, chi ricostruisce TCP o IP?
Giovanni Neglia
Mi si dice che i router possono frammentare i pacchetti IP di
dimensione maggiore a quella massima prevista dalla rete e a tal fine
sono previsti nel preambolo IP dei campi come Fragment offset. Il
livello rete del ricevente provvede poi a riassemblare il pacchetto
originario e a fornirlo al livello trasporto.
Fin qui tutto bene, solo un dubbio: anche se si perde un frammento va
ritrasmesso l'intero pacchetto IP originario, no?
Al momento di parlare del protocollo TCP è scritto che un router, nel
caso indicato sopra, al momento della frammentazione crea nuovi
preamboli IP e *nuovi preamboli TCP*. Ma un router (livello 3) non
dovrebbe essere all'oscuro di TCP (livello 4)? E' chiaro che volendo
può ricostruire il preambolo aggiornando in base alla frammentazione
il numero di sequenza e ricopiando tutti gli altri campi, ma non si
tratta di una cosa *sporca*?
Se le cose stanno effettivamente così , non sarà che il livello rete
del ricevente si limita ad inoltrare il contenuto dei nuovi frammenti
IP al livello trasporto (visto che ciascuno ha la struttura di un
pacchetto TCP) lasciandogli il compito della ricostruzione? In tal
caso il campo fragment offset servirebbe semplicemente a creare da un
unico pacchetto IP pacchetti IP con differente numerazione. Il livello
trasporto del mittente dovrebbe inoltre essere in grado di rinviare
pezzi arbitrariamente collocati all'interno dei pacchetti TCP.
Ringrazio fin da adesso quanti risponderanno.
Ciao,
Giovanni.
Giovanni Neglia
gne...@ZZZtiscalinet.it
per rispondere rimuovere ZZZ dall'indirizzo
Massimo Baschieri
<3991c6f4...@news.tiscalinet.it>...
>Sto studiando questi protocolli da Tanenbaum - Reti di Computer.
>Mi si dice che i router possono frammentare i pacchetti IP di
>dimensione maggiore a quella massima prevista dalla rete e a tal fine
>sono previsti nel preambolo IP dei campi come Fragment offset. Il
>livello rete del ricevente provvede poi a riassemblare il pacchetto
>originario e a fornirlo al livello trasporto.
>Fin qui tutto bene, solo un dubbio: anche se si perde un frammento va
>ritrasmesso l'intero pacchetto IP originario, no?
IP, essendo un protocollo cosidetto "unreliable" non ritrasmette nulla di
sua iniziativa, si limita ad incapsulare un pacchetto TCP in un datagram ed
a spedirlo in rete.
E' TCP che ha il compito di rilevare eventuali errori durante la
ricomposizione dei pacchetti e di richiederne la trasmissione, per cui, come
minimo, viene ritrasmesso un pacchetto TCP per volta, il che potrebbe voler
dire più pacchetti IP (se viene superato l'MTU).
>
>Al momento di parlare del protocollo TCP è scritto che un router, nel
>caso indicato sopra, al momento della frammentazione crea nuovi
>preamboli IP e *nuovi preamboli TCP*. Ma un router (livello 3) non
>dovrebbe essere all'oscuro di TCP (livello 4)? E' chiaro che volendo
>può ricostruire il preambolo aggiornando in base alla frammentazione
>il numero di sequenza e ricopiando tutti gli altri campi, ma non si
>tratta di una cosa *sporca*?
Esistono casi in cui i routers modificano gli headers TCP dei pacchetti, uno
di questi è quando viene attivato il NAT, ma non vedo una relazione tra
questi casi e la necessità di frammentare i pacchetti, se occorre
frammentare un pacchetto i routers lo fanno a livello 3, lavoro per cui sono
deputati e che sanno fare come nessun altro.
>Se le cose stanno effettivamente così , non sarà che il livello rete
>del ricevente si limita ad inoltrare il contenuto dei nuovi frammenti
>IP al livello trasporto (visto che ciascuno ha la struttura di un
>pacchetto TCP) lasciandogli il compito della ricostruzione? In tal
>caso il campo fragment offset servirebbe semplicemente a creare da un
>unico pacchetto IP pacchetti IP con differente numerazione. Il livello
>trasporto del mittente dovrebbe inoltre essere in grado di rinviare
>pezzi arbitrariamente collocati all'interno dei pacchetti TCP.
>
In effetti il compito di frammentazione e ricomposizione dei dati, con
relativa verifica ed eventuale correzione (ritrasmissione) è affidato al
TCP, non ad IP che si occupa semplicemente dell'indirizzamento dei pacchetti
verso la giusta destinazione.
La tua analisi è quindi corretta, tranne per il fatto che se un pacchetto
TCP viene spezzato in più datagram IP (per motivi di MTU) ed uno di questi
viene perso, IP scarterà l'intero pacchetto che non è riuscito a completare
e TCP, non avendolo mai ricevuto, ne richiederà la ritrasmissione (con tutti
i suoi frammenti).
Ciao,
Massimo.
Midori (no spam allowed)
> di questi è quando viene attivato il NAT
Il NAT dovrebbe agire solo sulle entry Source e Destination (IP e port) dello
header IP. O no?
Il NAT puro e semplice modifica in uscita il source IP:port ed in ingresso il
destination IP:port. Cos'altro fa?
Il NAT "sporco" cerca di far funzionare protocolli non NAT fiendly (tipo FTP)
modificando la parte DATI del pacchetto (come il MASQ di linux ed alcuni NAT
router)
In ogni caso, l'IP ha due scopi fondamentali:
Permettere l'instradamento dei pacchetti e gestire in maniera trasparente la
frammentazione (e' detto tra le prime righe del RFC dell'IP).
> In effetti il compito di frammentazione e ricomposizione dei dati, con
> relativa verifica ed eventuale correzione (ritrasmissione) è affidato al
> TCP, non ad IP che si occupa semplicemente dell'indirizzamento dei pacchetti
> verso la giusta destinazione.
Mi permetto di contraddirti (pardon :) )
L'IP si occupa anche di gestire la frammentazione dei pacchetti. Allego una
parte del RFC 791 che riguarda questo fatto.
Volendo riassumerlo: l'IP gestisce la frammentazione e deframmentazione dei
Datagram se necessario.
Il pacchetto viene spezzato in tanti frammenti, ognuno dei quali coniene anche
il numero di sequenza, tranne l'ultimo che contiene anche un flag di Ultimo
Frammento.
Tutto cio' avviene in maniera trasparente; il contenuto del Datagram non ha
nessuna importanza per l'IP.
- Fragmentation
Fragmentation of an internet datagram is necessary when it
originates in a local net that allows a large packet size and must
traverse a local net that limits packets to a smaller size to reach
its destination.
An internet datagram can be marked "don't fragment." Any internet
datagram so marked is not to be internet fragmented under any
circumstances. If internet datagram marked don't fragment cannot be
delivered to its destination without fragmenting it, it is to be
discarded instead.
Fragmentation, transmission and reassembly across a local network
which is invisible to the internet protocol module is called
intranet fragmentation and may be used [6].
The internet fragmentation and reassembly procedure needs to be able
to break a datagram into an almost arbitrary number of pieces that
can be later reassembled. The receiver of the fragments uses the
identification field to ensure that fragments of different datagrams
are not mixed. The fragment offset field tells the receiver the
position of a fragment in the original datagram. The fragment
offset and length determine the portion of the original datagram
covered by this fragment. The more-fragments flag indicates (by
being reset) the last fragment. These fields provide sufficient
information to reassemble datagrams.
The identification field is used to distinguish the fragments of one
datagram from those of another. The originating protocol module of
an internet datagram sets the identification field to a value that
must be unique for that source-destination pair and protocol for the
time the datagram will be active in the internet system. The
originating protocol module of a complete datagram sets the
more-fragments flag to zero and the fragment offset to zero.
To fragment a long internet datagram, an internet protocol module
(for example, in a gateway), creates two new internet datagrams and
copies the contents of the internet header fields from the long
datagram into both new internet headers. The data of the long
datagram is divided into two portions on a 8 octet (64 bit) boundary
(the second portion might not be an integral multiple of 8 octets,
but the first must be). Call the number of 8 octet blocks in the
first portion NFB (for Number of Fragment Blocks). The first
portion of the data is placed in the first new internet datagram,
and the total length field is set to the length of the first
[Page 8]
September 1981
Internet Protocol
Overview
datagram. The more-fragments flag is set to one. The second
portion of the data is placed in the second new internet datagram,
and the total length field is set to the length of the second
datagram. The more-fragments flag carries the same value as the
long datagram. The fragment offset field of the second new internet
datagram is set to the value of that field in the long datagram plus
NFB.
This procedure can be generalized for an n-way split, rather than
the two-way split described.
To assemble the fragments of an internet datagram, an internet
protocol module (for example at a destination host) combines
internet datagrams that all have the same value for the four fields:
identification, source, destination, and protocol. The combination
is done by placing the data portion of each fragment in the relative
position indicated by the fragment offset in that fragment's
internet header. The first fragment will have the fragment offset
zero, and the last fragment will have the more-fragments flag reset
to zero.
--
Ciauz!
midorichan
////////////////////////////////////
... Erroneus Error. Nothing Wrong.
Massimo Baschieri
<3995E728...@paipai.net>...
>Il NAT dovrebbe agire solo sulle entry Source e Destination (IP e port)
dello
>header IP. O no?
>Il NAT puro e semplice modifica in uscita il source IP:port ed in ingresso
il
>destination IP:port. Cos'altro fa?
>Il NAT "sporco" cerca di far funzionare protocolli non NAT fiendly (tipo
FTP)
>modificando la parte DATI del pacchetto (come il MASQ di linux ed alcuni
NAT
>router)
>
Guarda che quando parli di source IP:port e destination IP:port ti riferisci
proprio delle porte TCP il cui riferimento è contenuto guardacaso
nell'header TCP, non in quello IP (e che quindi deve essere aperto per la
modifica).
Si tratta di una implementazione di NAT chiamata anche PAT (port address
translation) che serve quando hai un solo indirizzo IP valido verso
internet.
.......
>Mi permetto di contraddirti (pardon :) )
>L'IP si occupa anche di gestire la frammentazione dei pacchetti. Allego una
>parte del RFC 791 che riguarda questo fatto.
>Volendo riassumerlo: l'IP gestisce la frammentazione e deframmentazione dei
>Datagram se necessario.
>Il pacchetto viene spezzato in tanti frammenti, ognuno dei quali coniene
anche
>il numero di sequenza, tranne l'ultimo che contiene anche un flag di Ultimo
>Frammento.
>Tutto cio' avviene in maniera trasparente; il contenuto del Datagram non ha
>nessuna importanza per l'IP.
>
>
Non mi sembra che tu mi stia contraddicendo, è già stato detto più volte che
IP può frammentare i pacchetti, la differenza è che TCP lo fa di mestiere ed
in maniera affidabile (essendo un protocollo connesso e "reliable") mentre
IP lo fa solo se costretto per motivi di MTU (maximum trasmission unit, per
la cronaca) ed in maniera meno affidabile, essendo un protocollo non
connesso ed "unreliable".
Se nel percorso dei dati non esiste nessun dispositivo con un MTU più
piccolo della dimensione del pacchetto, IP non si sogna nemmeno di
frammentarlo.
Tra l'altro la frammentazione di un pacchetto da parte di IP è frutto spesso
di qualche errore, dato che le recenti implementazioni di IP sfruttano una
prestazione chiamata "mtu discovery" proprio per scoprire qual'è la
dimensione massima dei pacchetti da trasmettere in modo da evirare che IP di
ricorra alla frammentazione, cosa che introduce ritardi, occupa preziose
risorse nei routers e, come detto prima, è meno affidabile di quella operata
dal TCP.
In aggiunta, la frammentazione dei pacchetti da parte di IP può anche avere
degli effetti collaterali, mi spiego meglio:
l'header IP contiene, nel campo flag, un bit chiamato DF (don't fragment)
che se settato ad 1 impedisce la frammentazione del pacchetto (ad esempio
per motivi di QoS); ora, se un pacchetto con il bit DF settato deve
attraversare un dispositivo con una MTU più piccola della dimensione del
pacchetto viene scartato in quanto non passa e non è nemmeno possibile
frammentarlo.
Questa è un'altra ragione di esistere di mtu discovery e del fatto che, se
pur possibile, la frammentazione da parte di IP viene utilizzata solo se
indispensabile.
Ovviamente la soluzione a tutti questi problemi è che TCP "confezioni" per
IP dei pacchetti già adattati alla MTU più piccola tra quelle dei
dispositivi che il pacchetto stesso deve attraversare.
Ciao,
Massimo.
Midori (no spam allowed)
> proprio delle porte TCP il cui riferimento è contenuto guardacaso
> nell'header TCP, non in quello IP (e che quindi deve essere aperto per la
> modifica).
E' vero, ho preso una svista enorme!
Ai fini dell'IP la porta non serve ad un tubo.
Grazie per la spiegazione.
ciau ciau
midorichan
Giovanni Neglia
wrote:
>Giovanni Neglia ha scritto nel messaggio
><3991c6f4...@news.tiscalinet.it>...
>>Al momento di parlare del protocollo TCP è scritto che un router, nel
>>caso indicato sopra, al momento della frammentazione crea nuovi
>>preamboli IP e *nuovi preamboli TCP*. Ma un router (livello 3) non
>>dovrebbe essere all'oscuro di TCP (livello 4)? E' chiaro che volendo
>>può ricostruire il preambolo aggiornando in base alla frammentazione
>>il numero di sequenza e ricopiando tutti gli altri campi, ma non si
>>tratta di una cosa *sporca*?
>Esistono casi in cui i routers modificano gli headers TCP dei pacchetti, uno
>di questi è quando viene attivato il NAT, ma non vedo una relazione tra
>questi casi e la necessità di frammentare i pacchetti, se occorre
>frammentare un pacchetto i routers lo fanno a livello 3, lavoro per cui sono
>deputati e che sanno fare come nessun altro.
Perdona l'ignoranza, ma cos'è il NAT?
>In effetti il compito di frammentazione e ricomposizione dei dati, con
>relativa verifica ed eventuale correzione (ritrasmissione) è affidato al
>TCP, non ad IP che si occupa semplicemente dell'indirizzamento dei pacchetti
>verso la giusta destinazione.
>La tua analisi è quindi corretta, tranne per il fatto che se un pacchetto
>TCP viene spezzato in più datagram IP (per motivi di MTU) ed uno di questi
>viene perso, IP scarterà l'intero pacchetto che non è riuscito a completare
>e TCP, non avendolo mai ricevuto, ne richiederà la ritrasmissione (con tutti
>i suoi frammenti).
In definitiva: TCP passa un pacchetto-TCP a IP, IP lo frammenta, per
esempio in 10 pacchetti-IP. Al ricevente arrivano a causa della
frammentazione più pacchetti-IP diciamo 20. Il livello cerca di
ricostruire ciascuno dei 10 pacchetti-IP, ma non passa a TCP del
ricevente il pacchetto TCP intero, ma direttamente i pacchetti
ricostruiti. Se ricostruisce 9 pacchetti-IP e gli mancano pezzi per
ricostruire il 10-mo, scarta i pezzi di questo e passa i 9 pacchetti
completi al TCP. Sarà poi compito di questo sfruttando gli
identificatori basati sul numero di byte richiedere, o meglio non
confermare i byte persi (conferma fino all'ultimo byte correttamente
ricevuto).
Giusto?
Si tratta comunque di un comportamento non conforme al modello a
strati, secondo il quale IP dovrebbe passare a TCP l'intero pacchetto
o nulla. Ma non è mia intenzione sputare sui pacchetti che invio, è
solo per capire. ;-)
In ogni caso un dubbio rimane: perché i router quando frammentano i
pacchetti IP vanno ad aggiornare il preambolo TCP (almeno a quanto
dice il Tanenbaum)? Il pacchetto può essere in ogni caso riassemblato
sulla base di fragment offset, quindi questa sembra un'informazione
ridondante. Potrebbe servire solo al livello TCP se volesse recuperare
qualche altro byte (ma questo sopra l'abbiamo escluso).
>Ciao,
> Massimo.
Corallo Giuseppe
Quando mi connetto, c'è ZoneAlarm che è attivo e durante la connessione mi
sono arrivati una miriade di attacchi e mi spunta il seguente messaggio
ZoneAlarm
The firewall has blocked Internet access to your computer (TCP Port XXX)
from a1156.g.akamai.net (194.98.93.245) (HTTP).
Scusate la mia ignoranza nell'argomento ma ho capito che ci sono stati una
serie di attacchi e vorrei sapere come si può rimediare a questo e se c'è
pericolo per il mio sistema.
Grazie anticipatamente e a presto!
mailto:cora...@inwind.it
Massimo Baschieri
Giovanni Neglia ha scritto nel messaggio
>Perdona l'ignoranza, ma cos'è il NAT?
E' il sistema più utilizzato per l'accesso ad internet di una rete locale.
Siccome di solito in una rete locale usa i cosidetti indirizzi privati, che
non possono essere "ruotati" su internet (oltre al fatto che acquistare
indirizzi pubblici costa troppo, quando te li danno) occorre un trucco per
veicolare gli accessi ad internet di tutta la rete in un unico indirizzo
pubblico (che può essere statico, quindi acquistato, oppure dinamico, quindi
di proprietà del provider).
In pratica tramite NAT puoi collegare tutti i PC che vuoi ad internet
acquistando un unico indirizzo pubblico, questo permette un notevole
risparmio di soldi e di indirizzi internet, che a quanto pare stanno
scarseggiando.
>In definitiva: TCP passa un pacchetto-TCP a IP, IP lo frammenta, per
>esempio in 10 pacchetti-IP. Al ricevente arrivano a causa della
>frammentazione più pacchetti-IP diciamo 20. Il livello cerca di
>ricostruire ciascuno dei 10 pacchetti-IP, ma non passa a TCP del
>ricevente il pacchetto TCP intero, ma direttamente i pacchetti
>ricostruiti. Se ricostruisce 9 pacchetti-IP e gli mancano pezzi per
>ricostruire il 10-mo, scarta i pezzi di questo e passa i 9 pacchetti
>completi al TCP. Sarà poi compito di questo sfruttando gli
>identificatori basati sul numero di byte richiedere, o meglio non
>confermare i byte persi (conferma fino all'ultimo byte correttamente
>ricevuto).
>Giusto?
Non proprio.
Normalmente TCP passa ad IP pacchetti di dimensioni sufficientemente piccole
da non dover essere frammentati (ad esempio, in una rete ethernet, meno di
1500 bytes), in quanto già lui ha dovuto frammentare i dati che gli sono
stati passati dai livelli superiori (potrebbe trattarsi benissimo di un file
trasfer di alcuni MB) e quindi non è saggio prevedere a priori due fasi di
frammentazione.
Nei casi in cui IP debba frammentare i pacchetti (TCP non sempre riesce a
sapere, soprattutto in caso di percorsi tortuosi, la dimensione minima dei
pacchetti in tutti i salti) li spezza in un certo numero di frammenti e li
ricostruisce dalla parte opposta; in questo caso, se un frammento non viene
ricevuto, o non passa il CRC, IP scarta tutti i frammenti ed aspetta che
TCP, una volta resosi conto che il pacchetto non è mai arrivato, gli invii
di nuovo lo stesso pacchetto per la trasmissione.
Se ci pensi è corretto, TCP non se ne farebbe di nulla di pacchetti
incompleti che non saprebbe come gestire, tanto vale non inviare nulla ed
aspettare che il pacchetto "ritorni" sperando in una miglior sorte.
>In ogni caso un dubbio rimane: perché i router quando frammentano i
>pacchetti IP vanno ad aggiornare il preambolo TCP (almeno a quanto
>dice il Tanenbaum)? Il pacchetto può essere in ogni caso riassemblato
>sulla base di fragment offset, quindi questa sembra un'informazione
>ridondante. Potrebbe servire solo al livello TCP se volesse recuperare
>qualche altro byte (ma questo sopra l'abbiamo escluso).
>
Il Tanembaum sà senz'altro quello che dice, ma io non vedo nessuna relazione
tra il preambolo TCP e la frammentazione a livello IP, tanto più che il
preambolo TCP rimane all'interno del primo frammento IP, mentre tutti gli
altri frammenti conterranno dei dati incomprensibili per il TCP (sempre che
anche il primo possa essere considerato tale) e quindi i singoli frammenti
non hanno nessun valore per TCP; d'altra parte al termine del processo di
frammentazione/ricomposizione è obbligatorio ri-ottenere lo stesso pacchetto
TCP originale, se ne viene cambiata l'intestazione non sarà più tale.
La frammentazione IP è solo una tecnica, per cause di forza maggiore, che
permette ad IP di aggirare il problema delle diverse dimensioni dei
pacchetti permesse dai protocolli di livello inferiore, quindi rimane
imperativa la trasparenza verso i livelli superiori.
Ciao,
Massimo.
Giovanni Neglia
wrote:
>Nei casi in cui IP debba frammentare i pacchetti (TCP non sempre riesce a
>sapere, soprattutto in caso di percorsi tortuosi, la dimensione minima dei
>pacchetti in tutti i salti) li spezza in un certo numero di frammenti e li
>ricostruisce dalla parte opposta; in questo caso, se un frammento non viene
>ricevuto, o non passa il CRC, IP scarta tutti i frammenti ed aspetta che
>TCP, una volta resosi conto che il pacchetto non è mai arrivato, gli invii
>di nuovo lo stesso pacchetto per la trasmissione.
>Se ci pensi è corretto, TCP non se ne farebbe di nulla di pacchetti
>incompleti che non saprebbe come gestire, tanto vale non inviare nulla ed
>aspettare che il pacchetto "ritorni" sperando in una miglior sorte.
Per me questo e' perfetto.
>>In ogni caso un dubbio rimane: perché i router quando frammentano i
>>pacchetti IP vanno ad aggiornare il preambolo TCP (almeno a quanto
>>dice il Tanenbaum)? Il pacchetto può essere in ogni caso riassemblato
>>sulla base di fragment offset, quindi questa sembra un'informazione
>>ridondante. Potrebbe servire solo al livello TCP se volesse recuperare
>>qualche altro byte (ma questo sopra l'abbiamo escluso).
>>
>Il Tanembaum sà senz'altro quello che dice, ma io non vedo nessuna relazione
>tra il preambolo TCP e la frammentazione a livello IP, tanto più che il
>preambolo TCP rimane all'interno del primo frammento IP, mentre tutti gli
>altri frammenti conterranno dei dati incomprensibili per il TCP (sempre che
>anche il primo possa essere considerato tale) e quindi i singoli frammenti
>non hanno nessun valore per TCP;
Questo e' il punto. Il Tanenbaum afferma "se un segmentoarriva a una
rete in cui MTU e' inferiore alla dimensione del segmento, *il router*
al confine frammenta il segmento in due o piu' segmenti piu' piccoli.
*Ogni* nuovo segmento ottiene il proprio preambolo IP e *TCP*..."
In alcune risposte che mi sono arrivate su altri ng si diceva che e'
una "scorrettezza", dal punto di vista formale, di TCP-IP, in cui TCP
e IP sanno troppo l'uno dell'altro.
> d'altra parte al termine del processo di
>frammentazione/ricomposizione è obbligatorio ri-ottenere lo stesso pacchetto
>TCP originale, se ne viene cambiata l'intestazione non sarà più tale.
>La frammentazione IP è solo una tecnica, per cause di forza maggiore, che
>permette ad IP di aggirare il problema delle diverse dimensioni dei
>pacchetti permesse dai protocolli di livello inferiore, quindi rimane
>imperativa la trasparenza verso i livelli superiori.
>
>Ciao,
> Massimo.
>
>
Ciao,
Massimo Baschieri
Giovanni Neglia ha scritto nel messaggio >
>Questo e' il punto. Il Tanenbaum afferma "se un segmentoarriva a una
>rete in cui MTU e' inferiore alla dimensione del segmento, *il router*
>al confine frammenta il segmento in due o piu' segmenti piu' piccoli.
>*Ogni* nuovo segmento ottiene il proprio preambolo IP e *TCP*..."
>
>In alcune risposte che mi sono arrivate su altri ng si diceva che e'
>una "scorrettezza", dal punto di vista formale, di TCP-IP, in cui TCP
>e IP sanno troppo l'uno dell'altro.
>
Mi sbaglierň (niente di piů facile, dato che non sono certo al livello degli
autori del Tanenbaum) ma mi pare na str....ata !!!
Ciao,
Massimo.