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 ***