La pressante necessità di usufruire di una semplice, rapida ed economica comunicazione intra-domestica a breve distanza è stata soddisfatta, ormai diversi anni orsono, con lo sviluppo di un sofisticato sistema fonico full-duplex non strutturato cablato, chiamato comunemente citofono.

Il grande successo ottenuto dall'apparecchio ha fatto si che la sua diffusione raggiungesse la quasi totalità delle abitazioni, prestando il suo utile servizio ogni giorno 24 ore su 24, con continuità e ad un costo praticamente nullo.

Tuttavia, a causa probabilmente dei brevi tempi destinati alla progettazione o degli scarsi fondi disponibili per la ricerca, il sistema citofonico risente ancora oggi di numerose limitazioni e fastidiosi malfunzionamenti, soprattutto in quelle circostanze in cui l'utenza di una unica rete superi i due nodi, cioè nei condomini. Si riscontrano inoltre ambigui funzionamenti nel protocollo di segnalazione e controllo, implementato in maniera eccessivamente elementare e semplificata.

Una rete citofonica è caratterizzata da una comune struttura client-server a stella, in cui un nodo centrale è collegato a diversi nodi periferici. Tuttavia, a differenza di quanto solitamente accade nelle reti odierne, il nodo centrale non è costituito dal server bensì dall'unico client, che attraverso un sistema di allertamento in banda può richiedere ai vari server distribuiti sulla rete di attivare una comunicazione. Questa caratteristica, unita al curioso fatto che venga contemplata (seppur raramente utilizzata) la possibilità di iniziare la comunicazione da parte di entrambi i nodi, fa si che tale network non possa sottostare alle comuni regole che governano la maggior parte dei sistemi di comunicazione del giorno d'oggi.

L'attivazione di chiamata avviene inviando un segnale di SYN da parte del client verso il server prescelto. Il server, alla ricezione di tale segnale, attiva un ulteriore sistema di segnalazione per la richiesta di assegnazione della prima risorsa disponibile (solitamente un essere umano) nel raggio di portata. Quando la risorsa viene destinata all'applicazione, il sollevamento della cornetta instaura immediatamente la comunicazione senza alcun feedback al client: il segnale di ACK viene delegato totalmente al livello superiore del protocollo, che tuttavia non è mai stato regolamentato a dovere, tanto che sono ammessi diversi tipi di risposta ai quali la risorsa assegnata al client deve sapersi adeguare in maniera dinamica. Per conoscenza, si riportano le risposte di tipo ACK di più frequente utilizzo: "Chi è?", "Pronto?", "Si?".

Ben più grave risulta tuttavia la totale assenza di un sistema per la segnalazione del rifiuto di chiamata: la risposta NACK non è affatto presa in considerazione dal protocollo, e rimane utopia pura l'implementazione di un protocollo di segnalazione e feedback per la notifica della motivazione che ha portato al rifiuto della chiamata, come un "risorsa occupata", "risorsa non disponibile", "risorsa fuori portata", ecc.

Quando la comunicazione risulta attiva, non viene allocata alcuna risorsa per un utilizzo esclusivo del sistema, con conseguente vulnerabilità a collisioni di chiamata. Inoltre, tale caratteristica può essere sfruttata a vantaggio di terzi con sniffing o il ben più temuto hijack di sessione (attacchi di tipo MITM, Man In The Middle), teniche di hacking da tempo conosciute e contro le quali non è mai stato preso alcun serio provvedimento.

Ancora una nota deve essere spesa sulla segnalazione: non esiste alcun controllo sul segnale di SYN inviato dal client verso il server: tale segnalazione può durare da frazioni di secondo ad un massimo in linea teorica pari ad infinito. Questa disuniformità nel segnale di allertamento può causare gravi inconvenienti, a partire dalla mancata attivazione del protocollo di livello superiore fino al ben più grave collasso delle balle della risorsa, seguita solitamente da ulteriori modifiche nel protocollo di completamento della chiamata. Tali modifiche comportano di norma l'aggiunta di coloriti termini atti a marcare la non necessità di ulteriore spreco di energie per il semplice invio del segnale SYN: i termini più di frequente utilizzati sono $organo_genitale_maschile, $complimenti_alla_mamma, $consigli_su_luoghi_dove_recarsi, o varianti di essi.

Inoltre il caso in cui più pacchetti SYN vengano inviati contemporaneamente a diversi server può causare una situazione di attacco IDOS (Inverse DOS), durante il quale il client stesso viene inondato da una serie di messaggi di ACK da parte dei server contattati, che vengono a loro volta messi in comunicazione tra di loro creando ulteriore scompiglio e caos, con totale inutilizzabilità della rete anche per diversi minuti. Nel caso poi il client (a causa di danni o intenzionalmente) invii un continuo segnale di SYN verso uno o più server, l'unica soluzione rimane quella di recarsi fisicamente presso la sede del client stesso e provvedere manualmente all'interruzione del SYN flood.

Da tali considerazioni si evince la spiccata necessità di un qualche tipo di controllo sul protocollo di segnalazione, quale la possibilità di attivare particolari regole di firewalling e forwarding, le quali migliorerebbero notevolmente l'affidabilità del sistema.

In conclusione, seppur la rete citofonica rimanga nel complesso un buon sistema per comunicazioni sporadiche e di bassa priorità, risulta del tutto inadeguata ad utilizzi più complessi o con particolari richieste di QOS. Risulta oltremodo sconcertante il fatto che nonostante la grande evoluzione intercorsa nell'arco degli ultimi anni, non sia ancora disponibile un aggiornamento dei protocolli di un servizio di così ampia diffusione.

Hai a disposizione ancora caratteri. Per inserire commenti più lunghi (e senza CAPTCHA), iscriviti.
Il tuo nome:		La tua email: