[LACNIC/Seguridad] Nuevo I-D sobre seguridad TCP (Fwd: New Version Notification for draft-gont-tcpm-tcp-seq-validation-00.txt)

[Iván Arce]

Ahh muy interesante, lo voy a leer en detalle, pero a simple vista me
recuerda a algo que (creo) OpenBSD corrigió hace varios años. Aunque
creo que en aquel caso era al revés, procesaban paquetes fuera de la
ventana que no debian procesarse.

Tendrían que pensar que implicancias de seguridad tiene la  modificación
propuesta, p.e. si hace mas fácil a un tercero hacer un DoS con paquetes
con segmentos TCP un byte fuera de la ventana.
A priori parecería que no hay mas problemas de los ya conocidos (
adivinar el seqno sería equivalente a adivinar seqno-1 ) pero no estoy
seguro.

En principio me resulta poco confiable recomendar una modificacion
general al procesamiento del TCP para que siempre incluya un byte menos
que el borde de la venta en lugar de hacerlo para las situaciones
específicas en que es necesario admitir esos paquetes. Pero por otro
lado, es posible que sea dicifil enumerar todas las situaciones en las
que es necesario admitir un segmento con número de sequencia un byte
fuera de la ventana.

-ivan



On 2/16/13 8:35 PM, Fernando Gont wrote:
> Estimados,
> 
> Hemos publicado un nuevo IETF I-D, sobre problemas que pueden ocurrir
> (situaciones de DoS) debido a las actuales reglas de validación de TCP
> Sequence Numbers.
> 
> El I-D se encuentra en:
> <http://www.ietf.org/internet-drafts/draft-gont-tcpm-tcp-seq-validation-00.txt>.
> Cualquier comentario será mas que bienvenido.
> 
> Comentarios informales/al_margen:
> 
> * Este trabajo surgió como spin off the mi I-D
> draft-ietf-tcpm-tcp-security. Luego que una aprte del globo terrestre
> practicara culto a Onan, dicho trabajo fue abandonado. Sin embargo,
> draft-ie una version de este I-D hace un año, y se me ocurrió publicarlo
> ahora, ya que hacia mucho que no hacía nada sobre TCP.
> 
> * El tema es super interesante.... Si alguna vez te preguntaste por que
> los paquetes con el mismo {SRC IP, SRC PORT} que {DST IP, DST PORT}
> causaban DoS, este I-D provee la respuesta... Partimos de un caso/vector
> especifico, y extrapolamos para llevarlo a otros casos.
> 
> * En lo personal, mi "paga" fue escribir algo con David Borman, quien
> creo que es un capo -- (pocas cosas pueden ser tan sublimes técnicamente
> como estar tomando un cafe con ese tipo, que pinte una charla de TCP, y
> que el chabó pele el fuente de BSD, y cual oráculo digga "esta linea es
> la que esta causando el problema" :-)
> 
> Saludos, y gracias!
> Fer
> 
> 
> 
> 
> -------- Original Message --------
> From: internet-drafts en ietf.org
> To: fgont en si6networks.com
> Cc: david.borman en quantum.com
> Subject: New Version Notification for
> draft-gont-tcpm-tcp-seq-validation-00.txt
> Date: Sat, 16 Feb 2013 15:02:18 -0800
> 
> 
> A new version of I-D, draft-gont-tcpm-tcp-seq-validation-00.txt
> has been successfully submitted by Fernando Gont and posted to the
> IETF repository.
> 
> Filename:	 draft-gont-tcpm-tcp-seq-validation
> Revision:	 00
> Title:		 On the Validation of TCP Sequence Numbers
> Creation date:	 2013-02-16
> Group:		 Individual Submission
> Number of pages: 15
> URL:
> http://www.ietf.org/internet-drafts/draft-gont-tcpm-tcp-seq-validation-00.txt
> Status:
> http://datatracker.ietf.org/doc/draft-gont-tcpm-tcp-seq-validation
> Htmlized:
> http://tools.ietf.org/html/draft-gont-tcpm-tcp-seq-validation-00
> 
> 
> Abstract:
>    When TCP receives packets that lie outside of the receive window, the
>    corresponding packets are dropped and either an ACK, RST or no
>    response is generated due to the out-of-window packet, with no
>    further processing of the packet.  Most of the time, this works just
>    fine and TCP remains stable, especially when a TCP connection has
>    unidirectional data flow.  However, there are three scenarios in
>    which packets that are outside of the receive window should still
>    have their ACK field processed, or else a packet war will take place.
>    The aforementioned issues have affected a number of popular TCP
>    implementations, typically leading to connection failures, system
>    crashes, or other undesirable behaviors.  This document describes the
>    three scenarios in which the aforementioned issues might arise, and
>    formally updates RFC 793 such that these potential problems are
>    mitigated.
> 
> 
> 
> 
> 
> The IETF Secretariat
> 
> 
> 
> 
> _______________________________________________
> Seguridad mailing list
> Seguridad en lacnic.net
> https://mail.lacnic.net/mailman/listinfo/seguridad
>