Suplantación de protocolo

Los protocolos de corrección de errores y transferencia de archivos suelen funcionar calculando una suma de verificación ( CRC) para un bloque de datos conocido como paquete y transmitiendo el resultado al final del paquete. En el otro extremo de la conexión, el receptor recalcula el número basándose en los datos recibidos y compara el resultado con el enviado desde la máquina remota. Si coinciden, el paquete se transmitió correctamente y el receptor envía una ACKseñal para indicar que está listo para recibir el siguiente paquete.

El tiempo de transmisión de la respuesta al remitenteACK depende de la velocidad de las líneas telefónicas, no de la del módem, y suele ser de aproximadamente 1/10 de segundo en enlaces cortos, pudiendo ser mucho mayor en enlaces de larga distancia o redes de datos como X.25 . Para un protocolo que utiliza paquetes pequeños, este retardo puede ser mayor que el tiempo necesario para enviar un paquete. Por ejemplo, el protocolo UUCP "g" y Kermit utilizan paquetes de 64 bytes, que en un enlace de 9600 bit/s tardan aproximadamente 1/20 de segundo en enviarse. XMODEM utilizaba un paquete ligeramente mayor de 128 bytes, que tarda aproximadamente 1/10 de segundo en enviarse.

El siguiente paquete de datos no se puede enviar hasta que ACKse reciba el paquete anterior. En el caso de XMODEM, por ejemplo, esto significa que se necesitan al menos 2/10 de segundo para que se complete el ciclo completo de un solo paquete. Esto implica que la velocidad general es solo la mitad de la máxima teórica, lo que representa una eficiencia del canal del 50 % .

La suplantación de protocolo aborda este problema haciendo que el módem local reconozca que se está realizando una transferencia de datos, generalmente mediante la búsqueda de encabezados de paquetes. Cuando estos se detectan, el módem busca el final del paquete, normalmente conociendo el número de bytes en un solo paquete. XMODEM, por ejemplo, tiene 132 bytes en un paquete debido a que el encabezado y la suma de verificación se suman a los 128 bytes de datos reales. Cuando el módem ve que el paquete ha terminado, envía inmediatamente un ACKmensaje suplantado de vuelta al host. Esto hace que la computadora local envíe inmediatamente otro paquete, evitando la latencia de esperar una respuesta ACKde la máquina remota. Los datos de múltiples paquetes se mantienen en un búfer interno mientras el módem los envía a la máquina remota. Esto permite que los paquetes se envíen continuamente, mejorando enormemente la eficiencia del canal. Sin embargo, esto también requiere que el enlace entre los dos sistemas esté libre de errores, ya que el módem ya ha ACKprocesado los paquetes incluso antes de que se hayan enviado. Normalmente, esto se solucionaba utilizando un protocolo de corrección de errores a nivel de módem, como los Protocolos de Red de Microcom .

La suplantación de protocolo también se utilizó ampliamente con otra característica de los primeros módems de alta velocidad. Antes de la introducción de la cancelación de eco en V.32 y protocolos posteriores, los módems de alta velocidad solían tener un "canal de retorno" muy lento para enviar este tipo de datos ACKal remitente. En el TrailBlazer de ~18.500 bit/s , por ejemplo, el módem podía enviar hasta 35 paquetes UUCP por segundo al receptor, pero el canal de retorno solo ofrecía 75 bit/s, insuficiente para los 35 bytes (280 bits) de ACKmensajes generados por el host remoto.

En este caso, la suplantación de identidad permitió que el módem emisor continuara enviando paquetes a la máxima velocidad posible. Al mismo tiempo, el módem del receptor remoto descartó los ACKpaquetes generados por el software del ordenador local, manteniendo así el canal de retorno despejado. Dado que la eficiencia del canal solo se convertía en un problema importante a velocidades superiores a 2400 bit/s, y los módems capaces de funcionar a mayor velocidad solían tener una potencia de procesamiento considerable, la suplantación de protocolo se asociaba principalmente con estos sistemas de alta velocidad.

Las conexiones TCP pueden sufrir limitaciones de rendimiento debido a un tamaño de ventana insuficiente para enlaces con un alto producto ancho de banda-retardo , y en enlaces de retardo prolongado, como los que se realizan a través de satélites GEO , el algoritmo de inicio lento de TCP retrasa significativamente el inicio de la conexión. Un enrutador de suplantación finaliza la conexión TCP localmente y traduce el TCP a protocolos adaptados a los largos retardos en el enlace satelital, como XTP .

SAP y RIP transmiten periódicamente información de red, incluso si las tablas de enrutamiento/servicio no se modifican. Por lo tanto, los enlaces WAN bajo demanda en redes IPX nunca se inactivan y no se desconectan. Un enrutador o módem malicioso interceptará las transmisiones de SAP y RIP y retransmitirá los anuncios desde su propia tabla de enrutamiento/servicio, la cual solo actualiza cuando el enlace está activo por otros motivos.