[LAC-TF] Netfilter developers working on NAT for ip6tables

[Fernando Gont]

On 12/01/2011 03:07 PM, Christian O'Flaherty wrote:
>>> Sin embargo si vos y yo desarrollamos algo simple y nuevo, y lo
>>> comenzamos a probar cada uno desde su casa, funcionará sin problema
>>> mientras no tengamos cosas raras en el medio que meta el proveedor.
>>
>> En la mayoria de los casos, esto se vuelve virtualmente imposible.
>> Firewalls y NAT (en los bordes) son el principal problema. Pero en el
>> core, por ejemplo, muchos routers tambien filtran paquetes con opciones IP.
> 
> Esa no es mi experiencia. Como cliente de 3 ISPs en Argentina, como
> administrador en una red regional y otra global y como usuario en
> Uruguay, no he visto filtros en la red. El CORE es absolutamente bobo.

Disculpá mi uso pobre de terminología. Lo que quise decir es que en
distintos puntos de la red, se aplica filtrado. Desde el punto de vista
de quien diseña un protocolo que corre IP, la red en si es una nube, y
en general el punto especifico en el cual se descarta o filtra algo
termina siendo irrelevante. Las pruebas que hice yo fueron demasiado
rudimentarias y precarias como para sacar un número en base a eso. Pero
recuerdo haber leido mediciones que indicaban lo que menciono, en
porcentajes altos. Si bien recuerdo, las mediciones en cuestion las
habia hecho Dan Wing (co-chair del behave wg de la ietf). Voy a buscar
en mis mails y/o pedirselas a Dan, e intentaré reenviarlas.


>> A modo de un simple ejemplo, *uno* de los argumentos para "deprecatear"
>> (http://www.gont.com.ar/rfcs/rfc6093.pdf) el mecanismo de "datos
>> urgentes" en TCP fue justamente que Cisco PIX filtraba, por default,
>> paquetes que hacen uso de este mecanismo. Dado lo ampliamente desplegado
>> que está este producto, el mecanismo ya no es confiabvle (reliable).
> 
> En el core de las redes no hay PIX u otros firewalls... 

Si, está claro. Este parrafo sobre PIX fue algo aparte, y e intentó
indicar que la red en muchos casos no es "tonta". Recuerdo casos de
proveedores filtrando paquetes con opciones (en otros casos, simplemente
las ignoran).


>> Hay varios estudios publicados sobre cuan dificil es hacer "funcionar"
>> trafico con opciones TCP o IP... lo cual muestra quemas allá del
>> direccionamiento o conectividad extremo a extremo, en lineas generales
> 
> Justamente esa es la prueba que el core es bobo... Esos routers solo
> miran la IP destino y disminuyen el TTL. Pedirles que procesen el
> campo options es demasiado :-)

Si y no. :-) Por un lado, estamos de acuerdo en que operativamente puede
ser "demasiado" pedir que procesen las opciones, por la penalidad de
performance que eso implica (y los potenciales ataques de DoS que eso
podría implicar). Por otro lado, eso también viola la propia
especificacion del protocolo que queremos "cuidar".


>> El problema es que, a la práctica, los usuarios no controlan un NAT. Vos
>> controlarás el tuyo, yo controlaré el mio, etc. Pero "Doña Rosa"
>> simplemente "enchufo el router inalambrico que compro en el
>> supermercado, apra usar Internet". -- lease, no se va a poner a
>> configurar el dispositivo, y en todos esos casos, la posicion del NAT
> 
> No esperamos aportes innovadores de "Doña Rosa". Estoy pensando en
> chicos de 15 años que saben mucho mas que eso.

El punto no es que Doña Rosa haga un aporte innovador, sino que Doña
Rosa pueda usar los aportes innovadores que hagan otros. Actualmente, si
yo desarrollo un protocolo de transporte nuevo, casi ningun usuario
hogareño podría utilizarlo, debido a firewalls y/o NATs.

Por ejemplo, hoy en dia sería imposible que un usuario hogareño use
SCTP, a menos que se lo tunelee sobre UDP.


> Cuanto mas simple sea para ellos desarrollar y probar sus cosas mejor
> será Internet.

Estamos completamente de acuerdo.

Al mismo tiempo, en general nadie quiere que sus redes sean utilizadas
para probar nada. Y no solo una empresa. Pese a que trabajo en el area,
salvo en casos particulares no quiero que por una red circule otra cosa
de lo que se espera que circule.

(ver la aclaración debajo, de todos modos)


>> Por otro lado (y mal que me pese), aquellos avances que han tenido un
>> impacto concreto creo que han sido en la capa de aplicacion, y no en las
>> capaz de transporte o internet. (Digo "mal que me pese", ya que dado que
>> en gral. trabajo en capas de transporte hacia abajo.)
> 
> Justamente es a las aplicaciones que debemos simplificarle la tarea.
> El que desarrolla la aplicación (que no sea sobre la web) tendrá que
> dedicar mas tiempo a atravesar cajas "manipuladoras de paquetes" que a
> su propia idea.

En muchos casos, esa dificultad es justamente intencional. (Recuerdo una
vez leer/escuchar(?) a Radia Perlman reirse de los protocolos
"firewall-friendly", argumentando que un protocolo que hace todo lo
posible para sobrepasar un firewall, en realidad es firewall-unfriendly,
o al menos admin-unfriendly).

Cajas tales como packet-scrubbers tienen una razon de ser. Obviamente,
en muchos casos la postura de quien trabaja en redes es opuesta o
diferente a la de quien trabaja en seguridad. Para quien hace redes,
dichas cajas acotan funcionalidad. Para quien hace seguridad, estas
cajas mitigan motenciales vulnerabilidades (en algunos cosos, incluso
desconocidas).

Quien hace redes, espera que todo lo que diseñe sea facil de desplegar.
Quien hace seguridad usualmente espera lo contrario: que algo que él no
"aprobó" que su red soporte sea dificil de desplegar.

Personalmente, en algunos casos trabajo de un lado, y en otros trabajo
del otro. Y mas que catalogar a una u otra postura como buena o mala,
creo que el tema es entender que se tratan de dos visiones y objetivos
distintos.

Y "cual es la postura adecuada" termina siendo dependiente de cual es la
razón de ser de la red en cuestión.


>> El "problema" con el principio e2e es que, entre otras cosas, apunta a
>> tener una red con al que todo el mundo puede jugar. Pero en ambientes de
>> produccion, la filosofia aplicada usualmente es la opuesta: solo podés
>> jugar con aquellas cosas que *necesitas* poder jugar.
> 
> Eso es correcto... La gente de IT de las empresas debe hacer eso,
> dejando pasar solo lo "autorizado". Pero es decisión del cliente
> final. En nuestras casas decidimos nosotros.

Por si hace falta la aclaración, repito que no soy partidario del CGN,
sino todo lo contrario. Y obviamente que estoy en favor de que quien
tenga el conocimiento para hacerlo, pueda tener conectividad y
direccionamiento e2e si asi lo desea.

Tal vez la discusión/confusión viene porque mi argumento se toma como un
"via libre" para el despliegue de tecnologias tipo CGN. Pero nada mas
lejos de mi pensamiento.

Mi argumento es que, incluso teniendo la posiblidad de tener
conectividad e2e, en muchisimos casos, uno no permitiria esa
conectividad extremo a extremo, por los motivos mencionados en mi otro
mail. Ese es simplemente mi argumento.

Ahora bien, si la discusión es: quien debería tomar esa decision? --
Obviamente que el usuario final. Si la tomara el proveedor, obviamente
estaría limitando el uso que puedo hacer de la red (mas alla de que
despues yo decida (o no) tener conectividad extremo a extremo). La
posibilidad de "elegir" es importante "per se".

Un abrazo,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont at si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492