Autore: PUOJACKZ Data: 2005-12-06 Modificato: Documento non modificato Letture: 391 Torna indietro

SLIP & PLIP

- SLIP: Serial Line Internet Protocol
- Incapsulamento di layer 2, al quanto obsoleto
- Funziona su porte seriali e connessioni via modem
- Descritto dall'RFC 1055
- Rimpiazzato dal PPP, in quanto, meglio costruito, con più features (es. l'autenticazione) e non necessita di un indirizzo IP settato preventivamente, prima di stabilire la connessione
- Ha un piccolo overhead
- Il carattere "SLIP END" segnala la fine di un datagramma e l'inizio del successivo
- Configurazione porta seriale richiesta: 8 data bits, nessuna parità, controllo del flusso hardware
- Non offre identificazione d'errore, il quale dev'esser trattato a layer + alti
- Non indicato per trasmissioni con alto tasso di rischio d'errore
- Versione con header compresso chiamata: CSLIP (SLIP Compresso)
- Versione usata in parallelo, simile alla SLIP, detta PLIP (Parallel Line Internet Protocol), usata nelle porte parallele a velocità maggiori
- SLIP & PLIP sostituiti dall'USB, nelle comunicazioni seriali per il trasferimento di files ad un secondo computer, ove l'accesso alla rete non è necessario

PPP

- Di grossa importanza nelle operazioni tra tecnologie dial-up
- Prima dell'avvento di questo protocollo, occorreva effettuare un incapsulamento multiplo. I metodi di collegamento proprietari (es. lo SLIP), non erano dotati di features avanzate (es. non erano dotate di capacità di negoziazione dell'indirizzamento)
- Il PPP è composto da 3 fasi: Link Control Protocol (LCP), Authentication, and Network Control Protocol (NCP)

L' LCP

- Layer più basso del PPP
- Non segue un modello client/server; entrambi i terminali della connessione PPP devono concordare il protocollo impiegato
- La negoziazione inizia, tra i 2 terminali, con la trasmissione di una richiesta di configurazione "CONFREQ" (contiene delle opzioni particolari, quali l'unità di ricevimento massimale, la mappa del carattere di controllo asincrono, il protocollo di auth ed il magic number). A tal punto, i 2 terminali effettuano la negoziazione del metodo di autenticazione ed indicano l'eventuale supporto al PPP multilink. Se il terminale ricevente riconosce le opzioni e le accetta, viene spedito un CONFACK; se tali valori vengono rifiutati (es. a causa della configurazione presente nel terminale), viene inviato un CONFREJ; se i valori vengono ricevuti, ma non accettati, viene inoltrato un CONFNAK. Tale procedimento continua fino a quando non viene inviato un CONFACK, la connessione dial viene interrotta o uno dei due terminali non notifica il suo pari riguardo l'impossibilità di completare l'operazione di negoziazione

L'Authenticazione

- Fase opzionale, ma fortemente raccomandata in tutte le connessioni dial. In certi casi, è un requisito per permettere un operazione appropriata con i profili dialer
- 2 tipologie principali: Password Authentication Protocol (PAP) e Challenge Handshake Authentication Protocol (CHAP)
- L'autenticatore verifica la validità dell'info pervenuta, permettendone o no la connessione (prassi comune tra 2 terminali che impiegano una connessione DDR tra i routers)
- Il PAP è meno sofisticato del CHAP. Dopo la negoziazione LCP, il richiedente invia (in chiaro), ripetutamente, la propria UserName/Password attraverso un collegamento, all'autenticatore. Tale operazione continua fino a quando non viene ricevuto un ACK, oppure il collegamento viene interrotto. Inoltre, il ricevente può disconnettere il collegamento qualora la combinazione UserName/Password non sia corretta. Tale genere di autenticazione è soggetta a vari problemi di sicurezza (trasmissione dei dati in chiaro e non in crittato, attacco DoS Playback e possibile Trial-And-Error)
- Il CHAP è più complicato. L'autenticatore effettua un Handshake particolare con il richiedente. Viene inviato un "challenge" a chi ha effettuato la richiesta di connessione, il quale deve rispondere con un valore. Quest'ultimo è calcolato tramite una funzione di "One-Way Hash", sfruttando il valore Challenge e la password CHAP. Il risultato viene spedito all'autenticatore, assieme all'HostName (il quale può essere diverso da quello adottato dal dispositivo), nel messaggio di risposta. L'autenticatore legge l'hostname, ricerca la password abbinata e ne calcola il valore (sfruttando lo stesso metodo di hashing). Quest'ultimo dovrà coincidere con quello spedito dal richiedente (e ciò implica, automaticamente, che entrambi i dati siano uguali e, pertanto, validi). Se il valore risultante è uguale, l'autenticazione è avvenuta con successo. Il fallimento conduce ad una disconnessione. L'autenticatore, onde evitare problemi di DoS PlayBack, può richiedere, in qualsiasi momento, un nuovo "Handshake" al richiedente. Con tale protocollo, inoltre, i casi di Trial-And-Error sono evitati e la trasmissione dei dati è crittata

L'NCP

- Il negoziato NCP viene condotto con lo stesso sistema dell'LCP (tramite CONFREQs,
CONFREJs, CONFNAKs, e CONFACKs)
- Gli elementi sono di layer più alto (es. IP, IPX, bridging, CDP, ecc.)
- Uno o più di questi protocolli può esser negoziato contemporaneamente