Autore: PUOJACKZ Data: 2005-11-08 Modificato: 2005-11-12 Letture: 593 Torna indietro

1. Perchè son stati ideati questi sistemi?

Uno dei problemi più tedianti del protocollo IRC originale, è stata la mancata trattazione del problema di collisione logica tra più nicknames o canali uguali, durante le fasi di NetMerge/Heal. In origine, quando si manifestava uno split tra 2 servers, quest'ultimi, nella fase di riunione, scambiavano informazioni riguardo i canali, accettando, incondizionatamente quanto veniva ricevuto, da entrambi le parti. Ovviamente, col passare del tempo, ciò ha introdotto tutta una serie di problematiche legate alla gestione dei canali, oltre che al rischio di collisione mirata di eventuali utenti presenti nella rete. In passato, il server, semplicemente, disconnetteva entrambi gli utenti con nickname uguale, ma questo era solo una soluzione marginale. Ovviamente, c'è chi iniziò ad abusare di queste debolezze del protocollo, non solo infastidendo gli utenti, ma anche chi aveva il compito di gestire la rete. Accadeva, inoltre, che i canali caduti in "opless", tramite il NetMerge, poteressero riottenere la moderazione, ma molto spesso, gli IRCWarrior utilizzavano tale "particolarità" dei server IRC, proprio per causare TakeOvers, rendendo la chat, nei canali, impossibile.
A causa dell'instabilità dei servers IRC, dovuta per tale motivo, manifestatosi in seguito all'aumento dell'utenza nelle reti di chat, i coders decisero di implementare dei sistemi per limitare tale fenomeno.

2. Cos'è il TS?

Il TS è uno dei due protocolli creati e significa "TimeStamp". Quest'ultimo è stato totalmente descritto dall'autore, Roger Espel Llima. Nella versione "server", l'implementazione è stata effettuata da Chris Behrens e Shrihari Pandit.

3. E il Nick/Chan-Delay (abbreviato ND/CD)?

Il concetto di delay (ritardo) è stato introdotto con la versione 2.9 di "ircd".
Purtroppo, però, non è presente una documentazione approfondita riguardo tale sistema.
 
4. Qual è il concetto del TS?

4.1 Per i nicknames

Un server che implementa il protocollo TS, aggiunge e (successivamente) conosce il TimeStamp del momento in cui un nickname s'è connesso, decidendo, durante il NetSplit, chi delle due identità ha scelto lo pseudonomio più recentemente. Grazie a ciò, è possibile stabilire con precisione chi dei due nicknames dev'essere killato, senza causare la disconnessione di entrambi, nella rete. Tale sistema è stato ideato per proteggere l'utente, che si è connesso prima dello split, dalle attività di NickColliding intenzionali.

4.2 Per i canali

Un server che implementa il protocollo TS, mantiene un TimeStamp del momento di creazione del canale. Durante la fase di NetMerge, i server remoti inviano le informazioni del canale da reimpostare, inviando anche il loro TimeStamp registrato, per quest'ultimo. Il nodo locale effettuerà, quindi, una comparazione per vedere se il TimeStamp, a lui in possesso, è più datato di quello ricevuto. Questo check è fondamentale per stabilire se le informazioni di un dato canale son state create durante il periodo di split, oppure, in un momento, in cui, la rete era stabile.
Se il TimeStamp più datato è quello remoto, il server utilizzerà le informazioni ricevute per aggiornare lo stato del canale, altrimenti, invierà le proprie informazioni al nodo remoto, al fine di permettere, a quest'ultimo l'esatto aggiornamento. Se ciò accade, le informazioni dello stato del server remoto vengono sovrascritte, continuando, in seguito, con la fase di controllo e reimpostazione. Questo sistema, permette, la rimozione di tutti gli operatori di canale che han ottenuto tale status durante un NetSplit, bloccando ogni tentativo di Op Riding durante i momenti d'instabilità della rete.

4.3 Note tecniche

Il server associa un TimeStamp (formato dalla data e dall'ora di connessione o di creazione) ad ogni nickname e canale, in modo da poter, in caso di necessità, reagire nel modo migliore possibile, in caso un conflitto venga a manifestarsi.
Questo protocollo impone il funzionamento del sistema solo se i servers linkati sono entrambi TS.
Quando avviene un conflitto, il server TS contrassegna il nodo ove il problema è stato generato, in modo da coordinare le decisioni univocamente in tutti i nodi della rete, evitando, quindi, i loop.
Il TS è un protocollo molto più complesso dell'ND/CD, sia nel design che nell'implementazione attiva nel codice di un IRCd. Nonostante, col tempo, siano state effettuate molte revisioni, può accadere la presenza di un eventuale "desynch" (cioè, ove uno o più servers considerano esatte le informazioni locali, riguardo lo stato del resto del network).
Nelle prime versioni del protocollo, addirittura, non vi era alcuna protezione riguardo l'impostazione di bans ed altre modalità, nel canale splittato. Tali informazioni non venivano perdute e, durante la fase di NetHealing, tali informazioni venivano condivise ed impostate dai servers, anche se l'operatore che le aveva settate, inizialmente, non aveva più lo stato di moderazione del canale. Successivamente, al fine di risolvere tale problema, s'è pensato, banalmente, di bloccare la possibilità, agli utenti, di ottenere lo status di ChanOp, mentre il server era in Split-Mode. Tale sistema, in modo molto semplice, ha limitato l'azione distruttiva di tale pecca, nel protocollo TS, non rimuovendo, del tutto, però, i problemi.
Alcuni IRCd, implementano, inoltre, un sistema TimeStamp ibrido con il Nick/Chan-Delay, oltre a qualche altro espediente non ufficialmente documentato.

5. Qual è il concetto del Nick/Chan-Delay?

5.1 Per i nicknames

Un server dotato di "nickname delay" evita che gli utenti utilizzino un nickname recente, qualora questo sia stato colliso.

5.2 Per i canali

Un server dotato di "channel delay" non permette agli utenti di entrare nei canali ove è stato perso recentemente lo status di moderazione, a causa dello split. I Join son permessi se il canale non è vuoto.

5.3 Note tecniche

Con il termine "nickname usato di recente" ci si riferisce ad uno pseudonomio splittato di recente (da un minimo di 15 minuti).
Con il termine "canale in status opless recente" ci si riferisce ad un canale che ha perso il suo status di moderazione a meno di 15 minuti dall'ultimo split.
Successivamente, è stata implementata una nuova versione del Nick/Chan Delay, la quale introduce il concetto di identificatori server e utenti, effettuando una modifica, di massa, a tutti i nicknames presenti su un server splittato, durante lo Split-Mode, al fine di evitare la possibilità di una collisione. Anche in questo caso, è stato introdotto il blocco nella ricezione dello status di ChanOp, durante le fasi d'instabilità di rete, al fine di marginare il problema relativo ai modes di canale, non legati agli utenti.

6. Comparazione tecnica dei protocolli

In primo luogo, sia chiaro che nessuno dei due evita il colliding dei nicknames o i takeover dei canali.

Vi è un sistema di gestione di queste attività, differente l'un dall'altro:
 
TS permette agli utenti di fare quel che vogliono, tentando di correggere la collisione quando questa capita.
Con il concetto di delay, gli utenti non possono effettuare particolari azioni che potrebbero condurre ad un conflitto.

In caso di tentato conflitto di nickname, il TS killa l'utente col nickname più recente, generando la disconnessione di quest'ultimo, mentre il Delay blocca solamente il processing del comando NICK. Per i canali, è possibile elaborare un discorso uguale.
Una delle grandi differenze, tra questi due concetti, è il sistema di gestione dei problemi.
Il TS si affida alla rete, cosa che non fà il Delay. Ciò significa che il TS può generare dei problemi, nell'intera rete, in certe occasioni, mentre il Delay non agisce mai al di fuori del proprio server locale.
Il TimeStamp, però, può gestire splits di durata variabile, mentre il Delay solo per quelli che rimangono entro i 15 minuti.
Il Delay non effettua il broadcast di nessun info extra, cosa che invece viene effettuata dal TimeStamp. 
Il TimeStamp richiede una rete omogenea (tutti servers TS). Per il Delay, invece, questo fattore non è del tutto necessario.

7. Uso della memoria per i protocolli

Il TimeStamp, per mantenere tutta la lista di canali ed utenti, usa 100Kb ogni 25000 utenti, e 24Kb ogni 6000 canali).
Il Delay, invece, usa, per il Nickname Delay, 400Kb ogni 25000 utenti e, per il "Channel Delay", un quantitativo di memoria prossimo allo 0.

8. Problemi dei Protocolli implementati

8.1 Lag-Killer Bots

Purtroppo, i 2 protocolli non son in grado di evitare questo problema.
Le azioni compiute sono queste:

- L'autore dell'attacco decide quale nickname infastidire e controlla ove questo è connesso
- Si collegano, alla rete, 2 bots. Uno nel server locale e nel canale ov'è presente l'utente da infastidire e l'altro in un server remoto, che presenti del ritardo di propagazione (es. LAG a causa di routing inefficiente)
- Quando l'utente cambia nickname, il bot presente nello stesso canale informa, tramite un mezzo comunicativo diverso, il bot remoto,  inviandogli il nuovo nickname dell'utente vittima
- Il bot remoto cambia il proprio nickname nello stesso dell'utente vittima
- Se la propagazione e il resynch del server remoto avviene in ritardo, verran a formarsi 2 nicknames uguali e, nel protocollo Delay, entrambi vengono killati per collisione

Neppure il TimeStamp può risolvere questo problema. Può, al massimo, limitare questo tipo di abuso, in quanto, occorre che il bot remoto sia molto veloce nel cambiare nickname. Inoltre, con il sistema Delay, i nicknames vengono killati e, come da routine, il nickname bloccato. Con il TimeStamp, è possibile che il bot continui a tentare di collidere l'utente, se il primo tentativo fallisce.

Lo stesso problema può manifestarsi in caso di Start e /Restart dei servers. Se il routing è ben fatto, i colliders han solo pochi secondi per operare il loro abuso.

8.1 Splits Lunghi

Qualora si presente il protocollo nick delay, non vi è tutela se lo split dura più di 15 minuti. Dopo tale limite, infatti, un qualsiasi client può clonarsi per generare un gran numero di collisioni, senza che nulla lo fermi nel suo intento. Allo stesso motivo, tale limite del funzionamento di questo protocollo, può essere sfruttato per i canali, al fine di generare dei TakeOvers (sempre se non son state intraprese delle precauzioni aggiuntive).
Oltretutto, un server che è rimasto splittato dal resto della rete, per moltissimo tempo, non dovrebbe neppure relinkare, non solamente per non generare caos, a causa di questo limite del Chan/Nick Delay, ma anche perchè, una rete IRC deve poter ricollegare velocemente tutti i singoli nodi, senza ritardi eccessivi.

Il protocollo TimeStamp ha, anch'esso, dei problemi in questi casi. Ad esempio, se 2 servers rimangono divisi per lungo tempo, è possibile che vi siano 2 utenti ufficiali, aventi entrambi diritto nell'usofrutto di una particolare identità. Non avrebbe senso che, in questo caso, uno dei due fosse killato.