\documentclass[a4paper,10pt]{article} \usepackage[italian]{babel} \usepackage[T1]{fontenc} \usepackage[utf8]{inputenc} \usepackage[pdftex,bookmarks,colorlinks,citecolor=green, linkcolor=red, urlcolor=blue]{hyperref} % testo colorato %\usepackage{color} % riferimenti incrociati dinamici %\usepackage{varioref} % SoujaK %\usepackage[pdftex,pdftitle={},pdfauthor={},pdfpagemode=FullScreen, %plainpages=false,pdfpagelabels,urlcolor=blue,linkcolor=red,citecolor=green, %bookmarks=false]{hyperref} \title{Associazione multipla simultanea\\ di un \textit{client} 802.11} \author{Andrea Rappini, Alessio Romagnoli,\\Marco Solieri, Andrea Simeone} \begin{document} \maketitle \begin{abstract} La diffusione di reti \textit{wireless} è in forte crescita a causa della sua comodità e della diffusa disponibilità di connessioni ad Internet con ampie larghezze di banda. Sfruttare contemporaneamente la connessione alla molteplicità di reti spesso presente permetterebbe un utilizzo migliore di tali risorse, migliorando il \textit{throughput} e incrementandone l'affidabilità. Lo studio intende quindi analizzare le effettive possibilità di realizzazione di un'estensione delle comuni implementazioni dello standard IEEE 802.11 che permetta al singolo \textit{client} in ambiente GNU/Linux l'associazione simultanea a differenti reti \textit{wireless}. \end{abstract} % \newpage \section{Introduzione} \label{sec:introduzione} \subsection{Oggetto} \label{sec:oggetto} Lo studio di fattibilità si interroga sulle possibilità realizzative di connessione di un singolo \textit{client} 802.11 a diverse reti, partecipando a più BSS (cioè l'insieme di nodi costituenti una rete \textit{wireless}). Nel presente documento si intende dapprima introdurre il lettore allo scenario nel quale è stato condotto lo studio, evidenziandone gli aspetti salienti che riguardano lo standard IEEE 802.11 e le sue interpretazioni. In un secondo momento si presenteranno non solo proposte risolutive, ma anche spunti accessori. \subsection{Scopi} \label{sec:scopi} L'intento più evidente è quello di aumentare la connettività del \textit{client}, permettendogli connessioni simultanee a reti altrimenti isolate ed eventualmente consentendo al \textit{client} di agire in qualità di ponte. Qualora i punti di accesso resi contemporaneamente utilizzabili riferiscano (più o meno direttamente) alla medesima rete, allora la molteplicità si traduce in ridondanza e, conseguentemente, in affidabilità. I più coraggiosi potranno sfruttare le multi-connettività in oggetto come punto di partenza per la realizzazione di politiche di gestione al fine di massimizzare il \textit{throughput} aggregato. \subsection{Obiettivi supplementari} \label{sec:obiettivi} I criteri con i quali si sono prese le svariate decisioni che hanno caratterizzato lo studio e che si concretizzano nelle soluzioni proposte hanno risentito dei seguenti obiettivi supplementari: \begin{description} \item[\textit{overhead} minimo] abbattere i costi introdotti dalla gestione simultanea delle connessioni multiple; \item[perdite minime] ridurre o eliminare ogni possibile perdita di dati in ricezione causata dalla temporanea assenza su un BSS (cfr. sezione~\ref{sec:mezzotrasmissivo}); \item[portabilità] essere quanto più indipendente dalle specifiche piattaforme \textit{hardware}/\textit{firmware}, pur rimanendo legata all'ambiente GNU/Linux; \item[facilità implementativa] ridurre gli sforzi per l'effettiva messa in opera; \item[trasparenza] virtualizzare le interfacce di rete associate ad ogni connessione per minimizzare l'impatto. \end{description} \section{Scenario} \label{sec:scenario} \subsection{Caratteristiche del mezzo trasmissivo} \label{sec:mezzotrasmissivo} Il mezzo trasmissivo utilizzato nelle comunicazioni di reti senza fili è, per sua natura, disponibile e condiviso da ogni utilizzatore, pertanto lo standard IEEE 802.11 ne sancisce il partizionamento in diversi spettri di frequenza denominati canali. In tal modo si permette la coesistenza di reti \textit{wireless} distinte in aree limitrofe o addirittura sovrapposte grazie all'uso di canali differenti. \label{salti} Lo studio ha pertanto tenuto presente la necessità da parte del \textit{client} di effettuare salti periodici di canale per poter raggiungere ogni BSS a cui desideri partecipare. \subsection{Standard IEEE 802.11} \label{sec:80211} \subsubsection{Accesso alla rete} \label{sec:accessoallarete} Affinché una stazione mobile possa partecipare ad una rete \textit{wireless}, le è fatto obbligo di annunciare la sua presenza attraverso una procedura detta di \textbf{associazione}. Questo legame unisce una stazione ad uno ed un solo BSS e garantisce che la stazione possa effettuare trasmissioni dirette ad ognuno dei nodi appartenente all'intera rete e viceversa.\\ Lo studio intende proprio scardinare l'univocità del rapporto fra stazione e BSS che lo standard impone esplicitamente. A causa della natura condivisa del mezzo trasmissivo, l'accesso alla rete sarebbe aperto a qualunque stazione richieda di associarsi. IEEE ha quindi elaborato una strategia di regolazione dell'accesso richiedendo la mutua identificazione di entrambi gli estremi di ogni comunicazione. Tale procedura, definita \textbf{autenticazione}, risulta pertanto essere un prerequisito della stessa associazione. Il processo può diventare oneroso in termini di tempo a causa dei \textit{frame} da scambiare e dell'elaborazione necessaria (si pensi ai calcoli crittografici coinvolti), quindi ne viene permessa l'invocazione anche in maniera indipendente dal servizio di associazione. Così facendo lo standard permette di mantenere questo carico lontano dai momenti in cui il tempo è un fattore critico\footnotemark, sfruttando la \textbf{preautenticazione}. \footnotetext{Infatti, se la STA è in movimento fra due BSS e se l'autenticazione cade prima che la stessa STA possa riassociarsi con il successivo AP, la procedura potrebbe richiedere tempi considerevoli che andrebbero a degradare pesantemente le prestazioni.} Da quanto detto risulta quindi evidente che, a differenza dell'associazione, una stazione può essere autenticata presso molteplici altre stazioni. \subsubsection{Risparmio energetico} \label{sec:risparmioenergetico} Lo standard prevede la possibilità di utilizzare l'\textit{hardware} in maniera efficiente rispetto ai consumi energetici, dal momento che i dispositivi portatili alimentati a batteria sono tutt'altro che rari. Le stazioni che supportano tale funzionalità hanno la facoltà di ``addormentarsi'' durante i periodi di inattività. In questi momenti, gli eventuali dati ad esse destinati vengono conservati dal BSS\footnotemark per un invio successivo, essendo esso stato precedentemente avvisato dello stato delle stazioni in questione. I BSS, quindi, annunciano periodicamente la presenza delle trasmissioni in attesa, indicandone i destinatari con un messaggio chiamato TIM che è presente all'interno di alcuni dei \textit{beacon}. Conseguentemente le stazioni in risparmio energetico sono tenute a risvegliarsi in corrispondenza di questi intervalli regolari, per poi richiedere l'invio tramite un apposito tipo di \textit{frame} (il \texttt{PS-Poll}). \footnotetext{In realtà sarebbe doveroso fare una distinzione fra le reti infrastrutturate e quelle indipendenti (o \textit{ad hoc}), nelle quali la conservazione dei dati è appannaggio, rispettivamente, dell'\textit{access point} e del nodo trasmittente.} \subsubsection{Vincoli temporali} \label{sec:vincolitemporali} Come già anticipato precedentemente (nella sezione \ref{salti}), il \textit{client} avrà l'illusione di essere contemporaneamente associato ai BSS di interesse tramite continui salti fra di essi; per questo motivo risulta importante chiarire quali siano i vincoli temporali che lo standard gli impone. La padronanza di queste informazioni è di grande rilevanza, sia perché dovranno essere rispettate dal \textit{client} anche in seguito alle modifiche che verranno proposte nel presente studio, sia perché potranno essere tenute presenti per raffinamenti volti a migliorare l'efficienza delle soluzioni. L'accesso al mezzo trasmissivo, a causa della sua stessa natura condivisa, è regolato da convenzioni stabilite dallo standard che consentono una ripartizione equa di questa risorsa. Tali regolamentazioni di natura temporale si fondano sulla reciproca sincronizzazione delle stazioni che condividono il mezzo fisico, raggiunta tramite il mantenimento di un \textbf{orologio} comune al BSS\footnotemark di appartenenza. Il valore su cui accordarsi viene distribuito all'interno di un \textit{frame} di gestione, il \textit{\textbf{beacon}}, inviato ad intervalli regolari e prefissati. Se già ora si intuisce che l'eventuale perdita di questi messaggi periodici durante i salti va minimizzata, ancor di più se ne comprende l'importanza a fronte della presenza di ulteriori informazioni di grande interesse per i fini preposti. Trattasi non solo dei \textbf{TIM} (cfr. \ref{sec:risparmioenergetico}), ma anche degli annunci di inizio dei periodi liberi da contesa presenti nelle reti infrastrutturate, lassi di tempo durante i quali l'accesso al mezzo è coordinato da un gestore centrale. Esso risiede tipicamente nell'\textit{access-point} e provvede a coordinare le comunicazioni in maniera spesso più efficiente rispetto a quando il coordinamento è distribuito. \footnotetext{Ancora una volta è necessaria una distinzione fra le reti infrastrutturate e le reti \textit{ad hoc}: il valore comune su cui accordarsi è dettato rispettivamente dall'\textit{access point} e dall'intero BSS in maniera distribuita.} In aggiunta a quanto detto, il client non potrà trascurare le \textbf{scadenze} temporali oltre le quali i rapporti di autenticazione e associazione con i BSS vengono a cadere. \subsection{\textit{Wireless Extensions}} \label{sec:wext} La portabilità in ambienti GNU/Linux è stata ricercata usando come punto di riferimento le Linux Wireless Extensions (per brevità \texttt{wext}). Il progetto intende mettere ordine in uno scenario spesso dominato dall'eterogeneità, proponendo delle interfacce unificate per i driver di sistema delle varie soluzioni \textit{hardware} disponibili. Nel momento in cui si scrive sono ancora pochi i driver che si sono completamente uniformati a questo insieme di interfacce, ma questa scelta è stata dettata dalla speranza che esse diventino presto lo standard \textit{de facto}. % TODO % introduzione alla terminologia (managed, master, ad-hoc, monitor) Accanto alle API di programmazione sono stati sviluppati anche gli \textit{Wireless Tools}, comodi strumenti per l'utente che intendono offrire le medesime possibilità attraverso un'interfaccia a riga di comando. \subsection{Implementazioni} \label{sec:implementazioni} \subsubsection{Architettura} \label{sec:architettura} Lo standard IEEE 802.11 definisce due strati di rete che sono riconducibili, facendo riferimento al modello ISO/OSI, al livello fisico e a quello MAC (\textit{Medium Access Control}), implementati dai produttori tramite l'accoppiata \textit{hardware}/\textit{firmware}. MAC viene solitamente realizzato così a basso livello per rispondere alle esigenze di velocità e precisione temporale di cui si accennava in \ref{sec:vincolitemporali}. È importante sottolineare, quindi, che qualunque idea risolutiva dello studio in questione non potrà prescindere dalle modalità di interazione (interfacce e impostazioni) consentite dalla specifica implementazione di MAC. Questo discorso diventa tanto più importante quanto la soluzione perseguita si discosta dalla rigidità dello standard. La revisione 802.11i, che estende lo standard migliorando la sicurezza da esso offerta, definisce nuove funzionalità per il livello MAC che possono invece essere tranquillamente implementate all'esterno del \textit{firmware}. \subsubsection{Libertà d'azione} \label{sec:libertàdazione} Le più diffuse implementazioni di 802.11 sono però quantomai lontane dalle libertà di azione sperabili poiché il \textit{firmware} risulta essere scarsamente programmabile, consentendo poco più delle interazioni necessarie al normale funzionamento. Esempi di soluzioni \textit{chipset} che siano controcorrente, e pertanto interessanti, vengono riportati da \refname{guidadefinitiva}: Atheros\footnotemark e Broadcom. \footnotetext{L'unico (dei due) provato dagli autori, con driver \texttt{MADWiFi}.} A complicare ulteriormente la situazione intervengono le limitazioni imposte dalle autorità delle comunicazioni di molti Paesi (si pensi all'FCC % http://ftp.fcc.gov/Bureaus/Engineering_Technology/Orders/2001/fcc01264.pdf statunitense), che richiedono la distribuzione dei trasmettitori radio con \textit{firmware} in forma necessariamente binaria per scongiurare violazioni dei limiti di utilizzo delle frequenze. \subsubsection{Interpretazione dello standard} \label{sec:interpretazionedellostandard} Nemmeno le più fedeli realizzazioni di 802.11 supportano la preautenticazione (\refname{guidadefinitiva}), quindi i servizi di autenticazione e associazione risultano indissolubilmente legati, vanificando ogni possibilità di realizzare autenticazione multipla. Di conseguenza, il superamento di questo limite, vincolante per realizzare associazione multipla simultanea, sarà, in tutta la sua complessità, compito dell'implementatore della soluzione proposta in \ref{manca}. Un'altra eventuale limitazione dovuta all'interpretazione dello standard può derivare dalla libertà concessa riguardo la stessa implementazione del supporto alla gestione energetica. \subsection{Caso reale} \label{sec:casoreale} Le schede \texttt{Atheros} costituiscono una realtà attraente per i fini dello studio, in particolare per ciò che concerne le libertà d'azione concesse di cui al \ref{sec:libertàdazione}. Il driver \texttt{MADWiFi} è in grado sfruttare in maniera interessante le potenzialità fornite da questo \textit{chipset}, offrendo funzionalità non troppo distanti dagli scopi del presente. \subsubsection{Il \textit{chipset} \texttt{Atheros}} \label{sec:atheros} I \textit{chipset} \texttt{Atheros} equipaggiano i dispositivi 802.11 di alcuni fra i maggiori produttori di \textit{hardware} per la connettività, come \texttt{Linksys}, \texttt{NETGEAR}, \texttt{D-Link}, \texttt{Orinoco}, \texttt{Proxim} o \texttt{3Com}. Il suo \textit{firmware} consente un grado di interazione di estensione incomparabile, esponendo un'interfaccia in grado di offrire controllo anche su dettagli generalmente offuscati. Proprio per questa ragione la sua distribuzione è vincolata alla presenza di un sovrastrato (reso disponibile in sola forma binaria) atto a limitare l'interfaccia al fine di impedire utilizzi non conformi alle vigenti regolamentazioni sugli apparecchi radio. Tale componente, denominato \texttt{HAL} (\textit{Hardware Abstraction Layer}), interviene limitando le radiofrequenze operative del dispositivo, continuando comunque a concedere le libertà auspicate. \subsubsection{Il \textit{driver} \texttt{MADWiFi}} \label{sec:madwifi} A partire dallo scorso anno la spinta innovatrice di \texttt{Atheros} ha avuto riscontro anche nel progetto \texttt{MADWiFi}, i driver liberi per piattaforme Linux sviluppati inizialmente da Sam Leffler. Le novità introdotte dal nuovo \texttt{HAL} sono state sfruttate aggiungendo una serie di funzionalità di grande rilevanza. Il carattere rivoluzionario rende il progetto, come spesso capita, piuttosto instabile ma assai vitale. L'aspetto indubbiamente più interessante è l'introduzione della modalità \textbf{VAP} (\textit{Virtual Access Point}), grazie alla quale è possibile virtualizzare il dispositivo creando molteplici interfacce di rete operanti concorrentemente in maniera indipendente. Questa funzionalità è implementata facendo uso del medesimo livello fisico, vincolando così l'operatività dei VAP sullo stesso canale trasmissivo. Ciononostante, la rosa delle possibilità rimane ben assortita, permettendo la creazione di molteplici \textit{access point} e/o una (e al più una) stazione in modalità \texttt{managed} o \texttt{ad-hoc}. La nota modalità \texttt{monitor} viene inoltre resa inseribile in una qualsiasi delle configurazioni appena descritte, con la semplice aggiunta di un VAP di questo tipo. I vari VAP creati possono poi essere eventualmente interconnessi tramite il WDS, un'altra delle caratteristiche salienti del driver, che realizza un sistema di distribuzione basato su connessioni 802.11 fra i BSS d'interesse, siano essi locali (e virtualizzati) o esterni. % TODO % Chiarire il concetto di DS e di BSS Le interfacce virtuali create saranno esposte ed utilizzate comodamente in piena trasparenza, essendo presentate come ordinarie interfacce di rete aderenti alle \textit{Wireless Extensions}. L'alto grado di controllo permesso dal \textit{firmware} \texttt{Atheros} si propaga fino all'utente attraverso il \textit{driver} grazie ai suoi numerosi parametri specifici, che si ricordano essere gestibili tramite il comando \texttt{iwpriv} degli \textit{Wireless Tools}. Un ulteriore strumento a riga di comando, \texttt{wlanconfig}, completa le necessità di amministrazione proprie di questo \textit{driver}, permettendo creazione, distruzione e cambio di modalità dei VAP. \section{Soluzioni} \label{sec:soluzioni} Lo studio di fattibilità in oggetto non può che aver prodotto degli schemi di soluzione che coniugano le idee emerse durante la fase di analisi del problema, ma che si precisano essere ancora distanti dall'esaustività. Tali proposte di soluzione si differenziano per il livello implementativo di riferimento, poiché esso comporta un importante \textit{trade-off} fra portabilità ed efficienza. Quanto più basso, infatti, è il livello al quale si opera, tanto più alta è la possibilità di sfruttare appieno le potenzialità del dispositivo, a scapito della compatibilità offerta e della facilità implementativa. Punto fermo di ogni soluzione proponibile è l'effettuazione di salti periodici fra i BSS ai quali il \textit{client} desideri essere ``contemporaneamente'' associato. Le differenze di prestazioni fra le due soluzioni che si proporranno di seguito sono dovute proprio ai diversi tempi che i salti periodici richiedono, che costituiscono quasi interamente l'\textit{overhead} introdotto. Si procederà quindi ad illustrare due soluzioni attraverso un'attenta analisi che entrerà nei dettagli, dimostrando quanto appena affermato e calcolando il rapporto fra vantaggi e svantaggi che esse comportano. \subsection{Sopra il \textit{firmware}} \label{sec:soprailfirmware} \subsubsection{Descrizione} \paragraph{Idea} Questa soluzione nasce dal desiderio di realizzare associazioni multiple effettive, per mezzo delle quali, cioé, in un dato istante ogni BSS di interesse per il \textit{client} lo consideri regolarmente associato. Ciò che si propone consiste sostanzialmente di modifiche al \textit{driver} per implementare i salti fra i BSS in maniera tale da evitare la perdita di associazione presso ognuno di essi. \paragraph{Come} Per far ciò si deve interagire direttamente (ed eventualmente in maniera poco corretta) con l'entità di gestione di 802.11, che si è già chiarito risiedere all'interno del \textit{firmware} della scheda \textit{wireless}. Soltanto il \textit{driver} sovrastante ha infatti la possibilità di alterare determinati stati interni al \textit{firmware} per modificare il comportamento di MAC. I parametri a cui si sta facendo riferimento sono quelli che regolano i rapporti di associazione e necessaria autenticazione della stazione: caratteristiche del BSS, caratteristiche della crittografia e dell'autenticazione in uso, eventuali chiavi temporanee \ldots \paragraph{Gabola} Uno degli aspetti più convincenti di questa soluzione è la possibilità di utilizzare la modalità di risparmio energetica (introdotta nella sezione \ref{sec:risparmioenergetico}. I ripetuti salti costringono il \textit{client} ad assenze dal canale che possono infatti essere spacciate senza troppa difficoltà per riposi preannunciati, costringendo con l'inganno i BSS a conservare i dati a lui diretti. Per completare questa strategia, la stazione simula al suo ritorno un risveglio per ricevere l'intera mole di informazioni in attesa di consegna. % : * il driver sara' in grado di gestire in un unico punto d'entrata le % : interfacce multiple offerte dal SO % TODO % Grafico della faccenda % OS [] [] [] % \ | / % DRI \|/ % FW [ ] Si consiglia inoltre che il \textit{client} si presenti ai differenti BSS con indirizzi MAC diversi fra loro, in modo tale da evitare partecipazione ridondante al medesimo ESS. % . * componente scheduler (-> interfacce virtuali wext compliant) che % . pianifica le trasmissioni \subsubsection{Vantaggi} % : * nessuna perdita di dati % . * power-saving e bufferizzazione dei dati da parte degli AP % * buone prestazioni % . * reale associazione multipla -> nessun overhead per % . riautenticazione/riassociazione % . * totale trasparenza grazie alle interfacce wext compliant % . * si puo' non partire da zero (-> madwifi) \subsubsection{Svantaggi} % * grosso sforzo per l'implementazione % . * parziale reimplementazione di MAC per occuparsi di beghe causate % dalla molteplicita' dei BSS: % . * tempistiche: sincronizzazione, rilevamento beacon persi ed eventuale % . sfruttamento dei CFP. (beacon interval noti e mantenimento di % . informazioni necessarie per ogni BSS) % . * sottotipi di autenticazione/crittografia: mantenimento chiavi % . (|di sessione), stato della crittografia e dell'autenticazione. % . (getter e setter sugli attributi MIB relativi) % . * complessita' intrinseca dovuta al livello implementativo % . * firmware spesso solo binari, quindi probabile reverse engineering % . * prestazioni non eccellenti, perche` limitate da power-saving e relativi % . obblighi temporali (TIM...) {non posso proprio fare i miei comodi al % . 100% } % * troppo specifico % * dipendenza dalla piattaforma fw -> portabilita' minima % . * necessita' di power saving % . * la soluzione dipende fortemente dal firmware di riferimento, scarsa % . programmabilita' di parecchie implementazioni \subsection{Sopra il \textit{driver}} \label{sec:sopraildriver} \subsubsection{Descrizione} % : * idea: cheppalle riscriversi un driver, chissenefrega degli overhead, % : lavoriamo pure a livello alto % . * riassociazione ad ogni cambio di BSS % . * GNU/Linux e Wireless Extensions come riferimento % : * forse autenticazione multipla % . * interfacce virtuali wext compliant (->) % . * autenticazioni multiple a livelli superiori 802.1x (con wpa_supplicant) \subsubsection{Vantaggi} % . * facilita` implementativa % . * totale trasparenza grazie alle interfacce wext compliant (in questo % . la cosa e` non banale, per il livello implementativo e permette il % . comodo uso di wpa_supplicant) % . * portabilita' dovuta alle interfacce unificate \subsubsection{Svantaggi} % * dataloss [ma si puo` risolvere a livelli superiori (TCP, ATM)] % : * latenze (|assai) ingenti (con|senza) autenticazione multipla % * analisi costi vago in termini di ordini di grandezza: % * associazione % * sincronizzazione ~ 100 ms % * autenticazione (PSK) \section{Ottimizzazioni ulteriori per le scelte di swinging} \label{sec:ottimizzazioni} \section{Bibliografia} \label{sec:bibliografia} \section{Ringraziamenti} \label{sec:ringraziamenti} \end{document}