Leggo questo interessante post sulla possibilità che nel tentativo di rendere più sicuro il VoIP si stia rendendo meno sicura la rete nel suo complesso. Il passaggio critico è questo:
- It seems VoIP protocols were designed to be hardly secured ;): Complex signaling, dynamically negotiated ports, point to point communications, etc. It is hard for conventional firewalls to deal with these protocols.
- Protecting the whole IP network is made more complicated by the presence of VoIP.
Nello stesso tempo, leggo sempre più spesso delle “legittime preoccupazioni” dei carrier per il traffico P2P dei loro clienti, che impedisce l’utilizzo ottimale della banda. Sia il post che le “preoccupazioni” dei carrier mi sembrano non avere chiaro un aspetto fondamentale del traffico P2P.
Prima di tutto, non solo Skype ma tutto il traffico VoIP è P2P; immagino che le “legittime preoccupazioni” siano quindi per il traffico P2P che i carrier non ci offrono come servizio a costo aggiunto, ovvero quello che gli utenti si gestiscono in proprio (il fatto che il traffico P2P contenga molto materiale che víola la normativa sul copyright non mi pare possa interessare i carrier). Dato che l’offerta al cliente prevede dei limiti alla banda disponibile in funzione del contratto, l’impressione è che la preoccupazione del carrier sia: “Ho fatto delle offerte con una certa banda disponibile, ma mi aspetto un certo profilo di traffico per cui posso fare abbondantemente overbooking. Invece con certe applicazioni P2P questi utenti usano tutta la banda che gli ho venduto, giorno e notte, e il mio overbooking non funziona…” Solita “sorpresa” di tutte le offerte flat, solo che qui si può sfruttare la demonizzazione del P2P: dove sia la legittimità della preoccupazione non mi è chiaro.
Per quanto riguarda il post di RaDaJo, non tocca il vero punto dei problemi di sicurezza del VoIP, cioè appunto non la complessità del protocollo ma che è P2P. E il VoIP sarà sempre più un problema man mano che i protocolli per la cifratura del traffico VoIP si diffondono. I firewall sono nati per un modello di Internet in cui pochi server offrono servizi e molti client li utilizzano. Le connessioni “entranti” sono destinate ai pochi server pubblici, i molti client hanno solo connessioni uscenti. Protocolli come ftp hanno causato problemi fino a quando non è stato normale avere firewall stateful, e SSL è tollerato solo perché si tratta di connessioni uscenti. Con il VoIP, avremo connessioni cifrate entranti sui client.
È il momento di mettermi sulla sedia a dondolo davanti al fuoco (la pioggia concilia) e ricordare i bei vecchi tempi in cui i firewall non esistevano. La rete era, per sua natura, peer to peer. La rete non è mai stata disegnata per i servizi centralizzati, è nata p2p non per un errore dei progettisti, ma perché loro hanno seguito la loro natura (quella umana) di voler comunicare con i solo simili e non con un servizio centralizzato. Quando in questo contesto sono stati introdotti i firewall, sono stati visti come delle mostruosità, ed in effetti rispetto ai protocolli di Internet lo sono sempre stati: non quanto il NAT, ma quasi. Diverse forze tendono a portare verso servizi centralizzati. Ma ogni volta che qualche brillante ricercatore o visionario concepisce qualcosa di p2p, quel qualcosa ha successo. I blog e YouTube ne sono un’altra dimostrazione, a un livello diverso. Magari qualcuno obietterà che però quelli si devono appoggiare a dei server su Internet… non è vero. Prendiamo per primi i blog: perché non posso avere un server Web essenziale sulla mia macchina? Ad esempio, un CMS potrebbe essere distribuito con un suo serverino Apache e un suo PHP già configurati in modo da offrire in modo sicuro solo quel servizio… I motivi sono solo due: il primo è che la maggior parte degli utenti non ha un IP statico. Problema fino ad un certo punto, visto che esiste DynDNS, che un indirizzo fisso si può comprare e che comunque IPv6 avrebbe potuto risolvere il problema da tempo, se ci fosse stato abbastanza interesse nell’adottarlo (in realtà, sarebbe bastato un “IPv5” con indirizzi IP più lunghi, molto meno complicato da adottare, direi). Il secondo è che la connettività dell’utente ADSL non è abbastanza affidabile, e su questo non dico altro: non è certo un problema “di Internet”. In effetti ci sono alcuni blog che funzionano così, da indirizzi dinamici di casa. Ma YouTube, mi direte: l’utente domestico non ha certo la banda sufficiente. Sbagliato in parte anche questo, e anche qui parte della colpa va data ai firewall. La parola magica è multicast. Prima di tutto: la mia attuale ADSL ha un uplink a 256 kbps. Questo video è a 150kbps. Per farsi un’idea basta cercare kbps su YouTube. Questo vuole dire che il mio uplink sarebbe più che sufficiente per trasmettere un video o un webcast. Ma se gli “spettatori” sono tanti? Il multicast è un protocollo che ha proprio lo scopo di evitare di duplicare le trasmissioni quando non sono necessarie: io trasmetto una sola copia del video (un solo stream di pacchetti); quando i pacchetti arrivano ad un nodo di Internet (un router) che ha “spettatori” su più di un link uscente, allora (e solo allora) il pacchetto viene duplicato in modo che una copia possa essere trasmessa su ognuno dei link. Questi pacchetti proseguono fino a quando su un altro router non si presenta di nuovo la necessità di duplicazione, e così via fino ai destinatari, in una struttura ad albero. Un uso estremamente efficiente della banda: in pratica, un’ADSL domestica sarebbe sufficiente per trasmettere un webcast a livello mondiale. Chiaramente, se devono essere trasmessi più video contemporaneamente, la banda non basta più: l’offerta dovrebbe essere in qualche modo diversa da quella di YouTube, che d’altra parte ha il suo modello di business. Il multicast esiste dagli albori di Internet. Perché allora non viene usato? Uno dei motivi sono i firewall: quando si sono diffusi i primi prodotti per lo streaming audio/video, il multicast era poco utilizzato e i firewall, secondo la logica del default deny, lo bloccavano. Così anche questi prodotti si sono rassegnati ad usare http come tunnel per qualsiasi cosa, con uno spreco di banda terribile. Tuttavia, il multicast è sempre lì, e viene utilizzato ad esempio per alcune WebTV aziendali. Ad esempio, in RealPlayer, cercando nelle opzioni avanzate, si trova anche “Attempt Multicast”. Bisogna dire che se i protocolli di streaming non fossero dovuti passare ad http, probabilmente ci sarebbe stato da ragionare sui meccanismi di peering fra i carrier, dato che da una parte entra un pacchetto e dall’altra ne escono tanti (dopo le duplicazioni), e quindi verificare quanto sia equilibrato il peering non deve essere banale… Ma ecco, forse il multicast ritorna…
Comunque sia, la comunicazione p2p a tutti i livelli è qui per restare; qualcuno può provare (e prova) a contrastarla, ma continuerà a ritornare, perché è molto più naturale per gli utenti di Internet rispetto ad un’offerta di servizi centralizzati. Questo naturalmente non vuole dire che le offerte centralizzate non abbiano i loro motivi e i loro vantaggi: semplicemente, non sono la soluzione migliore per tutto.
Nel frattempo, abbiamo il VoIP, e presto il VoIP cifrato: sarà il caso di smettere di lamentarsi del P2P e cominciare a conviverci.
