Indice
Voci
Suite di protocolli Internet
1
Livello applicazioni
3
HTTPS
4
Hypertext Transfer Protocol
5
Simple Mail Transfer Protocol
10
Post Office Protocol
12
Internet Message Access Protocol
14
Dynamic Host Configuration Protocol
15
Simple Network Management Protocol
18
File Transfer Protocol
21
Domain Name System
26
Telnet
34
rsync
36
Real-time Transport Protocol
39
Livello di trasporto
40
Transmission Control Protocol
42
User Datagram Protocol
50
Livello di rete
52
IPv4
53
IPsec
58
Livello datalink
65
Secure shell
70
Note
Fonti e autori delle voci
74
Fonti, licenze e autori delle immagini
75
Licenze della voce
Licenza
76
Suite di protocolli Internet
Suite di protocolli Internet
In informatica e telecomunicazioni la suite di protocolli Internet è un insieme di protocolli di rete su cui si basa il
funzionamento della rete Internet. A volte, per sineddoche, è chiamata suite di protocolli TCP/IP, in funzione dei due
più importanti protocolli in essa definiti: il Transmission Control Protocol (TCP) e l'Internet Protocol (IP).
Storia del TCP/IP
Nei primi anni settanta, la Defence Advanced Research Project Agency (DARPA) finanziò l'Università di Stanford e
la BBN (Bolt, Beranek and Newman) per lo sviluppo di un insieme di protocolli di comunicazione da utilizzarsi per
lo sviluppo di reti a commutazione di pacchetto, per l'interconnessione di calcolatori eterogenei. Fu così che nacque
lInternet Protocol Suite i cui due protocolli più noti sono il TCP (Transmission Control Protocol) e l'IP
(Internet P'rotocol).
Si fa riferimento a questa architettura di rete con la sigla TCP/IP o IP/TCP (quest'ultima non è quasi mai usata). I
creatori di tali protocolli di trasmissione, tuttora utilizzati nel web, sono nello specifico Robert Kahn e Vinton Cerf, a
cui l'ex Presidente degli Stati Uniti George W. Bush ha consegnato la Presidential Medal of Freedom, ovvero la più
alta tra le onorificenze civili a stelle e strisce, il 9 novembre 2005. I due studiosi non sono nuovi a questo genere di
premiazioni: all'inizio del 2005 è stato assegnato loro il prestigioso 2004 A.M. Turing Award, equivalente del Premio
Nobel nel settore dell'Information Technology. Cerf e Kahn hanno sviluppato lo standard per la trasmissione di
pacchetti via rete nel lontano 1973, mentre lavoravano a un progetto di sviluppo dei sistemi di comunicazione voluto
dalla DARPA (Defense Advanced Research Projects Agency). Attualmente Vint Cerf, collabora con Google alla
creazione degli standard per le future applicazioni e nel frattempo si dedica allo sviluppo di nuovi protocolli di
comunicazione interplanetaria per il Jet Propulsion Lab della Nasa. Robert Kahn, invece, dopo 13 anni di servizio
presso la DARPA è diventato presidente della Corporation for National Research Initiatives (CNRI).
Questi protocolli, utilizzabili gratuitamente da tutti perché di pubblico dominio fin dall'inizio, ottennero un elevato
successo (utilizzati da un gruppo di ricercatori per ARPAnet).
Questo genera alcune ambiguità dovute al fatto che il nome più corretto sarebbe Internet Protocol Suite. Per esempio
succede di sentir parlare di servizi basati su TCP/IP anche quando in realtà, invece di TCP, viene usato un protocollo
alternativo, UDP, anch'esso appartenente all'Internet Protocol Suite. In genere il TCP viene utilizzato per quelle
applicazioni che richiedono un servizio orientato alla connessione, come ad esempio la posta elettronica e il file
sharing, mentre l'UDP prende sempre più piede per le applicazioni in tempo reale come l'on-line gaming o lo
streaming audio e video; la differenza fra i due protocolli risiede nella maggiore affidabilità nel trasporto dei dati di
TCP, che offre una serie di servizi appositamente pensati (gestione del flusso, della congestione...), mentre UDP
punta molto sulla velocità di trasmissione a scapito della affidabilità. Si tenga quindi sempre presente che la sigla
TCP/IP è di utilizzo talmente comune da essere utilizzata, talvolta, anche quando esistono termini alternativi più
corretti.
TCP/IP è l'architettura adottata dalla rete internet. Negli anni novanta, nonostante la sua età, è stata (più o meno
paradossalmente) l'unica architettura che ha interessato il mercato, al punto che gli enti di standardizzazione, di
fronte al fatto compiuto della sua massiccia diffusione hanno dovuto darle la stessa dignità di ISO/OSI.
Caratteristiche
Tale suite può essere descritta per analogia con il modello OSI, che descrive i livelli della pila di protocolli. In una
pila di protocolli ogni livello risolve una serie di problemi che riguardano la trasmissione di dati e fornisce un ben
definito servizio ai livelli più alti. I livelli più alti sono logicamente più vicini all'utente e funzionano con dati più
astratti lasciando ai livelli più bassi il compito di tradurre i dati in forme mediante le quali possono essere
fisicamente manipolati e trasmessi infine sul canale di comunicazione.
1
Suite di protocolli Internet
Il modello Internet è stato prodotto come una soluzione ad un problema ingegneristico pratico in quanto si è trattato
di aggiungere via via strati protocollari all'architettura di rete delle reti locali per ottenere un'interconnessione
efficiente ed affidabile. Il modello OSI, in un altro senso, invece è stato l'approccio più teorico-deduttivo ed è stato
anche prodotto nel più vecchio modello di rete.
Un esempio di funzionamento della suite TCP/IP
Per comprendere la struttura della suite TCP/IP, si utilizza una schematizzazione a livelli. Ogni livello esegue una
specifica serie di operazioni; ad ogni livello, ci si avvicina sempre più dall'interfaccia utente (quella con cui
interagiamo) all'interfaccia di rete. Il messaggio trasmesso è modificato di conseguenza.
Il primo livello è quello dell'applicazione: esso rappresenta l'interfaccia con l'utente ed abilita, ad esempio, la
consultazione di pagine web, stabilendo e gestendo le sessioni di lavoro dei processi client del nostro browser ed un
server web.
Il protocollo di trasporto TCP mette in coda i messaggi generati da client e server e li trasmette sotto forma di
pacchetti su di una connessione full-duplex; il buon fine della spedizione è attestato da una ricevuta di ritorno. Anche
questo è un collegamento virtuale tra le due applicazioni, i cui dettagli sono demandati al successivo livello, detto di
rete. Quindi, il livello di trasporto offre un servizio al livello delle applicazioni avvalendosi dei servizi del sottostante
livello di rete (ed in particolare del protocollo IP). Per gestire molteplici processi attivi nel trasferimento dati sul
medesimo nodo (o computer) il livello di trasporto (TCP o UDP) utilizza più numeri di porta.
TCP nell'invio dei pacchetti usa il meccanismo dello Sliding Window (o finestra scorrevole). Una serie di pacchetti
viene inviata da TCP seguendo delle regole ben precise:
•
•
•
•
Ad ogni finestra di pacchetti spedita il trasmettitore fa partire un timeOut.
Il Ricevitore invia per ogni pacchetto ricevuto un ACK indicando il successivo pacchetto atteso.
Il trasmettitore considera quindi spediti tutti i pacchetti precedenti.
Se il timeout scade oppure sono ricevuti 3 ACK duplicati, TCP assume si sia verificata la perdita di uno o più
pacchetti e provvede ad implementare opportune strategie di ritrasmissione dei dati e di controllo della
congestione.
Questa è una tecnica molto importante perché fornisce un canale di comunicazione affidabile. Inoltre TCP contiene
meccanismi per gestire la congestione ed il controllo di flusso.
Internet Protocol (IP) è il protocollo di InternetWorking del modello DOD/DARPA (secondo il modello OSI è
classificato nel livello rete). Esso si occupa di gestire l'indirizzamento dei nodi e l'instradamento. A ciascun nodo
viene infatti assegnato un indirizzo IP che lo identificherà in modo non ambiguo in rete. Le funzionalità di
instradamento, invece, consentono di selezionare il percorso migliore per veicolare un messaggio verso un dato nodo
destinatario, noto che sia il suo indirizzo IP.
Al livello di collegamento si decide come fare il trasferimento del messaggio per ogni singolo tratto del percorso: dal
computer del browser al primo router, dal primo router al secondo, dal secondo al terzo e dal terzo al computer del
server. Questo è un collegamento virtuale tra due computer (o router) adiacenti. Anche in questo caso le interfacce di
comunicazione dei nodi adiacenti saranno individuate per mezzo di un indirizzo univoco, usualmente denominato
indirizzo MAC.
Il livello fisico, che è l'ultimo, trasmette il messaggio sul canale di comunicazione usualmente sotto forma di onde
elettromagnetiche, sebbene sia anche possibile utilizzare onde acustiche (come ad esempio nelle reti di sensori
sottomarine).
2
Suite di protocolli Internet
Collegamenti esterni
• Introduzione al TCP/IP [1]
Note
[1] http:/ / www. oscene. net/ it/ sysadmin/ networking/ lo-stack-tcpip-introduzione
Livello applicazioni
In telecomunicazioni il livello applicazioni è il settimo ed ultimo livello del modello OSI per reti di calcolatori. La
sua funzione è quella di interfacciare e fornire servizi per i processi delle applicazioni; inoltra quindi le richieste al
sottostante livello di presentazione. Un programma applicativo interagisce con uno dei protocolli di livello di
trasporto per ricevere dati o inviarli passandoli nella forma richiesta.[1][2]
Tra i servizi più comuni offerti dal livello applicazioni ci sono le conversioni semantiche tra processi applicativi
associati. Nota: esempi di servizi usuali sono i file virtuali ed il virtual terminal.
Esempi
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
DNS
HTTP
SMTP
SNMP
POP3
FTP
Network Time Protocol (NTP)
Telnet
Secure shell (SSH)
IRC
Lightweight Directory Access Protocol (LDAP)
XMPP
FTAM
Advanced Program to Program Communications (APPC)
X.400
X.500
AFP
SIP
ITMS
AIM
3
Livello applicazioni
Note
[1] (EN) Application Layer Definition (http:/ / www. linfo. org/ application_layer. html). linfo.org, 16-11-2005. URL consultato il 14-5-2012.
[2] (EN) Bradley Mitchell. Visual Networking Overview - The OSI Model - Application Layer (http:/ / compnetworking. about. com/ od/
basicnetworkingconcepts/ l/ blbasics_osi7. htm). about.com. URL consultato il 14-5-2012.
Altri progetti
•
Wikimedia Commons contiene file multimediali: http://commons.wikimedia.org/wiki/
Category:Application layer protocols
HTTPS
In telecomunicazioni e informatica HyperText Transfer Protocol over Secure Socket Layer (HTTPS) è il
risultato dell'applicazione di un protocollo di crittografia asimmetrica al protocollo di trasferimento di ipertesti
HTTP. Viene utilizzato per garantire trasferimenti riservati di dati nel web, in modo da impedire intercettazioni dei
contenuti che potrebbero essere effettuati tramite la tecnica di attacco del man in the middle.
Descrizione
Nei browser web, la URI (Uniform Resource Identifier) che si riferisce a tale tecnologia ha nome di schema https
ed è in tutto e per tutto analoga alle URI http. Tuttavia, la porta di default impiegata non è la 80 come in HTTP, ma
la 443, mentre (trasparentemente all'utente) tra il protocollo TCP e HTTP si interpone un livello di
crittografia/autenticazione come il Secure Sockets Layer (SSL) o il Transport Layer Security (TLS).
In pratica viene creato un canale di comunicazione criptato tra il client e il server attraverso uno scambio di
certificati; una volta stabilito questo canale al suo interno viene utilizzato il protocollo HTTP per la comunicazione.
Questo tipo di comunicazione garantisce che solamente il client e il server siano in grado di conoscere il contenuto
della comunicazione.
Questo sistema fu progettato dalla Netscape Communications Corporation che si occupa delle autenticazioni e delle
comunicazioni crittografate ed è largamente usato nel World Wide Web per situazioni che richiedono particolari
esigenze in ambito di sicurezza come per esempio il pagamento di transazioni online. In questo caso SSL garantisce
la cifratura dei dati trasmessi e ricevuti su internet.
Funzionamento
HTTPS è un protocollo che integra l'interazione del protocollo HTTP attraverso un meccanismo di crittografia di
tipo Transport Layer Security (SSL/TLS). Questa tecnica aumenta il livello di protezione contro attacchi del tipo
man in the middle.
La porta di default per un accesso di tipo https:// è la porta 443 (mentre per il protocollo http:// si utilizza di default la
porta 80).
Per impostare un web server in modo che accetti connessioni di tipo https, l'amministratore di rete deve creare un
certificato digitale ovvero un documento elettronico che associa l'identità di una persona ad una chiave pubblica.
Questi certificati possono essere creati dai server basati su UNIX con l'ausilio di tools come ssl-ca di OpenSSL
oppure usando gensslcert di SuSE (tinyca2, CA.pl script perl, ). Questi certificati devono essere rilasciati da un
certificate authority o comunque da un sistema che accerta la validità dello stesso in modo da definire la vera identità
del possessore (i browser web sono creati in modo da poter verificare la loro validità tramite una lista preimpostata).
In particolari situazioni (come per esempio nel caso di aziende con una rete intranet privata) è possibile avere un
proprio certificato digitale che si può rilasciare ai propri utenti.
4
HTTPS
5
Questa tecnologia quindi può essere usata anche per permettere un accesso limitato ad un web server.
L'amministratore spesso crea dei certificati per ogni utente che vengono caricati nei loro browser contenenti
informazioni come il relativo nome e indirizzo e-mail in modo tale da permettere al server di riconoscere l'utente nel
momento in cui quest'ultimo tenti di riconnettersi senza immettere nome utente e/o password.
Voci correlate
• Hyper Text Transfer Protocol
• Strict Transport Security
Collegamenti esterni
•
•
•
•
RFC 2818: HTTP Over TLS [1]
SSL 3.0 Specification [2] (IETF)
HTTPS Everywhere [3] creato da Electronic Frontier Foundation
Wikipedia con protocollo HTTPS [4]
Note
[1]
[2]
[3]
[4]
http:/ / tools. ietf. org/ html/ rfc2818
http:/ / tools. ietf. org/ html/ draft-ietf-tls-ssl-version3-00
https:/ / www. eff. org/ https-everywhere/
https:/ / www. wikipedia. org/
Hypertext Transfer Protocol
L'HyperText Transfer Protocol (HTTP) (protocollo di trasferimento di un ipertesto) è usato come principale
sistema per la trasmissione d'informazioni sul web. Le specifiche del protocollo sono gestite dal World Wide Web
Consortium (W3C). Un Server HTTP generalmente resta in ascolto sulla porta 80 usando il protocollo TCP.
Storia
La prima versione dell'HTTP, la 0.9, risale alla fine degli anni ottanta e costituiva, insieme con il linguaggio HTML
e gli URL, il nucleo base della World Wide Web (WWW) global information initiative portata avanti da Tim
Berners-Lee al CERN di Ginevra per la condivisione delle informazioni tra la comunità dei fisici delle alte energie.
La prima versione effettivamente disponibile del protocollo, la HTTP/1.0, venne implementata dallo stesso
Berners-Lee nel 1991 e proposta come RFC 1945 [1] all'ente normatore IETF nel 1996. Con la diffusione di NCSA
Mosaic, un browser grafico di facile uso, il WWW conobbe un successo crescente e divennero evidenti alcuni limiti
della versione 1.0 del protocollo, in particolare:
• l'impossibilità di ospitare più siti www sullo stesso server (virtual host)
• il mancato riuso delle connessioni disponibili
• l'insufficienza dei meccanismi di sicurezza
Il protocollo venne quindi esteso nella versione HTTP/1.1, presentato come RFC 2068 nel 1997 e successivamente
aggiornato nel 1999 come descritto dal RFC 2616 [2]
Hypertext Transfer Protocol
Funzionamento
L'HTTP funziona su un meccanismo richiesta/risposta (client/server): il client esegue una richiesta e il server
restituisce la risposta. Nell'uso comune il client corrisponde al browser ed il server al sito web. Vi sono quindi due
tipi di messaggi HTTP: messaggi richiesta e messaggi risposta.
HTTP differisce da altri protocolli di livello 7 come FTP, per il fatto che le connessioni vengono generalmente
chiuse una volta che una particolare richiesta (o una serie di richieste correlate) è stata soddisfatta. Questo
comportamento rende il protocollo HTTP ideale per il World Wide Web, in cui le pagine molto spesso contengono
dei collegamenti (link) a pagine ospitate da altri server diminuendo così il numero di connessioni attive limitandole a
quelle effettivamente necessarie con aumento quindi di efficienza (minor carico e occupazione) sia sul client che sul
server. Talvolta però pone problemi agli sviluppatori di contenuti web, perché la natura senza stato (stateless) della
sessione di navigazione costringe ad utilizzare dei metodi alternativi per conservare lo stato dell'utente, tipicamente
basati sui cookie.
Messaggio di richiesta
Il messaggio di richiesta è composto di tre parti:
• Riga di richiesta (request line)
• Sezione header (informazioni aggiuntive)
• Body (corpo del messaggio)
Riga di richiesta
La riga di richiesta è composta da metodo, URI e versione del protocollo. Il metodo di richiesta, per la versione 1.1,
può essere uno dei seguenti:
•
•
•
•
•
•
•
•
GET
POST
HEAD
PUT
DELETE
TRACE
OPTIONS
CONNECT
l'URI sta per Uniform Resource Identifier ed indica l'oggetto della richiesta (ad esempio la pagina web che si
intende ottenere).
I metodi HTTP più comuni sono GET, HEAD e POST. Il metodo GET è usato per ottenere il contenuto della risorsa
indicata come URI (come può essere il contenuto di una pagina HTML). HEAD è analogo a GET, ma restituisce
solo i campi dell'header, ad esempio per verificare la data di modifica del file. Una richiesta con metodo HEAD non
prevede l'uso del body.
Il metodo POST è usato di norma per inviare informazioni al server (ad esempio i dati di un form). In questo caso
l'URI indica che cosa si sta inviando e il body ne indica il contenuto.
6
Hypertext Transfer Protocol
Gli header della richiesta
Gli header di richiesta più comuni sono:
Host: Nome del server a cui si riferisce l'URI. È obbligatorio nelle richieste conformi HTTP/1.1 perché permette
l'uso dei virtual host basati sui nomi.
User-Agent: Identificazione del tipo di client: tipo browser, produttore, versione...
Messaggio di risposta
Il messaggio di risposta è di tipo testuale ed è composto da tre parti:
• Riga di stato (status-line)
• Sezione header
• Body (contenuto della risposta)
Riga di stato
La riga di stato riporta un codice a tre cifre catalogato nel seguente modo:
• 1xx: Informational (messaggi informativi)
• 2xx: Successfull (la richiesta è stata soddisfatta)
• 3xx: Redirection (non c'è risposta immediata, ma la richiesta è sensata e viene detto come ottenere la risposta)
• 4xx: Client error (la richiesta non può essere soddisfatta perché sbagliata)
• 5xx: Server error (la richiesta non può essere soddisfatta per un problema interno del server)
I codici di risposta più comuni sono:
• 200 OK. Il server ha fornito correttamente il contenuto nella sezione body.
• 301 Moved Permanently. La risorsa che abbiamo richiesto non è raggiungibile perché è stata spostata in modo
permanente.
• 302 Found. La risorsa è raggiungibile con un altro URI indicato nel header Location. Di norma i browser
eseguono la richiesta all'URI indicato in modo automatico senza interazione dell'utente.
• 400 Bad Request. La risorsa richiesta non è comprensibile al server.
• 404 Not Found. La risorsa richiesta non è stata trovata e non se ne conosce l'ubicazione. Di solito avviene quando
l'URI è stato indicato in modo incorretto, oppure è stato rimosso il contenuto dal server.
• 500 Internal Server Error. Il server non è in grado di rispondere alla richiesta per un suo problema interno.
• 505 HTTP Version Not Supported. La versione di http non è supportata.
Gli header della risposta
Gli header della risposta più comuni sono:
• Server. Indica il tipo e la versione del server. Può essere visto come l'equivalente dell'header di richiesta
User-Agent
• Content-Type. Indica il tipo di contenuto restituito. La codifica di tali tipi (detti Media type) è registrata presso lo
IANA (Internet Assigned Number Authority ); essi sono detti tipi MIME (Multimedia Internet Message
Extensions), la cui codifica è descritta nel documento RFC 1521. Alcuni tipi usuali di tipi MIME incontrati in una
risposta HTML sono:
•
•
•
•
text/html Documento HTML
text/plain Documento di testo non formattato
text/xml Documento XML
image/jpeg Immagine di formato JPEG
7
Hypertext Transfer Protocol
Esempi di messaggi HTTP
Richiesta:
GET /wiki/Pagina_principale HTTP/1.1
Connection: Keep-Alive
User-Agent: Mozilla/5.0 (compatible; Konqueror/3.2; Linux) (KHTML, like Gecko)
Accept: text/html, image/jpeg, image/png, text/*, image/*, */*
Accept-Encoding: x-gzip, x-deflate, gzip, deflate, identity
Accept-Charset: iso-8859-1, utf-8;q=0.5, *;q=0.5
Accept-Language: en
Host: it.wikipedia.org
(la richiesta deve terminare con una riga vuota, cioè con due "a capo" consecutivi)
Risposta:
HTTP/1.0 200 OK
Date: Mon, 28 Jun 2004 10:47:31 GMT
Server: Apache/1.3.29 (Unix) PHP/4.3.4
X-Powered-By: PHP/4.3.4
Vary: Accept-Encoding,Cookie
Cache-Control: private, s-maxage=0, max-age=0, must-revalidate
Content-Language: it
Content-Type: text/html; charset=utf-8
Age: 7673
X-Cache: HIT from wikipedia.org
Connection: close
seguita dai dati richiesti.
Versioni sicure
Dal momento che tutto il traffico HTTP è anonimo e in chiaro, sono state sviluppate diverse alternative per garantire
differenti livelli di sicurezza, in termini di
•
•
•
•
cifratura del traffico;
verifica di integrità del traffico;
autenticazione del server;
autenticazione dell'utente.
La prima proposta venne direttamente da NCSA, con le versioni server 1.1 e client 2.2 che supportavano un
meccanismo di autenticazione utente e cifratura dati basati su messaggi formato PEM e chiavi PGP.
In seguito, sono state standardizzate due versioni sicure del protocollo HTTP chiamate SHTTP e HTTPS. La prima,
modellata sulla posta cifrata S/MIME, è ormai caduta in disuso e prevede meccanismi crittografici a livello di
payload: le richieste e gli header vengono scambiati in chiaro mentre il contenuto della pagina viene cifrato come
una struttura MIME multipart. Il meccanismo HTTPS, inventato da Netscape, usa invece il sottostante canale cifrato
a livello di trasporto mediante SSL o TLS per impedire l'intercettazione di qualsiasi parte della transazione. Entrambi
i protocolli possono garantire l'identità del mittente, ma solo SHTTP è in grado di garantire anche l'integrità del
contenuto dopo averlo, ad esempio, memorizzato su un disco.
8
Hypertext Transfer Protocol
Streaming HTTP
La fruizione nelle pagine WEB di materiale multimediale, quale audio o video viene gestito in modo del tutto
analogo al download dei file, tramite un caricamento progressivo o distribuzione progressiva, dove il file viene
scaricato in modo progressivo dall'inizio alla fine (tramite i protocolli Real Time Streaming Protocol e Real-time
Transport Protocol) e nel caso il bit-rate sia eccessivo per la rete che lo trasporta può verificarsi un continuo
ricaricamento del buffer
Per evitare questi inconvenienti esistono altri sistemi alternativi, che permettono l'adattamento del file alla rete
dell'utente finale, questi sistemi sono caratterizzati dai protocolli:
•
•
•
•
Smooth Streaming, ideato da Microsoft[3][4]
HTTP Dynamic Streaming soluzione ideata da Adobe
HTTP Live Streaming soluzione ideata da Apple
Octoshape è una piattaforma proprietaria di streaming multimediale, che utilizza la tecnologia per offrire un
throughput migliore e rompere la congestione nell'ultimo miglio. Ha la possibilità di utilizzare una suite di
tecnologie multicast per ridurre al minimo la larghezza di banda per qualsiasi CDN, ISP, emittente o del fornitore
dell'ultimo miglio.
Per contro queste soluzioni sono notevolmente più complesse rispetto alle tradizionali tecnologie di streaming.
Alcune delle considerazioni documentate riguardano lo stoccaggio, i costi aggiuntivi per la codifica e la difficoltà nel
mantenimento della qualità globale. Ci sono state anche alcune dinamiche interessanti trovate intorno alle interazioni
complesse fra logica adattiva bit rate in competizione con complessa logica di controllo del flusso TCP.[5][6]
Bibliografia
• RFC 1945 (Specifiche HTTP 1.0)
• RFC 2616 (Specifiche HTTP 1.1)
Voci correlate
•
•
•
•
HTTP tunneling
SPDY
HTTP Live Streaming
Do not track header
Note
[1] http:/ / tools. ietf. org/ html/ rfc1945
[2] http:/ / tools. ietf. org/ html/ rfc2616
[3] IIS Smooth Streaming Technical (http:/ / download. microsoft. com/ download/ 4/ 2/ 4/ 4247C3AA-7105-4764-A8F9-321CB6C765EB/
IIS_Smooth_Streaming_Technical_Overview. pdf)
[4] Smooth Streaming (http:/ / www. iis. net/ download/ smoothstreaming)
[5] An Experimental Evaluation of Rate-Adaptation Algorithms in Adaptive Streaming over HTTP (http:/ / www. cc. gatech. edu/ ~sakhshab/
Saamer_MMSys11. pdf)
[6] Is adaptive bit rate the yellow brick road, or fool's gold for HD streaming? (http:/ / www. fierceonlinevideo. com/ story/
adaptive-bit-rate-yellow-brick-road-or-fools-gold-hd-streaming/ 2011-01-28)
9
Hypertext Transfer Protocol
Altri progetti
•
Wikimedia Commons contiene file multimediali: http://commons.wikimedia.org/wiki/Category:HTTP
Simple Mail Transfer Protocol
Simple Mail Transfer Protocol (SMTP) è il protocollo standard per la trasmissione via internet di e-mail. In
italiano si potrebbe tradurre come "Protocollo elementare di trasferimento postale".
I protocolli utilizzati per ricevere posta sono invece il protocollo POP e l'IMAP.
Descrizione
È un protocollo relativamente semplice, testuale, nel quale vengono specificati uno o più destinatari di un messaggio,
verificata la loro esistenza e il messaggio viene trasferito. È abbastanza facile verificare come funziona un server
SMTP mediante un client telnet. Il protocollo SMTP utilizza come protocollo di livello transport TCP. Il client apre
una sessione TCP verso il server sulla porta 25 (recentemente modificata in 587 da molti Provider per limitare lo
spam). Per associare il server SMTP a un dato nome di dominio (DNS) si usa un Resource Record di tipo MX (Mail
eXchange) (Tipi di record DNS).
Poiché SMTP è un protocollo testuale basato sulla codifica ASCII ( in particolare ASCII NVT), non è permesso
trasmettere direttamente testo composto con un diverso set di caratteri e tantomeno file binari. Lo standard MIME
permette di estendere il formato dei messaggi mantenendo la compatibilità col software esistente. Per esempio, al
giorno d'oggi molti server SMTP supportano l'estensione 8BITMIME, la quale permette un trasferimento di un testo
che contiene caratteri accentati (non-ASCII) senza bisogno di trascodificarlo. Altri limiti di SMTP, quale la
lunghezza massima di una riga, impediscono la spedizione di file binari senza trascodifica. (Nota che per i file binari
inviati con HTTP si utilizza il formato MIME senza bisogno di una trascodifica.)
SMTP è un protocollo che permette soltanto di inviare messaggi di posta, ma non di richiederli ad un server: per fare
questo il client di posta deve usare altri protocolli, quali il POP3 (Post Office Protocol) e l'IMAP (Internet Message
Access Protocol).
Storia
SMTP iniziò a diffondersi nei primi anni '80. A quel tempo era un'alternativa a UUCP, che era più adatto a gestire il
trasferimento di e-mail fra computer la cui connessione era intermittente. L'SMTP, d'altra parte, funziona meglio se i
computer sono sempre collegati alla rete.
Sendmail fu uno dei primi (se non proprio il primo) mail transfer agent ad implementare il protocollo SMTP. Fino al
2001 sono stati scritti almeno 50 programmi che implementano il protocollo SMTP come client (mittente dei
messaggi) o server (destinatario del messaggio). Server molto diffusi sono Exim di Philip Hazel, Postfix di Wietse
Venema, qmail di D. J. Bernstein, Courier di Sam Varshavchik e Microsoft Exchange Server.
10
Simple Mail Transfer Protocol
Esempio di comunicazione SMTP
Quella che segue è una transazione SMTP valida. Le righe inviate dal client sono precedute da "C:", mentre quelle
inviate dal server da "S:". Su molti computer si può stabilire una connessione mediante il comando telnet:
telnet www.example.com 25
Questo comando apre una connessione a www.example.com sulla porta 25 di TCP.
S:
C:
S:
C:
S:
C:
S:
C:
S:
C:
C:
C:
C:
C:
C:
C:
S:
C:
S:
220 www.example.com ESMTP Postfix
HELO mydomain.com
250 Hello mydomain.com, pleased to meet you
MAIL FROM: <[email protected]>
250 [email protected] ... Sender ok
RCPT TO: <[email protected]>
250 [email protected] ... Recipient Ok
DATA
354 End data with "." on a line by itself
Subject: messaggio di prova
From: [email protected]
To: [email protected]
Ciao,
questa è una prova.
.
250 Ok: queued as 12345
QUIT
221 Bye
Sebbene non sia obbligatorio, quasi tutti i client richiedono al server quali estensioni del protocollo SMTP il server
supporta usando il saluto EHLO. Questi client usano HELO soltanto nel caso in cui il server non risponda ad EHLO.
La sicurezza del protocollo SMTP
Una delle limitazioni del protocollo SMTP originario è che non gestisce l'autenticazione dei mittenti. Oltre al rischio
di spam, esiste la possibilità di inviare e-mail facendo apparire come mittente l'indirizzo corrispondente ad un altro
account. Senza accedere all'account di terzi, è possibile stabilire una connessione al mail-server e scrivere un
messaggio in codice SMTP contenente i comandi relativi a mittente e destinatario, dare i relativi parametri e il corpo
della e-mail.
Per ovviare a questi problemi è stata sviluppata un'estensione chiamata SMTP-AUTH.
Nonostante questo, lo spam rimane ancor oggi un grave problema dello posta eletronica. Tuttavia, non si ritiene
praticabile una revisione radicale del protocollo SMTP, per via del gran numero di implementazioni del protocollo
attuale (ad esempio, è stato proposto Internet Mail 2000 come protocollo alternativo).
Per questo motivo sono stati proposti diversi protocolli ausiliari per assistere le transazioni SMTP. L'Anti-Spam
Research Group dell'IRTF sta lavorando su varie proposte di autenticazione e-mail centrate sulla flessibilità,
leggerezza e scalabilità.
11
Simple Mail Transfer Protocol
Gli standard RFC
(in lingua originale)
•
•
•
•
•
•
•
•
RFC 821, pubblicato nel 1982
RFC 1123 pubblicato nel 1989. Correzioni all'RFC 821
RFC 1425 pubblicato nel 1993. Introduce il comando EHLO
RFC 1651 pubblicato nel 1994. Rimpiazza l'RFC 1425
RFC 1869 pubblicato nel 1995. Rimpiazza l'RFC 1651
RFC 1891 pubblicato nel 1996. Corregge l'RFC 1869
RFC 2821 pubblicato nel 2001. Rimpiazza gli RFC 821, RFC 1123, RFC 1869
RFC 2822 pubblicato nel 2001.
(tradotti in italiano)
• RFC 1869 - Estensioni del servizio SMTP (tradotta) [1]
Voci correlate
• On-Demand Mail Relay
• Multipurpose Internet Mail Extensions (MIME)
• Mail server
Note
[1] http:/ / www. rfc. altervista. org/ rfctradotte. html
Post Office Protocol
Il Post Office Protocol (detto anche POP) è un protocollo di livello applicativo di tipo client-server che ha il
compito di permettere, mediante autenticazione, l'accesso da parte del client ad un account di posta elettronica
presente su di un host server e scaricare le e-mail dell'account stesso.
Il protocollo per inviare posta è invece il protocollo SMTP.
Descrizione
Il POP (nella versione 3) rimane in attesa sulla porta 110 dell'host (di default, ma può anche essere diversa) per una
connessione TCP da parte di un client.
I messaggi di posta elettronica, per essere letti, devono essere scaricati sul computer (questa è una notevole
differenza rispetto all'IMAP), anche se è possibile lasciarne una copia sull'host.
Il protocollo POP3 non prevede alcun tipo di cifratura, quindi anche le password utilizzate per l'autenticazione fra
server e client passano in chiaro. Per risolvere questo possibile problema è stata sviluppata l'estensione APOP che
utilizza MD5.
12
Post Office Protocol
Esempio di comunicazione POP3
Dopo aver stabilito una connessione tra il mittente (il client) e il destinatario (il server), ciò che accade è l'apertura di
una sessione POP3. Nella successiva conversazione, qualsiasi cosa inviata dal client è preceduta con "C:", mentre
qualsiasi cosa inviata dal server è preceduta da "S:". Su molti computer si può stabilire una connessione mediante il
comando telnet:
telnet www.example.com 110
Questo comando apre un collegamento POP3 verso l'host www.example.com.
S:+OK <[email protected]>
C:USER pippo
S:+OK
C:PASS pluto
S:+OK
C:LIST
S:+OK
1 817
2 124
.
C:RETR 1
S:+OK
Return-Path: <[email protected]>
Delivered-To: [email protected]
Date: Sat, 22 Oct 2005 13:24:54 +0200
From: Mario Rossi <[email protected]>
Subject: xxxx
Content-Type: text/plain; charset=ISO-8859-1
testo messaggio
.
C:DELE 1
S:+OK
C:QUIT
S:+OK
Voci correlate
• IMAP
Collegamenti esterni
•
•
•
•
•
RFC 937 POP versione 2
RFC 1939 POP versione 3 (traduzione in italiano [1])
RFC 1734 Il comando POP3 AUTH (traduzione in italiano [2])
RFC 1957 Osservazioni aggiuntive sull'implementazione di POP3 (traduzione in italiano [3])
RFC 3206 I codici di risposta POP SYS e AUTH (traduzione in italiano [4])
13
Post Office Protocol
Note
[1]
[2]
[3]
[4]
http:/ / www. rfc. altervista. org/ rfctradotte/ rfc1939_tradotta. txt
http:/ / www. rfc. altervista. org/ rfctradotte/ rfc1734_tradotta. txt
http:/ / www. rfc. altervista. org/ rfctradotte/ rfc1957_tradotta. txt
http:/ / www. rfc. altervista. org/ rfctradotte/ rfc3206_tradotta. txt
Internet Message Access Protocol
L'Internet Message Access Protocol (IMAP), a volte anche chiamato Interactive Mail Access Protocol, è un
protocollo di comunicazione per la ricezione di e-mail.
Il significato "Interactive Mail Access Protocol" è stato valido fino alla versione 3, dalla quarta in poi è cambiato in
"Internet Message Access Protocol". L'attuale versione è la "4 revision 1".
Il protocollo è stato inventato da Mark Crispin nel 1986 come alternativa più moderna all'utilizzatissimo POP.
La porta predefinita del demone IMAP sull'host è la 143. Se si utilizza una connessione sicura tramite SSL, allora la
porta è la 993.
Differenze tra IMAP e POP
Entrambi i protocolli permettono ad un client di accedere, leggere e cancellare le e-mail da un server, ma con alcune
differenze. Con entrambi i protocolli, il client scarica la posta direttamente sul PC, eventualmente cancellandola dal
server, ma è altresì possibile conservare copia delle proprie e-mail sul server, e scaricarle in un secondo momento da
altri computer. Ecco un elenco delle caratteristiche dell'IMAP ma non del POP:
• Accesso alla posta sia online che off-line
Mentre si utilizza il POP3, il client si connette per scaricare i nuovi messaggi e poi si disconnette. Con l'IMAP
il client rimane connesso e risponde alle richieste che l'utente fa attraverso l'interfaccia; questo permette di
risparmiare tempo se ci sono messaggi di grandi dimensioni.
• Più utenti possono utilizzare la stessa casella di posta
Il protocollo POP assume che un solo client (utente) sia connesso ad una determinata mailbox (casella di
posta), quella che gli è stata assegnata. Al contrario l'IMAP4 permette connessioni simultanee alla stessa
mailbox, fornendo meccanismi per controllare i cambiamenti apportati da ogni utente.
• Supporto all'accesso a singole parti MIME di un messaggio
La maggior parte delle e-mail sono trasmesse nel formato MIME, che permette una struttura ad albero del
messaggio, dove ogni ramo è un contenuto diverso (intestazioni, allegati o parti di esso, messaggio in un dato
formato, eccetera). Il protocollo IMAP4 permette di scaricare una singola parte MIME o addirittura sezioni
delle parti, per avere un'anteprima del messaggio o per scaricare una mail senza i file allegati.
• Supporto per attributi dei messaggi tenuti dal server.
Attraverso l'uso di attributi, tenuti sul server, definiti nel protocollo IMAP4, ogni singolo client può tenere
traccia di ogni messaggio, per esempio per sapere se è già stato letto o se ha avuto una risposta.
• Accesso a molteplici caselle di posta sul server
Alcuni utenti, con il protocollo IMAP4, possono creare, modificare o cancellare mailbox (di solito associate a
cartelle) sul server. Inoltre, questa gestione delle mailbox, permette di avere cartelle condivise tra utenti
diversi.
• Possibilità di fare ricerche sul server
14
Internet Message Access Protocol
L'IMAP4 permette al client di chiedere al server quali messaggi soddisfano un certo criterio, per fare, per
esempio, delle ricerche sui messaggi senza doverli scaricare tutti.
• Supporto di un meccanismo per la definizione di estensioni
Nelle specifiche dell'IMAP è descritto come un server può far sapere agli utenti se ha delle funzionalità extra.
Molte estensioni dell'IMAP sono molto diffuse, ad esempio l'IMAP Idle [1].
L'IMAP è principalmente utilizzato nelle grandi network come università o aziende, dove un utente cambia
postazione spesso: con il POP3, sarebbe necessario scaricare i messaggi ogni volta che si cambia pc, mentre con
l'IMAP si possono scaricare solo i nuovi messaggi o accedere ad un messaggio specifico senza dover scaricare gli
altri.
Collegamenti esterni
• Internet Message Access Protocol - version 4rev1 [2]
• Interactive Mail Access Protocol - version 3 [3]
• Interactive Mail Access Protocol - version 2 [4]
Note
[1]
[2]
[3]
[4]
http:/ / www. isode. com/ whitepapers/ imap-idle. html
http:/ / www. rfc-editor. org/ rfc/ rfc3501. txt
http:/ / www. rfc-editor. org/ rfc/ rfc1203. txt
http:/ / www. rfc-editor. org/ rfc/ rfc1176. txt
Dynamic Host Configuration Protocol
In telecomunicazioni e informatica il Dynamic Host Configuration Protocol (DHCP) (protocollo di
configurazione IP dinamica) è un protocollo di rete di livello applicativo che permette ai dispositivi o terminali di
una certa rete locale di ricevere dinamicamente ad ogni richiesta di accesso ad una rete IP (quale ad esempio
Internet) la configurazione IP necessaria per stabilire una connessione ed operare su una rete più ampia basata su
Internet Protocol cioè interoperare con tutte le altre sottoreti scambiandosi dati, purché anch'esse integrate allo stesso
modo con il protocollo IP.
Generalità
In una rete basata sul protocollo IP, ogni calcolatore ha bisogno di un indirizzo IP, scelto in modo tale che
appartenga all'insieme di indirizzi possibili assegnati all'intera sottorete (cioè al Net_ID) a cui è collegato e che sia
univoco, cioè non ci siano altri calcolatori che stiano già utilizzando quell'indirizzo.
Il compito di assegnare manualmente gli indirizzi IP ai calcolatori comporta infatti un rilevante onere per gli
amministratori di rete, soprattutto in reti di grandi dimensioni o in caso di numerosi computer che si connettono a
rotazione solo a ore o giorni determinati. Inoltre gli indirizzi IPv4 (attualmente usati nella quasi totalità delle reti al
mondo) con l'aumentare dei computer connessi a Internet hanno cominciato a scarseggiare, diminuendo la
disponibilità di IP fissi per eventuali configurazioni statiche.
DHCP supporta questo compito automaticamente ed in maniera dinamica cioè solo quando richiesto dall'host. Viene
utilizzato soprattutto in reti locali, in particolare su Ethernet. In altri contesti, funzioni simili sono svolte all'interno di
PPP. Una volta ricevuta la configurazione di rete la stazione o computer della rete locale diventa a tutti gli effetti un
host (ospite) della rete Internet e può intraprendere sessioni di navigazione Web e tutti gli altri servizi offerti dalla
Rete stessa.
15
Dynamic Host Configuration Protocol
Parametri gestiti da DHCP
Il protocollo DHCP viene usato anche per assegnare al computer diversi parametri necessari per il suo corretto
funzionamento sulla rete a cui è collegato. Tra i più comuni, oltre all'assegnazione dinamica dell'indirizzo IP, si
possono citare:
•
•
•
•
•
•
•
Maschera di sottorete
Default Gateway
Indirizzi dei server DNS
Nome di dominio DNS di default
Indirizzi dei server WINS
Indirizzi dei server NTP
Indirizzo di un server tftp e nome di un file da caricare per calcolatori che caricano dalla rete l'immagine del
sistema operativo (si veda Preboot Execution Environment).
• Parametri di configurazione del proxy WPAD
Nel protocollo c'è comunque il supporto per assegnare tramite DHCP molti altri parametri, definiti nell'RFC 2132.
Componenti del protocollo
Il Client DHCP è un calcolatore che ha bisogno di ottenere un indirizzo IP valido per la sottorete a cui è collegato, e
anche il programma che si occupa di richiedere l'indirizzo IP e configurarlo.
Il Server DHCP è il calcolatore che assegna gli indirizzi IP, e anche il processo che svolge questa funzione. Talvolta
questa funzione è incorporata in un router.
Il DHCP relay è il calcolatore (o più spesso una funzione implementata in un router) che si occupa di inoltrare le
richieste DHCP ad un server, qualora questo non sia sulla stessa sottorete. Questo componente è necessario solo se
un server DHCP deve servire molteplici sottoreti. Deve esistere almeno un DHCP relay per ciascuna sottorete
servita. Ogni relay deve essere esplicitamente configurato per inoltrare le richieste a uno o più server.
Richiesta e attribuzione dell'indirizzo
DHCP utilizza il protocollo UDP, le porte registrate sono la 67 per il server e la 68 per il client.
Quando un calcolatore vuole ottenere un indirizzo tramite DHCP, attiva il processo DHCP client. In questo
momento, il calcolatore non ha un indirizzo IP valido, quindi non può usare tutte le funzionalità della rete.
La procedura descritta dal protocollo consta di diversi handshake tra client e server ovvero scambio di pacchetti
ovviamente tutti incapsulati in frame di livello datalink come ad esempio Ethernet:
• In primis il client invia un pacchetto chiamato DHCPDISCOVER in broadcast, con indirizzo IP sorgente messo
convenzionalmente a 0.0.0.0, e destinazione 255.255.255.255 (indirizzo di broadcast).
• Il pacchetto viene ricevuto da tutto il dominio di broadcast ed in particolare da tutti i server DHCP presenti, i
quali possono rispondere (o meno) ciascuno con un pacchetto di DHCPOFFER in cui propongono un indirizzo
IP e gli altri parametri di configurazione al client. Questo pacchetto di ritorno è indirizzato direttamente
all'indirizzo di livello datalink del client (che non ha ancora un indirizzo IP) cioè in unicast, per cui può essere
inviato solo da un server che si trovi sullo stesso dominio di broadcast.
Se nel dominio di broadcast ci sono anche uno o più DHCP relay, questi inoltrano il pacchetto al loro server di
riferimento, che può rispondere al client sempre attraverso il relay. Il relay agent comunica al server il proprio
indirizzo IP sulla sottorete da cui ha ricevuto il pacchetto di DHCPDISCOVER, permettendo al server di capire da
quale sottorete è arrivata la richiesta, e quindi offrire un indirizzo per la sottorete giusta. Un server DHCP che debba
servire diverse sottoreti IP deve essere configurato per conoscere i parametri di ciascuna (indirizzo della rete,
maschera di sottorete, indirizzo di broadcast, indirizzo del gateway).
16
Dynamic Host Configuration Protocol
• Il client aspetta per un certo tempo di ricevere una o più offerte, dopodiché ne seleziona una, ed invia un
pacchetto di DHCPREQUEST in broadcast, indicando all'interno del pacchetto, con il campo "server identifier",
quale server ha selezionato. Anche questo pacchetto raggiunge tutti i server DHCP presenti sulla rete
(direttamente o tramite un relay).
• Il server che è stato selezionato conferma l'assegnazione dell'indirizzo con un pacchetto di DHCPACK
(nuovamente indirizzato in unicast all'indirizzo di livello datalink del client, possibilmente attraverso un relay); gli
altri server vengono automaticamente informati che la loro offerta non è stata scelta dal client, e che sulla
sottorete è presente un altro server DHCP.
Scadenza e rinnovo degli indirizzi
A questo punto, il client è autorizzato ad usare l'indirizzo ricevuto per un tempo limitato, detto tempo di lease. Prima
della scadenza, dovrà tentare di rinnovarlo inviando un nuovo pacchetto DHCPREQUEST al server, che gli
risponderà con un DHCPACK se vuole prolungare l'assegnazione dell'indirizzo. Questi sono normali pacchetti IP
unicast scambiati tra due calcolatori che hanno indirizzi validi. Se il client non riesce a rinnovare l'indirizzo, tornerà
allo stato iniziale cercando di farsene attribuire un altro.
Identificazione ed autenticazione dei client
Il client si identifica verso il server attraverso un campo client-id dei pacchetti DHCP. Questo campo ha
normalmente come valore il mac address della scheda di rete per cui si richiede l'indirizzo, ma può anche essere
configurato manualmente. Questa è l'unica forma di autenticazione disponibile per DHCP, ed è piuttosto debole, in
quanto utilizza un dato che viene inviato in broadcast sulla rete locale, e quindi può essere facilmente sniffato da
qualunque altro calcolatore connesso alla stessa rete. Per controllare l'accesso ad una rete esistono metodi più solidi,
che però richiedono un supporto da parte degli switch a cui sono collegati gli utenti, come IEEE 802.1x.
Un server dovrebbe cercare di assegnare allo stesso client sempre lo stesso indirizzo IP su ciascuna sottorete, ma non
ci sono garanzie che questo sia possibile, a meno che un indirizzo non sia associato esclusivamente ad un client.
Il server può utilizzare il campo client-id per decidere quale indirizzo assegnare al client, o quali altri parametri
passargli, o anche di non rispondere per nulla alla richiesta del client.
Identificazione del server, sicurezza
Il server si identifica verso il client con il proprio indirizzo IP. Un client potrebbe quindi decidere di accettare
indirizzi solo da un server già noto.
Qualunque calcolatore collegato ad una sottorete potrebbe fare da server DHCP per i calcolatori di quella sottorete, o
da relay verso un server DHCP arbitrario. È quindi possibile che un calcolatore configurato male o deliberatamente
per fini illeciti offra abusivamente indirizzi IP, creando malfunzionamenti alla rete e/o gravi problemi di sicurezza.
Un calcolatore che abbia ricevuto l'indirizzo IP da un server DHCP mal configurato non sarà in grado di utilizzare la
rete.
Se invece il server DHCP abusivo è configurato per scopi illeciti, le conseguenze possono essere anche peggiori:
esso infatti può offrire indirizzi che sa essere inutilizzati, oppure su una sottorete IP diversa da quella ufficiale,
evitando così di generare conflitti con il server ufficiale, ed indicare sé stesso come default gateway. Dovrà poi
ridirigere le connessioni effettuate dai client verso il gateway ufficiale utilizzando IP masquerading. A questo punto,
potrà intercettare e sniffare tutto il traffico generato dai client, che potrebbero non accorgersi facilmente della
differenza.
Per prevenire questi rischi, alcuni switch offrono una funzionalità detta "DHCP snooping", per cui analizzano tutti i
pacchetti DHCP che li attraversano, fermando quelli che non sono originati da server autorizzati.
17
Dynamic Host Configuration Protocol
Visualizzare la configurazione IP
I sistemi Windows offrono un comando da digitare direttamente su shell, detto ipconfig , che permette di conoscere
la configurazione IP del proprio computer. I comandi sono:
• ipconfig
oppure
• ipconfig /all
L'uscita di quest'ultimo comando fornisce configurazione IP per ogni interfaccia di rete.
Voci correlate
• Bootstrap Protocol (BOOTP)
• NAT
Collegamenti esterni
• RFC 2131 - Dynamic Host Configuration Protocol
• RFC 1534 - Interoperation Between DHCP and BOOTP
• RFC 2132 - DHCP Options and BOOTP Vendor Extensions
• Sito [1] del server DHCP prodotto dall'Internet Software Consortium
Note
[1] http:/ / www. isc. org/ sw/ dhcp
Simple Network Management Protocol
In informatica e telecomunicazioni Simple Network Management Protocol (SNMP) è un protocollo di rete che
appartiene alla suite di protocolli Internet definito dalla IETF (Internet Engineering Task Force). Il protocollo opera
al livello 7 del modello OSI e consente la configurazione, la gestione e la supervisione (monitoring) di apparati
collegati in una rete (siano essi nodi interni di commutazione come i dispositivi di rete e nodi terminali di utenza),
riguardo a tutti quegli aspetti che richiedono azioni di tipo amministrativo (management).
Architettura
I tre componenti logici fondamentali del framework SNMP per il suo funzionamento sono:
1. sistema gestito (managed object);
2. agente di gestione (management agent o master agent) e vari subagent (su sistema gestito);
3. sistema di gestione (manager) da remoto;
Ogni sistema gestito (per esempio un semplice nodo, un router, una stampante o qualsiasi altro dispositivo che
fornisca un'interfaccia di gestione SNMP) ospita un agente di gestione (master agent) e solitamente un certo numero
di subagent. Il master agent ha almeno il ruolo di intermediario fra il manager (che è l'applicazione remota che
prende le decisioni di gestione, per esempio sotto il controllo diretto dell'operatore umano) e i subagent (che sono gli
esecutori di tali decisioni). Ciascun subagent è incaricato di attuare le decisioni di gestione da parte del manager nel
contesto di un particolare sottosistema o relativamente a un particolare aspetto del sistema gestito. In sistemi che
forniscono meccanismi di gestione particolarmente semplici, master agent e subagent possono confluire in un unico
componente software capace sia di dialogare con il manager che di attuarne le decisioni; in questo caso si parlerà
semplicemente di agent.
18
Simple Network Management Protocol
SNMP utilizza quindi una chiara separazione fra il protocollo di gestione e la struttura dell'oggetto gestito.
Nell'architettura SNMP, per ogni sottosistema è definita una base di dati detta MIB (Management Information Base),
gestita dal corrispondente subagent, la quale rappresenta lo stato del sottosistema gestito, o meglio, una proiezione di
tale stato limitata agli aspetti di cui si vuole consentire la gestione. Si tratta di una base dati che si potrebbe definire,
mutuando un termine dalla riflessione, "causalmente connessa": in altre parole, ogni modifica alla MIB causa un
corrispondente mutamento nello stato del sottosistema rappresentato, e viceversa. Garantire questa proprietà della
MIB è la funzione principale del subagent che la gestisce.
L'accesso alla MIB (in lettura e scrittura) rappresenta l'interfaccia fornita al manager per gestire il sistema. Ogni
MIB, pur variando nei contenuti specifici, ha la medesima struttura generale e i medesimi meccanismi generali di
accesso da parte del manager (lettura e scrittura dei dati). Grazie alla connessione causale della MIB, è quindi
possibile al manager agire sullo stato del sottosistema in un modo che è largamente indipendente dalle procedure
concrete che devono poi essere messe in atto (dal subagent) per estrarre le informazioni di stato rappresentate nella
MIB, o attuare le modifiche di stato a seguito di cambiamenti dei contenuti della MIB. Così, per esempio, si potrebbe
avere un dato di MIB che rappresenta l'indirizzo IP del sistema gestito; per modificare tale indirizzo, al manager è
sufficiente accedere alla MIB sovrascrivendo il dato corrispondente, prescindendo dei dettagli di come una tale
modifica venga poi concretamente "attuata" sul sistema gestito attraverso l'agent o il subagent.
Funzionamento
Più in dettaglio, il manager dialoga con i sistemi gestiti essenzialmente in due modi: invia richieste SNMP e riceve
notifiche SNMP.
Porte utilizzate
Viene utilizzata la porta UDP 161 per le interrogazioni e le risposte, e la porta UDP 162 come destinazione dei
messaggi trap SNMP generate dagli agent SNMP.
Richieste
Alcuni esempi di richieste sono:
1.
2.
3.
4.
GET, usata per leggere uno o più dati di MIB;
GETNEXT, usata per leggere iterativamente una sequenza di dati di MIB;
GETBULK, usata per leggere con una sola richiesta grandi porzioni di MIB;
SET, usata per scrivere (modificare) uno o più dati di MIB.
Notifiche
Le notifiche sono messaggi asincroni inviati dall'agent per segnalare eventi occorsi nel sistema gestito (p.es. allarmi
in caso di guasti). Le notifiche SNMP senza acknowledgement vengono comunemente chiamate trap, anche se la
terminologia esatta varia a seconda della versione di SNMP in questione. Le notifiche SNMP con acknowledgment
vengono invece chiamate inform.
Autenticazione ed autorizzazione
Per motivi di sicurezza, i sistemi facenti parte di una rete SNMP vengono raggruppati in una cosiddetta comunità. La
comunità è identificata da una stringa di 32 byte e ciascun sistema può appartenere a più di una di queste comunità.
L'agent SNMP accetta richieste solo da un manager della stessa comunità che si identifica e autentica con la suddetta
stringa ottenendo l'autorizzazione o meno a procedere nel controllo remoto di gestione. L'autorizzazione dei membri
di una comunità ad operare su un oggetto può essere di tre tipi:
19
Simple Network Management Protocol
• read: il manager può interrogare l'agent solo per conoscere lo stato del sistema (solo GET o modalità di sola
lettura);
• write: dove il manager può anche variarne l'impostazione (GET e SET, o modalità lettura/scrittura);
• trap: l'agent può inviare trap al manager.
Trasporto
Tipicamente, SNMP utilizza le porte UDP 161 per l'agent e 162 per il manager.
Voci correlate
• Amministratore di sistema
• Amministratore di rete
Collegamenti esterni
• SimpleWeb [1]
• http://www.henrys.de/daniel/download/SNMP.HTM
• SNMP FAQ part 1 [2]
• SNMP FAQ part 2 [3]
• RFC:
•
•
•
•
RFC 1157 - A Simple Network Management Protocol (SNMP)
RFC 1441 - Introduction to version 2 of the Internet-standard Network Management Framework
RFC 3410 - Introduction and Applicability Statements for Internet Standard Management Framework
RFC 3411 - Standard 62 - An Architecture for Describing Simple Network Management Protocol (SNMP)
Management Frameworks
• RFC 3412 - Standard 62 - Message Processing and Dispatching for the Simple Network Management Protocol
(SNMP)
• RFC 3413 - Standard 62 - Simple Network Management Protocol (SNMP) Application
• RFC 3414 - Standard 62 - User-based Security Model (USM) for version 3 of the Simple Network
Management Protocol (SNMPv3)
• RFC 3415 - Standard 62 - View-based Access Control Model (VACM) for the Simple Network Management
Protocol (SNMP)
• RFC 3416 - Standard 62 - Version 2 of the Protocol Operations for the Simple Network Management Protocol
(SNMP)
• RFC 3417 - Standard 62 - Transport Mappings for the Simple Network Management Protocol (SNMP)
• RFC 3418 - Standard 62 - Management Information Base (MIB) for the Simple Network Management
Protocol (SNMP)
• RFC 3584 - Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network
Management Framework
• RFC 3512 - Configuring Networks and Devices with Simple Network Management Protocol (SNMP)
• Implementazioni:
• Net-SNMP: Open source SNMP implementation [4]
• Netsnmpj: Open source SNMP for Java [5]
• OpenSNMP: multi-threaded SNMPv3 engine [6]
• Cisco:
• Configuring SNMP Support [7]
• Cisco SNMP command reference [8]
20
Simple Network Management Protocol
• Cisco IOS MIB Tools [9]
Note
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
http:/ / www. simpleweb. org
http:/ / www. snmp. com/ FAQs/ snmp-faq-part1. txt
http:/ / www. snmp. com/ FAQs/ snmp-faq-part2. txt
http:/ / www. net-snmp. org/
http:/ / netsnmpj. sourceforge. net/
http:/ / sourceforge. net/ projects/ opensnmp/
http:/ / www. cisco. com/ univercd/ cc/ td/ doc/ product/ software/ ios122/ 122cgcr/ ffun_c/ fcfprt3/ fcf014. htm
http:/ / www. cisco. com/ univercd/ cc/ td/ doc/ product/ software/ ios123/ 123cgcr/ fun_r/ cfr_1g11. pdf
http:/ / www. cisco. com/ go/ mibs
File Transfer Protocol
Il File Transfer Protocol (FTP) (protocollo di trasferimento file), è un protocollo per la trasmissione di dati tra host
basato su TCP.
FTP è uno dei primi protocolli definiti ed ha subito una lunga evoluzione negli anni. La prima specifica, sviluppata
presso il MIT, risale al 1971 (RFC-114 [1]). L'attuale specifica fa riferimento all'RFC-959 [2].
Gli obiettivi principali di FTP descritti nella sua RFC ufficiale sono:
•
•
•
•
Promuovere la condivisione di file (programmi o dati)
Incoraggiare l'uso indiretto o implicito di computer remoti.
Risolvere in maniera trasparente incompatibilità tra differenti sistemi di stoccaggio file tra host.
Trasferire dati in maniera affidabile ed efficiente.
Altro protocollo usato per il trasporto dati in Internet è il protocollo HTTP.
21
File Transfer Protocol
Il modello
Dove:
• PI (protocol interpreter) è l'interprete del protocollo, utilizzato da client (User-PI) e server (Server-PI) per lo
scambio di comandi e risposte. In gergo comune ci si riferisce ad esso come "canale comandi".
• DTP (data transfer process) è il processo di trasferimento dati, utilizzato da client (User-DTP) e server
(Server-DTP) per lo scambio di dati. In gergo comune ci si riferisce ad esso come "canale dati".
Funzionamento generale
FTP, a differenza di altri protocolli come ad esempio HTTP, utilizza due connessioni separate per gestire comandi e
dati. Un server FTP rimane tipicamente in ascolto sulla porta 21 TCP a cui si connette il client. La connessione da
parte del client determinerà l'inizializzazione del canale comandi attraverso il quale client e server si scambieranno
comandi e risposte. Lo scambio effettivo di dati (come ad esempio file) richiederà l'apertura del canale dati il quale
può essere di due tipi.
In un canale dati di tipo attivo il client apre una porta tipicamente random, tramite il canale comandi rende noto il
numero di tale porta al server e attende che esso si connetta. Una volta che il server ha attivato la connessione dati al
client FTP, quest'ultimo effettua il binding della porta sorgente alla porta 20 del server FTP. A tale scopo possono
venire impiegati i comandi PORT o EPRT, a seconda del protocollo di rete utilizzato (tipicamente IPv4 o IPv6).
In un canale dati di tipo passivo il server apre una porta tipicamente random (> 1023), tramite il canale comandi
rende noto il numero di tale porta al client e attende che esso si connetta. A tale scopo possono venire impiegati i
comandi PASV o EPSV, a seconda del protocollo di rete utilizzato (tipicamente IPv4 o IPv6).
Sia il canale comandi sia il canale dati sono delle connessioni TCP; FTP crea un nuovo canale dati per ogni file
trasferito all'interno della sessione utente, mentre il canale comandi rimane aperto per l'intera durata della sessione
utente, in altre parole il canale comandi è persistente mentre il canale dati è non persistente.
22
File Transfer Protocol
23
Un server FTP offre svariate funzioni che permettono al client di interagire con il suo filesystem e i file che lo
popolano, tra cui:
•
•
•
•
•
Download/upload di file.
Resume di trasferimenti interrotti.
Rimozione e rinomina di file.
Creazione di directory.
Navigazione tra directory.
FTP fornisce inoltre un sistema di autenticazione (N.B. in chiaro) degli accessi. Il client che si connette potrebbe
dover fornire delle credenziali a seconda delle quali gli saranno assegnati determinati privilegi per poter operare sul
filesystem. L'autenticazione cosiddetta "anonima" prevede che il client non specifichi nessuna password di accesso e
che lo stesso abbia privilegi che sono tipicamente di "sola lettura".
Comandi
Lista dei comandi definiti nella RFC-959 [2].
Comandi
Nome
Comando
Parametri
Descrizione
Abort
ABOR
Interrompe trasferimento dati.
Account
ACCT
<account-information> Informazioni account (raramente usato).
Allocate
ALLO
<decimal-integer>
Alloca spazio sufficiente per ricevere un file (raramente usato).
Append (with
create)
APPE
<pathname>
Appende dati ad un file esistente.
Change to parent
directory
CDUP
Change working
directory
CWD
<pathname>
Cambia directory corrente.
Delete
DELE
<pathname>
Cancella file.
Help
HELP
<command>
Ritorna la lista dei comandi accettati dal server. Con argomento fornisce
spiegazioni riguardo al comando specificato.
List
LIST
<pathname>
Lista il contenuto di una directory o le proprietà di un singolo file.
Trasfer mode
MODE
<mode-type>
Imposta la modalità di trasferimento (S=stream, B=block,
C=compressed).
Make directory
MKD
<pathname>
Crea directory.
Name list
NLST
<pathname>
Ritorna il nome dei file della directory specificata.
Noop
NOOP
Password
PASS
Passive
PASV
Data port
PORT
Print working
directory
PWD
Ritorna nome della directory corrente.
Logout
QUIT
Disconnette. Se un trasferimento è ancora in corso attende che termini prima di
chiudere la sessione.
Reinitialize
REIN
Effettua il log-off dell'utente loggato.
Va alla parent directory.
Non fa nulla (usato prevalentemente per prevenire disconnessioni per inattività
prolungata).
<password>
Specifica la password dell'utente.
Inizializza connessione dati passiva.
<host-port>
Inizializza connessione dati attiva.
File Transfer Protocol
24
Restart
REST
<marker>
Riprende il trasferimento dall'offset indicato.
Retrieve
RETR
<pathname>
Preleva file (da server a client).
Remove directory
RMD
<pathname>
Rimuove directory.
Rename from
RNFR
<pathname>
Rinomina (sorgente).
Rename to
RNTO
<pathname>
Rinomina (destinazione).
Site parameters
SITE
<command>
Manda comando specifico per il server (non standardizzato; varia tra
implementazioni).
Structure mount
SMNT
<pathname>
Monta struttura (raramente usato).
Status
STAT
<pathname>
Ritorna statistiche riguardo al server. Con argomento lista il contenuto di una
directory utilizzando il canale comandi.
Store
STOR
<pathname>
Spedisce un file (da client a server).
Store unique
STOU
<pathname>
Spedisce un file (da client a server) utilizzando un nome univoco.
File structure
STRU
<structure-code>
Imposta la struttura dati (F=file, R=record, P=page). Praticamente
inutilizzato. Il valore di default è F.
System
SYST
Representation
type
TYPE
<type>
Imposta la modalità di trasferimento (A=ASCII, E=EBCDIC, I=Binary,
L=Local). Il valore di default è A. EBCDIC e Local sono raramente usati
(esempio: unicamente su sistemi mainframe).
User Name
USER
<username>
Specifica nome utente.
Ritorna tipo di sistema operativo.
Codici di risposta
• 1xx: Risposta positiva preliminare. L'azione richiesta è iniziata ma ci sarà un'altra risposta ad indicare che essa è
effettivamente completata.
• 2xx: Risposta positiva definitiva. L'azione richiesta è completata. Il client può ora mandare altri comandi.
• 3xx: Risposta positiva intermedia. Il comando è stato accettato ma è necessario mandarne un secondo affinché la
richiesta sia completata definitivamente.
• 4xx: Risposta negativa temporanea. Il comando non è andato a buon fine ma potrebbe funzionare in un secondo
momento.
• 5xx: Risposta negativa definitiva. Il comando non è andato a buon fine e il client non dovrebbe più ripeterlo.
• x0x: Errore di sintassi.
• x1x: Risposta ad una richiesta informativa.
• x2x: Risposta relativa alla connessione.
• x3x: Risposta relativa all'account e/o ai permessi.
• x4x: Non meglio specificato.
• x5x: Risposta relativa al file-system.
File Transfer Protocol
Problemi relativi alla sicurezza
La specifica originale di FTP non prevede alcuna cifratura per i dati scambiati tra client e server. Questo comprende
nomi utenti, password, comandi, codici di risposta e file trasferiti i quali possono essere "sniffati" o visionati da
malintenzionati in determinate situazioni (esempio: ambienti intranet).
Il problema è comune a diversi altri protocolli utilizzati prima della diffusione di SSL quali HTTP, TELNET e
SMTP. Per ovviare al problema è stata definita una nuova specifica che aggiunge al protocollo FTP originale un
layer di cifratura SSL/TLS più una nuova serie di comandi e codici di risposta. Il protocollo prende il nome di FTPS
ed è definito nella RFC-4217 [3]. Da non confondersi con SFTP che è comunque una valida alternativa per ovviare al
problema descritto.
Applicazioni che svolgono il ruolo di trasferimento dati per il tramite di FTP
FileZilla, Fire Downloader, JDownloader sono alcuni dei tanti gestori di download che permettono di trasferire i dati
mediante connessione FTP.
Tuttavia nei sistemi operativi, in genere, si può effettuare l'accesso anche tramite riga di comando.
Collegamenti esterni
•
•
•
•
(EN) RFC 959 FTP (traduzione in italiano [4])
(EN) RFC 2228 FTP Security Extensions
(EN) RFC 2640 Internationalization of FTP
(EN) RFC 4217 Securing FTP with TLS
Note
[1]
[2]
[3]
[4]
http:/ / www. networksorcery. com/ enp/ protocol/ ftp. htm
http:/ / www. faqs. org/ rfcs/ rfc959. html
http:/ / www. faqs. org/ rfcs/ rfc4217. html
http:/ / www. rfc. altervista. org/ rfctradotte/ rfc959_tradotta. txt
25
Domain Name System
Domain Name System
Il sistema dei nomi a dominio, in inglese Domain Name System (spesso indicato con l'acronimo DNS), è un
sistema utilizzato per la risoluzione di nomi dei nodi della rete (in inglese host) in indirizzi IP e viceversa. Il servizio
è realizzato tramite un database distribuito, costituito dai server DNS.
Descrizione
Il nome DNS denota anche il protocollo che regola il funzionamento del servizio, i programmi che lo implementano,
i server su cui questi girano, l'insieme di questi server che cooperano per fornire il servizio.
I nomi DNS, o "nomi di dominio", sono una delle caratteristiche più visibili di Internet.
C'è confusione in merito alla definizione dell'acronimo: la S spesso viene interpretata come service, ma la
definizione corretta è system.
L'operazione di convertire un nome in un indirizzo è detta risoluzione DNS, convertire un indirizzo IP in nome è
detto risoluzione inversa.
Motivazioni ed utilizzi
• La possibilità di attribuire un nome testuale facile da memorizzare a un server (ad esempio un sito world wide
web) migliora di molto l'uso del servizio, in quanto noi esseri umani troviamo più facile ricordare nomi testuali
(mentre gli host e i router sono raggiungibili utilizzando gli indirizzi IP numerici). Per questo, il DNS è
fondamentale per l'ampia diffusione di internet anche tra utenti non tecnici, ed è una delle sue caratteristiche più
visibili.
• È possibile attribuire più nomi allo stesso indirizzo IP (o viceversa) per rappresentare diversi servizi o funzioni
forniti da uno stesso host (o più host che erogano lo stesso servizio). Questa flessibilità risulta utile in molti casi:
• Nel caso in cui si debba sostituire il server che ospita un servizio, o si debba modificare il suo indirizzo IP, è
sufficiente modificare il record DNS, senza dover intervenire sui client.
• Un utilizzo molto popolare di questa possibilità è il cosiddetto virtual hosting basato sui nomi, una tecnica per
cui un web server dotato di una singola interfaccia di rete e di singolo indirizzo IP può ospitare più siti web,
usando l'indirizzo alfanumerico trasmesso nell'header HTTP per identificare il sito per cui viene fatta la
richiesta.
• Utilizzando nomi diversi per riferirsi ai diversi servizi erogati da un host, è possibile spostare una parte dei
servizi su un altro host, e spostare i client su questo nuovo host modificando il suo record nel DNS.
• Facendo corrispondere più indirizzi IP a un nome, il carico dei client viene distribuito su diversi server,
ottenendo un aumento delle prestazioni complessive del servizio e una tolleranza ai guasti (ma è necessario
assicurarsi che i diversi server siano sempre allineati, ovvero offrano esattamente lo stesso servizio ai client).
• La risoluzione inversa è utile per identificare l'identità di un host, o per leggere il risultato di un traceroute.
• Il DNS viene usato da numerose tecnologie in modo poco visibile agli utenti, per organizzare le informazioni
necessarie al funzionamento del servizio.
26
Domain Name System
Storia
Il DNS fu ideato il 23 giugno 1983 da Paul Mockapetris, Jon Postel e Craig Partrige; le specifiche originali sono
descritte nello standard RFC 882. Nel 1987 vennero pubblicati commenti allo standard RFC del DNS, con i nomi
RFC 1034 e RFC 1035 rendendo obsolete le specifiche precedenti.
Nomi DNS
Un nome di dominio è costituito da una serie di stringhe separate da punti, ad esempio it.wikipedia.org. A differenza
degli indirizzi IP, dove la parte più importante del numero è la prima partendo da sinistra, in un nome DNS la parte
più importante è la prima partendo da destra. Questa è detta dominio di primo livello (o TLD, Top Level Domain),
per esempio .org o .it.
Un dominio di secondo livello consiste in due parti, per esempio wikipedia.org, e così via. Ogni ulteriore
elemento specifica un'ulteriore suddivisione. Quando un dominio di secondo livello viene registrato all'assegnatario,
questo è autorizzato a usare i nomi di dominio relativi ai successivi livelli come it.wikipedia.org (dominio
di terzo livello) e altri come some.other.stuff.wikipedia.org (dominio di quinto livello) e così via.
Record DNS
Tipi di record
Ad
un
nome
DNS
possono
corrispondere
diversi
tipi
di
informazioni. Per questo motivo,
esistono diversi tipi di record DNS.
Ogni voce del database DNS deve
essere caratterizzata da un tipo. I
principali tipi sono:
• Record A - Indica la corrispondenza
tra un nome ed uno (o più) indirizzi IP (per la precisione indirizzi IPv4, ovvero la versione attualmente in uso).
• Record MX - (Mail eXchange) indica a quali server debba essere inviata la posta elettronica per un certo dominio.
• Record CNAME - Sono usati per creare un alias, ovvero per fare in modo che lo stesso host sia noto con più
nomi. Uno degli utilizzi di questo tipo di record consiste nell'attribuire ad un host che offre più servizi un nome
per ciascun servizio. In questo modo, i servizi possono poi essere spostati su altri host senza dover riconfigurare i
client, ma modificando solo il DNS.
• Record PTR - Il DNS viene utilizzato anche per realizzare la risoluzione inversa, ovvero per far corrispondere ad
un indirizzo IP il corrispondente nome di dominio. Per questo si usano i record di tipo "PTR" (e una apposita zona
dello spazio dei nomi in-addr.arpa).
• Record AAAA - È come il Record A ma lavora con l'IPv6 e restituisce un indirizzo IPv6.
• Record SRV - Identificano il server per un determinato servizio all'interno di un dominio. Possono essere
considerati una generalizzazione dei record MX.
• Record TXT - Associano campi di testo arbitrari ad un dominio. Questi campi possono contenere una descrizione
informativa oppure essere utilizzati per realizzare servizi.
Vi sono anche tipi di record "di servizio", necessari al funzionamento del database distribuito:
• Record NS - Utilizzato per indicare quali siano i server DNS autorevoli per un certo dominio, ovvero per
delegarne la gestione.
• Record SOA - (Start of Authority) usato per la gestione delle zone DNS.
27
Domain Name System
Nel DNS possono essere immessi altri tipi di record, alcuni folcloristici, come "LOC", usato (poco) per riportare le
coordinate geografiche di un sito, altri aggiungono funzioni di sicurezza per evitare manomissioni. Per avere
riferimenti su tutti questi record vedi Tipi di record DNS.
Record multipli
Ad uno stesso nome di dominio, possono essere associati contemporaneamente record di tipo diverso, o più record
dello stesso tipo. Questo generalmente viene fatto per suddividere il carico di un server molto frequentato su più
computer che offrono lo stesso servizio.
Time to live
I record associati ad un nome di
dominio possono cambiare nel tempo,
permettendo ad esempio di assegnare
un nuovo indirizzo IP ad un server,
facendo in modo che questo continui a
rispondere al nome già noto agli utenti.
A ciascun record DNS è associato un
parametro detto "time to live" o TTL
(tempo di vita), che indica per quanto
tempo questo record può venire memorizzato in un sistema di cache DNS prima che venga considerato scaduto.
Quando un server risponde ad una richiesta con un record preso dalla propria cache, assegna alla risposta il time to
live residuo del record. Quindi se il record originariamente ha un TTL di 12 ore, e un server risponde ad una richiesta
con un dato che ha ottenuto due ore prima, nella risposta metterà un TTL di 10 ore.
Utilizzo dei nomi DNS
Un nome di dominio, come per esempio it.wikipedia.org, può essere parte di un URL, come
http://it.wikipedia.org/wiki/Treno, o di un indirizzo e-mail, come per esempio [email protected].
Questi sono gli strumenti più utilizzati per identificare una risorsa su Internet, il che spiega la pervasività dei nomi di
dominio.
Molti nomi di dominio utilizzati per server web hanno nella parte sinistra la stringa di caratteri "www", ma non è
sempre necessario averla. In molti casi, ma non sempre, il nome privato del prefisso "www." porta comunque alla
stessa pagina, come per esempio "ns.nl" e "www.ns.nl".
Realizzazione
I DNS implementano uno spazio gerarchico dei nomi, per permettere che parti di uno spazio dei nomi, conosciute
come "zone", possano essere delegate da un name server ad un altro name server che si trova più in basso nella
gerarchia.
I nomi di dominio sono soggetti a determinate restrizioni: per esempio ogni parte del nome (quella cioè limitata dai
punti nel nome) non può superare i 63 caratteri e il nome complessivo non può superare i 255 caratteri.
I nomi di dominio sono anche limitati ad un sottoinsieme di caratteri ASCII; in questo modo si impedisce di scrivere
nomi e parole con caratteri che non tutti hanno sulla propria tastiera. Per superare questa limitazione, il sistema di
IDNA e basato sul modello Punycode, rileva stringhe Unicode in un insieme di caratteri DNS validi, venne
approvato dall'ICANN e adottato da alcuni registri.
28
Domain Name System
Zone, deleghe e repliche
Una zona DNS è una parte dello
spazio dei nomi, costituita da un
dominio e i suoi sottodomini che non
sono a loro volta delegati, che è sotto
una stessa gestione amministrativa e
quindi è gestita da uno o più server.
La gestione di una zona è delegata
dalla zona superiore tramite dei record
di tipo NS. Ad esempio, nella zona
.org ci sarà una delega per la zona
wikipedia.org ai server DNS che la
gestiscono. Per ragioni di ridondanza,
ciascuna zona è replicata su più
server, e di conseguenza la delega è
costituita da più record NS, che
indicano che ciascuno dei server
indicati contiene le informazioni per
quella zona (ovvero è autoritativo per la zona). All'interno di una zona possono essere delegate delle zone di livello
inferiore, ad esempio in wikipedia.org potrebbero esistere deleghe per devel.wikipedia.org o per
accounting.admin.wikipedia.org.
I diversi server che sono delegati per una zona dovrebbero contenere le stesse informazioni, in modo che uno
qualsiasi di questi possa rispondere ad una query per un record della zona.
Lo schema di replica tipicamente prevede che ci sia un server master (primario), che è quello sul quale vengono
aggiornate le informazioni, e uno o più server slave (secondari), che copiano le informazioni dal master quando
necessario. Per tener traccia delle diverse "versioni" di una zona che possono esserci in circolazione, ed in particolare
per permettere ad un secondario di decidere se deve trasferire la zona dal primario, ogni zona ha un numero di serie,
che deve essere aumentato ogni volta che vengono fatte modifiche sul primario. Per ottenere il numero di serie di
una zona presente su un server, si effettua una interrogazione di tipo SOA. Il secondario confronta il proprio numero
di serie con quello del primario, e se quello del primario è superiore trasferisce la zona.
L'operazione di copia di tutti i record di una zona dal master ad uno slave è detta zone transfer, e può essere
completo (tutto il contenuto della zona viene copiato) o incrementale (vengono copiati solo i record modificati
rispetto alla versione già presente).
Alcune implementazioni di DNS permettono di modificare le zone da qualsiasi server autorevole, propagando le
modifiche sugli altri server.
La radice (root) dell'albero dei nomi DNS è la zona . (punto), che è gestita da un insieme di server chiamati appunto
root servers.
29
Domain Name System
Ricorsione
In generale, per ottenere la risoluzione di un nome è necessario partire dalla radice, interrogare uno dei root server
nel dominio di primo livello, ottenere il server che lo gestisce, interrogarlo nel dominio di secondo livello, fino a
raggiungere il server autorevole per il nome desiderato. Questa tecnica è detta "ricorsione".
Caching
Alcuni server si prestano ad effettuare query ricorsive per conto di alcuni client. Una volta che hanno ottenuto una
risposta, memorizzano in una cache tutte le informazioni che hanno imparato, fino alla loro scadenza. Alcune
implementazioni del servizio DNS permettono di realizzare i cosiddetti servers caching only, ovvero privi di
database proprio, ma utili per reindirizzare ad un server autorevole le query di risoluzione. Tale caratteristica è utile
soprattutto quando la risoluzione deve essere effettuata attraverso collegamenti lenti (con velocità inferiore a 500
kbps) o firewall.
Funzioni dei server
Un server DNS può essere configurato per assolvere ad una o più delle seguenti funzioni:
• server autorevole per una o più zone, ovvero il server su cui sono configurati i dati di una zona, e che è delegato
a gestirla tramite record NS inseriti nella zona superiore. Normalmente sono presenti più server autorevoli per una
zona. Molte implementazioni permettono di modificare i dati di una zona solo su un server:
• primario - server autorevole su cui vengono modificati i dati di una zona
• secondario - server autorevole che copia i dati di zona da un primario
• server ricorsivo - il server che viene configurato in una popolazione di client, che si occupa di risolvere le query
che riceve interrogando i server originali, e mantenendo una cache delle risposte ricevute
• query forwarder - un server che viene configurato in una popolazione di client, che risolve le loro query non
direttamente ma interrogando un server ricorsivo
Origine dei dati
I dati contenuti in una zona possono essere configurati da uno o più operatori, oppure possono essere alimentati da
meccanismi automatici:
• nelle implementazioni più semplici, i dati di zona sono memorizzati in uno o più file sul server primario
• implementazioni più raffinate immagazzinano i dati in un database. In alcuni casi, questo è accessibile non solo
agli operatori del servizio ma anche direttamente ai clienti (è il caso dei servizi DNS commerciali)
DNS dinamico
Il termine DNS dinamico, o DDNS, indica un insieme di tecnologie che permettono di inserire automaticamente in
una zona DNS gli indirizzi di calcolatori che ottengono un indirizzo non predefinito, tipicamente attraverso il
protocollo DHCP o PPP. A questo scopo, sono definite query DNS di "UPDATE".
In una rete locale, questa funzionalità può essere utilizzata direttamente dai client, è presente nei servizi Active
Directory di windows, o può essere configurata usando BIND e il server DHCP di Internet Systems Consortium
(ISC).
Il DDNS viene inoltre utilizzato da servizi commerciali per permettere agli utenti dial-up (modem, ADSL) di
registrare un nome corrispondente all'indirizzo che viene loro assegnato di volta in volta dal loro provider. In questo
modo, un host con indirizzo IP dinamico è sempre raggiungibile. Esistono client DDNS sia sotto forma di
applicazioni che all'interno di router destinati al mercato domestico.
30
Domain Name System
Utilizzo
Per utilizzare il servizio, è necessario configurare su ciascun client uno o più server DNS di riferimento. Questi sono
predisposti a effettuare query ricorsive e che effettuano servizi di caching.
Quando un sistema ha la necessità di comunicare con un altro sistema, chiede al server DNS di riferimento di
effettuare il processo detto di "risoluzione" del nome in un indirizzo IP. Il server effettua una ricerca all'interno del
suo database per ottenere l'indirizzo IP corrispondente al sistema ricercato.
Se il server interrogato possiede l'informazione richiesta, il processo di ricerca termina con l'invio dell'indirizzo IP al
richiedente. Se la ricerca ha esito negativo il server effettua una richiesta "ricorsiva".
Implementazione
Il protocollo DNS è implementato da diversi software. Di seguito alcuni dei più diffusi:
•
•
•
•
•
BIND (Berkeley Internet Name Domain), il nome del più comune demone DNS usato sui sistemi Unix.
DJBDNS (Dan J Bernstein's DNS implementation)
Unbound, un server DNS progettato modularmente e con un riguardo particolare verso DNSSEC.
MaraDNS
NSD (Name Server Daemon)
• PowerDNS
• DDNS (Dynamic Domain Name System) Il servizio DNS alla base dei servizi di directory Microsoft incluso nelle
versioni server da Windows 2000 in poi.
Il DNS utilizza il protocollo di trasporto UDP e la porta 53 per soddisfare le richieste di risoluzione provenienti dagli
host.
I server DNS effettuano gli zone transfer usando il protocollo di trasporto TCP e la porta 53. Questa porta viene
usata anche quando una query ha una risposta molto lunga.
Il lato client del servizio DNS è normalmente implementato tramite librerie di sistema, che spesso lo integrano con
altri servizi di risoluzione, come ad esempio WINS, NIS, o con la consultazione di file locali, in modo che un utente
possa utilizzare un nome simbolico in un'applicazione ed ottenere la sua risoluzione in un indirizzo IP senza
preoccuparsi di quale strumento è stato utilizzato per ottenere la risoluzione.
Il sistema DNS in Internet
Qualsiasi rete IP può usare il DNS per implementare un suo sistema di nomi privato. Tuttavia, il termine "nome di
dominio" è più comunemente utilizzato quando esso si riferisce al sistema pubblico dei DNS su Internet. Questo è
basato su 13 "root server" universali, i cui indirizzi IP sono distribuiti indipendentemente dal DNS tramite un file
detto "root hints" (letteralmente: indizi per la radice). Da questi server principali, il DNS viene poi delegato ad altri
server DNS che si occupano dei nomi all'interno di parti specifiche dello spazio dei nomi DNS.
Dieci dei tredici root server sono, almeno nominalmente, situati negli USA. Tuttavia, dato l'accesso a molti di essi è
realizzato tramite indirizzamento anycast, che permette di assegnare a più computer lo stesso indirizzo IP per fornire
un servizio uniforme su vaste aree geografiche, la maggior parte dei server sono in effetti localizzati al di fuori degli
Stati Uniti.
Il proprietario di un nome di dominio è rintracciabile in un database chiamato Whois: per molti domini di primo
livello un Whois base è gestito dalla IANA, con il Whois dettagliato mantenuto dall'autorità di registrazione che
controlla quel dominio. Per i più di 240 domini nazionali l'autorità di registrazione gestisce in esclusiva il Whois per
il dominio di competenza.
31
Domain Name System
Politica
Allocazione delle zone di primo livello
L'attuale modalità di controllo del sistema DNS offre spesso alcune criticità. Alcuni root servers appartengono a
società private (esempio Verisign) anche se la maggior parte sono controllati da università o altri enti (ad esempio la
NASA)[1]. Non è possibile aggiungere altri root servers, o almeno, non in maniera fisica: a causa di un problema di
compatibilità con il protocollo UDP devono essere visibili solo 13 zone di root servers, ma ogni zona può avere più
server[2].
Utilizzi impropri
Nel 2009, Paul Vixie, presidente dell'Internet Systems Consortium, ha pubblicato sul sito della Association for
Computing Machinery un articolo riguardante pratiche che derivano da interpretazioni sbagliate del concetto di DNS
o lo violano deliberatamente.[3]
Manipolazione delle risposte
Quando un client inoltra una query DNS ad un server ricorsivo, si aspetta di ottenere la risposta "corretta", ovvero il
valore del record DNS richiesto oppure un messaggio di errore se il nome richiesto non esiste. Questo messaggio è
noto come "NXDOMAIN" o anche come "RCODE=3".
Tuttavia, alcuni gestori di server ricorsivi manipolano le risposte fornite ai propri clienti, eliminandone alcune
selettivamente, oppure restituendo un indirizzo IP diverso da quello corretto.
Questa tecnica può essere usata con diversi scopi:
• protezione da abusi: il server DNS può filtrare le query relative a siti pericolosi per gli utenti, ad esempio a causa
della distribuzione di malware, o perché usati per operazioni di phishing;
• censura: vengono filtrate le query relative a siti che si vogliono rendere inaccessibili per decisione politica (del
gestore della rete o di una autorità pubblica). In caso la visita o il tentativo di visita a siti "proibiti" venga
qualificata come indizio di reato, la redirezione del traffico su un server diverso da quello richiesto dall'utente può
permettere la raccolta degli indirizzi IP dei client, o anche in alcuni casi il furto di credenziali;
• man-in-the-middle: le query vengono modificate in modo da reindirizzare tutto o parte del traffico verso un
server che agisce da proxy trasparente, intercettando il traffico degli utenti. Questo permette il monitoraggio del
traffico degli utenti, e quindi anche il furto di informazioni sensibili e/o credenziali;
• redirezione degli errori: alle query per nomi inesistenti viene risposto con l'indirizzo IP di un server, che
tipicamente ospita un motore di ricerca e tenta di aiutare gli utenti a trovare il sito cercato.[3]
Queste tecniche possono essere adottate anche dai gestori di rete, redirigendo le query DNS dirette verso l'esterno su
propri server mediante meccanismi di destination NAT (Network address translation).
Il DNS non è stato progettato per questi utilizzi, pertanto le implicazioni sulla sicurezza degli utenti possono essere
negative, in quanto le informazioni personali condivise tra un utente ed il sito che sta visitando vengono scambiate
anche con siti di terzi, non autorizzati.[3]
32
Domain Name System
Note
[1] Sito ufficiale dei root servers - http:/ / www. root-servers. org/
[2] There are not 13 root servers (http:/ / blog. icann. org/ 2007/ 11/ there-are-not-13-root-servers/ )
[3] Paul Vixie. What DNS is Not. DNS is many things to many people - perhaps too many things to too many people (http:/ / dl. acm. org/ citation.
cfm?id=1647302). novembre 2009
Articolo disponibile anche sul sito (http:/ / queue. acm. org/ detail. cfm?id=1647302) della ACM.
Voci correlate
•
•
•
•
•
•
•
•
Risoluzione DNS inversa
Record DNS
Dynamic DNS
DNSSEC
ICANN
Nslookup
Cybersquatting
Nome di dominio internazionalizzato
Collegamenti esterni
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
DNS Security Extensions (DNSSEC) (http://www.dnssec.net/)
root-servers.org (http://www.root-servers.org/)
(EN) RFC 882, Domain Names - Concepts and Facilities (resa obsoleta da RFC 1034)
(EN) RFC 883, Domain Names - Implementation and Specification (resa obsoleta da RFC 1035)
(EN) RFC 920, Domain Requirements - Specified original top-level domains
(EN) RFC 1032, Domain Administrators Guide
(EN) RFC 1033, Domain Administrators Operations Guide
(EN) RFC 1034, Domain Names - Concepts and Facilities
(EN) RFC 1035, Domain Names - Implementation and Specification
(EN) RFC 1101, DNS Encodings of Network Names and Other Types
(EN) RFC 1123, Requirements for Internet Hosts—Application and Support
(EN) RFC 1178, Choosing a Name for Your Computer (FYI 5)
(EN) RFC 1183, New DNS RR Definitions
(EN) RFC 1591, Domain Name System Structure and Delegation (Informational)
(EN) RFC 1912, Common DNS Operational and Configuration Errors
(EN) RFC 1995, Incremental Zone Transfer in DNS
(EN) RFC 1996, A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)
(EN) RFC 2100, The Naming of Hosts (Informational)
(EN) RFC 2136, Dynamic Updates in the domain name system (DNS UPDATE)
(EN) RFC 2181, Clarifications to the DNS Specification
(EN) RFC 2182, Selection and Operation of Secondary DNS Servers
(EN) RFC 2308, Negative Caching of DNS Queries (DNS NCACHE)
(EN) RFC 2317, Classless IN-ADDR.ARPA delegation (BCP 20)
(EN) RFC 2671, Extension Mechanisms for DNS (EDNS0)
(EN) RFC 2672, Non-Terminal DNS Name Redirection
(EN) RFC 2845, Secret Key Transaction Authentication for DNS (TSIG)
• (EN) RFC 3225, Indicating Resolver Support of DNSSEC
• (EN) RFC 3226, DNSSEC and IPv6 A6 aware server/resolver message size requirements
• (EN) RFC 3597, Handling of Unknown DNS Resource Record (RR) Types
33
Domain Name System
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
(EN) RFC 3696, Application Techniques for Checking and Transformation of Names (Informational)
(EN) RFC 4033, DNS Security Introduction and Requirements
(EN) RFC 4034, Resource Records for the DNS Security Extensions
(EN) RFC 4035, Protocol Modifications for the DNS Security Extensions
(EN) RFC 4343, Domain Name System (DNS) Case Insensitivity Clarification
(EN) RFC 4470, Minimally Covering NSEC Records and DNSSEC On-line Signing
(EN) RFC 4509, Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records
(EN) RFC 4592, The Role of Wildcards in the Domain Name System
(EN) RFC 4635, HMAC SHA TSIG Algorithm Identifiers
(EN) RFC 4892, Requirements for a Mechanism Identifying a Name Server Instance (Informational)
(EN) RFC 5001, DNS Name Server Identifier (NSID) Option
(EN) RFC 5011, Automated Updates of DNS Security (DNSSEC) Trust Anchors
(EN) RFC 5155, DNS Security (DNSSEC) Hashed Authenticated Denial of Existence
(EN) RFC 5395, Domain Name System (DNS) IANA Considerations (BCP 42)
(EN) RFC 5452, Measures for Making DNS More Resilient against Forged Answers'
(EN) RFC 5625, DNS Proxy Implementation Guidelines (BCP 152)
(EN) RFC 5702, Use of SHA-2 Algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC
• Accesso alle funzioni DNS in .NET (http://www.giuseppesicari.it/articoli/framework-dot-net/
domain-name-system)
Telnet
In informatica e telecomunicazioni Telnet è un protocollo di rete utilizzato su Internet. I documenti IETF STD 8
(RFC 854 [1] e RFC 855 [2]) dicono:
L'obiettivo del protocollo TELNET è fornire un supporto per le comunicazioni sufficientemente generalizzato,
bidirezionale ed orientato ai byte (otto bit).
È solitamente utilizzato per fornire all'utente sessioni di login remoto di tipo riga di comando tra host su internet.
Per estensione, telnet è anche il nome di un programma che un utente può usare per avviare una sessione Telnet
ad un host remoto; il programma telnet implementa la parte client del protocollo. I client Telnet sono stati
disponibili sulla maggior parte dei sistemi Unix per parecchi anni e sono disponibili per qualsiasi tipo di computer.
In inglese to telnet è usato come verbo e significa stabilire una connessione Telnet.
Caratteristiche
Telnet è un protocollo client-server basato su TCP; i client solitamente si connettono alla porta 23 sul server
(nonostante la porta possa essere differente, come per parecchi protocolli internet). In parte a causa della
progettazione del protocollo e in parte per la flessibilità tipicamente fornita dai programmi Telnet, è possibile
utilizzare un programma Telnet per stabilire una connessione interattiva ad un qualche altro servizio su un server
internet. Un utilizzo classico è collegarsi col Telnet alla porta 25 (sulla quale tipicamente si trova un server SMTP)
per effettuare il debugging di un server di posta.
Il protocollo Telnet può essere diviso in una parte principale ed in un set di estensioni. La parte principale è descritta
dalle RFC 854 e RFC 855 dell'IETF, che sono anche unite nell'STD 8, e definiscono le caratteristiche base del
protocollo ed il modo di implementare le estensioni. Tra le tante estensioni, alcune sono state adottate come Standard
Internet. I documenti STD dal 27 al 32 definiscono varie estensioni di Telnet, la maggior parte delle quali sono molto
diffuse. Tra le estensioni rimanenti, le più importanti sono quelle proposte dall'IETF come standard; ulteriori dettagli
possono esser trovati nella STD 1.
34
Telnet
Come spiegato più avanti, Telnet non è sicuro e dovrebbe esser generalmente evitato. Il suo uso sulle reti pubbliche
comporta seri rischi di sicurezza.
Usi
I client Telnet sono ancora usati occasionalmente per "parlare" ad altri servizi. Telnet è usato ogni tanto nel debug di
servizi di networking come i server SMTP e HTTP, in quanto rappresenta un modo semplice per mandare comandi
al server ed esaminare le risposte. Telnet può anche essere usato come un rudimentale client IRC se si possiede una
conoscenza adeguata.
Telnet è molto usato per i giochi Multi User Dungeon giocati in rete.
Nel campo della posta elettronica Telnet ha molti validi usi, per esempio è possibile leggere la corrispondenza sulla
propria mailbox, cancellarla oppure spedire missive elettroniche [3]. Visto che normalmente l'accesso alla propria
casella di posta elettronica viene fatto in modo non sicuro oppure a volte da un computer pubblico, i problemi di
sicurezza di Telnet non sono di ostacolo.
A volte con le webmail si hanno problemi di accesso alla propria mailbox che con Telnet si possono risolvere, per
esempio nel caso di superamento della memoria concessa alcune caselle si bloccano e Telnet permette di risolvere il
problema.
Altro particolare interessante di Telnet e la posta elettronica è la possibilità di invio di email anonime oppure email
false (fake email). Se non vengono utilizzati proxy la magistratura tramite la polizia postale è in grado di individuare
il mittente tramite il suo indirizzo IP.
Telnet può essere utilizzato da un comune browser web, in presenza di una connessione (generalmente HTTP) già
attiva ad un Internet Service Provider: Telnet è un protocollo di livello più alto di quelli del livello di trasporto dei
dati, e richiede che una sessione sia già iniziata.
Sicurezza
Ci sono tre problemi principali legati a Telnet, che lo rendono una cattiva scelta per sistemi moderni dal punto di
vista della sicurezza informatica:
• Nei daemon Telnet comunemente usati sono state trovate nel corso degli anni molte vulnerabilità, e
probabilmente altre esistono tuttora.
• Telnet manca di uno schema di autenticazione che renda sicura le comunicazione tra due host e non intercettabile.
• Telnet non cripta i dati inviati tramite la connessione (nemmeno le password) ed è quindi banale catturare i dati
scambiati ed usare la password per scopi malevoli.
In ambienti dove la sicurezza è importante, come la rete pubblica Internet, Telnet non dovrebbe esser usato in quanto
le sessioni telnet non sono criptate. Ciò significa che chiunque abbia accesso ad un router, uno switch o un gateway
posizionato sulla rete tra i due host che stanno comunicando tramite Telnet, può intercettare i pacchetti che lo
attraversano e facilmente ottenere qualsiasi cosa venga scambiata (compresi nomi utente e password) con programmi
di sniffing come tcpdump e Wireshark (precedentemente chiamato Ethereal).
Queste falle han fatto sì che l'uso del protocollo Telnet cadesse rapidamente a favore del più sicuro protocollo SSH,
rilasciato nel 1998. SSH offre tutte le funzioni di Telnet più una sicura criptazione, che previene l'intercettazione dei
dati scambiati, ed un'autenticazione a chiave pubblica, che assicura l'identità del server remoto.
Gli esperti di sicurezza informatica, come l'Istituto SANS ed i membri del newsgroup di comp.os.linux.security,
consigliano di interrompere l'uso di Telnet per login remoti in circostanze normali.
Quando Telnet è stato sviluppato all'inizio degli anni ottanta, secondo alcune fonti [4] addirittura nel 1969, la maggior
parte degli utenti delle reti appartenevano a dipartimenti di istituti accademici o a centri di ricerca privati o
governativi. In quest'ambiente, la sicurezza non era così importante quanto lo è oggi, con l'espansione della banda
35
Telnet
36
larga e la rete globale. Con la crescita esponenziale del numero di persone che accedono ad Internet, e quindi del
numero di coloro che vogliono entrare in sistemi altrui con intenzioni malevoli, Telnet non dovrebbe essere usato in
reti Internet.
Note
[1]
[2]
[3]
[4]
http:/ / www. ietf. org/ rfc/ rfc854. txt
http:/ / www. ietf. org/ rfc/ rfc855. txt
Spedire o ricevere posta con Telnet (http:/ / www. kensan. it/ articoli/ Telnet. php)
http:/ / philip. greenspun. com/ ancient-history/ history-of-computer-science
rsync
rsync
Sviluppatore
Wayne Davison
Ultima versione 3.0.9 (23 settembre 2011)
S.O.
Multipiattaforma
Genere
Strumenti di sistema
Licenza
GPL
(Licenza libera)
Sito web
http:/ / rsync. samba. org
[1]
rsync è un software per Unix che sincronizza file e cartelle da una posizione all'altra minimizzando il trasferimento
di dati utilizzando quando possibile la codifica delta.
Un'importante caratteristica di rsync che non trova riscontri in programmi/protocolli simili è che il mirroring avviene
attraverso una sola trasmissione di dati per ogni direzione di comunicazione.
rsync può copiare o visualizzare il contenuto delle directory e copiare i file, utilizzando opzionalmente la
compressione dei dati e la ricorsione. Per default, rsync effettua la copia attraverso una connessione TCP sulla porta
873.
Algoritmo
L'algoritmo usato da rsync per la trasmissione efficiente di dati (tipicamente, i contenuti di un file) a un altro
computer che dispone di una versione precedente degli stessi dati è stato inventato dal programmatore Australiano
Andrew Tridgell, ed è descritto brevemente nel seguito.
Il ricevente spezza la sua copia del file in blocchi contigui di dimensione fissata
, e per ciascuno dei blocchi
calcola due checksum: la funzione hash MD4 e un checksum ciclico (meno preciso della MD4). Entrambi i valori
vengono inviati al mittente.
Il mittente calcola invece il checksum per tutti i possibili blocchi di lunghezza
della sua versione del file, anche
sovrapposti. Il calcolo può essere svolto efficientemente grazie a una proprietà del checksum ciclico: sia
checksum ciclico del blocco che va dal byte
valore dei byte alle posizioni
e
al byte
, allora
dipende solo da
, senza che sia necessario riesaminare i byte da
il
e dal
a
. Per grandi, il risparmio è notevole.
A questo punto il mittente compara i suoi checksum ciclici con quelli inviati dal ricevente, per verificare se ci sono
delle corrispondenze. Se ci sono, viene calcolato e controllato anche il corrispondente hash MD4 (più costoso) per
rsync
verificare se i blocchi sono effettivamente identici. A questo punto, il mittente invia al ricevente solo le parti del file
per cui non sono stati trovati blocchi corrispondenti, insieme a istruzioni su come ricomporre i blocchi già presenti e
le parti nuove in modo da ottenere una copia esatta del file originale. Se le due versioni del file hanno molte sezioni
in comune, com'è spesso il caso quando si tratta di versioni diverse dello stesso file, rsync può effettuare la
sincronizzazione trasmettendo molti meno dati rispetto alla dimensione dell'intero file.
Altre caratteristiche
L'algoritmo descritto sopra costituisce la base del funzionamento di rsync, ma l'applicazione fornisce varie altre
funzioni utili per ottimizzare il trasferimento e semplificare la creazione di copie di backup. Fra le altre, possiamo
citare l'uso di algoritmi di compressione per ridurre ulteriormente la dimensione dei dati trasferiti, e il supporto al
protocollo ssh per realizzare trasferimenti crittografati e quindi sicuri. In combinazione con utility UNIX standard
quali cron, rsync può essere usato per implementare facilmente backup centralizzati dei dati degli utenti su un server
centrale, oppure un sistema di mirroring di grandi quantità di dati.
Varianti
rdiff e rdiff-backup
Esiste un programma di utilità chiamato rdiff che usa l'algoritmo di rsync per generare un file delta contenente la
differenza fra due file A e B, nel formato usato da rsync. Il file delta può poi essere applicato in un secondo tempo al
file A, trasformandolo nel file B. L'operazione svolta è analoga a quella dei comandi UNIX diff e patch, ma
utilizzando un formato più efficiente per memorizzare le differenze.
A differenza di diff, la creazione del file delta richiede due fasi: dapprima viene generato un piccolo file firma da A,
quindi il file firma e B vengono usati per generare il file delta. Inoltre, rdiff funziona egregiamente con file binari,
per cui invece non è possibile usare diff.
Appoggiandosi a rdiff, un altro programma di utilità chiamato rdiff-backup mantiene un backup di un file o
directory su un server remoto, memorizzando i file delta per ogni versione dei dati archiviati. Usando i delta
memorizzati, si può poi ricostruire lo stato esatto dei dati in un qualunque momento fissato.
rsyncX e rsyncXCD
Una versione speciale di rsync per il file system del Mac OS X, rsyncX, trasferisce anche le cosiddette resource fork
(dati addizionali contenuti nei file del Mac), che non sono supportate da rsync (né da altri programmi UNIX). Con
Mac OS 10.4, la Apple ha inserito delle modifiche nella propria versione di rsync per fornire funzionalità analoghe.
rsyncXCD è una versione di rsyncX che consente di creare partizioni di boot.
Interfaccia grafica
rsync non possiede una propria interfaccia grafica, ma solo quella testuale. Esiste tuttavia il programma Grsync,
rilasciato sotto licenza GPL, che implementa una interfaccia grafica per rsync. Degno di nota è inoltre il progetto
FlyBack che si prefigge il compito di portare il programma di backup Time Machine di Apple MacOS X 10.5
Leopard in ambiente GNU/Linux proprio utilizzando rsync come applicazione di copia dati e gli hard link in un
singolo file system.
37
rsync
38
Windows
Come per altre utilità UNIX, per eseguire rsync su Microsoft Windows è necessario avere installato il pacchetto
Cygwin, che fornisce ai programmi una emulazione di ambiente UNIX su Windows. Sono disponibili alcuni
pacchetti che includono rsync, cygwin e un programma di installazione, rendendo rsync accessibile agli utenti
Windows. Fra gli altri:
•
•
•
•
cwRsync [2] (Licenza MIT)
NasBackup [3] (GNU General Public License), che fornisce anche un'interfaccia grafica
DeltaCopy [4] (GNU General Public License), che include un'interfaccia grafica e dei servizi di programmazione.
Unison file Synchronzer [5] (GNU General Public License), che fornisce anche un'interfaccia grafica
Tuttavia, va notato che si possono verificare dei piccoli problemi usando rsync fra macchine con diversi sistemi
operativi, in particolare per quanto riguarda le date di modifica dei file, l'accuratezza con cui vengono trasmesse
alcune informazioni ausiliarie sui file (proprietario, diritti, ecc.) e le possibili ambiguità fra nomi di file in maiuscolo
e minuscolo su Windows.
Collegamenti esterni
• (EN) La home page di rsync [6]
•
•
•
•
•
•
•
•
(EN) Tutorial: Using rsync [7]
Usare rsync+SSH per il backup [8]
Usare rsync per il backup [9]
(EN) L'algoritmo di rsync [10]
(EN) La versione di rsync per [[Mac OS X [11]]]
(EN) Unison, un altro tool di sincronizzazione bidirezionale [5]
(EN) Grsync, interfaccia grafica per rsync basata su GTK [12]
(EN) flyback, programma grafico che usa hard link ed rsync per il backup di propri file [13]
Note
[1] http:/ / rsync. samba. org/
[2] http:/ / itefix. no/ cwrsync
[3] http:/ / sourceforge. net/ projects/ nasbackup/
[4] http:/ / www. aboutmyip. com/ AboutMyXApp/ DeltaCopy. jsp
[5] http:/ / www. cis. upenn. edu/ ~bcpierce/ unison/
[6] http:/ / rsync. samba. org
[7] http:/ / everythinglinux. org/ rsync/
[8] http:/ / www. unixware. it/ wiki/ ssh-rsync
[9] http:/ / openskills. info/ infobox. php?ID=193
[10] http:/ / rsync. samba. org/ tech_report/ node2. html
[11] http:/ / archive. macosxlabs. org/ rsyncx/ rsyncx. html
[12] http:/ / www. opbyte. it/ grsync/
[13] http:/ / code. google. com/ p/ flyback/
Real-time Transport Protocol
39
Real-time Transport Protocol
In telecomunicazioni l' RTP o Real-time Transport Protocol è un protocollo del livello applicazioni utilizzato per
servizi di comunicazione in tempo reale su Internet.
Descrizione
È stato sviluppato da un gruppo di ricerca noto come Audio-Video Transport Working Group, facente capo alla
IETF (Internet Engineering Task Force). Il corrispondente RFC è stato pubblicato nel 1996.
RTP doveva inizialmente essere un protocollo multicast, ma viene più spesso impiegato in applicazioni unicast. È
basato sul protocollo UDP e viene usato in congiunzione con RTCP (RTP Control Protocol) che monitora la qualità
del servizio e trasporta le informazioni riguardo ai partecipanti ad una sessione. RTCP è sufficiente per sessioni
“loosely controlled”, in cui cioè non c’è un reale controllo dei partecipanti e set-up della sessione, e non è necessario
che tutti i requisiti di controllo siano soddisfatti. Per questo RTP può essere coadiuvato da un protocollo apposito per
la gestione delle sessioni (come SIP o H.323). Rappresenta una delle tecnologie fondamentali nell'industria della
telefonia su IP.
Questo protocollo permette distribuzione di servizi che necessitano di trasferimento in tempo reale, come
l'interattività audio e video. Fra questi servizi si trovano anche:
•
•
•
•
l'identificazione del payload type
la numerazione sequenziale
la marcazione temporale (timestamp)
la monitorazione.
Solitamente le applicazioni pongono l'RTP sopra l'UDP per le operazioni di multiplexing e checksum, anche se può
essere usato con altri protocolli di rete e trasporto sottostanti.
I numeri di sequenza (sequence numbers) che troviamo nel protocollo RTP permettono all'utente che riceve i dati di
ricostruire la sequenza dei pacchetti del mittente. Le conferenze multicast multimediali non sono però la sua unica
capacità, anche se è stato implementato inizialmente per tale scopo. Ad esempio, trovano posto in questo protocollo
la memorizzazione di un flusso dati continuo, le simulazioni interattive distribuite, le misurazioni e i controlli.
Header
bit offset 0-1 2 3 4-7 8 9-15
0
Ver. P X CC M
PT
16-31
Sequence Number
32
Timestamp
64
SSRC identifier
96
CSRC identifiers (optional)
...
I pacchetti RTP sono formati da un header di minimo 12 byte seguiti da un payload che dipende dalla specifica
applicazione. L’header RTP è formato da:
•
•
•
•
•
Ver. (Version): (2bit) indica la versione del protocollo. La versione corrente è la numero 2.
P (Padding): (1 bit) indica se è presente un byte di padding alla fine del pacchetto.
X (Extension): (1 bit) indica la presenza di un Extension header tra l’header standard e il payload.
CC (CSRC Count): (4 bit) contiene il numero di CSRC identifiers (definiti sotto) che seguono l’header minimo.
M (Marker): (1 bit) Usato dal livello applicativo e quindi definito dal profilo specifico. Se è settato, significa che
il pacchetto ha una qualche speciale rilevanza per il livello applicativo.
Real-time Transport Protocol
• PT (Payload Type): (7 bit) indica il formato del payload e determina la sua interpretazione dall’applicazione.
Questo è specifico per ogni profilo RTP.
• Sequence Number: (16 bit) il sequence number viene incrementato di uno per ogni pacchetto RTP inviato e
permette al ricevente di identificare perdite di pacchetti e ripristinare l’ordine corretto. Il protocollo RTP non
prende provvedimenti quanto un pacchetto viene perduto, ma lascia campo libero all’applicazione. In accordo con
l’RFC 3550, il valore iniziale deve essere casuale per rendere attacchi di tipo known-plaintext più difficili.
• Timestamp: (32 bit) utilizzato per permettere al ricevente di riprodurre il media ricevuto all’intervallo
appropriato. La granularità dipende dall’applicazione ed è definita dallo specifico profilo RTP.
• SSRC: (32 bit) il synchronization source identifier identifica in modo univoco la fonte dello stream all’interno
della sessione RTP.
• CSRC: (da 0 a 15, 32 bit ciascuno) gli identificatori contributing source enumerano le fonti di uno stream
generato da più fonti. Il numero di identificatori CSRC è dato dal valore del campo CC.
Collegamenti esterni
• RFC 3550 Real-time Transport Protocol
• RFC 1889
Livello di trasporto
In telecomunicazioni e informatica nell'ambito delle reti di calcolatori, il livello di trasporto è il quarto dei livelli nel
modello OSI. Il suo compito è di fornire servizi al soprastante livello 5 (livello sessione) e per raggiungere tale scopo
sfrutta i servizi offerti dal sottostante livello 3 (livello rete). Lo scopo del livello di trasporto è fornire un canale
logico-affidabile di comunicazione end-to-end per pacchetti.
Funzionalità
Di seguito vengono riportati i servizi che vengono, in genere, offerti dal livello di trasporto; è bene ricordare che
nessuno di tali servizi è obbligatorio. Di conseguenza, per ciascuna applicazione è possibile scegliere il protocollo
più adatto allo scopo.
• Servizio orientato alla connessione. In genere il livello rete non stabilisce una connessione persistente verso l'host
di destinazione. Il livello di trasporto si incarica, quindi, di realizzare una connessione persistente che viene poi
chiusa quando non è più necessaria.
• Corretto ordine di consegna. Poiché i pacchetti possono seguire percorsi diversi all'interno della rete, non c'è
alcuna garanzia che i dati vengano recapitati nello stesso ordine in cui sono stati inviati. Il livello di trasporto
verifica che i pacchetti vengano riordinati nella giusta sequenza in ricezione prima di passarli al livello superiore.
• Trasferimento affidabile. Il protocollo si occupa di garantire che tutti i dati inviati vengano ricevuti; nel caso il
servizio di rete utilizzato perda pacchetti, il protocollo di trasporto si occupa di ritrasmetterli.
• Controllo di flusso. Se gli host coinvolti nella comunicazione hanno prestazioni molto differenti può capitare che
un pc più veloce "inondi" di dati uno più lento portando alla perdita di pacchetti. Mediante il controllo di flusso,
un host in "difficoltà" può chiedere di abbassare il tasso di trasmissione in modo da poter gestire le informazioni
in ingresso.
• Controllo di Congestione: il protocollo riconosce uno stato di congestione della rete e adatta di conseguenza la
velocità di trasmissione.
• Orientamento al Byte. Invece che gestire i dati in base ai pacchetti, viene fornita la possibilità di vedere la
comunicazione come uno stream di byte, in modo da semplificarne l'utilizzo.
40
Livello di trasporto
• Multiplazione. Il protocollo permette di stabilire diverse connessioni contemporanee tra gli stessi due host,
tipicamente utilizzando l'astrazione delle porte. Nell'uso comune diversi servizi utilizzano porte logiche di
comunicazione diverse.
Il nome trasporto per tale livello può quindi trarre in inganno in quanto non implementa alcun meccanismo di
trasferimento logico e fisico dei dati sul canale (multiplazione/accesso multiplo, indirizzamento e commutazione) cui
ovviano i livelli architetturali inferiori attraverso i meccanismi propri del particolare modo di trasferimento adottato,
bensì al contrario si occupa di supplire alle mancanze delle funzionalità del trasferimento in termini di affidabilità
implementando le suddette funzioni come garanzie sul trasporto stesso cioè chiudendo il cerchio su tutto ciò che il
trasporto in toto dovrebbe fare e garantire.
Livello di trasporto in Internet
Nello stack protocollare Internet, i protocolli di trasporto più utilizzati sono TCP e UDP. TCP è il più complicato fra
i due e fornisce un servizio end-to-end orientato alla connessione e al byte, con verifica del corretto ordine di
consegna, controllo di errore e di flusso. Il nome è un acronimo per Transmission Control Protocol. UDP, invece, è
un protocollo più snello e fornisce un servizio a datagrammi, senza connessione, con un meccanismo di riduzione
degli errori e con porte multiple. Il nome è un acronimo per User Datagram Protocol.
Esempi
Di seguito sono elencati alcuni protocolli di trasporto. In genere questi protocolli si basano su IP.
•
•
•
•
•
•
•
•
•
•
•
•
AEP, AppleTalk Echo Protocol
AMTP [1]
ATP, AppleTalk Transaction Protocol
NBP, Name Binding Protocol
NetBEUI, NetBIOS Extended User Interface
RSVP, Resource Reservation Protocol
RTMP, Routing Table Maintenance Protocol
SMB, Server Message Block
SPX, Sequenced Packet Exchange
SCTP, Stream Control Transmission Protocol
TCP, Transmission Control Protocol
UDP, User Datagram Protocol
Note
[1] http:/ / amtp. bw. org
41
Transmission Control Protocol
Transmission Control Protocol
In telecomunicazioni e informatica il Transmission Control Protocol (TCP), anche chiamato Transfer Control
Protocol, è un protocollo di rete a pacchetto di livello di trasporto, appartenente alla suite di protocolli Internet, che
si occupa di controllo di trasmissione. È definito nella RFC 793 e su di esso si appoggiano gran parte delle
applicazioni della rete Internet. È presente solo sui terminali di rete (host) e non sui nodi interni di commutazione
della rete di trasporto, implementato all'interno del rispettivo sistema operativo e vi si accede automaticamente dal
browser attraverso l'uso di opportune chiamate di sistema definite nelle API di sistema.
Descrizione
Il TCP può essere classificato al livello trasporto (OSI level 4) del modello di riferimento OSI, e di solito è usato in
combinazione con il protocollo di livello rete (OSI level 3) IP. La corrispondenza con il modello OSI non è perfetta,
in quanto il TCP e l'IP nascono prima del suddetto modello. La loro combinazione è indicata come TCP/IP e, alle
volte, è erroneamente considerata un unico protocollo. Da qui, la difficoltà di una classificazione univoca per un
protocollo che comprende, a pieno titolo, due livelli dello stack OSI (o pila ISO/OSI in italiano).
In linea con i dettami del livello di trasporto stabiliti dal modello ISO-OSI e con l'intento di superare il problema
della mancanza di affidabilità e controllo della comunicazione sorto con l'interconessione su vasta scala di reti locali
in un'unica grande rete geografica, TCP è stato progettato e realizzato per utilizzare i servizi offerti dai protocolli di
rete di livello inferiore (IP e protocolli di livello fisico e livello datalink) che definiscono efficacemente il modo di
trasferimento sul canale di comunicazione, ma che non offrono alcuna garanzia di affidabilità sulla consegna in
termini di ritardo, perdita ed errore dei pacchetti informativi trasmessi, sul controllo di flusso tra terminali e sul
controllo della congestione di rete, supplendo quindi ai problemi di cui sopra e costruendo così un canale di
comunicazione affidabile tra due processi applicativi di rete. Il canale di comunicazione così costruito è costituito
da un flusso bidirezionale di byte a seguito dell'instaurazione di una connessione agli estremi tra i due terminali in
comunicazione. Inoltre alcune funzionalità di TCP sono vitali per il buon funzionamento complessivo di una rete IP.
Sotto questo punto di vista TCP può essere considerato come un elemento di rete che si occupa di garantire una
qualità di servizio minima su una rete IP sotto che è di tipo best-effort.
Il TCP nacque nel 1970 come frutto del lavoro di un gruppo di ricerca del dipartimento di difesa statunitense. I suoi
punti di forza sono l'alta affidabilità e robustezza. La sua popolarità si deve anche grazie ad una sua implementazione
diffusa dalla Università di Berkeley, rilasciata in California sotto forma di sorgenti (TCP Berkeley). Molte tuttavia
sono le implementazioni e sviluppi che si sono succedute nel tempo come evoluzioni e miglioramenti (es. TCP
Tahoe, TCP Reno, TCP New Reno).
Caratteristiche principali
• TCP è un protocollo orientato alla connessione, ovvero prima di poter trasmettere dati deve stabilire la
comunicazione, negoziando una connessione tra mittente e destinatario, che viene esplicitamente chiusa quando
non più necessaria. Esso quindi possiede le funzionalità per creare, mantenere e chiudere/abbattere una
connessione.
• Il servizio offerto da TCP è il trasporto di un flusso di byte bidirezionale tra due applicazioni in esecuzione su
host differenti. Il protocollo permette alle due applicazioni di trasmettere contemporaneamente nelle due
direzioni, quindi il servizio può essere considerato "Full-Duplex" anche se non tutti i protocolli applicativi basati
su TCP utilizzano questa possibilità.
• Il flusso di byte viene frazionato in blocchi per la trasmissione dall'applicazione a TCP (che normalmente è
implementato all'interno del sistema operativo), per la trasmissione all'interno di segmenti TCP, per la consegna
all'applicazione che lo riceve, ma questa divisione in blocchi non è necessariamente la stessa nei diversi passaggi.
42
Transmission Control Protocol
43
• TCP garantisce che i dati trasmessi, se giungono a destinazione, lo facciano in ordine e una volta sola ("at most
once"). Più formalmente, il protocollo fornisce ai livelli superiori un servizio equivalente ad una connessione
fisica diretta che trasporta un flusso di byte. Questo è realizzato attraverso vari meccanismi di acknowledgment e
di ritrasmissione su timeout.
• TCP offre funzionalità di controllo di errore sui pacchetti pervenuti grazie al campo checksum contenuto nella sua
PDU.
• TCP possiede funzionalità di controllo di flusso tra terminali in comunicazione e controllo della congestione sulla
connessione, attraverso il meccanismo della finestra scorrevole. Questo permette di ottimizzare l'utilizzo della rete
anche in caso di congestione, e di condividere equamente la capacità disponibile tra diverse sessioni TCP attive su
un collegamento.
• TCP fornisce un servizio di multiplazione delle connessioni su un host, attraverso il meccanismo delle porte.
Confronto con UDP
Le principali differenze tra TCP e UDP (User Datagram Protocol), l'altro principale protocollo di trasporto della
suite di protocolli Internet, sono:
• mentre TCP è un protocollo orientato alla connessione, pertanto per stabilire, mantenere e chiudere una
connessione, è necessario inviare pacchetti di servizio i quali aumentano l'overhead di comunicazione. Al
contrario, UDP invece è senza connessione ed invia solo i datagrammi richiesti dal livello applicativo;
• UDP non offre nessuna garanzia sull'affidabilità della comunicazione ovvero sull'effettivo arrivo dei datagrammi,
sul loro ordine in sequenza in arrivo, al contrario il TCP tramite i meccanismi di acknowledgement e di
ritrasmissione su timeout riesce a garantire la consegna dei dati, anche se al costo di un maggiore overhead
(raffrontabile visivamente confrontando la dimensione delle intestazioni dei due protocolli);
• l'oggetto della comunicazione di TCP è il flusso di byte mentre quello di UDP è il singolo datagramma.
L'utilizzo del protocollo TCP rispetto a UDP è, in generale, preferito quando è necessario avere garanzie sulla
consegna dei dati o sull'ordine di arrivo dei vari segmenti (come per esempio nel caso di trasferimenti di file). Al
contrario UDP viene principalmente usato quando l'interazione tra i due host è idempotente o nel caso si abbiano
forti vincoli sulla velocità e l'economia di risorse della rete (es. instant messaging).
Segmento TCP
La PDU di TCP è detta segmento. Ciascun segmento viene normalmente imbustato in un pacchetto IP, ed è costituito
dall'intestazione (header) TCP e da un carico utile (in inglese payload), ovvero dati di livello applicativo. I dati
contenuti nell'intestazione costituiscono un canale di comunicazione tra le due entità TCP, che viene utilizzato per
realizzare le funzionalità dello strato di trasporto e non è accessibile agli strati dei livelli superiori.
Un segmento TCP è così strutturato:
TCP Header
Bit offset
0
Bits 0–3
4–7
8–15
Source port
16–31
Destination port
32
Sequence number
64
Acknowledgment number
96
Data offset Reserved CWR ECE URG ACK PSH RST SYN FIN
Window Size
128
Checksum
Urgent pointer
160
Options (optional)
160/192+
Data
Transmission Control Protocol
• Source port [16 bit] - Identifica il numero di porta sull'host mittente associato alla connessione TCP.
• Destination port [16 bit] - Identifica il numero di porta sull'host destinatario associato alla connessione TCP.
• Sequence number [32 bit] - Numero di sequenza, indica lo scostamento (espresso in byte) dell'inizio del
segmento TCP all'interno del flusso completo, a partire dall' Initial Sequence Number (ISN), negoziato all'apertura
della connessione.
• Acknowledgment number [32 bit] - Numero di riscontro, ha significato solo se il flag ACK è impostato a 1, e
conferma la ricezione di una parte del flusso di dati nella direzione opposta, indicando il valore del prossimo
Sequence number che l'host mittente del segmento TCP si aspetta di ricevere.
• Data offset [4 bit] - Indica la lunghezza (in word da 32 bit) dell'header del segmento TCP; tale lunghezza può
variare da 5 word (20 byte) a 15 word (60 byte) a seconda della presenza e della lunghezza del campo facoltativo
Options.
• Reserved [4 bit] - Bit non utilizzati e predisposti per sviluppi futuri del protocollo; dovrebbero essere settati a
zero.
• Flags [8 bit] - Bit utilizzati per il controllo del protocollo:
• CWR (Congestion Window Reduced) - se settato a 1 indica che l'host sorgente ha ricevuto un segmento TCP
con il flag ECE settato a 1 (aggiunto all'header in RFC 3168).
•
•
•
•
•
• ECE (ECN-Echo) - se settato a 1 indica che l'host supporta ECN (Explicit Congestion Notification) durante il
3-way handshake (aggiunto all'header in RFC 3168).
• URG - se settato a 1 indica che nel flusso sono presenti dati urgenti alla posizione (offset) indicata dal campo
Urgent pointer. Urgent Pointer punta alla fine dei dati urgenti;
• ACK - se settato a 1 indica che il campo Acknowledgment number è valido;
• PSH - se settato a 1 indica che i dati in arrivo non devono essere bufferizzati ma passati subito ai livelli
superiori dell'applicazione;
• RST - se settato a 1 indica che la connessione non è valida; viene utilizzato in caso di grave errore; a volte
utilizzato insieme al flag ACK per la chiusura di una connessione.
• SYN - se settato a 1 indica che l'host mittente del segmento vuole aprire una connessione TCP con l'host
destinatario e specifica nel campo Sequence number il valore dell' Initial Sequence Number (ISN); ha lo scopo
di sincronizzare i numeri di sequenza dei due host. L'host che ha inviato il SYN deve attendere dall'host
remoto un pacchetto SYN/ACK.
• FIN - se settato a 1 indica che l'host mittente del segmento vuole chiudere la connessione TCP aperta con
l'host destinatario. Il mittente attende la conferma dal ricevente (con un FIN-ACK). A questo punto la
connessione è ritenuta chiusa per metà: l'host che ha inviato FIN non potrà più inviare dati, mentre l'altro host
ha il canale di comunicazione ancora disponibile. Quando anche l'altro host invierà il pacchetto con FIN
impostato la connessione, dopo il relativo FIN-ACK, sarà considerata completamente chiusa.
Advertise Window [16 bit] - Indica la dimensione della finestra di ricezione dell'host mittente, cioè il numero di
byte che il mittente è in grado di accettare a partire da quello specificato dall'acknowledgment number.
Checksum [16 bit] - Campo di controllo utilizzato per la verifica della validità del segmento. È ottenuto facendo
il complemento a 1 della somma complemento a uno a 16 bit dell'intero header TCP (con il campo checksum
messo a zero),dell'intero payload, con l'aggiunta di uno pseudo header composto da: indirizzo IP
sorgente(32bit),indirizzo IP destinazione(32bit), un byte di zeri, un byte che indica il protocollo e due byte che
indicano la lunghezza del pacchetto TCP (header + dati).
Urgent pointer [16 bit] - Puntatore a dato urgente, ha significato solo se il flag URG è settato a 1 ed indica lo
scostamento in byte a partire dal Sequence number del byte di dati urgenti all'interno del flusso.
Options - Opzioni (facoltative) per usi del protocollo avanzati.
Data - rappresenta il carico utile o payload da trasmettere cioè la PDU proveniente dal livello superiore.
44
Transmission Control Protocol
Connessione
Prima ancora del trasferimento dei dati su canale di comunicazione e delle operazioni di controllo di trasmissione sul
flusso dei dati in ricezione, in trasmissione TCP si occupa di instaurare la connessione agli estremi tra i processi
applicativi dei terminali in comunicazione attraverso la definizione del socket ovvero coppia indirizzo IP, porta sia
del mittente che del destinatario. Si ricorda invece che la commutazione interna nei nodi della rete di trasporto dati
segue invece tipicamente la commutazione di pacchetto ovvero senza circuito o connessione fissa dedicata tipica
invece della commutazione di circuito. Il fine della connessione TCP è in ogni caso il riservamento di risorse tra
processi applicativi che si scambiano informazioni o servizi tra loro (es. server e client). Al termine della
connessione, TCP attua la fase dell'abbattimento della connessione. Le due procedure sono distinte e descritte a
seguito. L'implementazione di applicazioni di connessione di rete a pacchetto ricade nell'ambito della cosiddetta
programmazione socket.
Apertura di una connessione - Three-way handshake
La procedura utilizzata per instaurare in
modo affidabile una connessione TCP tra
due host è chiamata three-way handshake
(stretta di mano in 3 passaggi), indicando la
necessità di scambiare 3 messaggi tra host
mittente e host ricevente affinché la
connessione sia instaurata correttamente.
Consideriamo ad esempio che l'host A
intenda aprire una connessione TCP con
l'host B; i passi da seguire quindi sono:
1. A invia un segmento SYN a B - il flag
SYN è impostato a 1 e il campo Sequence
number contiene il valore x che specifica
l' Initial Sequence Number di A;
2. B invia un segmento SYN/ACK ad A i flag SYN e ACK sono impostati a 1, il
campo Sequence number contiene il
valore y che specifica l' Initial Sequence Number di B e il campo Acknowledgment number contiene il valore x+1
confermando la ricezione del ISN di A;
3. A invia un segmento ACK a B - il campo Acknowledgment number contiene il valore y+1 confermando la
ricezione del ISN di B.
Il terzo segmento non sarebbe, idealmente, necessario per l'apertura della connessione in quanto già dopo la
ricezione da parte di A del secondo segmento, entrambi gli host hanno espresso la loro disponibilità all'apertura della
connessione. Tuttavia esso risulta necessario al fine di permettere anche all'host B una stima del timeout iniziale,
come tempo intercorso tra l'invio di un segmento e la ricezione del corrispondente ACK.
Il flag SYN risulta utile nell'implementazione pratica del protocollo, e nella sua analisi da parte dei firewall: nel
traffico TCP i segmenti SYN stabiliscono nuove connessioni, mentre quelli con il flag non attivo appartengono a
connessioni già instaurate.
I segmenti utilizzati durante l'handshake sono solitamente 'solo header', ossia hanno il campo Data vuoto essendo
questa una fase di sincronizzazione tra i due host e non di scambio di dati.
45
Transmission Control Protocol
Chiusura di una connessione - Four-way handshake
Dopo che è stata stabilita, una connessione TCP non è considerata
una singola connessione bidirezionale, ma piuttosto come
l'affasciamento di due connessioni monodirezionali. Pertanto,
ognuna delle parti deve terminare la sua connessione, e possono
esistere anche connessioni aperte a metà, in cui solo uno dei due
terminali ha chiuso la connessione e non può più trasmettere, ma
può (e deve) ricevere i dati dall'altro terminale.
Di conseguenza, la chiusura della connessione si può effettuare in
due modi: con un handshake a tre vie, in cui le due parti chiudono
contemporaneamente le rispettive connessioni, o con uno a quattro
vie, in cui le due connessioni vengono chiuse in tempi diversi.
L'handshake a 3 vie è omologo a quello usato per l'apertura della
connessione, con la differenza che il flag utilizzato è il FIN invece
del SYN. Un terminale invia un pacchetto con la richiesta FIN,
l'altro risponde con un FIN + ACK, ed infine il primo manda
l'ultimo ACK, e l'intera connessione viene terminata.
L'handshake a 4 vie invece viene utilizzato quando la disconnessione non è contemporanea tra i due terminali in
comunicazione. In questo caso uno dei due terminali invia la richiesta di FIN, e attende l'ACK. L'altro terminale farà
poi altrettanto, generando quindi un totale di 4 pacchetti.
Multiplazione e porte
Ciascuna connessione TCP attiva è associata a un socket aperto da un processo (il socket è lo strumento offerto dal
sistema operativo alle applicazioni per usare le funzionalità della rete). TCP si occupa di smistare i dati tra le
connessioni attive ed i relativi processi. Per questo, a ciascuna connessione tra due host viene associato un numero di
porta su ciascuno dei due host, che è un intero senza segno a 16 bit (0-65535), contenuto nell'apposito campo
dell'header.
Una connessione TCP sarà quindi identificata dagli indirizzi IP dei due host e dalle porte utilizzate sui due host.
In questo modo, un server può accettare connessioni da più client contemporaneamente attraverso una o più porte, un
client può stabilire più connessioni verso più destinazioni, ed è anche possibile che un client stabilisca
contemporaneamente più connessioni indipendenti verso la stessa porta dello stesso server.
Server e Client
I due processi che comunicano attraverso una connessione TCP hanno ruoli diversi:
• Il processo che avvia una nuova connessione TCP è detto client, ed invia una richiesta di connessione verso una
determinata porta.
• Affinché la connessione venga stabilita, su quella porta deve esserci un processo server "in ascolto", che accetta di
stabilire una connessione TCP.
Le porte conosciute e registrate sono quindi utilizzate dai processi server, e sono convenzionalmente associate a
particolari servizi, in modo che un client sappia a quale porta connettersi per raggiungere un determinato server.
Il processo server, che è in ascolto su una certa porta, rimane bloccato in attesa che un client si colleghi. Il processo
client richiede di stabilire una connessione verso un determinato server su una determinata porta. Normalmente la
porta sorgente usata dal client viene allocata dinamicamente dal sistema operativo del client. Quando il TCP
stabilisce la connessione, a entrambi i processi viene assegnato un socket tramite cui essi possono comunicare tra
46
Transmission Control Protocol
loro. Tipicamente il processo server effettua una fork, affida al figlio il compito di comunicare con il nuovo client e
si rimette in ascolto. Da questo punto in poi, client e server hanno ruoli simmetrici, e utilizzano gli stessi strumenti
per comunicare attraverso il socket.
Affidabilità della comunicazione
Consegna ordinata ed eliminazione di duplicati
Il Sequence number, o numero di sequenza, serve a identificare e posizionare in maniera ordinata il carico utile del
segmento TCP all'interno del flusso di dati. Con la trasmissione tipica a commutazione di pacchetto delle rete dati
infatti ciascun pacchetto può seguire percorsi diversi in rete e giungere fuori sequenza in ricezione.
In ricezione TCP si aspetta di ricevere il segmento successivo all'ultimo segmento ricevuto in ordine ovvero quello il
cui numero di sequenza è pari al numero di sequenza dell'ultimo pervenuto in ordine più la dimensione del carico
utile del segmento in attesa (cioè del suo campo Data).
In relazione al numero di sequenza TCP ricevente attua le seguenti procedure:
• se il numero di sequenza ricevuto è quello atteso invia direttamente il carico utile del segmento al processo di
livello applicativo e libera i propri buffer.
• se il numero di sequenza ricevuto è maggiore di quello atteso deduce che uno o più segmenti ad esso precedenti
sono andati persi, ritardati dal livello di rete sottostante o ancora in transito sulla rete. Pertanto, memorizza
temporaneamente in un buffer il carico utile del segmento ricevuto fuori sequenza per poterlo consegnare al
processo applicativo solo dopo aver ricevuto e consegnato anche tutti i segmenti precedenti non ancora pervenuti
passenti anch'essi per il buffer, aspettandone l'arrivo fino ad un tempo limite prefissato (time-out). All'istante di
consegna del blocco ordinato di segmenti tutto il contenuto del buffer viene liberato. Dal punto di vista del
processo applicativo, quindi, i dati arriveranno in ordine anche se la rete ha per qualsiasi motivo alterato questo
ordine realizzando così il requisito della consegna ordinata dei dati.
• se il numero di sequenza ricevuto è inferiore a quello atteso, il segmento viene considerato un duplicato di uno già
ricevuto e già inviato allo strato applicativo e dunque scartato. Questo permette di realizzare l'eliminazione dei
duplicati di rete.
Riscontro dei pacchetti e ritrasmissione
Per ogni segmento ricevuto in sequenza inoltre TCP lato ricevente invia un Acknowledgment Number o numero di
riscontro dell'avvenuta ricezione. Il numero di riscontro presente in un segmento riguarda il flusso di dati nella
direzione opposta. In particolare, il numero di riscontro inviato da A a B è pari al numero di sequenza atteso da A e,
quindi, riguarda il flusso di dati da B ad A.
In particolare il protocollo TCP adotta la politica di Conferma cumulativa, ovvero l'arrivo di numero di riscontro
indica al TCP trasmittente che il ricevente ha ricevuto e correttamente inoltrato al proprio processo applicativo il
segmento avente numero di sequenza pari al numero di riscontro indicato (-1) ed anche tutti i segmenti ad esso
precedenti. Per tale motivo TCP lato trasmittente mantiene temporaneamente in un buffer una copia di tutti i dati
inviati, ma non ancora riscontrati: quando questi riceve un numero di riscontro per un certo segmento, deduce che
tutti i segmenti precedenti a quel numero sono stati ricevuti correttamente liberando il proprio buffer dai dati. La
dimensione massima dei pacchetti riscontrabili in maniera cumulativa è specificata dalle dimensioni della cosiddetta
finestra scorrevole.
Per evitare tempi di attesa troppo lunghi o troppo corti per ciascun segmento inviato TCP lato trasmittente avvia un
timer, detto timer di ritrasmissione RTO (Retransmission Time Out): se questi non riceve un ACK di riscontro per il
segmento inviato prima che il timer scada, TCP assume che tutti i segmenti trasmessi a partire da questo siano andati
persi e quindi procede alla ritrasmissione.
47
Transmission Control Protocol
Si noti che, in TCP, il meccanismo dei numeri di riscontro non permette al ricevitore di comunicare al trasmettitore
che un segmento è stato perso, ma alcuni dei successivi sono stati ricevuti (meccanismo ad Acknowledgment Number
negativi), quindi è possibile che per un solo pacchetto perso ne debbano essere ritrasmessi molti. Questo
comportamento non ottimale è compensato dalla semplicità del protocollo. Questa tecnica è detta Go-Back-N (vai
indietro di N segmenti); l'alternativa, ovvero progettare il protocollo in modo tale che solo i pacchetti effettivamente
persi vengano ritrasmessi, è detta Selective Repeat (ripetizione selettiva); l'utilizzo però di alcuni campi opzionali
appositi permette l'utilizzo della ripetizione selettiva.
I numeri di riscontro e i relativi timer di ritrasmissione permettono quindi di realizzare la consegna affidabile,
ovvero di garantire che tutti i dati inviati siano comunque consegnati nel caso in cui qualche pacchetto possa essere
perso nel transito attraverso la rete (controllo di errore in termini di riscontro di trasmissione).
Controllo di flusso
L'affidabilità della comunicazione in TCP è garantita anche dal cosiddetto controllo di flusso ovvero far in modo che
il flusso di dati in trasmissione non superi le capacità di ricezione ovvero di memorizzazione del ricevente con
perdita di pacchetti e maggior peso e latenze nelle successive richieste di ritrasmissione. Viene attuato attraverso la
specifica da parte del destinatario di un opportuno campo noto come RCW_WND (finestra di ricezione) il quale
specifica il numero massimo di segmenti ricevibile dal destinatario.
Controllo di congestione
Infine l'ultimo tipo di controllo effettuato da TCP per garantire affidabilità alla comunicazione è il cosiddetto
controllo della congestione ovvero far in modo che si limitino il più possibile fenomeni di congestione all'interno
della rete per eccessivo traffico sui dispositivi di rete con perdita di pacchetti in transito e maggior peso e latenze
nelle successive richieste di ritrasmissione, modulando nel tempo la quantità di dati in trasmissione in funzione dello
stato interno di congestione. La particolarità di tale controllo è che viene effettuato agendo sulla trasmissione agli
estremi cioè sui terminali di rete e non attraverso la commutazione interna alla rete grazie alle informazioni
deducibili dal terminale stesso sullo stato della trasmissione dei pacchetti. Nello specifico, una volta "stimato" lo
stato di congestione interno della rete avendo scelto come parametro di riferimento la perdita di pacchetti trasmessi
desunta dai mancati ACK di riscontro dei pacchetti stessi, tale controllo viene poi attuato attraverso la definizione da
parte del mittente di un opportuno campo noto come C_WND (finestra di congestione) la quale assegna,
dinamicamente nel tempo, il numero massimo di segmenti da trasmettere al destinatario.
I timer del TCP
Timer di ritrasmissione
Come descritto sopra, il timer di ritrasmissione serve a verificare che ciascun segmento trasmesso venga riscontrato.
La corretta impostazione di questo timer è difficile ma molto importante, in quanto un timer troppo breve comporta
ritrasmissioni inutili (il timer scatta mentre il riscontro o il pacchetto sono ancora in viaggio), mentre un timer troppo
lungo comporta attese in caso di effettiva perdita di pacchetti. Ovviamente tale intervallo dovrà essere almeno pari al
Round Trip Time cioè al tempo di percorrenza a due vie di un pacchetto per tornare al mittente sotto forma di ACK.
Tale RTT, per la natura intrinseca della commutazione di pacchetto interna alla rete, è tipicamente variabile in
maniera aleatoria. TCP allora aggiusta continuamente il timer di ritrasmissione basandosi su una stima a media
mobile del Round Trip Time.
48
Transmission Control Protocol
Timer di persistenza
Come spiegato sopra, il TCP utilizza il metodo della finestra scorrevole per gestire il controllo di flusso di dati che il
ricevente è in grado di accettare dal mittente. Tra i valori validi di questo campo vi è anche lo zero, a significare che
il ricevente richiede l'interruzione momentanea dell'invio di dati.
Nel malaugurato caso in cui il pacchetto che riapre la finestra venga perso, il mittente del canale TCP rimarrà però in
attesa indefinita. Per evitare questo, il TCP avvia un timer, detto timer di persistenza, ogni qual volta il ricevente
chiude la finestra. Quando questo timer scade, il mittente invia un pacchetto sonda al ricevente, provocandone una
risposta: in questo modo il mittente potrà essere sicuro che la finestra sia chiusa (ricevendo un altro pacchetto con
campo Window a 0) o sbloccarsi dallo stallo (ricevendo un pacchetto con campo Window diverso da zero).
Timer di keepalive
La RFC 793 che definisce il protocollo TCP non prevede particolari azioni da intraprendere quando non ci sono dati
da trasmettere sulla connessioni. Alcune implementazioni però consentono di trasmettere periodicamente segmenti
vuoti, detti keepalive, per evitare di mantenere indefinitamente in memoria connessioni con sistemi che potrebbero
anche non essere più attivi. In molti sistemi il software applicativo ha la possibilità di scegliere se abilitare o meno i
keepalive per ogni connessione.
Quando si usano i keepalive, è presente dunque il timer di keepalive: esso viene reimpostato alla ricezione o alla
trasmissione di ogni segmento, e quando scade viene trasmesso un keepalive. Un valore tipico è di due ore.
Timed wait
L'ultimo timer utilizzato da TCP è il timed wait. In pratica, prima di disconnettere effettivamente una connessione, i
due estremi del canale attendono un tempo pari al doppio del tempo di vita di un comune pacchetto: questo evita che
dei pacchetti possano rimanere circolanti per la rete anche dopo la chiusura.
Voci correlate
•
•
•
•
•
•
•
•
Internet Protocol
Porta (reti)
Finestra scorrevole
User Datagram Protocol (UDP)
SCTP
Controllo di errore
Controllo di flusso
Controllo della congestione in TCP
49
Transmission Control Protocol
Collegamenti esterni
• (EN) RFC 793 - Transmission Control Protocol Specifications [1]
• Traduzione in italiano dell'RFC [2]
• (EN) Porte di comunicazione TCP [3]
Note
[1] http:/ / tools. ietf. org/ html/ rfc0793
[2] http:/ / www. rfc. altervista. org/ rfctradotte/ rfc793_tradotta. txt
[3] http:/ / www. answersthatwork. com/ Download_Area/ ATW_Library/ Networking/ Network__2-List_of_Common_TCPIP_port_numbers.
pdf
User Datagram Protocol
In telecomunicazioni lo User Datagram Protocol (UDP) è uno dei principali protocolli di rete della suite di
protocolli Internet. È un protocollo di livello di trasporto a pacchetto, usato di solito in combinazione con il
protocollo IP.
Funzionamento
A differenza del TCP, l'UDP è un protocollo di tipo connectionless, inoltre non gestisce il riordinamento dei
pacchetti né la ritrasmissione di quelli persi, ed è perciò generalmente considerato di minore affidabilità. È in
compenso molto rapido ed efficiente per le applicazioni "leggere" o time-sensitive. Ad esempio, è usato spesso per la
trasmissione di informazioni audio o video. Dato che le applicazioni in tempo reale spesso richiedono un ritmo
minimo di spedizione, non vogliono ritardare eccessivamente la trasmissione dei pacchetti e possono tollerare
qualche perdita di dati, il modello di servizio TCP può non essere particolarmente adatto alle loro caratteristiche.
L'UDP fornisce soltanto i servizi basilari del livello di trasporto, ovvero:
• multiplazione delle connessioni, ottenuta attraverso il meccanismo delle porte
• verifica degli errori mediante una checksum, inserita in un campo dell'intestazione del pacchetto.
mentre TCP garantisce anche il trasferimento affidabile dei dati, il controllo di flusso e il controllo della congestione.
L'UDP è un protocollo stateless, ovvero non tiene nota dello stato della connessione dunque ha, rispetto al TCP,
informazioni in meno da memorizzare. Un server dedicato ad una particolare applicazione che scelga UDP come
protocollo di trasporto può supportare molti più client attivi.
Struttura di un datagramma UDP
Un datagramma (o pacchetto) UDP è così strutturato:
50
User Datagram Protocol
51
+
Bit 0-15
16-31
0
Source Port (optional)
Destination Port
32
Length
Checksum (optional)
64+
Data
•
•
•
•
Source port [16 bit] - Identifica il numero di porta sull'host del mittente del datagramma;
Destination port [16 bit] - Identifica il numero di porta sull'host del destinatario del datagramma;
Length [16 bit] - contiene la lunghezza totale in bytes del datagramma UDP (header+dati);
Checksum [16 bit] - contiene il codice di controllo del datagramma (header+dati+pseudo-header,quest'ultimo
comprendente gli indirizzi IP di sorgente e destinazione). L'algoritmo di calcolo è definito nell'RFC del
protocollo;
• Data - contiene i dati del messaggio
Applicazioni che utilizzano UDP
Le applicazioni che hanno la necessità di un trasferimento affidabile dei loro dati si affidano ovviamente a TCP. Le
applicazioni più elastiche riguardo alla perdita dei dati e dipendenti dal tempo si affidano invece a UDP. Inoltre si
utilizza UDP per comunicazioni in broadcast (invio a tutti i terminali in una rete locale) e multicast (invio a tutti i
terminali iscritti ad un servizio).
Di seguito è proposto un elenco dei principali servizi internet e dei protocolli che adottano:
Applicazione
Protocollo strato applicazione
Protocollo strato trasporto
Posta elettronica
SMTP
TCP
Accesso a terminale remoto
telnet
TCP
Trasferimento file
FTP
TCP
Web
HTTP
TCP
Streaming Audio/Video
RTSP/RTP
TCP (comandi) + UDP (flusso)
Server di file remoto
NFS
tipicamente UDP
Telefonia su internet (VoIP)
SIP, H.323, altri
tipicamente UDP
Gestione della rete
SNMP
tipicamente UDP
Protocollo di routing
RIP
tipicamente UDP
Risoluzione dei nomi
DNS
tipicamente UDP
Collegamenti esterni
• RFC 768 User Datagram Protocol (traduzione in italiano [1])
Note
[1] http:/ / www. rfc. altervista. org/ rfctradotte/ rfc768_tradotta. txt
Livello di rete
Livello di rete
In telecomunicazioni e informatica nell'ambito delle reti di calcolatori il livello rete (Network layer) è il livello 3
della pila ISO/OSI. Questo livello riceve segmenti dal soprastante livello di trasporto e forma pacchetti che vengono
passati al sottostante Livello datalink.
Il compito del livello di rete è la trasmissione logica di pacchetti tra due host arbitrari, che in generale non sono
direttamente connessi (ovvero non hanno un collegamento diretto tra di loro) cioè in sostanza si occupa di
indirizzamento e instradamento verso la giusta destinazione attraverso il percorso di rete più appropriato. Nel
modello ISO/OSI il livello di rete è l'ultimo livello presente nei commutatori della rete ovvero nei nodi interni,
mentre i livelli architetturali superiori sono presenti solo nei nodi terminali.[1][2]
Funzioni del livello di rete
• inoltro, ovvero ricevere un pacchetto su una porta, immagazzinarlo e ritrasmetterlo su un'altra. Questa funzione è
presente in tutti i nodi della rete, e può comportare l'utilizzo di protocolli di livello collegamento differenti;
• frammentazione e riassemblaggio: se un pacchetto ricevuto ha una dimensione eccessiva per la rete su cui deve
essere trasmesso, il livello di rete lo divide in frammenti e, in maniera complementare, si occupa di riassemblare i
frammenti ricevuti al momento della consegna;
• instradamento (routing), ovvero determinare il percorso ideale per la trasmissione dei dati attraverso la rete a
partire dall'indirizzo IP del destinatario. Nella maggior parte dei casi, questa funzione viene svolta dinamicamente
tramite appositi algoritmi, che utilizzano le informazioni provenienti dai protocolli di routing sulle condizioni
della rete, le tabelle di instradamento, la priorità del servizio e altri elementi secondari;
• alcuni protocolli di rete forniscono un servizio di gestione delle connessioni (x.25, Frame Relay, Asynchronous
Transfer Mode), ovvero richiedono che venga stabilito un canale di comunicazione fisso e dedicato prima che due
host possano iniziare a scambiarsi dati; altri protocolli invece trasportano semplicemente i datagrammi a
destinazione (IP, IPX) senza connessione. I protocolli orientati alla connessione possono offrire garanzie di
consegna in ordine dei pacchetti, mentre questo non avviene normalmente nei protocolli senza connessione;
• funzioni talvolta presenti nel livello di rete sono il controllo della congestione, o garanzie di qualità di servizio,
tipicamente basate sulla prenotazione delle risorse su tutti i nodi della rete;
• nelle reti geografiche (WAN o MAN) può venire gestita la tariffazione, calcolata sulla base dei tempi di
connessione e/o di altri parametri.
Livello rete in IP
Nel modello TCP/IP, il livello 3 viene detto livello internet oppure livello di internetworking, in quanto
interconnette reti eterogenee, che possono essere basate su protocolli di livello collegamento (ad esempio ethernet,
PPP) o su protocolli di rete (ad esempio Frame Relay, Asynchronous Transfer Mode), per realizzare un'unica rete in
modo trasparente agli utilizzatori. La forza di IP sta proprio in questo agnosticismo rispetto al livello di rete, che
permette di usare o riusare tecnologie già disponibili, e di adattarsi con naturalezza a nuove tecnologie.
Osservando una rete IP costruita con tecnologie eterogenee, si può notare che alcuni nodi della rete eseguono IP (e
sono detti router); altri nodi instradano pacchetti IP usando altre tecnologie di rete (che stanno sotto IP nello stack dei
protocolli). Questi nodi sono normalmente detti switch o commutatori, anche se il termine per antonomasia indica
specificamente lo switch ethernet.
IP determina il miglior cammino (detto routing ovvero instradamento) per l’inoltro dei pacchetti, attraverso la
consultazione delle tabelle di instradamento. Tali tabelle possono essere di tipo statico (realizzate manualmente dai
gestori della rete) o dinamico (composte con l'utilizzo di protocolli di routing tipo l'OSPF, il RIP o il BGP che
servono a popolare tali tabelle scambiando tra i vari apparati le informazioni sulle rotte conosciute).
52
Livello di rete
53
Note
[1] (EN) Network Layer Definition (http:/ / www. linfo. org/ network_layer. html). linfo.org, 16-9-2005. URL consultato il 13-5-2012.
[2] (EN) Bradley Mitchell. Visual Networking Overview - The OSI Model - Network Layer (http:/ / compnetworking. about. com/ od/
basicnetworkingconcepts/ l/ blbasics_osi3. htm). about.com. URL consultato il 13-5-2012.
IPv4
IPv4 (Internet Protocol version 4) è la quarta revisione dell'Internet Protocol. Il protocollo è descritto nell'RFC 791,
pubblicato dalla IETF nel settembre 1981, ed è il più usato a livello di rete, poiché fa parte della suite di protocolli
Internet.
Nel 1998 è stata suggerita una nuova versione del protocollo Internet, denominata IPv6, a causa del problema della
saturazione di IPv4. Al 2011 l'IPv6 risulta tuttavia meno utilizzato rispetto alla versione 4.[1]
Il pacchetto IPv4
L'header del pacchetto IPv4 consiste in 13 campi di cui 1 opzionale (segnalato nello schema con sfondo rosso) e
chiamato con l'ovvio nome di Options. I campi sono inseriti col byte più significativo messo per primo (notazione
big-endian) e all'interno dei singoli byte il bit più significativo è il primo (quello di indice 0).
+
Bits 0–3
0
Version
4–7
Internet
Type of Service
Header length (now DiffServ and ECN)
32
64
8–15
Identification
Time to Live
16–18
19–31
Total Length
Flags Fragment Offset
Protocol
96
Source Address
128
Destination Address
160
Options (optional)
160
o
192+
Data
Header Checksum
• Versione [4 bit] - Indica la versione del datagramma IP: per IPv4, ha valore 4 (da qui il nome IPv4).
• Internet Header Length (IHL) [4 bit] - Indica la lunghezza (in word da 32 bit) dell'header del datagramma IP
ovvero l'offset del campo dati; tale lunghezza può variare da 5 word (20 byte) a 15 word (60 byte) a seconda della
presenza e della lunghezza del campo facoltativo Options;
• Type of Service (TOS) [8 bit] - Nelle specifiche iniziali del protocollo (RFC 791), questi bit servivano all'host
mittente per specificare il modo e in particolare la precedenza con cui l'host ricevente doveva trattare il
datagramma:
•
•
•
•
•
bit 0-2 : Precedenza
bit 3: Latenza (0 = normale, 1 = bassa)
bit 4: Throughput (0 = normale, 1 = alto)
bit 5: Affidabilità (0 = normale, 1 = alta)
bit 6-7: Riservati per usi futuri
ad esempio un host poteva scegliere una bassa latenza, mentre un altro preferire un'alta affidabilità. Nella
pratica questo uso del campo TOS non ha preso largamente piede.
IPv4
54
Dopo molte sperimentazioni e ricerche, recentemente questi 8 bit sono stati ridefiniti ed hanno la funzione di
Differentiated services (DiffServ nell'IETF e Explicit Congestion Notification (ECN) codepoints (vedi RFC
3168), necessari per le nuove tecnologie basate sullo streaming dei dati in tempo reale, come per il esempio il
Voice over IP (VoIP) usato per lo scambio interattivo dei dati vocali.
• Total Length [16 bit] - Indica la dimensione (in byte) dell'intero datagramma, comprendendo header e dati; tale
lunghezza può variare da un minimo di 20 byte (header minimo e campo dati vuoto) ad un massimo di 65535
byte. In ogni momento, ad ogni host è richiesto di essere in grado di gestire datagrammi aventi una dimensione
minima di 576 byte mentre sono autorizzati, se necessario, a frammentare datagrammi di dimensione maggiore.
• Identification [16 bit] - Utilizzato, come da specifiche iniziali, per identificare in modo univoco i vari frammenti
in cui può essere stato "spezzato" un datagramma IP. Alcune sperimentazioni successive hanno però suggerito di
utilizzare questo campo per altri scopi, come aggiungere la funzionalità di tracciamento dei pacchetti.
• Flags [3 bit] - Bit utilizzati per il controllo del protocollo e della frammentazione dei datagrammi:
• Reserved - sempre settato a 0. Come pesce d'Aprile, in RFC 3514 si è proposto di utilizzarlo come "Evil bit".
• DF (Don't Fragment) - se settato a 1 indica che il datagramma non deve essere frammentato; se tale
datagramma non può essere inoltrato da un host senza essere frammentato, viene semplicemente scartato.
Questo può risultare utile per "ispezionare" la capacità di gestione dei vari host del percorso di routing.
• MF (More Fragments) - se settato a 0 indica che il datagramma è l'ultimo frammento o il solo frammento del
datagramma originario, pertanto tutti gli altri suoi frammenti hanno il bit MF settato a 1. Naturalmente, questo
bit sarà sempre 0 anche in tutti i datagrammi che non sono stati frammentati.
• Fragment Offset [13 bit] - Indica l'offset (misurato in blocchi di 8 byte) di un particolare frammento
relativamente all'inizio del datagramma IP originale: il primo frammento ha offset 0. L'offset massimo risulta
pertanto pari a
65528 byte che, includendo l'header, potrebbe eccedere la dimensione
massima di 65535 byte di un datagramma IP.
• Time To Live (TTL) [8 bit] - Indica il tempo di vita (time to live) del datagramma, necessario per evitarne la
persistenza indefinita sulla rete nel caso in cui non si riesca a recapitarlo al destinatario. Storicamente il TTL
misurava i "secondi di vita" del datagramma, mentre ora esso misura il numero di "salti" da nodo a nodo della
rete: ogni router che riceve il datagramma prima di inoltrarlo ne decrementa il TTL (modificando di conseguenza
anche il campo Header Checksum), quando questo arriva a zero il datagramma non viene più inoltrato ma
scartato. Tipicamente, quando un datagramma viene scartato per esaurimento del TTL, viene automaticamente
inviato un messaggio ICMP al mittente del datagramma, specificando il codice di Richiesta scaduta; la ricezione
di questo messaggio ICMP è alla base del meccanismo di traceroute.
• Protocol [8 bit] - Indica il codice associato al protocollo utilizzato nel campo dati del datagramma IP: per
esempio al protocollo TCP è associato il codice 6, ad UDP il codice 17, mentre ad IPv6 è associato il codice 41.
La lista dei codici dei vari protocolli, inizialmente definita in RFC 790, è mantenuta e gestita dalla Internet
Assigned Numbers Authority.
• Header Checksum [16 bit] - È un campo usato per il controllo degli errori dell'header. Ad ogni hop, il checksum
viene ricalcolato (secondo la definizione data in RFC 791) e confrontato con il valore di questo campo: se non c'è
corrispondenza il pacchetto viene scartato. È da notare che non viene effettuato alcun controllo sulla presenza di
errori nel campo Data deputandolo ai livelli superiori.
• Source address [32 bit] - Indica l'indirizzo IP associato all'host del mittente del datagramma.
Da notare che questo indirizzo potrebbe non essere quello del "vero" mittente nel caso di traduzioni mediante
NAT. Infatti, qualora un host intermedio effettui questa traduzione, sostituisce l'indirizzo del mittente con uno
proprio, procurandosi poi di ripristinare l'indirizzo originario su tutti i messaggi di risposta che gli arrivano
destinati al mittente originario.
• Destination address [32 bit] - Indica l'indirizzo IP associato all'host del destinatario del datagramma e segue le
medesime regole del campo Source address.
IPv4
55
• Options - Opzioni (facoltative e non molto usate) per usi più specifici del protocollo.
Si ricorda che il valore del campo IHL deve essere sufficientemente grande da includere anche tutte le opzioni
e, nel caso queste siano più corte di una word, il padding necessario a completare i 32 bit. Inoltre, nel caso in
cui la lista di opzioni non coincida con la fine dell'header, occorre aggiungere in coda ad essa un marcatore
EOL (End of Options List).
C'è da notare infine che, potendo causare problemi di sicurezza, l'uso delle opzioni LSSR e SSRR (Loose e
Strict Source and Record Route) è scoraggiato e molti router bloccano i datagrammi che contengono queste
opzioni.
Di seguito è riportata la struttura contenuta nell'header ip.h della libreria GNU C:
struct iphdr
{
#if __BYTE_ORDER == __LITTLE_ENDIAN
unsigned int ihl:4;
unsigned int version:4;
#elif __BYTE_ORDER == __BIG_ENDIAN
unsigned int version:4;
unsigned int ihl:4;
#else
# error "Please fix <bits/endian.h>"
#endif
u_int8_t tos;
u_int16_t tot_len;
u_int16_t id;
u_int16_t frag_off;
u_int8_t ttl;
u_int8_t protocol;
u_int16_t check;
u_int32_t saddr;
u_int32_t daddr;
/*The options start here. */
};
Indirizzamento IPv4
L'indirizzo IPv4 è formato da 32 bit, esso è univoco sulla rete di cui fa parte. Tale indirizzo, inoltre, non va assegnato
all'host, ma alle connessioni fisiche alla rete che l'host possiede (nel cast di host multicollegati o di dispositivi di
rete). Si è però verificato che i primi paesi in cui si è diffuso Internet e all'interno di essi i primi provider, si sono
"accapparrati" un numero di Ip proporzionalmente sbilanciato. Gli ultimi provider hanno pertanto dovuto ricorrere ad
un sistema per ovviare alla scarsità degli IP a loro attribuiti. Hanno pertanto considerato gli utenti a loro connessi di
una intera città come un'unica LAN e pertanto tutti dotati dello stesso IP.
Concettualmente l'indirizzo IP si compone di due parti:
1. identificatore di rete e precisamente della sottorete
2. identificatore di host
IPv4
56
Notazione decimale puntata
Per semplificarne la lettura, ogni indirizzo IP viene descritto con 4 numeri in base decimale, in modo che ognuno
rappresenti un byte (il valore di un byte varia da 0 a 255 quando lo consideriamo in base dieci), separati dal simbolo
"punto"; un esempio di indirizzo IPv4 è 192.0.34.166.
Indirizzi particolari
Ogni indirizzo in cui l'identificativo host presenta tutti 0 si riferisce alla rete, mentre se tutti i bit di questo
identificativo sono a 1, l'indirizzo si riferisce ad una trasmissione broadcast diretta.
In pratica quando ad un router arriva un pacchetto in cui la parte di host dell'indirizzo presenta tutti i bit a 1, esso
esegue un broadcast a tutti i nodi della sotto-rete. Questo comportamento è stato sfruttato dai cracker per creare
attacchi di tipo denial of service, pertanto è buona norma disabilitare nei router l'inoltro del broadcast diretto.
Indirizzamento a classi
Se un host deve comunicare con un altro host della stessa sottorete, userà il protocollo di livello 2 della rete a cui è
collegato, altrimenti dovrà inviare i pacchetti ad un gateway o router, che sarà connesso ad altre reti e si occuperà di
inoltrare i pacchetti ricevuti.
La comunicazione tra i router avviene mediante indirizzi IP utilizzando delle tecniche particolari di indirizzamento
per individuare la sottorete e l'host.
Originariamente lo schema delle suddivisioni delle due componenti era a classi per cui un indirizzo IP apparteneva
una classe (classfull) in base ai primi 4 bit dell'IP.
Con questo schema l'indirizzo è ad autoidentificazione perché il confine tra le due componenti si può determinare
con i bit più significativi.
Limiti
Il numero di indirizzi univoci disponibili in IPv4 è
, ma bisogna
tener presente che non vengono usati tutti, perché alcuni sono riservati a un particolare utilizzo (ad esempio gli
indirizzi 0.0.0.0, 127.0.0.1, 255.255.255.255, 192.0.34.166 e la classe 192.168.0.1/16) e perché certe classi non
vengono sfruttate interamente per via della suddivisione interna in classi più piccole.
L'indirizzamento a classi, proprio per questo, presenta diversi limiti dovuti soprattutto al numero di host gestibili
dalle diverse classi.
In pratica se si esauriscono gli indirizzi univoci resi disponibili da una classe, ad esempio la C connettendo più di
255 host, occorre fare ricorso ad un indirizzo di classe superiore.
Il cambiamento di indirizzo non è indolore con questa tecnica perché il software di rete va aggiornato con i nuovi
indirizzi e non consente una transizione graduale.
In pratica l'indicatore di rete univoco non poteva adempiere alle esigenze della crescita che negli anni '80 ebbero le
reti LAN. Quindi per risparmiare i prefissi di rete si dovettero escogitare altre tecniche come quella del
mascheramento (vedi NAT) per continuare a fare in modo che IPv4 potesse adempiere al suo ruolo prima dell'entrata
di IPv6.
IPv4
57
Indirizzamento senza classi
L'indirizzamento in classi è considerato obsoleto, e per permettere un migliore sfruttamento degli indirizzi IP
disponibili, è stato introdotto l'indirizzamento senza classi (classless), o CIDR.
La modifica introdotta dal CIDR consiste essenzialmente nell'utilizzare maschere di sottorete (subnet mask) di
lunghezza arbitraria, mentre l'indirizzamento con classi ammetteva solo tre lunghezze della maschera di sottorete: /8,
/16 e /24. La maschera della vecchia classe C (/24) è ancora popolare, ma si usano anche maschere più corte per reti
grandi (/23 o /22) o più lunghe per reti piccole (/25, /26, fino a /30 per reti punto-punto).
I bit che nella maschera di sottorete sono a 1 fanno parte dell'indirizzo della sottorete, gli altri sono l'indirizzo
dell'host. Normalmente, la maschera di sottorete è costituita da N bit a 1 seguiti da (32-N) bit a 0, e può essere
abbreviata nella forma /N.
In questo modo non si è vincolati a un numero fisso di bit per determinare l'indirizzo di rete, ma i bit utili a
rappresentare la rete, piuttosto che l'host, sono fissati liberamente.
Vedi anche Saturazione di IPv4.
Enti di gestione
Gli indirizzi IP sono univoci a livello mondiale, e vengono assegnati in modo centralizzato da una gerarchia di enti
appositi. Sono considerati una risorsa preziosa da gestire con cura. Per rafforzare questo concetto, si parla di
"indirizzi IP pubblici".
Inizialmente l'autorità preposta era la IANA (Internet Assigned Number Authority), dopo il 1998 venne creato
l'ICANN (Internet corporation for Assigned Names and Numbers) che opera tuttora. Essa è responsabile della
gestione degli indirizzi IP in base alle direttive dell'RFC 2050.
Note
[1] (EN) IPv6: IPv6 / IPv4 Comparative Statistics (http:/ / bgp. potaroo. net/ v6/ v6rpt. html)
Voci correlate
•
•
•
•
•
Internet Protocol
IPv6
Classi di indirizzi IP
Saturazione di IPv4
Transizione IPV4/IPV6
Collegamenti esterni
• (EN) RFC 791 - Internet Protocol (http://www.ietf.org/rfc/rfc0791.txt)
• (EN) RFC 3168 - Explicit congestion notification (http://tools.ietf.org/html/rfc3168)
• (EN) RFC 2050 - Internet Registry IP Allocation Guidelines (http://www.ietf.org/rfc/rfc2050.txt)
IPsec
58
IPsec
In telecomunicazioni e informatica IPsec, abbreviazione di IP Security, è uno standard per reti a pacchetto che si
prefigge di ottenere connessioni sicure su reti IP. La sicurezza viene raggiunta attraverso funzionalità di
autenticazione, cifratura e controllo di integrità dei pacchetti IP (datagrammi). La capacità di fornire protezione o
sicurezza viene fornita quindi a livello di rete (diversamente da HTTPS, SSL/TLS) cui IP appartiene e questo fatto
rende questo protocollo trasparente al livello delle applicazioni che non devono quindi essere modificate.
Panoramica dello standard
Scopo del progetto
IPsec è stato progettato per rendere sicure sia comunicazioni portal-to-portal sia comunicazioni end-to-end. Nella
prima configurazione il traffico viene reso "sicuro" a diversi computer (in alcuni casi ad un'intera LAN); nella
seconda solo i peer che stabiliscono la connessione scambiano pacchetti protetti. Tuttavia l'uso predominante di
IPsec è la creazione di VPN (virtual private network); per conseguire tale scopo possono essere utilizzati entrambi i
metodi prima esposti.
Introduzione
IPsec è una collezione di protocolli formata da:
• Protocolli che implementano lo scambio delle chiavi per realizzare il flusso crittografato.
• Protocolli che forniscono la cifratura del flusso di dati;
Per quanto riguarda il primo aspetto, esistono due protocolli: Authentication Header (AH) e Encapsulating Security
Payload (ESP).
AH fornisce autenticazione e integrità del messaggio, ma non offre la confidenzialità ed è il protocollo IP 51.
ESP fornisce invece autenticazione, confidenzialità e controllo di integrità del messaggio ed è il protocollo IP 50.
Per questi motivi ESP è molto più usato di AH.
Attualmente esiste un solo protocollo per lo scambio delle chiavi, il protocollo IKE. IPsec è parte integrante di IPv6,
mentre è opzionale in IPv4. Di conseguenza, ci si aspetta che sarà maggiormente utilizzato quando IPv6 acquisterà
popolarità. Il protocollo è definito negli RFC 2401-2412. Dal 2004, sono in corso studi per l'aggiornamento dei
protocolli.
Dettagli tecnici
IPsec supporta due modalità di funzionamento:
• Transport mode
1. connessione host-to-host
2. usato dagli end-point non dai gateway
3. viene cifrato solo il payload dei datagrammi IP, non l'header
4. computazionalmente leggero
5. ogni host che vuole comunicare deve avere tutto il software necessario ad implementare IPsec
6. si aggiunge solo l'header IPsec; mittente e destinazione si vedono
• Tunnel mode
1. connessione gateway-to-gateway
2. viene cifrato tutto il pacchetto IP originale
3. utilizzato per realizzare le VPN
IPsec
59
4.
5.
6.
7.
computazionalmente oneroso
solo i gateway devono avere il software Ipsec
si hanno punti di centralizzazione quindi single point of failure
si ha un doppio incapsulamento, aggiungendo l'header del gateway e l'header IPsec; mittente e destinazione
non si vedono
Le due modalità sono supportate sia da AH che da ESP.
IPsec può essere utilizzato anche per connessioni tra gateway e host.
Security Association e Security Policy
Il concetto di Security Association (in breve SA) è alla base del funzionamento di IPsec. Una SA è un "contratto"
fra le due entità coinvolte nella comunicazione; in essa vengono stabiliti i meccanismi di protezione e le chiavi da
utilizzare durante il successivo trasferimento dei dati. Nell'ambito di IPsec, stabilire le security association è compito
del protocollo IKE, sebbene sia possibile anche impostarle manualmente; ovviamente la procedura manuale è
sconsigliata in quanto può introdurre errori che indeboliscono il tunnel.
Una peculiarità delle SA è che individuano una comunicazione unidirezionale; quindi durante la creazione della
connessione le entità coinvolte creano e gestiscono una SA per ognuno dei versi della comunicazione, quindi 2 SA
individuano un canale full-duplex. Al fine di semplificare la gestione delle SA, viene utilizzato un apposito database
detto SAD (Security Association Database), dove viene tenuta traccia delle SA attive. In particolare una SA è
costituita dai seguenti parametri:
•
•
•
•
Gli indirizzi IP dei peer coinvolti nella comunicazione;
Il protocollo che verrà utilizzato per il tunnel (AH o ESP);
le tecniche di cifratura utilizzate e le relative chiavi;
Un intero a 32 bit chiamato SPI, acronimo per Security Parameter Index.
Dall'esame dei parametri di una SA si deducono quindi tutte le informazioni necessarie per stabilire le modalità in
cui il traffico debba essere protetto; il passo successivo è definire quale traffico debba essere protetto: di questo si
occupa la Security Policy (in breve SP). Una SP è una regola che stabilisce che tipo di traffico deve essere
instradato nel tunnel e quindi essere coperto da IPsec; in modo analogo alle SA, le SP sono contenute in un SPD
(Security Policy Database). La security policy contiene:
• Indirizzo sorgente e indirizzo destinazione del pacchetto. Tale informazione è già contenuta nella SA e quindi può
sembrare ridondante. In realtà questa informazione ha senso quando viene utilizzato il Tunnel mode.
• Il protocollo e la relativa porta da instradare nel tunnel. Questa opzione dipende dall'implementazione del
protocollo e non è sempre contemplata; nel caso non sia disponibile, tutto il traffico prodotto viene veicolato nel
tunnel.
• Un identificativo della SA da utilizzare per processare i dati.
Una volta stabilita la security association e la security policy, può cominciare la comunicazione che sfrutterà il
protocollo AH o il protocollo ESP cui verrà passato il parametro SPI, che permetterà di risalire alle tecniche
crittografiche da utilizzare per la trasmissione.
IPsec
60
Protocolli di IPsec
IKE
Descrizione
IKE è un acronimo per Internet key exchange ed è il protocollo usato per stabilire una security association nella
suite di protocolli IPsec. Questo protocollo è definito in RFC 4306. È un protocollo di livello applicazione e utilizza
il protocollo UDP come protocollo di trasporto; la porta su cui viene stabilita la connessione è 500.
L'obiettivo di IKE è stabilire uno shared session secret, ossia una chiave condivisa corrispondente alla sessione da
instaurare e a tal fine utilizza l'algoritmo di Diffie-Hellman; dallo shared secret vengono successivamente derivate le
chiavi crittografiche che verranno utilizzate per la successiva comunicazione. Al fine di autenticare le entità
coinvolte nella comunicazione possono essere utilizzate tecniche a chiave simmetrica o, alternativamente, a chiave
asimmetrica; in quest'ultimo caso si fa ricorso a infrastrutture a chiave pubblica (PKI) e all'uso di certificati digitali.
Authentication Header (AH)
Descrizione
L''Authentication Header (abbreviato AH), è un protocollo che fa parte della suite IPsec. Il suo compito è quello
di fornire un controllo di integrità pacchetto per pacchetto, verifica dell'autenticità del mittente e protezione
contro i replay attack. AH non garantisce in alcun modo la confidenzialità del messaggio.
L'autenticità è garantita tramite funzioni di hash a chiave simmetrica, ossia tramite il meccanismo delle pre-shared
keys. Per poter comunicare, due entità devono condividere la medesima chiave; tale chiave viene combinata con il
messaggio originale e quindi viene calcolato il checksum tramite una funzione di hash crittografico(MD5 o SHA). Il
messaggio e il checksum vengono, infine, inviati al peer remoto. Il peer remoto riceve il messaggio; dato che questo
è in chiaro, lo può leggere, combinare con la chiave di cui è a conoscenza e calcolare il checksum. Se il checksum
corrisponde a quello inviato, il messaggio è autentico e viene accettato altrimenti viene scartato in quanto è stato
modificato in un modo non consentito dallo standard.
Il protocollo AH è progettato per proteggere l'intero pacchetto IP inviato; tuttavia bisogna considerare che alcuni
campi dell'header IP, come il TTL, variano durante la trasmissione; queste modifiche devono essere necessariamente
consentite, per cui prima di calcolare il checksum, i campi cui è permesso variare vengono posti a 0.
Formato del pacchetto
Di seguito viene illustrata la struttura del pacchetto AH (ogni casella rappresenta 1 byte).
0
1
2
3
Header successivo Dimensione Payload RISERVATO
Security Parameter Index (SPI)
Numero di Successione
Dati per l'autenticazione (lunghezza variable)
Header successivo
Indica che tipo di protocollo verrà dopo.
Dimensione Payload (8 bit)
La lunghezza dell'AH in word (1 word = 32 bit) meno 2. Per esempio , 96 sono i bit di default del campo
Authentication Data, più altri 96 bit per i campi di lunghezza fissa di AH fanno 6 word ( 96+96 = 192 bit ,
diviso per 32 = 6). Sottraendo 2 risulta quindi 4 il valore contenuto della dimensione del payload standard.
IPsec
61
RISERVATO
Spazio lasciato per sviluppi futuri. Tutti i bit di questo campo vengono impostati a 0.
Security Parameter Index
Questo campo identifica i parametri di sicurezza in combinazione con l'indirizzo IP. In genere è un numero
pseudo-casuale che identifica la security association cui fa parte questo pacchetto.
Numero di successione
Una successione di numeri monotonicamente crescenti. Per imperdire i replay attack, il numero di successione
quando raggiunge il valore massimo (2^{32}-1) non deve ritornare a 0, ma una nuova SA deve essere creata.
Dati per l'autenticazione
Contiene l'Integrity Check Value (ICV) è rappresenta l'HMAC calcolato dall'originatore del messaggio.
L'HMAC viene calcolato utilizzando i campi dell'header IP (con il TTL originario), i campi dell'header AH
tranne i dati dell'autenticazione (viene considerato a 0) e infine tutti i dati degli header di livello superiore,
compresi quelli applicativi, che non vengono modificati durante il trasporto.
Transport mode e Tunnel mode
AH supporta nativamente sia il transport mode che il tunnel mode. In transport mode vengono protetti solo i
protocolli di livello superiore a quello di rete (TCP, UDP, etc); in tunnel mode il pacchetto IP originale viene
incapsulato in un nuovo pacchetto IP, dopo essere stato elaborato da AH. Ne spieghiamo il funzionamento con
l'ausilio di alcuni disegni. Il metro di confronto è senza dubbio il pacchetto IP originale; in presenza di un
collegamento basato su IPsec il pacchetto viene, ovviamente, alterato.
Header IP Header TCP Dati
Pacchetto IP originale
A seconda della modalità di funzionamento di IPsec (tunnel mode o transport mode), il pacchetto originale viene
alterato in modo diverso.
Header IP Header
AH
Header TCP Dati
dati autenticati
AH in transport mode
Header IP esterno Header
AH
Header IP Header TCP Dati
dati autenticati
AH in tunnel mode
La linea azzurra indica le zone del pacchetto che sono autenticate. Dal punto di vista della protezione, in entrambi i
casi, i pacchetti vengono protetti completamente. Notiamo che nell'header IP, alcuni campi variano durante il transito
nella rete, ad esempio il TTL. Questi campi vengono posti a 0 prima di calcolare la funzione di hash, necessaria per
la protezione del pacchetto. Da quanto appena detto si evince subito che il protocollo AH è incompatibile con le
varie tecniche di NAT; difatti se vengono alterati i campi indirizzo nell'header IP (in entrambe le modalità), in
ricezione la checksum fallisce subito.
IPsec
62
Encapsulating Security Payload (ESP)
Descrizione
Encapsulating Security Payload, denotato con l'acronimo ESP, è un protocollo che fa parte della suite IPsec. Il suo
obiettivo è fornire autenticità, confidenzialità e controllo di integrità alla comunicazione. Contrariamente a quanto fa
AH, l'header IP non viene coperto dai controlli. Al pari di AH, però, supporta sia il tunnel mode che il transport
mode.
Formato del pacchetto
Di seguito viene riportato il formato del pacchetto ESP (ogni casella rappresenta 1 byte).
0
1
2
3
Security Parameters Index (SPI)
Sequence Number
Payload * (variable)
Padding (0-255 byte)
Pad Length Next Header
Authentication Data (variable)
Security Parameters Index (SPI)
Al pari di quanto avviene in AH, questo campo, in combinazione con l'indirizzo IP, individua la Security
Association cui appartiene il pacchetto.
Sequence Number
Una successione di numeri monotonicamente crescente, che identifica il pacchetto all'interno delle Security
Association e previene da replay attack.
Payload
I dati che devono essere trasferiti
Padding
È un campo di riempimento. È necessario in quanto alcuni codici di cifratura lavorano su blocchi di lunghezza
fissa. Serve a far crescere la dimensione dei dati fino a divenire multiplo del blocco che l'algoritmo in uso
riesce a gestire.
Pad Length
Rappresenta, in ottetti, la dimensione dei dati di padding aggiunti.
Next Header
Identifica il protocollo dei dati trasferiti
Authentication Data
Contiene i dati usati per autenticare il pacchetto.
Come si può vedere dalla struttura del pacchetto (ma sarà illustrato meglio in seguito), ESP "avvolge" i dati dei
protocolli di livello superiore, contrariamente a quanto fa AH che antepone un header.
IPsec
63
Tunnel mode e Transport mode
Essendo un protocollo per il trasferimento dati della suite IPsec, ESP supporta sia il Tunnel mode che il Transport
mode. A seconda della modalità tratta i dati in modo differente. Prima di descrivere l'incapsulamento dei dati
mostriamo il pacchetto IP originale, che transiterebbe sulla rete in assenza di IPsec
Header IP Header TCP Dati
Pacchetto IP originale
Header IP Header
ESP
Header TCP Dati Trailer
ESP
ESP
auth
Dati autenticati
ESP in Transport mode
Header IP Header
ESP
Header IP interno Header TCP Dati Trailer
ESP
ESP
auth
Dati autenticati
ESP in Tunnel mode
Le linee azzurre sottendono la parte di pacchetto che viene sottoposta a controllo di autenticità e integrità; le zone
verdi indicano le zone di pacchetto che vengono protette tramite algoritmi crittografici. Per quanto riguarda gli
algoritmi di cifratura possono essere utilizzati Data Encryption Standard (DES), 3DES, AES e Blowfish. Il controllo
di integrità e autenticità viene eseguito tramite HMAC (funzioni di hash); l'hash viene calcolato tramite una funzione
di hash (MD5 o SHA1), utilizzando una chiave condivisa; l'hash ottenuto viene allegato al messaggio e inviato. In
ricezione viene controllata l'integrità del messaggio. Dagli schemi visti prima si nota che l'indirizzo IP più esterno
non viene coperto dal controllo di integrità. Tale opzioni rende il protocollo ESP adatto ad essere utilizzato in alcuni
tipi di NAT, in particolare in quelli statici. Tuttavia esistono soluzioni ad-hoc per il funzionamento congiunto di
IPsec e NAT come il NAT Traversal.
NAT Traversal
Descrizione
NAT traversal (o più in breve NAT-T) è il nome di un protocollo facente parte della suite IPsec e standardizzato in
diversi RFC, di cui quello ufficiale è RFC 3947. L'obiettivo di questo protocollo è fornire la possibilità di stabilire un
tunnel IPsec anche quando uno dei due peer coinvolti subisce un'operazione di nat per raggiungere l'altra entità
coinvolta nella comunicazione.
Scenario
Il NAT è una tecnica molto utilizzata per il riuso degli indirizzi IP. Tuttavia gli host dietro un router (o un firewall)
che effettua operazioni di NAT non godono di connettività end-to-end. Sebbene esistano diversi tipi di NAT,
l'obiettivo generale è l'alterazione degli header del pacchetto. Questo comportamento è in netto contrasto con IPsec
che ha tra i suoi obiettivi il controllo dell'integrità del pacchetto. In particolare il NAT è incompatibile con AH sia
in tunnel mode che in transport mode, in quanto AH verifica l'integrità di tutto il pacchetto IP. ESP, invece, non
copre l'header IP con controlli di sorta né in Tunnel mode né in Transport mode, per cui risulta adatto nel caso in cui
il NAT eseguito sia di tipo SNAT; in altre parole, la modifica apportata dal router deve coinvolgere solamente
l'header IP e non anche la porta del livello superiore.
IPsec
64
Il NAT crea problemi anche con IKE e soprattutto con IKE in main mode. Il main mode usato congiuntamente al
metodo delle preshared-keys richiede l'autenticazione degli host coinvolti nella comunicazione e tale autenticazione
prevede un controllo sugli indirizzi IP; per cui l'alterazione dell'indirizzo da parte di un'apparecchiatura di NAT
provoca il fallimento dell'autenticazione.
In genere, nei dispositivi preposti alla gestione dei tunnel IPsec e nei client VPN, il NAT-T non è abilitato di default
ma deve essere impostato a mano; tuttavia il suo utilizzo rimane opzionale: difatti durante la creazione della security
association, i peer determinano se uno dei due subisce operazioni di NAT e solo in questo caso viene usato il
NAT-T; questa operazione viene fatta durante la prima fase della negoziazione IKE. In prima battuta, i peer
verificano che entrambi siano in grado di supportare in NAT-T; questa verifica è eseguita nella primissima fase del
protocollo IKE, per mezzo di un pacchetto con un campo Vendor-ID, che contiene un valore hash noto.
Una volta stabilito che entrambi supportano il NAT-T, vengono inviate delle frame "NAT-Discovery" (NAT-D), in
modo da verificare chi dei due subisca il NAT, o al limite se lo subiscano entrambi.
Una volta stabilito chi subisce il NAT, la comunicazione si sposta su una nuova coppia di porte UDP e l'entità
"nat-tata" comincia a inviare delle frame keepalive; queste frame servono a mantenere fisse le porte di
comunicazione sul router e ad impedirgli di riassegnarle ad una nuova comunicazione.
Descriviamo come viene incapsulato il pacchetto originale ESP.
Header IP Header ESP Header IP interno Header TCP Dati Trailer ESP ESP auth
ESP in Tunnel mode
Header IP
Header UDP
Header NAT-T
Header ESP
Header IP interno
Header TCP
Dati
Trailer ESP
ESP auth
ESP in Tunnel mode con incapsulamento UDP per NAT-T
I campi segnati in verde scuro sono quelli relativi al NAT-T; questi campi vengono inseriti subito dopo l'header IP
esterno, che non viene alterato, così come non vengono alterati i campi successivi. In ricezione viene fatta
l'operazione inversa.
Elenco degli RFC relativi ad IPsec
RFC 4301
Security Architecture for the Internet Protocol
RFC 2402
Authentication Header
RFC 2406
Encapsulating Security Payload
RFC 2407
IPsec Domain of Interpretation for ISAKMP (IPsec DoI)
RFC 2408
Internet Security Association and Key Management Protocol (ISAKMP)
RFC 2409
Internet Key Exchange (IKE)
RFC 2410
The NULL Encryption Algorithm and Its Use With IPsec
RFC 2411
IPsec
65
IP Security Document Roadmap
RFC 2412
The OAKLEY Key Determination Protocol
RFC 3947
Negotiation of NAT-Traversal in the IKE
Voci correlate
•
•
•
•
•
Sicurezza informatica
HTTPS
SSL
TLS
SSH
Collegamenti esterni
• http://www.ipsec-howto.org/italian/x151.html
• IPsec e TLS a confronto: funzioni, prestazioni ed estensioni [1]
• How to pass IPSec traffic through ISA Server [2]
Note
[1] http:/ / www. linux. it/ ~davide/ doc/ tesi_html/ index. html
[2] http:/ / www. isaserver. org/ articles/ IPSec_Passthrough. html
Livello datalink
Il livello datalink è il secondo livello dei protocolli del modello ISO/OSI per l'interconnessione di sistemi aperti.
Questo livello in trasmissione riceve pacchetti dal livello di rete e forma i frame che vengono passati al sottostante
livello fisico con l'obiettivo di permettere il trasferimento affidabile dei dati attraverso il sottostante canale.
Il livello datalink deve quindi svolgere diverse funzioni specifiche:
• in trasmissione raggruppare i bit provenienti dallo strato superiore e destinati al livello fisico in pacchetti chiamati
frame (framing);
• in ricezione controllare e gestire gli errori di trasmissione (controllo di errore);
• regolare il flusso della trasmissione fra sorgente e destinatario (controllo di flusso).
Tutto ciò consente di far apparire in ricezione, al livello superiore, il mezzo fisico come una linea di trasmissione
esente da errori.[1][2]
Trasmissione sincrona e asincrona
La trasmissione seriale può avvenire in modo sincrono o asincrono.
Nella trasmissione asincrona ogni carattere trasmesso viene preceduto e seguito da segnali che indicano appunto
l'inizio e la fine del carattere; tali segnali vengono detti segnali di start e stop. La trasmissione asincrona perciò viene
detta anche trasmissione start-stop. Con tale metodo ogni carattere può essere considerato indipendente dagli altri,
l'intervallo di tempo tra l'invio di due caratteri è imprecisato.
Nella trasmissione sincrona i caratteri da inviare vengono raggruppati in messaggi (frame). Ogni frame viene fatto
precedere da caratteri di sincronizzazione che servono a far sì che la stazione ricevente si sincronizzi sulla velocità di
Livello datalink
trasmissione della stazione che invia il messaggio. La trasmissione sincrona è più veloce perché i tempi morti di
trasmissione vengono ridotti, ma un errore anche in un singolo bit può danneggiare l'intero messaggio inviato. I
protocolli di trasmissione sincrona si suddividono in BCP Byte Control Protocol) o orientati al byte, in cui viene
mantenuta la suddivisione in caratteri del messaggio da trasmettere, e BOP (Bit Oriented Protocol) o orientati al bit,
in cui i messaggi sono visti come una successione di bit (in questo modo non si è legati alla codifica ASCII a 8 bit).
Un'operazione importante nella trasmissione sincrona è il framing, cioè la suddivisione in frame delle informazioni
da trasmettere.
Framing
Al fine di fornire servizi al livello di rete, il livello data link deve usufruire dei servizi fornitigli dal livello fisico.
L'approccio consueto del livello data link è quello di dividere il flusso dei bit in pacchetti (adattatti appunto ad una
trasmissione su una rete a pacchetto), e calcolarne la Checksum. Vari metodi vengono utilizzati per la suddivisione
dei bit in pacchetti o frame:
• Conteggio dei caratteri.
• Caratteri di inizio e fine.
• Indicatori (flag) di inizio e fine.
Il metodo del conteggio di caratteri (ottenuto specificando nel campo d’intestazione del pacchetto il numero di
caratteri del frame) è raramente utilizzabile poiché, se il campo che contiene il numero di caratteri si rovina (altera)
durante la trasmissione, non si può più individuare dove comincia il frame successivo; vengono quindi utilizzate le
altre tecniche.
Nella trasmissione orientata al byte (il frame mantiene la suddivisione in byte) il frame viene preceduto dalla
sequenza di caratteri ASCII DLE STX (Data Link Escape Start of TeXt) e finisce con la sequenza DLE ETX (Data
Link Escape End of TeXt). Se un frame si rovina e la destinazione perde la sincronizzazione basta trovare il
successivo DLE STX o DLE ETX. Il carattere DLE però può comparire casualmente dentro al frame quando
vengono trasmessi dati binari come programmi oggetto o numeri in virgola mobile; perché questi caratteri non
interferiscano viene aggiunto un ulteriore DLE (che viene rimosso a destinazione prima di passare al frame al livello
di rete) in modo che solo i DLE singoli vengano interpretati come delimitatori; questa tecnica si chiama character
stuffing.
Nella trasmissione orientata al bit (il frame può contenere un numero qualsiasi di byte) ogni frame inizia e finisce
con la sequenza 01111110 chiamata flag: questa sequenza può comparire casualmente nei dati, perciò in
trasmissione dopo cinque 1 consecutivi viene sempre inserito uno 0 nel flusso di bit, indipendentemente dal fatto che
il bit successivo sia 1 o 0, mentre in ricezione bisogna provvedere ad eliminare i bit inseriti, rimuovendo sempre uno
0 dopo cinque 1; questa tecnica è chiamata bit stuffing.
Controllo di errore
Come detto, la stazione mittente del livello data-link riceve i dati dal livello superiore e li suddivide in frame prima
di affidarli al livello fisico per la trasmissione su canale, aggiungendo ad esso un codice per il controllo degli errori
(integrità dati) di trasmissione in ricezione (checksum).
Quando un pacchetto arriva a destinazione, la checksum viene ricalcolata dallo stesso livello data-link del sistema
ricevente. Se il risultato è diverso da quello contenuto nel pacchetto, il livello data-link riconosce che è stato
commesso un errore e prende adeguati provvedimenti (come ad esempio scartare il pacchetto e spedire un messaggio
di errore in risposta al mittente).
In generale si hanno due tipi di codici di controllo, i codici rilevatori che permettono soltanto di capire che il frame
non è corretto ed eventualmente richiedere la ritrasmissione del pacchetto (ARQ Automatic Repeat-reQuest) e i
codici correttori che permettono non solo di capire se si è verificato un errore, ma anche di individuare la posizione
66
Livello datalink
dell'errore e di conseguenza correggerlo (FEC Forward Error Correction). Questi ultimi codici richiedono molti più
bit dei codici rilevatori e quindi sprecano ampiezza di banda; di solito perciò vengono usati i codici a sola
rilevazione.
In caso di errore, se il servizio è inaffidabile il frame può essere semplicemente scartato; se la linea deve essere
affidabile bisogna che tutti i frame arrivino correttamente; se si usa un codice rilevatore il ricevente deve richiedere
la ritrasmissione dei frame errati.
La scelta tra codici rilevatori e correttori può dipendere anche dalla velocità delle linee (per linee a bassa velocità,
aspettare la ritrasmissione potrebbe richiedere troppo tempo) o affidabilità (se il tasso di errore sulla linea è molto
basso non vale la pena sprecare molta banda per un codice correttore) o dal tipo di servizio richiesto (real-time o
meno).
Il modo consueto per assicurare una consegna affidabile è quello di fornire al mittente un riscontro di quello che sta
accadendo all'altro capo della linea. Tipicamente il protocollo richiede che il ricevente rispedisca alcuni speciali
pacchetti di controllo con valore positivo o negativo a seconda dei pacchetti ricevuti. Se il mittente riceve un
riscontro positivo su di un pacchetto spedito, sa che esso è arrivato correttamente. Se invece ottiene un riscontro
negativo significa che qualcosa è andata male e che occorre ritrasmettere il pacchetto.
Una complicazione aggiuntiva potrebbe derivare dalla possibilità che i problemi hardware causino la sparizione
totale del pacchetto. Se un pacchetto non arriva a destinazione, il mittente non aspetterà all'infinito, infatti viene
utilizzato un timer, che viene avviato quando i dati vengono trasmessi, se il timer supera la soglia limite
(programmata) senza ricevere l'ACK (Acknowledgment o conferma), rimanderà di nuovo i pacchetti. Tuttavia, se il
pacchetto o il messaggio di riscontro vengono persi, il timer scade (time-out), e la stazione mittente, non ricevendo
conferma, è costretta a reinviare i dati, ma a questo punto il mittente potrebbe ricevere due o più volte lo stesso
pacchetto. Per risolvere questo problema, i pacchetti inviati vengono numerati, così il sistema ricevente, nel caso in
cui riceva un numero di pacchetto uguale al precedente, cioè una copia del pacchetto, lo scarta. Questa tecnica è nota
come Stop and wait; le altre tecniche maggiormente utilizzate per il controllo degli errori sono il Codice di Hamming
e il CRC (Controllo a Ridondanza Ciclica). Di fatto però funzionalità di controllo dell'errore sui singoli pacchetti
vengono espletate non solo a livello datalink, ma in ogni altro strato del protocollo per garantire la correttezza dei
dati di servizio (header) dei protocolli destinati ai rispettivi strati.
Controllo di flusso
Un altro importante problema di progettazione che si ritrova nel livello di data link è quello di gestire una linea
condivisa quando più nodi vogliono inviare messaggi nello stesso tempo e inoltre deve decidere cosa fare di un
mittente che sistematicamente tende a trasmettere pacchetti più velocemente di quanto il ricevente possa accettarli.
Questa situazione può facilmente essere riscontrata quando il mittente è dislocato su una macchina veloce e il
ricevente su una macchina lenta. Il mittente continua a spedire pacchetti ad alta velocità, fino a quando il ricevente
non è completamente sopraffatto. Anche se la trasmissione è esente da errori, a un certo punto il ricevente non sarà
in grado di gestire i pacchetti in arrivo e inizierà a perderli (buffer overflow).
La tipica soluzione è quella di introdurre un controllo di flusso per obbligare il mittente a rispettare la velocità del
ricevente nello spedire i pacchetti. Questa imposizione solitamente richiede un certo tipo di meccanismo di riscontro
(feedback) in modo che il mittente possa essere avvisato se il ricevente è in grado di ricevere o meno.
Nel caso in cui invece più nodi vogliono inviare contemporaneamente dei messaggi, si tende ad introdurre un
controllo centralizzato, creando un singolo nodo di controllo, responsabile di determinare chi ottiene la priorità
all'interno della rete; il nodo successivo quindi, controllerà quando la rete non sarà più occupata, così da poter inviare
il messaggio appena questa diventerà libera. Può accadere però, che più nodi monitorizzano la rete e che appena
questa sia libera, inviano immediatamente i messaggi, in questo caso si avranno dei problemi di collisione; per
ovviare a questo problema, i nodi che monitorano la rete saranno regolati da un protocollo di accesso multiplo
attendendo ad esempio un tempo casuale prima di inviare i messaggi, poiché è improbabile che i nodi scelgano lo
67
Livello datalink
stesso istante per inviare i dati.
Protocolli
Nello stack IP, in alcuni casi, il livello datalink consiste nell'utilizzo di una rete realizzata con un altro protocollo per
il trasporto di pacchetti IP. Questo avviene ad esempio con X.25, Frame Relay, Asynchronous Transfer Mode. Sono
protocolli del livello datalink Ethernet (per le LAN) e PPP, HDLC e ADCCP per le connessioni punto a punto (cioè
tra due stazioni collegate tra loro fisicamente).
Può essere o non essere affidabile: molti protocolli di data link non utilizzano conferme e alcuni potrebbero
addirittura non controllare se sono stati commessi errori di trasmissione. In questo caso devono essere i livelli
superiori ad effettuare il controllo di flusso, il controllo degli errori e gestire le conferme (e relative ritrasmissioni).
In alcune reti, come le LAN IEEE 802, questo livello è diviso nei sottolivelli MAC e LLC. Quest'ultimo è comune a
tutti i livelli MAC, come token ring e IEEE 802.11 ma anche a livelli MAC che non fanno parte dello standard 802,
come FDDI.
Sottolivello LLC
Il sottolivello superiore è Logical link control (LLC), e può fornire servizi di controllo di flusso, conferma,
rilevazione (o correzione) degli errori. I protocolli PPP e HDLC fanno parte di questo sottolivello.
I protocolli di sottolivello LLC che forniscono il servizio di conferma di o garanzia di ricezione dei dati devono
prevedere messaggi di conferma avvenuta ricezione (acknowledge, o ACK). Il trasmittente può attendere il riscontro
di ciascun messaggio prima di trasmettere il successivo, oppure può continuare a trasmettere fino al raggiungimento
di un numero massimo di messaggi non ancora confermati dal ricevente, nei cosiddetti protocolli finestrati.
Nei protocolli con finestra ciascun pacchetto trasmesso è identificato con un numero progressivo all'interno della
finestra, detto numero di sequenza (sequence number); i messaggi di conferma devono riportare il numero di
sequenza del pacchetto che riscontrano.
I messaggi di conferma possono essere cumulativi ("ricevuti i pacchetti fino a N"), o richiedere la ritrasmisione
cumulativa ("ritrasmettere i pacchetti fino a N") o selettiva dei soli pacchetti non ricevuti correttamente. In alcuni
casi il riscontro dei messaggi ricevuti utilizza un messaggio dedicato, in altri casi il riscontro viene inserito in campi
specifici dei messaggi trasmessi in direzione opposta (piggyback) diminuendo le latenze di ritrasmissione.
Sottolivello MAC
Il sottolivello inferiore è Media Access Control o Medium Access Control. Il suo scopo è quello di disciplinare
l'accesso multiplo di molteplici nodi ad un canale di comunicazione condiviso evitando o gestendo l'occorrenza di
collisioni. Una collisione si verifica quando due o più nodi trasmettono simultaneamente dati sul canale condiviso.
Ciò comporta l'inevitabile perdita dei dati trasmessi con conseguente spreco di banda. Esistono molteplici algoritmi e
protocolli standard per il controllo dell'accesso multiplo. Ad esempio, il MAC IEEE 802.3 adotta l'algoritmo
CSMA/CD mentre il MAC IEEE 802.11 si basa sull'algoritmo CSMA/CA. Il primo è comunemente adottato in LAN
cablate il secondo in WLAN. Due sono le principali tipologie di algoritmi di accesso multiplo: casuale e ordinato.
Nell'accesso multiplo casuale è possibile che si verifichino delle collisioni ma vengono implementati degli opportuni
meccanismi per ridurne la probabilità di occorrenza e per ritrasmettere le trame collise. Nell'accesso ordinato, invece,
l'evenienza di una collisione è del tutto impossibile poiché i nodi seguono un preciso ordine di accesso al canale
(stabilito nella fase di inizializzazione della rete) che li rende utilizzatori esclusivi del mezzo trasmissivo (a meno di
guasti o malfunzionamenti). A livello MAC, inoltre, si definisce il formato della trama, che tipicamente conterrà i
campi di inizio/fine, i campi di indirizzo MAC mittente/destinatario, il pacchetto incapsulato di livello LLC, il codice
per la rilevazione degli errori (FEC), ed opzionalmente dei byte di padding per garantire che la dimensione della
trama non scenda al di sotto di una soglia minima.
68
Livello datalink
Interfacce
Il livello di data link è spesso implementato come un driver della scheda di rete. Il sistema operativo avrà una certa
interfaccia software tra questo livello e quello superiore (di rete). Questa interfaccia non è un livello, ma più uno
standard per la comunicazione tra livelli. Alcuni esempi:
• ODI
• NDIS
• SANA II - Standard Amiga Networking Architecture, versione 2
Note
[1] (EN) Data Link Layer Definition (http:/ / www. linfo. org/ data_link_layer. html). linfo.org, 16-10-2005. URL consultato il 13-5-2012.
[2] (EN) Bradley Mitchell. Visual Networking Overview - The OSI Model - Data Link Layer (http:/ / compnetworking. about. com/ od/
basicnetworkingconcepts/ l/ blbasics_osi2. htm). about.com. URL consultato il 13-5-2012.
Bibliografia
A. Tanenbaum, Reti di Computer. Fabrizia Scorzoni, Reti e protocolli.
Voci correlate
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Management di rete
Protocollo di rete
Organizzazione Internazionale per le Standardizzazioni
ISO/OSI
Ethernet
WiFi
Point-to-Point Protocol
Token ring
ARP
ATM
FDDI
Serial Line Internet Protocol (SLIP)
ARCnet
Cisco Discovery Protocol (CDP)
Controller Area Network (CAN)
Econet
Frame Relay
High-Level Data Link Control (HDLC)
IEEE 802.2 (comprende le funzioni LLC per tutti i livelli MAC IEEE 802)
IEEE 802.11 wireless LAN
LocalTalk
Multiprotocol Label Switching (MPLS)
StarLan
Comunicazioni seriali.
69
Secure shell
Secure shell
In informatica e telecomunicazioni SSH (Secure SHell, shell sicura) è un protocollo di rete che permette di stabilire
una sessione remota cifrata tramite interfaccia a riga di comando con un altro host di una rete informatica. È il
protocollo che ha sostituito l'analogo ma insicuro Telnet.
Descrizione
Il client SSH ha una interfaccia a riga di comando simile a quella di telnet e rlogin, ma l'intera comunicazione
(ovvero sia l'autenticazione (mutua) che la sessione di lavoro) avviene in maniera cifrata. Per questo motivo, SSH è
diventato uno standard di fatto per l'amministrazione remota di sistemi unix e di dispositivi di rete, rendendo
obsoleto il protocollo telnet, giudicato troppo pericoloso per la sua mancanza di protezione contro le intercettazioni.
Il client ed il server SSH sono installati o installabili su molte versioni di UNIX, GNU/Linux, Mac OS X e Microsoft
Windows. Inoltre è disponibile come strumento di amministrazione su alcuni apparati di rete
La sintassi su sistemi UNIX-like è la seguente:
$ ssh [opzioni] nomeutente@host [comando]
dove con "$" si intende il prompt della shell utilizzata
La prima versione dell'SSH era completamente Open Source, mentre la seconda è diventata commerciale; esiste
comunque una versione libera detta OPEN SSH che si basa sulla prima versione, ma che fornisce supporto alla
seconda versione.
Autenticazione
SSH prevede un'autenticazione mutua sia per il client che per il server.
Autenticazione del client
Esistono principalmente due metodi di autenticazione per controllare l'accesso ad un server ssh:
Username/Password
L'utente fornisce un nome utente ed una password, che vengono validati dal server. Questo scambio avviene
all'interno di un canale cifrato, per cui non è a rischio di intercettazione.
Procedura:
1.
2.
3.
4.
A ⇒ B: SSH_MSG_USERAUTH_REQUEST, pappy, ssh-userauth, keyboard-interactive
B ⇒ A: SSH_MSG_USERAUTH_INFO_REQUEST, pappy, password-authentication, 1, "Enter Password"
A ⇒ B: SSH_MSG_USERAUTH_INFO_RESPONSE, 1, "love"
B ⇒ A: SSH_MSG_USERAUTH_SUCCESS.
Per prevenire attacchi brute force si può utilizzare un tool DenyHosts o Fail2ban.
70
Secure shell
Chiave pubblica
Questo metodo di autenticazione è basato sulla crittografia asimmetrica. Per utilizzarlo l'utente genera una coppia di
chiavi. La chiave pubblica è copiata sul server, tipicamente in un apposito file nella home directory dell'utente; la
chiave privata deve essere conservata dall'utente, ed è bene che sia protetta con una parola chiave (passphrase).
Nella fase di accesso, il client ssh prova al server di essere in possesso della chiave privata, e in caso di successo
viene consentito l'accesso. In questo modo, all'utente non è richiesto di fornire la propria password ad ogni
connessione.
Autenticazione del Server
L'autenticazione del server serve ad evitare che un utente maligno "impersoni" il server, facendosi fornire le
credenziali dell'utente (attacco man in the middle). A questo scopo, per ciascun server viene generata una coppia di
chiavi asimmetriche. La chiave privata rimane sul server. La chiave pubblica deve essere installata sui client.
Quando un client si collega ad un server di cui conosce la chiave pubblica, verifica che il server sia ancora in
possesso della chiave privata. Se questa verifica fallisce, la connessione viene abbattuta, evitando di fornire
credenziali al server.
Nella pratica, quando ci si collega ad un server per la prima volta, il client chiede se si vuole accettare la chiave
pubblica di questo server, e se l'utente risponde positivamente memorizza questa chiave e prosegue nella
connessione. Alle connessioni successive con lo stesso server, il client ne verifica l'autenticità, e in caso la chiave
privata non corrisponda impedisce di proseguire la connessione.
Port forwarding
La sicurezza della comunicazione tramite SSH è assicurata grazie alla realizzazione di tunnel criptati che,
trasportando sessioni TCP arbitrarie all'interno della connessione criptata, permettono di proteggere da
intercettazione protocolli non sicuri, o di aggirare limitazioni di routing.
Questa funzionalità è detta port forwarding, e permette di aprire un socket TCP sul client SSH (local port
forwarding) o sul server (remote port forwarding). Le connessioni ricevute su questa porta vengono inoltrate
dall'altro capo della connessione SSH, verso un host e una porta specificata.
Ad esempio, con questo comando ci si collega ad host1, inoltrando la porta 10022 della macchina in cui
lanciamo il client ssh alla porta 22 di host2 attraverso un canale sicuro tra client e host1:
ssh host1 -L 10022:host2:22
Mentre questa connessione è attiva, collegandosi alla porta 10022 del client si viene rediretti verso la porta
22 di host2.
X forwarding
Il port forwarding è utile anche per trasportare applicazioni X Window attraverso una connessione SSH. SSH
imposta anche automaticamente le opportune variabili d'ambiente, in modo che le applicazioni X lanciate da un
terminale remoto vengano visualizzate sul display da cui è stata avviata la connessione.
L'X forwarding dal lato client deve essere abilitato passando l'opzione "-X" mentre dal lato server va modificato il
file di configurazione /etc/ssh/sshd_config abilitando la direttiva X11Forwarding (ricordatevi di riavviare il
server una volta apportata la modifica al file di configurazione).
71
Secure shell
Esempio di uso del port forwarding
Il port forwarding è utile ad esempio per fare assistenza remota a macchine prive di un sistema di gestione remota
sicuro. È possibile creare un tunnel sicuro tra una porta del client e una porta del server remoto o di qualsiasi terza
macchina dietro al sever remoto, a patto che la macchina server abbia abilitato il forwarding. Questo è normalmente
possibile senza installare nessun pacchetto aggiuntivo.
Ad esempio, nel seguente scenario
CLIENT --[rete sicura]--> ssh server --[rete insicura]--> TERZA MACCHINA
Se vogliamo utilizzare un desktop remoto sulla terza macchina basta che ci connettiamo al server ssh includendo un
tunnel tra una porta locale della macchina dove lavoriamo e la porta 3389 della TERZA MACCHINA. Dopo di che
basterà avviare il client RDP e connettersi a localhost:(porta scelta).
Il client ssh locale stabilirà una connessione criptata con il server, creerà un tunnel all'interno di questa connessione
criptata, ed invierà la connessione RDP su questo tunnel. Il server a sua volta stabilirà una normale sessione TCP con
la terza macchina sulla porta richiesta.
Come risultato, il client RDP verrà messo in comunicazione con la terza macchina. La connessione tra ssh server e
terza macchina non sarà criptata, per cui è opportuno che la comunicazione tra queste due macchine non sia a rischio
di intercettazione. La terza macchina vedrà la connessione TCP provenire dal server ssh invece che dal client.
Voci correlate
•
•
•
•
•
•
OpenSSH
PuTTY
WinSCP
Transport Layer Security
Secure copy
SFTP
Collegamenti esterni
•
•
•
•
•
•
•
•
Configurazione dei Virtual Hosts con Apache2 [1]
Esempio di tunnel SSh usando Putty [2]
Uso e configurazione di SSH [3]
(EN) Sito di Openssh [4]
(EN) Pagina di manuale di Openssh [5] via OpenBSD
(EN) HOWTO: Five steps to a more secure SSH [6]
(EN) DenyHosts: script intended to help thwart SSH server attacks [7]
(EN) SSH via HTTP [8]
72
Secure shell
Note
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
http:/ / www. oscene. net/ site/ sysadmin/ web-server/ howto-configurazione-dei-virtual-hosts-con-apache2
http:/ / www. compago. it/ index. php/ it/ manuali/ 39-windows/ 169-tunnel-ssh-con-putty
http:/ / www. cert. garr. it/ documenti/ ssh/
http:/ / www. openssh. org/
http:/ / www. openbsd. org/ cgi-bin/ man. cgi?query=ssh
http:/ / thinkhole. org/ wp/ 2006/ 10/ 30/ five-steps-to-a-more-secure-ssh
http:/ / denyhosts. sourceforge. net/
http:/ / webssh. cz. cc/
73
Fonti e autori delle voci
Fonti e autori delle voci
Suite di protocolli Internet Fonte:: http://it.wikipedia.org/w/index.php?oldid=49493820 Autori:: Abisys, Amux, Ary29, AttoRenato, Braccobaldo92, Castagna, Daniele Forsi, Davide,
Domenico De Felice, Giovannigobbin, Guarracino, Hce, Ilario, KeyboardSpellbounder, Lukius, M1CH3L3, Misakiforever, Moongateclimber, NicFer, Nitya Dharma, Ricercatorew76, Tank00,
Vdfn, Vulkano, 50 Modifiche anonime
Livello applicazioni Fonte:: http://it.wikipedia.org/w/index.php?oldid=49560578 Autori:: Abisys, Ary29, Avesan, Buggia, Daniele Forsi, FrAnCiS, Hce, Mar.pollo, Neustradamus, Pietrodn,
Rotpunkt, Taueres, 11 Modifiche anonime
HTTPS Fonte:: http://it.wikipedia.org/w/index.php?oldid=48770924 Autori:: Abisys, Antonio Felaco, Archiegoodwinit, Avesan, Azrael555, Bla, Davide21, DnaX, Frack, Frieda, Gvf, Hellis,
Hydra2005, IlMatte, Joana, LapoLuchini, Luifiora, Lukius, Marcuscalabresus, Orso della campagna, Panairjdde, Phantomas, Quatar, Roneda, Salvatore Ingala, Salvorapi, Samuele, Sbisolo,
Sedlex, Spinot, Template namespace initialisation script, Toobaz, Vulkano, Ylebru, 40 Modifiche anonime
Hypertext Transfer Protocol Fonte:: http://it.wikipedia.org/w/index.php?oldid=49640948 Autori:: %Pier%, .anaconda, .mau., 5Y, A7N8X, Abisys, Al Pereira, Alfio, Anotherhacktivist, Ary29,
Avesan, Azrael555, Brownout, Buggia, Caulfield, Davide21, Derfel74, Elbloggers, Eumolpo, Fabexplosive, Filemon, FollowTheMedia, Frieda, Giacomo Ritucci, Gioppe, Guidomac, Gvf,
Harlock81, Hashar, Hellis, Iron Bishop, Iskander, L736E, Lorenzor, M.Costantino, M7, Madaki, Mamo139, Marius, MaxDel, Maxferrario, Mfprimo, Miklee, Moongateclimber, Napy84, Ninja,
Phantomas, Rojelio, Rollopack, Salvatore Ingala, Sbisolo, Sentruper, Simone, Suisui, Taueres, Ticket 2010081310004741, TierrayLibertad, Toobaz, Twice25, Unriccio, Vulkano, Wfra, 82
Modifiche anonime
Simple Mail Transfer Protocol Fonte:: http://it.wikipedia.org/w/index.php?oldid=49175275 Autori:: .anaconda, Abisys, Airon90, Ale2006, Alef.ala, Alfio, Arkanoid80, Avesan, Barbaking,
Fbartolom, Frieda, Govoch, Guam, Hashar, Hellis, Iron Bishop, Luckyz, M7, Marcuscalabresus, Mauro742, MikyT, Moongateclimber, Rl89, Sbisolo, Sergio.ballestrero, Simo ubuntu, Sythos,
Toobaz, Unriccio, Vanadio, Vulkano, Zhw, 42 Modifiche anonime
Post Office Protocol Fonte:: http://it.wikipedia.org/w/index.php?oldid=48933194 Autori:: .anaconda, Abisys, Airon90, Alfio, Amux, Avesan, Brownout, Duvet, Fatzeus, Frieda, Govoch, Hawk,
Iron Bishop, Laurentius, Lurkos, Marcuscalabresus, Moongateclimber, Simo ubuntu, Snowdog, Vanadio, Vulkano, 24 Modifiche anonime
Internet Message Access Protocol Fonte:: http://it.wikipedia.org/w/index.php?oldid=48634303 Autori:: Abisys, Airon90, Amarvudol, Avesan, Azrael555, B3t, Dommac, Fedcas, Frieda,
Guidomac, Hashar, Hawk, Iron Bishop, Lurkos, Moongateclimber, Salvatore Ingala, Simone, Snowdog, Suisui, Timendum, Vulkano, 17 Modifiche anonime
Dynamic Host Configuration Protocol Fonte:: http://it.wikipedia.org/w/index.php?oldid=47800970 Autori:: %Pier%, 5Y, Abisys, Alec, Ary29, Avesan, Bla, ChemicalBit, Civvì, Crimer,
Dolcerino, Edonan, Enzotib, Frieda, Hashar, Hce, Homer, Ilario, Ippatsu, M7, Moongateclimber, Naryalin, No2, Nuno Tavares, Phantomas, Pracchia-78, Saint-Just, Shivanarayana, Simone,
ViciDig, Vulkano, 73 Modifiche anonime
Simple Network Management Protocol Fonte:: http://it.wikipedia.org/w/index.php?oldid=48599609 Autori:: %Pier%, Abisys, AttoRenato, Avesan, Daniele Gallesio, DnaX, Hce, Hellis,
Lenore, Leofiore, Marcobombe, Moongateclimber, No2, Phantomas, Sbisolo, Simo ubuntu, Taueres, Toobaz, Vulkano, 24 Modifiche anonime
File Transfer Protocol Fonte:: http://it.wikipedia.org/w/index.php?oldid=49426413 Autori:: 27182, Abisys, Alfio, Anglachel, AnjaManix, Arkanoid80, Ary29, Avesan, Bigboss00, Billiejoex,
Blakwolf, Brownout, Cyberuly, Daemon nio, Dega180, Dirigenteitis, DnaX, Eippol, Eumolpo, Frieda, Gabrielemargon, Gauss, Giomol, Guidomac, Harlock81, Hellis, Iron Bishop, Lorenzo
Zoffoli, Marcel Bergeret, Marius, Mavericksaur, Maxcip, Mirkop88, Moongateclimber, Moroboshi, Ninja, No2, Orso della campagna, Phantomas, Pracchia-78, Sassospicco, Sbisolo, Shardanaa,
Snowdog, Stemby, Template namespace initialisation script, Ticket 2010081310004741, Tomi, Twice25, Vulkano, Wfra, 36 Modifiche anonime
Domain Name System Fonte:: http://it.wikipedia.org/w/index.php?oldid=49063093 Autori:: %Pier%, .anaconda, .mau., Abisys, Albert2810, Alfio, Amarvudol, Ancelli, Angelo Mascaro,
Antonellosinisi1986, Ary29, Ask21, Avesan, Balabiot, Beta16, Brownout, Calabash, ChemicalBit, Dav82, Domenico Romeo, Dragotti SLA, Enricomilano, Fede Reghe, Frack, Frieda, Gastipi,
GiaGar, Gig, Gionnico, Giovannigobbin, Govoch, Gvf, HT, Hce, Hellis, Hill, Igualeonte, Iron Bishop, Jredmond, Kaeso, LoStrangolatore, Lp, LukeWiller, M7, Marcok, Maui, Michelep23,
Mira1-System, Moongateclimber, Nitya Dharma, No2, P tasso, Phantomas, Piermarini, Quoniam, Rojelio, Rollopack, Salparadiso, Samadhi56, Sbisolo, Scienzape, Senpai, Sentruper,
Shivanarayana, Simone, Sinigagl, Sir marek, Smallpox, Snowdog, Speedymax, Spikeyrock, Theferro, Tibe, Utopio, Valepert, Viscontino, Vulkano, XCash, Yukie, Zandegù, 127 Modifiche
anonime
Telnet Fonte:: http://it.wikipedia.org/w/index.php?oldid=45621586 Autori:: %Pier%, .jhc., Abisys, Alez, Ary29, Avesan, Cls-classic, Dfmarco, FrAnCiS, Giancy, Hellis, Jacopo, Leoman3000,
M7, MikyT, Moongateclimber, Nevermindfc, Ninja, Qualc1, Rquaglia, Salvatore Ingala, Sandro kensan, Sentruper, Simo ubuntu, Vulkano, 28 Modifiche anonime
rsync Fonte:: http://it.wikipedia.org/w/index.php?oldid=45888189 Autori:: .anaconda, Ale-sandro, Antonell, Argento, Ary29, AttoRenato, Avesan, Basilero, Bla, Came88, Dwdp, F l a n k e r,
Fale, Gac, Gervasi, Jacopo, Johnlong, Lusum, Mr.evolution, Nalegato, Patafisik, Pigr8, Poweruser, Salvatore Ingala, Simo ubuntu, Sofisma75, Stacky, 12 Modifiche anonime
Real-time Transport Protocol Fonte:: http://it.wikipedia.org/w/index.php?oldid=49525401 Autori:: Avesan, Broc, CapSnake, Groucho75, Hellis, Moongateclimber, Pietrodn, Robmontagna,
SiGMa83, Simo ubuntu, Vulkano, 10 Modifiche anonime
Livello di trasporto Fonte:: http://it.wikipedia.org/w/index.php?oldid=49490946 Autori:: %Pier%, Abisys, Avesan, Beren023, Buggia, Civvì, Davide, Hce, Mar.pollo, MitRouting,
Pegasovagante, Phantomas, Pietrodn, Rotpunkt, Salvorapi, Tank00, 22 Modifiche anonime
Transmission Control Protocol Fonte:: http://it.wikipedia.org/w/index.php?oldid=49549070 Autori:: %Pier%, 212.177.57.xxx, A7N8X, Abisys, Acchiappasogni, Alfio, Alleborgo,
Anotherhacktivist, Ar mythra, Archenzo, Ary29, Automatic jack, Avesan, Azrael555, Bergonz, Brownout, Bultro, Calius25, Cruccone, Daimon, Dav82, Davide, Ddonato, DoBs, Edonan,
Fabior1984, Frieda, Gac, Gianfranco, Hce, IRedRat, Iron Bishop, Jacopo Werther, Jacopobenz, Jean85, KeyboardSpellbounder, Kormoran, Leo144, Lgiove, Luigi.tuby, Marcuscalabresus,
Matteo92Ferrari, Maui, Mess, Mix, Moongateclimber, Nervosud, No2, Qualc1, Remulazz, SalvoIsaja, SbiellONE, Sbisolo, Simo ubuntu, Snubcube, Unriccio, Vulkano, 127 Modifiche anonime
User Datagram Protocol Fonte:: http://it.wikipedia.org/w/index.php?oldid=47468222 Autori:: %Pier%, Abisys, Acchiappasogni, Alfio, Anotherhacktivist, Ary29, Avesan, Brownout, Elwood,
Frendine, Frieda, GianniPucillo, Hce, Hellis, Iannigb, Iron Bishop, Jean85, Krabbit, Misterioso, Moongateclimber, Moroboshi, Pibo, Salvorapi, Sbrandollo, Simo ubuntu, Unriccio, Vulkano, 30
Modifiche anonime
Livello di rete Fonte:: http://it.wikipedia.org/w/index.php?oldid=49575840 Autori:: %Pier%, Abisys, Alfio, Ary29, Avesan, DnaX, Fosco86, Frieda, Hce, Ignorantone, Leitfaden, Mar.pollo,
Paginazero, Pegasovagante, Perteghella, Pietrodn, RL, Rojelio, Rotpunkt, Sentruper, Snowdog, Svante, TommiMazza, 29 Modifiche anonime
IPv4 Fonte:: http://it.wikipedia.org/w/index.php?oldid=48502124 Autori:: .anaconda, Abisys, Acchiappasogni, Archenzo, Ary29, Avesan, Clamiax, DaVid83, Frack, Gsdefender2, Happyhour,
Hce, Helios, Hellis, Ilario, Jean85, M7, Marco Plassio, Matra dj, Max Null, Mizardellorsa, Moongateclimber, No2, Onr, Penaz, Rojelio, Valepert, Vulkano, 33 Modifiche anonime
IPsec Fonte:: http://it.wikipedia.org/w/index.php?oldid=48988465 Autori:: %Pier%, .mau., Abisys, Aker, Alef.ala, Ary29, Avesan, Bla, Dinwath, Ercaran, F. Cosoleto, Fabexplosive, Frieda,
Guam, Guidomac, Hellis, IngDani, Lgiove, Mcicogni, MitRouting, Moongateclimber, Phantomas, Rojelio, Snowdog, Viames, Vulkano, 71 Modifiche anonime
Livello datalink Fonte:: http://it.wikipedia.org/w/index.php?oldid=49575883 Autori:: 0x1.gen, Abisys, Alfio, Ary29, Avesan, Bart46, DanGarb, Daniele Forsi, Eumolpa, Eumolpo, Famasoft,
Frieda, GiacomoV, Hce, Hellis, Knottyboy, L'alchimista, Llorenzi, Mar.pollo, Nalegato, No2, Pap3rinik, Phantomas, Ricercatorew76, Rotpunkt, Sbisolo, Scorpios90, Simoz, Tomi, Wikit2006, 81
Modifiche anonime
Secure shell Fonte:: http://it.wikipedia.org/w/index.php?oldid=48709071 Autori:: Abisys, Alleborgo, Apollo13, Avesan, Brownout, Domenico De Felice, Fabianope, Fatzeus, Francesco.monte,
Gliu, Golf-ball, Govoch, Hashar, Hce, Hellis, Ianezz, Johnlong, Kaos Ktrl, LapoLuchini, Leo72, Lukius, No2, Pietrodn, Reddstain, Robbyd1983, Rollopack, Romanm, Salvatore Ingala,
Sassospicco, Siciliano Edivad, T137, Vulkano, Wiso, 53 Modifiche anonime
74
Fonti, licenze e autori delle immagini
Fonti, licenze e autori delle immagini
Immagine:Commons-logo.svg Fonte:: http://it.wikipedia.org/w/index.php?title=File:Commons-logo.svg Licenza: logo Autori:: SVG version was created by User:Grunt and cleaned up by
3247, based on the earlier PNG version, created by Reidab.
File:Modello FTP.png Fonte:: http://it.wikipedia.org/w/index.php?title=File:Modello_FTP.png Licenza: Creative Commons Attribution 2.5 Autori:: Fale, No2, Sbisolo, 3 Modifiche anonime
File:svg2raster.jpg Fonte:: http://it.wikipedia.org/w/index.php?title=File:Svg2raster.jpg Licenza: sconosciuto Autori:: Samadhi56
File:DNS RR.png Fonte:: http://it.wikipedia.org/w/index.php?title=File:DNS_RR.png Licenza: sconosciuto Autori:: Samadhi56
File:Nome spazio di dominio.jpg Fonte:: http://it.wikipedia.org/w/index.php?title=File:Nome_spazio_di_dominio.jpg Licenza: Public domain Autori:: Samadhi56
File:Tcp-handshake.svg Fonte:: http://it.wikipedia.org/w/index.php?title=File:Tcp-handshake.svg Licenza: Creative Commons Attribution-ShareAlike 3.0 Unported Autori::
300px-Tcp-handshake.png: ??? derivative work: Snubcube (talk)
File:TCP-Chiusura-a-4-vie.png Fonte:: http://it.wikipedia.org/w/index.php?title=File:TCP-Chiusura-a-4-vie.png Licenza: Public Domain Autori:: Acchiappasogni
75
Licenza
Licenza
Creative Commons Attribution-Share Alike 3.0 Unported
//creativecommons.org/licenses/by-sa/3.0/
76
