[LAC-TF] [lacnog] [LACNIC/Seguridad] IPv6 & Bye-bye End-To-End Principle

[Fernando Gont]

On 11/17/2016 03:38 AM, Octavio Alvarez wrote:
> On 11/15/2016 10:04 PM, Fernando Gont wrote:
>> Quien desee ver la grabación de la lista de la reunión del 6man wg,
>> puede hacerlo en:
>> <http://recs.conf.meetecho.com/Playout/watch.jsp?recording=IETF97_6MAN&chapter=chapter_1>
> 
> Gracias por pasarlo. Me resulta más fácil interpretar el video dentro de
> un contexto explicado.
> 
> Disclaimer: soy totalmente neófito a la IETF, pero de lo que he visto
> tengo mis opiniones.
> 
> En cuanto a los comentarios que a continuación mencionas, no sé cuáles
> son de desaprobación y cuáles no. Por contexto entiendo que todos son de
> desaprobación y contesto en consecuencia. Espero no haberme equivocado.

A mi criterio, son argumentos rebuscados para justificar la decision final.



> Y aunque mi opinión es mayoritariamente a favor de lo que se dijo en la
> IETF, también estoy de acuerdo con lo que has expuesto en otros mensajes
> en cuanto a las dificultades de participación latinoamericana, a la
> autoridad de los fabricantes y yo hasta agregaría Authority Bias en la
> comunidad, pero esos son otros temas.
> 
>> * Le pregunto a algunos de los proponentes del *cambio* "vos me estas
>> queriendo decir que porque vos implementaste esto en codigo nosotros
>> tenemos que cambiar el estandar?". Respuesta "Si"
> 
> 50/50. Si algo se implementa en código y las mediciones arrojan que
> funciona y es congruente, también tiene un mérito a considerar.

Yo apoyo los cambios cuando tienen sentido.

El tema aca es: es la inserción de EHs la manera adecuada como para
especificar que ruta deben seguir los paquetes? -- Para mi: No. Es mas
correcto y limpio la encapsulacion ("tuneleo").

Los cambios deben realizarse cuando hay buenas ideas, no cuando hay
ideas implementadas.  Que algo este implementado simplemente quiere
decir que se conto (por algun motivo) cn las horas-hombre necesarias...
no que la idea sea buena.


Y si se va a actualizar el estandar, debe escribirse una propuesta para
tal fin -- no relajar un estandar, sin consenso explicito.



> Es como el RFC de lo del /127 (RFC 3627 y luego el RFC 6547, RFC 6164).
> Estaba "prohibido" (considered harmful) y después lo "aceptaron"
> (recommended). Posiblemente muchos lo ofrecieron mientras tanto como una
> "extensión propietaria".

En realidad, esto es algo operacional. En RFC7421 nosotros explicamos el
porque del /64. Aunque en gran medida creo que el hardcodeo de /64 es
una mala idea.




>> * "El RFC2460 nunca prohibio la inserción de EHs"   --  bueno, tampoco
>> prohibe que en vez de reenviar los paquetes, imprimas el paquete en hexa
>> en un apel, te armes un faso, y te lo fumes.
> 
> Sería divertido ver una implementación de esta propuesta. ;-) Lo único
> cierto es que tienes razón: el RFC 2460 no lo prohibe.

Personalmente creo que implicitamente lo prohibe. Un estandar n puede
explayarse en todas las cosas no permitidas, ya que la lista seguramente
seria infinita.  Insertar EHs viola la arquitectura de IPv6, rompe IPsec
y PMTUD, y va en contra del ropio principio E2E.


> El hecho de que esté permitido no significa que resulte conveniente, y
> al mismo tiempo el hecho de que no resulte conveniente tampoco implica
> que esté prohibido.
> 
> Al tema: si antes no estaba explícitamente prohibido y ahora se
> documenta que hacerlo puede ocasionar problemas ¿no es un avance?

No, es un retroceso. Uno no puede permitir algo que de base ya se sabe
que potencialmente va a traer problemas. Menos aun si el documento en
cuestion se panea publicar como Internet Standard.




>> * "El RFC2460 no tiene lenguaje normativo que prohiba la inserción de
>> EHs" -- bueno, en realidad RFC2460 no tiene lenguaje normativo :-)
>> (RFC2119), y cuando se propuso arreglar esto, dijeron que no.
> 
> ¿Entonces si no hace referencia al 2119 puedo interpretar un MUST NOT
> como MAY, un MAY como MUST NOT, un MUST como SHOULD...?

Exacto.

Muchos propusimos que el RFC2460 se actualice para utilizar keywords de
RFC2119. Pero se decidio dejarlo así.


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