domingo, diciembre 19, 2010

Una llamada a las armas (II): dinero P2P (I)


En Constructive Direct Action Against Censorship, la Electronic Frontier Foundation (EFF) nos propone 4 proyectos de lucha contra la censura en Internet. No son manifiestos, no son ataques de denegación de servicio distribuidos (DDoS), ni tampoco son pérdidas de tiempo como llamar a acciones "en el mundo real". Las propuestas son:

Voy a contextualizar y analizar cada una de las propuestas (excepto Tor, sobre la que no tengo nada que decir). Como se va a alargar, voy a hacerlo en varias partes, manteniendo esta cabecera en cada entrada.

Respecto al dinero P2P, voy a hablar de dos proyectos, el mencionado por la EFF y otro más con una concepción diferente. Cada enfoque tiene sus pros y sus contras, pero aun más: se basan en filosofías P2P diferentes,por lo que resulta interesante analizarlas incluso más allá de la mera problemática monetaria.

Ripple Project: lo primero que tenéis que hacer es ver el video de 5 minutos que tienen en su página principal, explicando qué es y cómo funciona Ripple (lo que me ahorrará una farragosa explicación). La idea clave, tal y como dicen en el video es que "toda persona [en una red Ripple] tiene deudas/débitos sólo con personas con las que tiene confianza". Las redes de pares más conocidas unen pares al azar, sin otra consideración. Ripple, en cambio, formaría parte de lo que se conoce como redes "Friend-To-Friend" o F2F, aunque no por el mantenimiento del anonimato como hacen las Darknets, sino todo lo contrario: por las relaciones de confianza. También se podría enunciar como que Ripple forma una estructura de red de confianzas, o Web of Trust (si os fijáis en la Wikipedia estos dos conceptos aparecen relacionados, y Ripple aparece como ejemplo de F2F).
Aparte de su interesante arquitectura F2F, Ripple presenta otras características. La primera que es interesante destacar es que Ripple no es en realidad una moneda. En terminología Ripple, la unidad se expresa como IOU (I Owe yoU, o sea Yo Te Debo), pero esa unida en realidad puede ser cualquiera. En los ejemplos del video se emplean dólares, pero podría tratarse de cualquier otra moneda (de hecho, podría hasta tratarse de los bitcoins que veremos más adelante). El modelo de Ripple permitiría incluso gestionar múltiples monedas, con o sin intercambios entre ellas. En este sentido, Ripple más que dinero P2P es un medio de pago P2P. Claro que, como la función principal del dinero es la de servir de medio de pago, podemos hablar de dinero P2P tranquilamente aunque luego ese dinero en realidad esté expresado en las monedas habituales.
Si lo analizamos desde el punto de vista punto de vista estrictamente monetario, Ripple presenta unas características bastante inusuales. Es un esquema monetario bastante poco inflacionario, tanto porque los actores tienden al punto de equilibro (en el estado ideal de equilibrio nadie debe nada a nadie, con lo que el dinero "creado" es cero) como porque la masa monetaria máxima es la suma de todos los límites de préstamo en cada relación (en realidad sólo la del mayor de los dos sentidos). Puesto que las personas en la red de confianza tenderán a ser conservadores en los límites de las líneas de crédito, el riesgo de una expansión monetaria es bastante difícil de imaginar. Incluso una explosión en el número de relaciones de confianza, tendería a repensar los límites personales a la baja para no estar excesivamente expuestos.
Sin embargo, esta naturaleza limitadora de la expansión monetaria, si bien deseable, trae consigo problemas de difícil solución. El asunto radica en que Ripple gira alrededor de un punto de equilibrio bastante estable. Si la economía que está representando la red Ripple no está a su vez equilibrada, la red tenderá a colapsar. Por ejemplo, si Ripple estuviera implementado en un pequeño pueblo, y se empleara para los intercambios de bienes y servicios de sus habitantes, si por lo que sea alguien estuviera acumulando mucho dinero, esto significaría que sus líneas de crédito terminarían exhaustas, y eso se iría transmitiendo desde su vértice a todas las aristas adyacentes, luego a las adyacentes a éstas, y así sucesivamente, con lo que los movimientos de dinero serían casi imposibles porque todo el dinero estaría "congelado" en las deudas directas o indirectas para con esta persona (o personas). Y cualquier acumulación excesiva de dinero va a conllevar estos efectos en la red, salvo que se amplíen mucho los topes de las líneas de confianza (que a la larga sólo retrasará el problema, no lo evitará).
Este problema no es un problema real del sistema Ripple. Ripple sólo está reflejando un desequilibrio económico inherente a la economía que hay por debajo. La solución no viene dada por Ripple, viene dada porque la economía esté equilibrada. En un sistema cerrado no debería ser muy problemático: el agricultor vende el grano y el forraje, el panadero hace pan con el grano y vende el pan, el ganadero usa el forraje para alimentar a sus animales y luego los vende al carnicero, que a su vez... y todos consumen el pan, y la carne, etc, etc con lo que el ciclo se cierra.
Pero ahora imaginemos que todos esos habitantes de ese pueblo usan gasolina o gasoil u otro combustible, que tienen que comprar a un agente externo (por ejemplo, una petrolera controlada por un jeque árabe). Si este agente externo empieza a operar mediante el sistema Ripple, puesto que todos compran combustible, se producirá nuevamente el colapso en la red alrededor de su vértice. El agente externo obviamente podría querer adquirir algunos productos de ese pueblo, pero ¿serán suficientes para equilibrar la balanza de combustibles vendidos? Si el pueblo en cuestión está especializado en crear ciertos bienes y servicios en los que el agente externo está interesado, tal vez. Pero si no, si los intercambios con el agente externo están desequilibrados, nuevamente el colapso de la red es inevitable.
Otro problema que suele plantearse con las redes Ripple es el de los "grandes préstamos". ¿Qué pasa si quiero comprarme una casa? La respuesta en la FAQ a mi entender no es muy satisfactoria. Hacer intervenir a entidades crediticias, que van a pedir un interés a cambio, me huele a introducir desequilibrios en la deuda (al estilo de la parábola de las 100 monedas) que terminaría colapsando la red Ripple alrededor de los vértices de dichas entidades financieras. Uno podría imaginarse que redes Ripple suficientemente grandes, con topes crediticios suficientemente generosos, podrían hacer innecesarias a estas entidades financieras, pero no sabemos si en realidad funcionaría. Incluso planteado a nivel experimental, como una simulación, me parece un desafío sumamente complejo.
Por último me gustaría comentar que no he probado ninguna de las implementaciones del sistema Ripple (que son "Work in progress"), así que no puedo hablar del sistema desde un punto de vista práctico.

He decidido que, dada la extensión actual del texto, es mejor que pare aquí, y deje la parte de bitcoin para una "segunda parte de la segunda parte" en una entrada diferente. Sirvánse de comentar sobre Ripple aquí, o si prefieren hacer comentarios en general, pueden esperar a la segunda entrada.

sábado, diciembre 18, 2010

Una llamada a las armas (I): DNS

En Constructive Direct Action Against Censorship, la Electronic Frontier Foundation (EFF) nos propone 4 proyectos de lucha contra la censura en Internet. No son manifiestos, no son ataques de denegación de servicio distribuidos (DDoS), ni tampoco son pérdidas de tiempo como llamar a acciones "en el mundo real". Las propuestas son:

Voy a contextualizar y analizar cada una de las propuestas (excepto Tor, sobre la que no tengo nada que decir). Como se va a alargar, voy a hacerlo en varias partes, manteniendo esta cabecera en cada entrada.


The Dot-P2P Project:  a raiz del borrado del dominio Wikileaks.org se puso de manifiesto uno de los grandes cuellos de botella de la Internet actual: la gestión de nombres de dominio está centralizada en una organización, la ICANN, que supuestamente debería conducirse de forma neutral, pero que ha demostrado todo lo contrario cediendo a las presiones de un gobierno concreto. Pero aun hay más: nuevas leyes promulgadas en EE.UU. están resultando en embargo de nombres de dominio a páginas acusadas de "piratería", como es este caso, con el agravante de que las acusaciones vienen de un país diferente.

Se podrían poner más ejemplos, pero ya habéis captado la esencia del problema: InterNIC (que es como históricamente se ha llamado a los servidores raiz ahora gestionados por la ICANN) ya no es fiable. La primera solución obvia que se le ocurre a cualquiera es precisamente cambiar la autoridad de los servidores raiz. Al fin y al cabo, nadie ha escrito en piedra que los root-servers de Internet (aquellos de los que al final depende la resolución de los nombres de dominio) tengan que ser los 13 de InterNIC. Y por eso, desde hace tiempo existen algunas raices DNS alternativas. Por desgracia, estas alternativas son escasamente populares y no parece que amenacen la hegemonía de InterNIC/ICANN, aunque yo por si acaso ya estoy usando los servidores raiz de OpenNIC (si no eres de OpenNIC, ese enlace no te funcionará, puedes consultar más sobre ellos aquí o en Wikipedia), la más popular de las poco populares alternativas.

Otra de las pegas de OpenNIC y otras raices alternativas es que realmente sólo gestionan dominios de alto nivel alternativos (como .free, .geek, .indy, .oss, etc), mientras que para los "7 grandes" (ahora son más) dominios de alto nivel, más los dominios nacionales se limitan a copiar los registros de InterNIC. Es decir, que los típicos .com, .org, .net, y compañía, siguen resolviéndose como hasta ahora, y lo único que se gana son los nuevos dominios de alto nivel gestionados por OpenNIC. Estos dominios son gratuitos (no son el gran negocio de los dominios que se ha montado la ICANN), sin embargo, sigue siendo una entidad centralizada quien los gestiona. Particularmente, me molesta además que, por ejemplo, haya que dar datos personales (como una dirección o un teléfono) para registrar un dominio (por eso no he registrado ninguno).

Volvamos al proyecto dotP2P. En este estado de cosas, y con la censura del dominio de Wikileaks y la posterior reacción popular creando subdominios apuntando a sus direcciones IP, uno de los cofundadores de The Pirate Bay lanza una propuesta de crear un sistema DNS libre alternativo al de  ICANN. Entre otras cosas se quiere que sea un sistema distribuido, para que no pueda sufrir ataques de denegación de servicio como los que estaba sufriendo el DNS de Wikileaks, y para ello se propone usar protocolos P2P. Todo esto se canaliza —se esta canalizando, puesto que está en plena fase de formación— en lo que bautiza como Dot-P2P. En la web podéis ver un wiki con las líneas en las que se están trabajando.

He de decir que mi primera reacción fue de escepticismo. Escepticismo porque el DNS es ya un sistema distribuido de por sí. Sin embargo, es cierto que tiene algunos cuellos de botella atacables. El primero y obvio es el de la gestión: es centralizada, y por lo tanto dependiente del "buen comportamiento" de la organización que la realiza. El segundo, menos obvio, es cada propio nodo de la estructura de DNS empezando por los propios root-servers, que si bien pueden ser replicados y reforzados, no es algo que se haga automática y dinámicamente, y por lo tanto no es algo que se defienda bien de ataques DDoS (la mejor defensa contra un ataque distribuido es una defensa distribuida).

Así que una vez pasado mi escepticismo inicial, reconozco que un sistema de resolución de nombres descentralizado y P2P no es una mala idea. Lo que ya no me parece tan buena idea son algunas de las decisiones que se están tomando ahora mismo dentro de dotP2P:
  • Se ha escogido mantener la gestión de dominios centralizada (al parecer, pese a las protestas de un sector)
  • Se ha escogido seguir dependiendo de unos root-servers estáticos, en este caso de los de OpenNIC, que delegarían la zona .p2p a los servidores de esta red (no está muy claro cómo ni a cuáles)
En todo éste lío creo que lo primero es tener claro qué es lo que se pretende. Y lo que se pretende (en mi opinión) es resolver 2 problemas diferentes:

  1. Por un lado, una gestión descentralizada de los nombres de dominio
  2. Por otro, un sistema de resolución de nombres a IPs distribuido y probablemente dinámico.
Para el primer problema, sólo hay una manera de convertir una autoridad centralizada en una distribuida, y es una Web of Trust. Pero como eso transciende el problema del DNS, lo voy a dejar estar de momento.

En cuanto al segundo problema, lo que debemos plantearnos para empezar es si queremos mantener el viejo sistema del DNS. El DNS es una estructura jerárquica, y plasmarla mediante una estructura horizontal va a llevar a ciertos problemas de "impedancia" entre modelos. Por otro lado, se pueden plantear enfoques mucho más radicales:
  • los nombres para identificar máquinas (al menos a primer nivel) no son jerárquicos. Esto significa que, por poner un ejemplo, mi nombre de máquina (o mejor, dominio) no sería "jcantero.org" o "jcantero.com" o "jcantero.algo"; sería "jcantero". No hay necesidad de fragmentar en grandes grupos tipo "org" o "com", que son cuellos de botella y que además no reflejan ninguna subdivisión real. Podría pensarse en una subdivisión geográfica "jcantero.es", pero entonces tenemos el problema de que es una división arbitraria, no balanceable y que aporta datos privados que igual no queremos dar. Tendría mucho más sentido subdividir, por ejemplo, por comunidades virtuales ("jcantero.ecol").
  • El resolutor de nombres P2P no tiene por qué pasar por el sistema DNS. Puede usar su propio sistema P2P para resolver el nombre, sin consultar servidores raiz ni bajar por los nodos. Si estás en una red que no controlas, el que las peticiones pasen por el sistema DNS tiene la ventaja —no en todos los casos— que los firewalls y demás filtros permiten esas conexiones y puede que tengas permitido resolver peticiones DNS aunque no puedas abrir otro tipo de conexiones. Pero tiene la desventaja que se puede manipular (incluyendo filtrar) en el camino los paquetes de DNS. Si el resolutor es un cliente P2P, mientras puedas abrir algún tipo de conexión con la red P2P podrás resolver nombres, y si fuera necesario las comunicaciones podrían ir cifradas para garantizar su integridad.
  • Si por las razones que fueran se decide que el sistema debe responder al protocolo DNS (es decir, ser un backend DNS en su conjunto), si se quiere que participen masivamente servidores para que la red sea robusta ante ataques, debe permitirse la participación de servidores residentes en IPs dinámicas, incluso detrás de NATs. Ello plantea una serie de desafíos, puesto que tanto el protocolo DNS en sí como los servidores DNS tal y como estan programados hoy en día, estan pensados para un universo de IPs estáticas que cambian muy poco en el tiempo.
  • Si ni siquiera se cumple la condición anterior, entonces simplemente estamos hablando de la delegación del top level domain .p2p a una serie de servidores con IP estática bien conocidos, cuya única ¿ventaja? es que intercambian los ficheros de zona vía P2P, entonces estamos hablando de una solución no muy, y también un poco "más de lo mismo" respecto a lo que ya hay. No significa que no pueda ser interesante, pero no va mucho más allá de lo que OpenNIC puede ofrecer, por ejemplo.
Bien, ahora es cuando podéis decirme "Si eres tan listo, show us the code"; "Muéstranos cómo lo harías tú". Reconozco que no tengo un diseño hecho —aunque le haya dado algunas vueltas en la cabeza—, así que no puedo dar mi solución. Si es que a alguien le interesara, que esa es otra. Pero es que también hay que plantearse si estamos enfocando bien el problema. ¿Este es un asunto que se circunscribe estrictamente al DNS? Más adelante veremos que no, y que por ello tal vez no conviene pararse a pensar mucho en resolver un detalle, cuando hay que resolver un problema mucho más global.