Studio di fattibilita': associazione multipla simultanea

Abstract

La diffusione di reti wireless e' in forte crescita ed e' stimolato dalla facile disponibilita' di connessioni ad Internet con ampie larghezze di banda anche in ambienti domestici. Non e' infatti raro, specialmente se si abita in una citta' densamente popolata, trovarsi nel raggio di copertura di piu' di una rete wireless. Sfruttare contemporaneamente la connessione alla molteplicita' di reti permetterebbe uno sfruttamento migliore delle risorse disponibili (miglioramento del throughput) e un incremento di affidabilita' (grazie alla ridondanza).
Lo studio intende analizzare le effettive possibilita' di realizzazione di un' estensione delle comuni realizzazioni di IEEE 802.11 che permetta al singolo client l'associazione simultanea a differenti reti wireless. Gli scenari che saranno oggetto della ricerca dovranno essere i piu' svariati: le reti potrebbero utilizzare canali diversi o addirittura essere di natura diversa: ad-hoc o ad infrastruttura.

Precisare il concetto di simultaneita' facendo riferimento alla strategia di swinging

Introduzione

Come risulta evidente, l'avvio e l'approccio di questo studio dipende in maniera forte dagli aspetti architetturali del protocollo 802.11. La questione non entra in gioco soltanto nel definire una bozza di implementazione, ma, ancor prima, nel comprendere a livello ideale quali siano le strade da intraprendere per una realizzazione.

Dalle conoscenze iniziali dell'intero gruppo di lavoro e' risultato evidente che la ricerca non poteva perseguire una soluzione che lavorasse al di sopra del livello di astrazione creato dal driver del dispositivo. In questo tipo di scenario si renderebbe necessaria la ri-associazione ad ogni cambio di canale, una operazione che richiede tempi che sono definibili lunghi (o biblici se si considera anche la fase di autenticazione) se comparati ai tempi di trasmissione dei dati. Il che significa che operare anche soltanto una doppia associazione produrrebbe prestazioni inferiori rispetto ad una associazione singola.

_{20070404-1533 SoujaK: il seguente paragrafo necessita di pesante revisione}
Se come riferimento si prende lo stack ISO/OSI, da quanto detto risulta evidente che la ricerca sara' orientata al di sotto del livello Network, nei meandri dello stack IEEE 802.11. Dal momento che la conoscenza dell'argomento e' qualificabile come limitata agli aspetti piu' didattici, risulta evidente che prima di poter proseguire in maniera sensata, si e' ritenuto necessario approfondire la materia. Nei primi tempi si e' quindi cercato di acquisire l'indispensabile padronanza dell'architettura del protocollo e delle interfacce offerte dal livello MAC e da quello PHY.

---

Consigli da Ghini

Relazione sintetica

Obiettivi Analisi

Specifiche IEEE 802.11 (solo quelle strettamente necessarie)

Soluzioni

Soluzione a basso livello

NonAncora Soluzioni e Idee

Analisi tempistiche

Bibliografia per approfondimenti

---

Indice

 * Abstract
 * Introduzione
   * scopo, motivazione 
.    * connessione a differenti reti wireless
.    * incremento affidabilita` tramite ridondanza
.    * sfruttamento ottimale delle risorse disponibili migliorando il throughput
.    * interconnessione di differenti reti wireless 
   * oggetto
|    * client singolo connesso a diversi BSS (anche independent?)
   * obiettivi supplementari
.    * basso overhead (costo intrinseco per il mantenimento)
.    * minimizzare la perdita di dati
.    * portabilita'
.    * facilita` implementativa
:    * virtualizzazione delle interfacce di rete (-> massima trasparenza):
       compliant a wext, con MAC address multipli, bridging/routing triviale,
       wpa_supplicant autentica agile

 * Scenario
:    * mezzo fisico partizionato in canali -> necessita` di sfruttarne
:      "contemporaneamente" + di 1 (spesso BSS differenti -> canali differenti)
     * standard
|      * introduzione ai concetti di autenticazione e associazione e alla loro
|        interrelazione (molteplicita` si/no ...)
       * imposizioni temporali
:        * sincronizzazione: beacon, timestamping, CFP ...
:        * mantenimento dell'autenticazione
       * powersaving
:        * notifica dello stato del CLI al AP (power-saving o no)
:        * bufferizzazione
:        * trasmissioni on-demand (PS-poll, TIM ...)
     * Linux Wireless Extensions
.      * interfacce unificate per i driver delle piattaforme GNU/Linux
.      * wireless tools a livello utente
     * implementazioni
       * architettura
|        livello di implementazione dello strato MAC, quasi tutto
|        e` nel firmware, a causa delle esigenze real-time precedentemente
|        menzionate, eccezion fatta per 802.11i (stato dell'autenticazione
|        mantenuto internamente).
       * distanza dallo standard
|        * preautenticazione non implementata da alcuno, probabile assenza di
|          strutture per supportare autenticazione multipla
.        * powersaving opzionale
:      * scarsa programmabilita` dei fw (ed eccezioni: atheros, forse broadcom)

     * caso reale
       * Atheros
.        * il chipset
.        * fw molto permissivo
.        * HAL (binarieta` e brevissima descrizione)
       * MADWiFi
:        * possibilita` offerte (modalita` multipla eterogenea)
.        * interfaccia verso l'alto

 * Soluzioni
   * trattasi di idee e non di SOLUZIONI FINALI
:  * introduzione sul livello a cui operare: pro/contro e trade-off tra
:    efficienza e portabilita`/facilita` implementativa

   * livello di sistema operativo, sopra il firmware
     * descrizione
|      * il firmware offre primitive piu' elementari (anche legate a PHY)
|        sfruttiamo il firmware a nostro piacimento! e riscriviamo/pacciamo un
|        driver
:      * il driver sara' in grado di gestire in un unico punto d'entrata le
:        interfacce multiple offerte dal SO
|      * rivisitazione di MAC, smanettandolo per i nostri sporchi fini
|        (cambiamenti vigliacchi di BSSID mask, stato d'associazione, tipi di
|        auth)
|      * lo sgamo del power-saving, la vigliaccheria, i buffer
.      * componente scheduler (-> interfacce virtuali wext compliant) che
.        pianifica le trasmissioni
     * pro
:      * 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)
     * contro
       * 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

   * livello utente, sopra il driver livello driver
     * 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)
     * pro
.      * 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
     * contro
       * 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)

:  * Ottimizzazioni ulteriori (scelte di swinging)
       * obblighi temporali da rispettare [sincronizzazione]
       * costi dello switch
       * qualita' dei BSS (carico di lavoro, segnale)
       * caratteristiche delle comunicazioni (esigenze di interattivita` o meno,
         priorita' ...) -> politiche di QoS di 802.11e

 * Bibliografia
   * standard vari
   * la guida definitiva
   * madwifi
   * cisco (che fa figo)

 * Ringraziamenti
   * Vittorio Ghini, mentore
   * Luciano Bononi
   * Sam Leffler, autore di HAL (-> Atheros)
   * Jouni Malinen, autore di hostap e wpa_supplicant


                              8===D         - - -

                        "Non siamo mica dei tecnici"

Da fare

• Sniffing
  • analisi dello stato del fw / driver in seguito ad un cambiamento di indirizzo MAC
    • MAC spoof con [ifconfig <iface> hw ether <address>]: dissoc, auth, assoc
    • MAC spoof via wext?
  • analisi della autenticazione ripetuta
    • auth, assoc, MAC spoof, MAC despoof, ...
    • auth, assoc, MAC spoof (dissoc, auth, assoc), MAC despoof (dissoc, auth, assoc) -> il processo di autenticazione viene ripetuto
• Tempistiche
  • rilevamento del timeout di associazione/autenticazione (auth, assoc, poweroff ...)
  • tempi di auth (open|psk), assoc
• Indagine sulle implementazioni: strutture dati dedicate alle autenticazioni e relative modalita` di manipolazione, meccanismi interni vincolanti (riassociazione):
  • wext
  • MADWiFi
• Mantenimento esterno dell'autenticazione (forse con wpa_supplicant) e problemi derivanti dai meccanismi interni vincolanti (dissociazione che causa deauth) (-> sniffing, cisco guide)