El LAT

      4441

Autor: Lagarto

 oAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAo
 A   11    - EL LAT -                                                    A
 A                                                                       A
 oAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAo



        Definici¢n del Protocolo Local Area Transport de
        Digital Equipment Corporation.

        Por Lagarto (lagarto@hotmail.com)
        15 de Enero de 1995.  Versi¢n 1.0

                                   ®This time we R gonna ScrEw' eM AlL¯


        0.- INTRODU€AO

        š Qui‚n dice que el hackin' se para en los sistemas abiertos ?
     š Es que todo se va a quedar en UNIX y TCP/IP ?   š No est n dema-
     siado orondos con sus vaxen, ibms y dem s ?   š Es que se va a parar
     la noria loca sin tocar lo que ellos piensan que es intocable ?


        1.- DISCLAIMER (QUE QUEDA BONITO).

        La info recopilada en ‚ste dok proviene del curre de medio mega
     de paquetes de mierda intentando buscar una visi¢n general de lo
     que es el protocolo, y no est  afanada de ning£n libro autorizado,
     as¡ que casi fijo que tiene alg£n gazapillo o le faltan datos, pero
     para lo que pretende ;-) pueda valer baxtante bien.   Por supuesto
     £sese para hacer el mayor da€o posible, que a mi me la suda.


        2.- š QUE ES, PA QUE VALE, POR QUE ES IMPORTANTE ?

        Local Area Transport (LAT) o Transporte en Area Local es un
     protocolo de comunicaciones que usan los trastos de DEC (Digital
     Equipment Corporation) para hablarse entre ellos.   Digo yo que
     andar  en la capa de transporte de datos de la pila de protocolos
     ISO-OSI para redes, y es importante porque define el formato de
     los paquetes que circulan palante y patr s.   (got this?)


        3.- OBJETIVO.

        Se asume para empezar que el hardware de la comunicaci¢n es
     de tipo Ethernet.   Pues bien:  Por un lado tengo lo que me su-
     ministra Ethernet, osea paquetes.   Pones en el paquete una di-
     recci¢n de destino (de tipo Ethernet), unos datos, y la tarjeta
     a€ade un checksum y el resto de la ferreter¡a se encarga de que
     llegue al destinatario.   Por el otro lado (en plan m s abstrac-
     to) tengo una tarea en un nodo que dice que quiere establecar
     una comunicaci¢n bidireccional con otra tarea de otro nodo,
     para mandar y recibir datos como le salga de los pies (muchos
     o pocos, y en el momento que quiera) y que adem s no se f¡a un
     pelo de las ethernets (que luego se pierden paquetes o llegan
     desordenados) y necesita que se le garantice que los datos
     circulan de guay.   Es lo mismo que los sockets en Unix.

        Para hacer esto un pollo algo neur¢tico y esquizofr‚nico
     trabajando dos semanas a pan y agua en una mazmorra de DEC
     se inventa un protocolo que es lo que aqu¡ se trata de describir.


        4.- TERMINOLOGIA (LAS PALABRUCAS).

        De repente un nodo toma la iniciativa y empieza una conexi¢n.
     Pues lo bautizo como originario, y al que se conecta lo llamo des-
     tino.   Para la transferencia de los datos se usa un *canal* de
     datos, que conecta un *puerto* de la m quina originaria y otro
     en la de destino.   Lo que pasa es que ese canal puede llevar
     los datos de varias conexiones simult neamente.   Por ello la
     conexi¢n tiene que establecerse no entre puertos, sino entre
     *sockets* de cada puerto.   Entonces se tiene que una conexi¢n
     viene individualizada por dos m quinas, la originaria y la de des-
     tino, dos puertos que establecen el canal, y dos sockets que iden-
     tifican qu‚ conexi¢n concreta de las varias posibles circula
     por el susodicho canal.


        5.- POR QUE LA PARANOIA DE LOS SOCKETS:  LOS PAQUETES SEMIVACIOS.

        Imaginemos dos m quinas, en las que mil pollos de la primera se
     conectan a la segunda para entrar en su cuenta por ejemplo.   Cada
     vez que un pollo pulsa una tecla se genera un paquete que tiene dos
     docenas y pico de bytes de cabecera y que tiene que ser de 60 bytes
     como m¡nimo (milongas de Ethernet).   Parece que se desaprovecha
     bastante y que se aprovechar¡a m s la red metiendo las letras de va-
     rios pollos distintos en el mismo paquete.   Esto es lo que se hace
     en LAT.   Entre las dos m quinas esas se establece un canal y en
     cada paquete circulan datos de varias conexiones simult neamente.
     Hay una cabecera est tica para los datos del canal, y luego por ah¡
     tiradas cachos de datos de distintas conexiones asociados cada uno
     con los sockets respectivos de cada conexi¢n.


        6.- DIRECCIONAMIENTO, USEA ADDRESSING.

        En vez de usar un direccionamiento espec¡fico como se hace en
     el protocolo IP, se utiliza directamente el direccionamiento de
     Ethernet sin m s.   Por tanto cada nodo debe conocer la direc-
     ci¢n de Ethernet del destino para establecer la conexi¢n.   Que
     yo sepa no hay protocolo para la "resoluci¢n de direcciones" equi-
     valente al ARP que acompa€a a IP.

        En el caso concreto de que los nodos pertenezcan a una red DECNET
     (que pienso de que usa LAT para el transporte de los datos) la di-
     recci¢n de Ethernet es una direcci¢n l¢gica que tiene el siguiente
     formato:

        AA:00:04:00:XX:YY

        El AA:00:04 corresponde a una direcci¢n l¢gica de DECNET, el 0
     est  por narices, y con el XX:YY se compone una direcci¢n de DEC-
     NET as¡n: Se swapean los bytes, quedando YYXX.  Tomando los 6 bits
     m s significativos se obtiene el n£mero de  rea, y con el resto
     el n£mero de nodo.   Por ejemplo 69:EC corresponde a 59.105.   En
     el formato de un £nico n£mero se multiplica el n£mero de  rea por
     1024 y se le suma el n£mero de nodo.


        7.- EL FORMATO DE LOS PAQUETES.

        M s o menos ya se ha visto una panor mica del asunto, osea que
     vamos al meollo, a concretar.

        Por orden, los paquetes empiezan con una cabecera cl sica de
     Ethernet, una cabecera de los datos del canal, y luego para cada
     conexi¢n una cabecera de conexi¢n y los propios datos que se
     transmiten.

        En lo sucesivo, para hablar de un byte determinado dentro de
     un paquete usar‚ su desplazamiento usea "offset", de modo que
     el primer byte es el 0 y as¡ sucesivamente.   Vease la axiom -
     tica estandard Peano para m s info.


        7.1.- LA CABECERA DE ETHERNET.

        Es una cabecera t¡pica Ethernet II con los siguientes campos:

       ÚÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
       Aoffset A Contenido                                A
       Ã=======Å==========================================Ž
       A  0    A Direcci¢n de Ethernet del destino.       A
       ÃÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄŽ
       A  6    A Direcci¢n de Ethernet del origen.        A
       ÃÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄŽ
       A  12   A Tipo del paquete.                        A
       AÄÄÄÄÄÄÄAÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ

        En este caso el tipo del paquete es el 6004h (DEC LAT) en orden
     de red, usea el 60h en el offset 12.


        7.2.- LA CABECERA DE DATOS DEL CANAL.

       ÚÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
       Aoffset A Contenido               A
       Ã=======Å=========================Ž
       A  14   A Flags                   A
       ÃÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄŽ
       A  15   A N£mero de conexiones    A
       ÃÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄŽ
       A  16   A Puerto de destino       A
       ÃÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄŽ
       A  18   A Puerto de or¡gen        A
       ÃÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄŽ
       A  20   A S1                      A
       ÃÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄŽ
       A  21   A S2                      A
       AÄÄÄÄÄÄÄAÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ

        Los Flags son los siguientes:

       ÚÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
       A  bit  A Contenido    A
       Ã=======Å==============Ž
       A   0   A Flag loco    A
       ÃÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄŽ
       A   1   A Sentido      A
       ÃÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄŽ
       A   2   A Inicio       A
       ÃÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄŽ
       A   3   A Fin          A
       AÄÄÄÄÄÄÄAÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ

        El bit 0 es el menos significativo.   El flag loco equivale a la
     condici¢n "el paquete va del destino al origen y el n£mero de co-
     nexiones es distinto de cero".   El de sentido vale uno si el paquete
     va del nodo originario al de destino, el de inicio se pone a uno
     cuando es el primer paquete de la conexi¢n, y el de fin cuando es
     el £ltimo (en cada sentido).

        El n£mero de conexiones indica cu ntos fragmentos de conexio-
     nes distintas van en ese paquete.   De los puertos hay que acla-
     rar que las palabras "origen y destino" se refieren al punto de
     vista de la m quina remitente del paquete.

        S1 y S2 est n relacionados con la sincronizaci¢n de
     la conexi¢n, el orden en el que van los paquetes dentro de la
     conexi¢n y el acuse de recibo de los paquetes enviados por el
     otro, pero pas‚ de currar c¢mo eran.


        7.3.- EL FORMATO DE LAS CONEXIONES.

        A cada conexi¢n le corresponde un par de bloques: la cabecera y
     los datos en s¡.

        La cabecera son tres bytes que van como sigue:

           ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
           A  socket de destino     A
           ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄŽ
           A  socket de or¡gen      A
           ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄŽ
           A  longitud de datos     A
           AÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ

        La "logitud de datos" es cu ntos bytes tiene el bloque de datos
     que se transmite en el paquete para esa conexi¢n.


        7.4.- EL PROBLEMA DEL ALINEAMIENTO.

        Muy bien, ya se c¢mo van las conexiones, pero ahora lo que tengo
     es un pegote de bloques de bytes de cabeceras y datos.   š En qu‚
     offset van ?   Parecer¡a que lo m s l¢gico es que fuera primero la
     cabecera del canal, justo despu‚s la cabecera de la primera co-
     nexi¢n, sus datos, la cabecera de la segunda, etc.   De hecho van
     en ese orden, lo que pasa es que esos bloques no van apelmazados
     sino que de vez en cuando hay alg£n espacio que otro que no se usa.
     š C¢mo se determina el tema de los espacios ?

        La £nica regla que logr‚ encontrar es la del "alineamiento" que
     parece un dexfase impresionante.   Esta regla viene a decir que
     tanto los bloques de las cabeceras de las conexiones como los de
     datos tienen que estar alineados pares dentro del paquete, lo que
     quiere decir que el primer byte de cada uno debe tener un offset
     par dentro del paquete.

        Por ejemplo, si tengo que mandar en un mismo paquete dos co-
     nexiones, la primera de 5 bytes y la segunda de 2 la cosa ir¡a
     as¡:  Hasta el offset 21 inclusive, la cabecera de Ethernet y
     la del canal.  Luego la de la primera conexi¢n:  El siguiente
     offset disponible es el 22, que como es par, ya me sirve y pon-
     go los tres bytes ah¡.   Luego tengo que poner los datos.   El
     siguiente offset no utilizado es el 25.   No me sirve por ser
     impar, as¡ que incremento uno y pongo los datos en el 26.   Plan-
     to los 5 bytes de datos.   Tengo que poner la cabecera de la se-
     gunda conexi¢n, pero el siguiente byte libre es el 31.   Incre-
     mento y tentetieso, planto la cabecera, y para los datos ya es-
     toy en el 35, no me sirve, incremento, pongo datos...  Si por
     ejemplo la longitud de los datos es par, la siguiente cabecera
     ya entra en direcci¢n par y puede ir pegada sin intersticios
     raros š Me explico ? (vaya braxa).


        8.- ESTABLECIMIENTO DE UNA CONEXION.

        Dado que tanto los n£meros de puerto como los de socket son en
     principio aleatorios se plantea el problema de su asignaci¢n que
     se resuelve con un sencillo protocolo:

        Tenemos una m quina O que es la m quina originaria y otra D
     que es la de destino.   Para iniciar la conexi¢n O manda a D
     un paquete con el flag de inicio en el que se incluye como puer-
     to de or¡gen el puerto asociado a O.   Cuando D recibe ese pa-
     quete, manda otro de respuesta (tambi‚n con el flag de inicio)
     en el que como puerto de destino figure el asociado a O y de ori-
     gen el suyo propio.   En este momento O y D ya saben qu‚ puerto
     es el del otro.

        Entonces O manda un paquete con una conexi¢n en la que pone
     su socket como socket de inicio, a lo que D responde con otro
     paquete con otra conexi¢n teniendo como socket de inicio el de
     D y de destino el de O.   Al recibir O el paquete, los dos no-
     dos han establecido todos los par metros de la conexi¢n.

        En resumen:

        Paquete         Info v lida
        -------         -----------
        1§ O->D         Puerto de O
        2§ D->O         Puerto de O y D
        3§ O->D         Puertos de O y D y socket de O
        4§ D->O         Puertos de O y D y sockets de O y D


        9.- PUNTOS OSCUROS

           š Qu‚ falta ?  Pues: S1 y S2 no parece chungo, pero hacen
        falta paquetes con la red muy cargada y adem s que no se pier-
        dan, el routing, que no se si va inclu¡do en el protocolo, muy
        chungo de ver, saber qu‚ demonios es la direcci¢n l¢gica
        9:0:2B:0:0:F a la que llegan paquetes muy extra€os, y por £l-
        timo, curiosidad morbosa, š No hab¡a una especie de byte de
        checksum al final del paquete ?


        10.- CONTRIBU€AOS Y ROLLOS FINALES

           - X1 realiz¢ el programa con el que se cachaban los
        paquetes y entre los dos los pillamos.   Adem s cach¢ el ma-
        peo direcci¢n Ethernet -> direcci¢n DECNET.

           - X2 fue el que vio el rollo de las m£ltiples conexio-
        nes en un mismo paquete (tela marinera).

        Seg£n mis noticias todav¡a no existe un esniffer para estas
        cuestiones. Yo tengo uno a medio hacer, pero en la fase de
        debugeo un rayo chamusc¢ el servidor de terminales de donde
        sacaba mis packets y se jodi¢ el tema. Si alguien quiere co-
        laborar que mande un mail (braxas abstenerse).

        Me despido con unos lyrics de Siniestro:

         Todo por la napia 
                 snif  snif 
                         TODO POR LA NARIZ !!! 



                              *** THE END ***