TEMA 1 - PROTOCOLOS D E TRANSPORTE 1.1.

Introduccin El objetivo de es te captulo es conocer qu funci onalidades y servi ci os incl uye la capa de trans porte y cules s on los protocol os ms utilizados. Los servicios ofreci dos son (comuni ca ci ones extremo a extrem o, end to end): - Orienta do a conexin - Mul tiplexa cin/dem ul tipl exaci n (concepto de puerto) de aplica ciones . - Control de errores: i ncluido en la ca pa de trans porte debi do a la na turaleza bes t effort de IP. - Control de flujo (a ni v de transporte y a pli cacin). el - Control de congestin: se pretende li bera r de es ta tarea al ni vel de apli cacin. Estudia remos los protocoles de TCP (ori enta do a conexin y fiable), UD P (NO orientado a conexin y no fiable), STCP y RTP. Los objetiv os fundamentales de las com unicaciones extrem o a extrem o son: El problema es la conges ti n es ina borda ble (pto a pto). La i ntegri dad "pto a pto" no ga rantiza la fia bilidad extrem o a extremo. Sim plificar el CORE de la red: TCP/IP pretender concentra r la compleji dad en los extremos.

Donde

fuera de orden. En este caso, el TSN no es vli do. Simila r a datos urgentes en TCP. Ejemplo de transferencia de datos con m ux-dem ux de stream s y Confirmaci ones (ges tin)

Sin embargo, pueden a parecer ambigedades en la medida del R TT: y Tras una prdida de ACK, se a gota el timeout del emisor; se transmite el paquete y me llega el ACK al poco tiem po despus . Es te ACK, es una versi n reta rda da del primer ACK, o una retra nsmisin del ACK por prdida ? Cunto es el RTT medi do, el tiem po de TIMEOUT ms el tiempo que ha tardado en llegar el ACK desde la retransmisin, o el tiem po que ha pasado des de que mande la retransmisin del paquete?

Utili za confi rma ciones a cumula tivas y selecti vas . U n trozo ACK puede confirmar todos (o vari os) de l os s treams de la asocia cin.

Esquem a de ACK selecti vo En el di bujo de a rri ba vem os como se confi rma has ta el 37, y l as partes a confi rmar s electi vamente se especi fi ca n con offsets de principi o y fin res pecto del 37. El formato del ACK de SCTP queda representado: Incluye la posibilidad de indi car qu ACKs s e envan por duplicado. As se evita la ambi gedad que tenamos en TCP para es timar el RTT Cada vez que se enva un ACK el contador de duplicados se res etea . y Mul tihomi ng Una enti dad SCTP con ms de una IP se denomina mul tihoming. INIT expresa todas las direcciones IP o el hos tname que se usa en el origen. INIT ACK puede i ncl uir ms de una IP o hos tname.

Hay va rias soluciones: NO actualizar el RTTnuevo para los ACK am biguos, o cua ndo hay am bigedad, actualiza r el TIMEOUT como sigue:

congestin, pero no es til en todos los casos; o 3 ACKs duplicados consecutivos. El control en TCP consiste en variar la CongWin. Lo deseable es que sea tan grande como s ea posible pero sin agotar los recursos. Bsicamente el control de congestin en TCP consiste en una variante de AIMD basada en ventanas con notificacin implcita en el que los timeouts (o 3 ACKs consecutivos) s iempre son interpretados como perdidas: Multiplicative Decrease reducir CongWing a 1M SS (M aximum Segment Siz e) al detectar una perdida. Aditive Increase s e aumenta la ventana mientras no haya perdidas (ensayo-error) Podemos distinguir dos regiones de comportamiento: inicio lento y Pre vencion de la congestin. 1.) conexin y CongWin=1M SS, dado que el ancho de banda disponible suele ser mucho mayor que M SS/RT podemos aumentar rpidamente el tamao de CongWin (podemos aumentarlo de forma exponencial hasta un tamao dado doblando CongW in cada RTT un M SS por cada ACK recibido En el modo de prevencin de la congestin esta zona es la realmente A ditive Increas e, para no generar problemas a partir de un cierto umbral CongWin crece linealmente (1M SS por cada RTT a lo sumo) CongWing=CongWin+MSS *MSS/CongWin (equivale a crecer en 1M SS cuando se reciben todos los ACK s pendientes). Debemos determinar hasta cuando crece CongWin, hasta que se produce un timeout que entonces consideramos que existe congestin severa, entonces CongWin se reduce a 1M SS y posteriormente se continua creciendo exponencialmente con el InicioLento CongWin=1MSS ; Umbral=C ongWin/2 O hasta que s e reciben 3 ACK s duplicados consecutivos, lo cual es menos alarmante que el timeout, se denomina fast retransm it y se retransmite sin esperar al time out, CongWin se reduce y posteriormente existe una variante que infla la ventana para reflejar que hay 3 segm entos que abandonan la red fas t recover y CongWin=Umbral; Umbral=CongWin/2 En el emisor por tanto s e emplean dos ventanas y un umbral: BytesPermitidos En viar=min{CongWin,VentanaDelReceptor}; la ventana del receptor es utilizada para el control de flujo (s egn el campo ventana). 7. M ODELADO DE TCP TCP est obsoleto, ignorando el inicio lento (que en general dura poco) y asumiendo que las prdidas son detectadas por 3 A CK s consecutivos simplificacin W= tamao de la ventana cuando ocurre una perdida throughput=W/RTT, a continuacin tras la prdida el tamao de la ventana se reduce a la mitad, por tanto cual sera el throughput medio? Vara en funcin del tamao de la ventana? si expresamos throughput (S) en trminos del loss rate(p) Para poder modelar correctamente TCP es necesario aceptar una serie de simplificaciones como que no hay inicio lento, no hay perdidas en las confirmaciones y no existe compresin de cabeceras. Hay dos procesos que s on fundam entales: la dinmica de la ventana de congestin que impone un lmite y la prdida de paquetes que indica congestin. A dems s e supone estacionariedad, es decir, cuando hay una perdida el tamao de la ventana es W y las prdidas de paquetes se dan con probabilidad p constante. En m edia (1/p)-1 paquetes entre dos perdidas consecutivas. 1.)M odelo peridico: el numer de paquetes enviados en cada periodo T es 1/P y est relacionado con el rea de la curva en un periodo #paquetes=(T/(2*RTT))*(W/2+W)=1/p En la zona de prevencin de la congestin la ventana crece 1M SS cada RTT T=RTT*W/2 W=sqrt(8/3p), por tanto la velocidad de transmisin para la fuente T CP sera: 2.)M odelo ms realista y preciso de las perdidas incluye perdidas por timeout (T out_new=2*T out_old) y si se considera la limitacin impuesta por la ventana del receptor (Wm) 3.)M odelado del retardo: la latencia es el tiempo transcurrido desde que una aplicacin solicita un objeto hasta que es recibida completamente. Vamos a suponer una transmisin en la que no hay prdidas por congestin ni retransmis in por errores. Las cabeceras de los protocolos son despreciables y el tamao del objeto es un nmero entero de M SS y adems todos los segm entos TCP que no sean de datos tienen un tiempo de transmisin despreciable Ttrans<<Tprop. Por ltimo indicar que no s e llega a entrar en la zona de prevencin de la congestin. Si suponemos CongWin=W, M SS esttica y RTT constante: Si WS /R > RTT + S/R: ACK vuelve antes de que la ventana se cierre. No para de transmitir hasta que se enva todo el objeto. delay = 2RTT + O /R Por el contrario si tenemos WS /R < RTT + S /R: la ventana s e cierra antes de que vuelva el prim er ACK. delay = 2RTT + O/R+ (K-1)[S /R + RTT - WS /R] Cuando llega el 1er ACK le siguen (W-1) A CKs separados S/R segundos. Dado que la ventana se va abriendo y cerrando existen por tanto periodos de transmisin (W segm entos) y periodos de parada (S/R+RTTWS/R). Si K=O/(WS) (o s u redondeo entero) es #ventanas Si suponemos ahora una CongWin=W, #M SS dinmica con inicio lento y RTT=cte, nos queda que la latencia estara compuesta por 3 trminos: (2RTT para sincronizacin y solicitud de objeto, O/R para transmitir el objeto, paradas del s ervidor debido al arranque lento primera ventana=S /R segunda ventana=2S /R tercera ventana=4S /R P=min{k-1,Q }(k=numero de ventanas que cubren el objeto, Q=numero paradas) Tiempo desde que se enva un s egmento hasta que s e recibe el ACK= S/R + RTT Tiempo en transmitir la k-esima ventana = 2^(k-1) * S/R Tiempo de parada: S/R + RTT - 2^(k-1) * S/R latencia en zona de crecimiento lento. K=log2(O/S+1); Q=log2(1+RTT/(S /R)) + 1 En resumen tenemos que el inicio lento puede incrementar significativamente la latencia: si el objeto es grande y el RTT moderado con R alto si el objeto es pequeo y el RTT moderado no es tan severo si el objeto es pequeo y el RTT relativamente grande afecta incluso con un rate bajo. 8.G EST ION ACTIVA DE CO LA S (RANDOM EARLY DETECT ION) El control de congestin tiene por objetivo reducir la ocupacin de las colas en los buffers, de tal forma que tengamos un menor tiempo de espera. La ocupacin crece cuando la razn de llegadas excede la razn con la que el planificador extrae paquetes de la cola hacia la lnea de salida. Para reducir la ocupacin s e disparan los procedimientos de control de congestin a nivel de transporte sobre los flujos de la cola. Importante saber cuanto esperamos para activar dichos procedimientos: muy pronto pobre utilizacin de la lnea de salida muy tarde posibles perdidas por congestin La solucin es una respuesta probabilstica 1.)Deteccin temprana aleatoria la probabilidad de disparo es una funcin creciente de la ocupacin de la cola. La ocupacin media se calcula con la llegada de cada paquete y puede haber valores distintos por cada cola: Descartar paquetes sirve cuando los flujos que provocan la congestion son TCP. Para UDP no afecta. Los paquetes descartados son aquellos que pertenecer al buffer problemtico. M ientras el buffer tenga una determinada ocupacin la probabilidad de accionar el disparado es 0. 2.)Detecin temprana aleatoria pesada Se elige la funcin de disparo adems del paquete por otros parmetros adicionales (x.ej se us a una estrategia ms agresiva con paquetes marcados previamente). Se puede emplear los bits de prioridad (T oS) para definir la funcin de disparo 3.)D eteccin temprana aleatoria adaptable (A-RED) para ajustar los parmetros de forma ptima escogemos un mecanismo adaptable. Wq fija la rapidez con la que estimamos la ocupacin de la cola. Dado que des cartar un paquete es perder efectividad, podemos ajustar tambin un maxP segn la derivada de Qavg. Nos ajustamos asi a la cantidad de flujo variable s in tener un conocimiento explicito de su numero. 9.OTROS PROCED IMIENTO S PARA EL CC. TCP-FRIENDLY. Superponemos a UD P procedimientos que permitan la coexistencia de ambos trficos. Se puede emplear algoritmos de control de congestion (Equation-Bas ed-Congestion Control) que generan un rate por debajo de lo que lo hara TCP Conociendo p, RTT , y T out se regula la tasa de envio p lo calcula el receptor y lo enva al transmisior RTT se calcula en el em isor Tout=4*RTT 2.)

monitorizamos?cuntos recursos reservamos? Todo esto depender del tipo de trfico al que pe rtene zca el flujo: Perfiles con bit-rate c onstante, se monitoriza la VP; Perfiles con bit-rate variable y sin limitacin de VP, se monitoriza VM y D MR ; Perfiles con bit-rate varia ble con limitacin en la VP, se monitoriza VP, VM y DMR . Cmo se monitoriza si un flujo tiene su VP acotada? Se utiliza la m etfora del Cub o de agua. Para medir la velocidad de pico, idealmente el cubo tendra que tener un tam ao 0 (as, en cuando se pase de la velocidad de escape, igual a VP, el cubo se desborda y el tr fico no cumple los requis itos iniciales). En la realidad, el cubo tiene un tam ao muy pequeo (1 o 2 paquetes) para amortiguar las pequeas variaciones temporales asociadas al procesado de los paquetes por parte del SO. Si se recibe un paquete que desborda el cubo, se considera com o no cumplidor, y se marca o recha za. Cmo m onitorizar si un flujo tiene una velocidad media acotada pero hay rfagas de un tam ao dado? Se utiliza el Cub o de tokens. Se generan tokens a una velocidad de VM tokens/s. El cubo tiene un tamao de b tokens, siendo b=D MR. El trfico supera el test si ningn paquete llega cuando el cubo est vaco de tokens. Enviar un paquete consume un token del cubo. Este perfil permite enviar un mximo de paquetes en un tiempo t de rt+b .

En el modelo de IntServ se definen 2 clases de servicios: a) Servicio de C alidad Garantizada: Indicado para aplicaciones en R T. Se necesita acotar el reardo m ximo extrem o-extrem o (uso de tokenbucket (r,b)). Se necesita conocer las caractersticas del trfico y utilizar control de admisin. El router debe supervisar el trfico generado por la fuente. El formato de los mensajes RSVP es el siguiente En realidad no se especifica el retardo, sino un margen o intervalo de confianza. Sabiendo los parmetros b, r, p, M, m, BW y nsaltos podem os acotar el delay. De ah que se especifique un margen de confianza (es lo que la red puede pasarse del delay a cotado). b) Servicio de Carga Controlada: Pone aplicaciones que puedan tolerar cierto retardo, pero sensibles a congestin (prdidas). Se pretende dar un servicio sim ilar al de una red best-effort sin cargas. Intenta especificar descripciones no cuantitati vas, sino cualitativas. Es un best-effort + control de admisin, por eso no requiere WFQ. No necesita especificar rate ni delay, slo el Tspec. Si se acepta la reserva significa que la red tiene recursos suficientes para acom odar el trfico sin congestin. Se admiten picos de retardo o prdidas, pero con la probabilidad suficientemente baja como para mantener un retardo medio razonable. Ahora , vamos a pasar a ver el pr otocolo. Se va a estudiar con cierto detenimiento dado que el modelo MPLS utiliza RSVP com o protocolo de sealizacin para reservar recu rsos. Algunas caractersticas genricas: La reserva de recursos es dinm ica (adaptati va), tanto para flujos unicast como multicast, esto se hace gracias a que el protocolo es soft-state (un protocolo es soft-state cuando el estado de entidades se mantiene mediante la repeticin de mensajes). 2 Es orientado al receptor, las reservas 3 se originan desde el receptor. Es sim plex. 4Opera sobre IPv4 e IPv6. Puede encapsularse sobre UDP ya que no todos los SO permiten encapsular RSVP sobre IP directamente. 5RsVP no especifica com o los routers deben reservar los recursos. 6RSVP o
1

donde es tads ti camente se ha comprobado que un buen valor para y Control de flujo:

TCP libera a la aplica ci n de es te cometi do. El esquema se basa en lo siguiente: El receptor es tima s u disponibilidad o capacidad (en Bytes) y s e la enva al emisor (dentro del propio segmento TCP, en el cam po ventana , a provecha ndo as el trfi co receptor emisor). As no se pueden enviar ms Bytes de los que puedan ser proces ados. As, segn la ventana til en el receptor, se cal cula la ventana til en el emisor como sigue: l  

1.2. UD P Las unida des de da tos del ni vel de transporte se llaman segmentos o datagramas de usuario. UD P ofrece un servi ci o best-eff ort , l o ni co que aade IP es la multiplexacin/dem ultiplexacin de aplicaciones; s e hace aadiendo en la cabecera UD P un puerto (enteros de 2 Bytes ) que identi fica qu apli caci n (origen y des ti no) va a utili zar IP. UDP coloca cabeceras a las a pli caci ones para identi fica r l os puntos finales de la comuni ca ci n mediante la asi gna cin de puertos . Algunas propiedades son: Servicio no orientado a conexin: no handshake (las apli ca ciones no precisa n de un i ni cio de sesin), por tanto no hay retardos de establecimiento. Servicio no fiable: puede haber prdidas. No hay garantas de entrega ordenada No hay control de congestin: fil osofa entrega tan rpido como puedas .

Cmo monitorizar los tres parm etros? Mediante el Cub o dual. Es el resultado de concatenar cubos para obtener un con trol ms refinado para un conte xto dado.

1.5. Protocolo de tiempo-real (RTP) Se utili za para aplica ciones con requisitos de tiempo real . Adems , incorpora informa ci n necesa ria (cabeceras ) pa ra afronta r problemas relaciones con el reta rdo, prdidas , etc. o Identifica el tipo de carga, numera cin de s ecuencias , ma rcas de tiempo, etc. RTP no es un protocol o de recuperacin RTP normalmente es usuario de UDP RTP opera en unicast y multicast. Facilita la interoperabilidad entre aplicaciones: un contenido mul timedia de una a pli caci n puede intercambiarse con otra a pli cacin, y que RTP i denti fi ca a el cdec. RTCP es un protocolo asocia do para monitorizar la QoS del receptor.

o o o o

De las cabeceras UDP mencionaremos el CHECKSUM (compl . a 1 de la s uma compl . a 1 de las palabras de 16 bi ts que conforman la cabecera ) se incl uyen la IP ori gen y destino, el campo PROTOCOLO y LONGITUD. Otras cosas desta ca bles de UD P: Hay puertos univers ales. UDP es til para aplicaciones multim edia, tolerante a fallos y m uy exi gentes en cuanto a reta rdos. UDP va montado sobre IP. La fiabilida d proporcionada por TCP ti ene un cos te. UD P se utiliza cuando di cho cos te no compensa para la na turaleza de la aplica cin. En general , UDP es recomendable en aplicaciones en tiempo real. Este es quema tiene un problema , conocido como el sndrome de la ventana tonta (si se utili zan segmentos m uy pequeos): cua ndo la dis parida d entre la tasa de genera cin de datos por pa rte del emisor y la ca paci dad de procesamiento por parte del receptor es m uy gra nde, se tiende a un esquema de Stop & Wait . En esta si tua cin, se mandan un montn de mini segmentos de 1 Byte, algo a todas luces muy ineficiente; es to puede s oluci ona rse es tableci endo un umbral: has ta que la venta na disponi ble no supere cierto tamao umbral (de Bytes recibi dos), se manda ventana no disponibl e . o

- Conformacin del trfico : Hemos visto mtodos de supervisin (mtodos pasivos) para etiquetar el trfico como cumplidor o no cumplidor. Ahora pretendemos suavizar, generar trfico con un determinado perfil. Ahora queremos mtodos o algoritmos activos que conformen el trfico a perfiles definidos. Simplemente se introduce buffering para elim inar el ritm o irregular de las fuentes de generacin de trfico . - Estrategias de planificacin (Scheduling): Tenem os el problema de compartir la lnea de salida de forma controlada, asignando los recursos disponibles entre las colas definidas. Por cada lnea de salida necesitamos de un planificador que decida a quin le toca. El algoritmo de un planificador QoS debe garantiza r/cumplir: C ompartir el BW, ser equitati vo (o no), garantiza r un BW m ximo y mnimo, garantizar un probabilidad de prdidas, garantizar retardo acotado y reducir el jitter. El primer esquema a estudiar es la estrategia FIFO (FC FS, First C ome FirstServed). Este esquema no es equitati vo, dado que si no ha y supervisin, una clase malintencionada puede monopolizar el recurso y producir bloqueos. Puede haber tratamiento diferencial si el gestor de la cola altera las probabilidades de rechazo (R ED ) para las distintas clases. A con tinuacin, vamos a ver una serie de esquemas conservativos, ya que siguen La ley de conser vacin: La suma de los retardos medios pesada por la utilizacin m edia de la lnea de salida es constante, sea cual sea el planificador. Intuitivamente, lo que nos viene a decir esta ley es que reducir el re tardo medio para una cola siempre va a ser a costa de otra. Adems, se dice que una estrategia es conservati va si slo entra en reposo cuando no hay paquetes esperando. Ahora , Cmo repartir un recurso entre usuarios con distintas demandas? Veamos el algoritmo Max-Min: Sea R el recurso a compartir, sean K contextos con dem andas X1<X2 <X3<X4<<XK; a) se garantiza que cada contexto recibe R/K. Em pezamos a servir por el conte xto que menos demanda; b) Si R /K > X1 , los K-1 contextos restantes se reparten el e xceso de forma equitati va, tal que :  Este algoritmo supone dos ventajas: Ma xim iza el m nimo que reciben los contextos cuyas demandas no son 2 satisfechas; y garanti za que lo recibido no es peor que lo recibido por otros. El sistema ideal para un router es el l amado GPS (General ProcessorSharing), en el que cada contexto se asigna a una cola diferente. El esquema GPS se describe como sigue: Se sirve una cantidad infinitesimal de cada cola, de forma que en cualquier intervalo finito cada una de las cosas se visita al menos una ve z; si est vaca , se salta a la siguiente. Esta estrategia es ideal, y por tanto irrealizable (por lo de los infinitsimos), y conseguira una comparticin max-min. No obstante, com o no es viable, vam os a ver otras estrategias ms reales. La estrategia siguiente es RR (Round Robin). Se basa en hacer un barrido cclico de las colas, sirviendo un paquete por turno, y saltndose la cola si est vaca. Es equitati vo? No, solamente lo es si la longitud de los paquetes es la mismas para todas las colas (Li = cte ). Ven taja: aisla de flujos malintencionados. Sin embargo, Cmo hacer un RR no-equitativo? Depende de Li: a) Si Li=cte, se normalizan los pesos y se sirve un nmero de paquetes variable para cada cola (sto es WR R); b) Si Li cte, se norm aliza los pesos considerando (Problema: hay una suposicin muy fuerte, que es que no se puede conocer . Por otro lado, tenemos Dficit Round Robin, que mejora a WRR sin necesidad de conocer a priori. N ecesita 2 variables: Dficit (D), cada cola va contando lo que el planificador le debe; Quantum (Q) cantidad que se sirve en cada round. Por ltimo, queda describir FairQueueing (Colas equitati vas). Se trata de una aproximacin de GPS sin suposiciones de tamao infinitesim al. No requiere conocimiento a priori de , y es pa ra paque tes de longitud variable. El proceso es el siguiente: Tenemos una cola para cada clase; a cada paquete recibido lo etiqueto con un nmero F (Finishnumber) que es el n de rounds que necesitara GPS para servirlo; cada ve z que ha y que en viar un paquete, se enva el de m enor etiqueta. La etiquetacin se hace de la siguiente forma: sea R(t) el n de rounds que GPS ha dado en el instante t, diremos que una cola est acti va si la m ayor de las etiquetas es mayor a R (t) (acti va max{Fi}>R (t)). Entonces el paquete K que llega a la cola i en el instante t ser e tiquetado tal que as:        Notar que P(i,k,t) es lo que tardara GPS en servir tal paquete. -QoS garantizada: En este caso hablamos de FairQueueing ponderado, lo que se denomina WFQ (WeightedFairQueue ing). Las etiquetas en este caso seran:  En una nica e xpresin:  Este esquema garantiza en el peor de los casos (todas colas acti vas) un ancho de banda por flujo igual a:         
1

Terminologa RTP o Sesin: es una asociaci n esta bleci da entre un grupo de usuari os comuni cndose con RTP. Puede ser uni cas t o mul ti cast, en este caso se identifi ca mediante una di recci n IP mul ticast (des tino) y 2 puertos UDP del des tino. SSRC, 32 bi ts que i denti fi can a una fuente del s tream RTP. Hay dos tipos de retransmisores (proxies): Mezcladores: recibe paquetes RTP (de una o ms fuentes). Opci onalmente cam bia el forma to y combi na l os paquetes , reenvindolos . Se modi fica el SSRC. Traductores: retra nsmi te paquetes RTP dejando i nta cto el SSRC. Peridi camente se difunde en el puerto RTCP un informe con los paquetes RTP recibidos a l os partici pantes en la conferencia .

1.3. Protocolo TCP Se trata de un servi cio extrem o a extremo orientado a conexin. Se ga rantiza la entrega de los paquetes a ni vel de a pli caci n de forma ordenada . El servi ci o oferta do es "full duplex" e implementa esquemas de deteccin y recuperacin de errores (servi cio fiable en ARQ, ACK+, y timeouts ada ptabl es), as com o control de flujo y congestin (venta nas deslizantes con piggyba cking). Fiable: im plementa un esquem a de deteccin (ARQ + ACK posi tivos + timeout) debido a que la probabilidad de error es ba ja. Adaptable: las ventanas deslizantes y timeouts s on a dapta bles para permi ti r flexibili dad segn el entorno.

1.3.4. Extensiones TCP Vam os a ver algunas opciones a a didas (campo Opciones del segmento TCP) que a umentan las funcionalida des TCP: 1) El campo ventana del s egmento TCP ti ene 16 bi ts, por lo que la mayor ventana posible es de  , al go a todas l uces escaso con las tecnologas GIGABIT actuales . Esto se llama ventana escalada : s e aaden 14 bits en la opcin, permi tiendo entonces has ta  m ximo de ventana. Para llev r a cabo m ejores estima ciones del RTT, hay a una opci n de sello de tiem po en todos los segmentos . Tam bin es t la opci n de PAW S, que permite rechazar segmentos duplicados, que tendrn el mismo n de secuencia , pero distinta marca de tiem po. 1.4. SCTP, Protocolo de transm isin para el control de stream Es una al ternati va ms a ctual a TCP como protocol o de trans porte (no es un protocolo extendido gl obalmente). Es ms complejo que TCP, aunque compa rte muchas cara cters ti cas con TCP: servici o extremo a extrem o (no mul ticast), orientado a conexi n y que ga ranti za la entrega ordenada de s egmentos . Di fiere li geramente en el sis tema de recupera ci n de fallos : utili za un esquem a ARQ con ACKs+ (acumula ti vos ), timeouts adaptables, pero incl uye opcionalmente repeticin selectiva . Se trata adems de un servicio fiable: SCTP se encarga del control de conges ti n y de fl ujo con ventanas desli zantes de tamao mximo ada pta ble. El cam bio/mejora ms importa nte que introduce SCTP es el siguiente: mientras que TCP necesita una conexin por cada flujo de da tos , SCTP permite gestionar mltiples streams en un solo paquete. Se trata de defini r una especie de macrotubera . Adems , requiere un nivel de direcci onamiento extra : hay que identi fi car el s tream . Tam bin i ncluye la posibili dad de multihoming : s i emis or y/o receptor disponen de ms de una direccin IP puede enviarse una misma secuencia de pa quetes por las dis ti ntas IPs (dis tintas IPs origen/des tino pa ra un mismo flujo de transporte). Por l timo, i ncluye como novedad cara cters ti cas de seguri dad que lo protegen de ataque de denegacin de servicio. y Forma to o o o

2)

Algunos campos de la trama TCP le permiten ofrecer ciertas funci onali dades : Mux-dem ux de aplicaciones : igual que UDP con el concepto de puerto. Control de conexin: establecimiento y cierre. Necesa rio por la na turaleza orientada a conexin. Control de errores y de flujo: con l os nmeros de secuencia /confi rma cin y el campo comproba ci n . Control de congestin.

3)

Adems: y y

Las conexi ones comienzan a numerarse a pa rti r de un nm ero aleatorio (ISN). El campo UAPRSF es una secuencia de flags . Son bits de control pa ra sealiza ci n: Urgent: envo de informa cin no ordena da . Es to es til en el siguiente escena rio: Cuando en un sistem a operativo se manda un com ando prioritario: por ejemplo, usamos Telnet para utilizar un term inal rem oto cuya aplicacin est bl oqueada y querem os cancelar o cerrar la aplicacin (Ctrl+C), este comando deber saltarse el orden, ya que la aplicacin bloqueada no coger sus segmentos del buffer. ACK: i ndi ca que se est haciendo piggybacking (confi rmaci n). Pus h: para vaciar el buffer rem ot o entre TCP y l a aplica cin. Reset: para cancela r/resetea r una conexi n. Synchroniz ed: pa ra el establecim iento de la conexin. FIN: Se soli ci ta la liberacin de recurs os (ci erre de conexi n). Control de flujo: el campo ventana del receptor informa al origen del tam ao de ventana de que dispone el destino, o permi te al desti no adapta r s u entorno y controlar el flujo de tr fico entra nte. Com probacin (com o en IP): com pl . a 1 de la suma compl . a 1 de las palabras de 16 bi ts que conforman el segmento completo (no solo la cabecera como en IP).

SCTP va m ontado tambin sobre IP. El forma to de los mensa jes se mues tra en la fi gura. Cabe desta ca r: Ahora la conexi n se denomi na asociacin , ya que tenemos va ri os s treams. La mul tiplexa ci n de s treams s e lleva a cabo con el concepto de troz o. Cada troz o de datos pertenece a un s tream, pudiendo lleva r ms de un trozo del mismo s tream en el mismo pa quete (habr que numera rlos). El concepto de trozo tambin permi te una gra n flexibilidad en funcionali dades : cada trozo de funci onali dad/opcin permi te aadi r nuevas funciones . Los trozos de da tos y opci ones se dis tinguen por el tipo. Adems, los trozos pueden i r en el orden que sea . La i nforma ci n de la longi tud se extrae de IP (Crossla yer). El formato de los trozos depende del tipo de trozo: habr pa rmetros fi jos . Dispone de cabecera fija. y Funcionamiento de SCTP

1.3.1. (TRANSPARENCIAS).

Multiplexacin/desmultiplicacin

de

aplicaciones

Exis ten puertos preasi gnados con servi cios normaliza dos : 1.3.2. Control de la conexin y y Cliente: entida d TCP que solicita/inicia l a conexin. Servidor: enti dad que escucha o espera perma nentemente soli citudes de conexi n.

Com o es un servicio orientado a conexin, el funcionamiento consta de 3 fases: esta blecimiento, ges tin y cierre de la conexi n. Los mensa jes azules forma r el es tablecimiento de la conexin, los 4 si gui entes (morados y verdes) pertenecen a la ges ti n y los ltimos 3 (rojos ) se enca rga n del cierre. En el es tablecimi ento se utili za n l os mensa jes cooki es para i ntentar evitar un ataque de negacin de servicio. Na da ms reci bi r una soli citud, TCP reserva recursos para la conexi n; por ta nto, pa ra denega r un servi cio bas ta con env r ia mucha soli ci tudes a una misma enti dad TCP. SCTP intenta protegerse contra es to con las cookies . Se trata de mensajes que enva el servidor con inf ormacin de com probacin que se envian tras recibir una solicitud; hasta que no se recibe una res puesta a la cookie , no se reservan recurs os . La filos ofa que si gue es la sigui ente: si quieres a taca rme pa ra denega rm e el servici o, t vas a tener que ha cer mucho mas computo que yo . El esquema de es ta blecimiento de asociaci n l o hemos repres enta ndo a nteri ormente en el gr fi co de arriba , donde representados en azules es taba n las tramas pertenecientes a es ta etapa. El mensaje cookie es una funci n de la IPori gen e IPdes tino, puerto ori gen y des tino, etc. 

TEMA 2 Es un hecho que las aplicaciones reciben una respuesta variable, e IP es un protocolo best-effort que s e basa en la conmutacin de paquetes (store-andforw ard) salto a s alto tpicamente con una disciplina F IFO . A dems es un hecho que los recursos son limitados en buffer y ancho de banda. A causa de la congestin el usuario percibe un servicio de calidad inferior al esperado (con ms retardos debido a las colas y con posibles prdidas de paquetes). y U na posible solucin es el sobredimensionamiento de recursos (por ejemplo aumentar el ancho de banda que es econmico fcil de gestionar y previene ante la llegada de nuevos servicios y M ediante el CONTROL D E CONGEST ION tratamos de aprender a usar los recursos eficazmente. El objetivo es maxim izar el throughput minimizando las prdidas y los retardos. CAUSAS Y EFECTOS DE LA CONGEST IN: Con dos orgenes y dos destinos, un router con buffer infinito y BW=C en un escenario en el que no hay retrasmis iones el mximo trhoughput que conseguimos es C/2 y el retardo tiende a infinito con la congestin (Uno de los objetivos de diseo es mantener las colas pequeas. En un segundo escenario con un buffer finito y BW=R en una lnea en la que no hay errores y el emisor ret ransmite los paquetes perdidos por descarte en el buffer los efectos de la congestin dependern de cmo se realiz an las retransmis iones. El caso ideal es que el emisor solo enva cuando el buffer est libre Lin= Lout y habra que tener un timeout ideal de tal forma que solo s e retransmita cuando hay una prdida real. Si retransmitimos prematuramente los paquetes, para un Lout fijo neces itaremos un Lin m ayor. Es decir para conseguir un buen throughput hay que transmitir ms trafico del necesario. Las retransmis iones inneces arias provocan grandes retardos e implican una utilizacin peor. En un tercer escenario en el que tenemos varios emisores y un camino con varios saltos puede ocurrir que cuando un paquete es descartado todo el ancho de banda consumido en sa ltos anteriores es desperdiciado incluso ser 0. El problema es que hay demas iadas fuentes generando demasiado trfico para el dimens ionamiento de la red, se emplea el control de congestin para proteger la red Tenemos dos tipos de control de congestin: en bucle abierto y en bucle cerrado: En bucle abierto exige tener un conocimiento a priori de la red, y no es una tcnica adaptativa. No es eficaz a baja carga y requiere un control de admisin (sin realimentacin) En bucle cerrado existe realimentacin y tcnicas reactivas o adaptativas. La red puede notificar la existencia de problemas mediante notificacin implcita (inferido en el emisor por perdidas y retardo) o notificacin explicita (los routers envan informacin al origen). 2.T IPO S D E RESPU ESTA : M IM D, AIAD , MIMD , M IAD. Para solucionar un problema de congestin debemos ajustar el rate del trfico generado. Estando en bucle cerrado no sabemos que reajuste debemos realizar en el reate y queremos conseguir la m xima eficacia, sin oscilaciones y con imparcialidad. Podemos suponer una respuesta binaria F(t)={0,1}; 0 si NO hay congestin y 1 si hay. Suponemos una reaccin con un rate con evolucin temporal lineal donde A son las componentes aditivas y B las multiplicativas: El mejor es el caso A IM D, ya que cuando la cos a va bien crece aditivamente, mientras que cuando va mal disminuye multiplicativamente. Vamos a comparar ahora M IA D con AIMD : Cada eje representa un cliente de la red. Cada punto (x,y) repres enta el reparto de la carga de los clientes. La sumatoria de la carga del sistema no debe exceder unos ciertos lmites Efficiency Line La carga es la misma para todos los puntos que formen una lnea paralela a dicha lnea. Pretendemos s iempre que nuestro s istema se acerque lo mximo posible a esta lnea. Para que la carga consumida por el cliente 0 sea igual a la consumida por el cliente 1 los puntos deben encontrars e sobre la Fairness line. El punto ptimo por tanto es la interseccin entre eficiencia e imparcialidad. La tcnica AIMD lleva el sistema a la zona deseable: el rate de ambos clientes va convergiendo. Una alternativa seria emplear funciones no lineales o un feedback no binario. En internet (TCP) emplea una variante de AIMD . M IAD converge hacia la parcialidad y siempre premia a la fuente que de partida est mejor s ituada. Es importante que la frecuencia de actualizacin s ea igual a la frecuencia del sistema RTT0=2xRTT1 (caso ms realista de heterogeneidad). 3.CONTRO L DE CONG ESTIN BA SADO EN RATE O VENTANAS.

Dado que TCP (fiable) va m ontado sobre IP (no fiable), no es posible garantizar un establecim iento o cierre de la conexin fiable. Por ta nto, es necesario a rbi tra r un mecanismo o secuencia de mensajes pa ra es tablecer la conexi n (handshake a 3 bandas) (VER DIBUJO). Comentem os algo de l os nmeros de secuencia: El ISN (Ini tial Secuence Number) no es aleatorio, si no ms bien predecible: el est nda r recomienda que el ISN se proponga a pa rti r de un contador que s e incrementa en 1 ca da 4 us . De es ta ma nera, resul ta muy fcil averiguar el ISN de una conexin e i nterceptarla suplantando a al guno de los dos pa rti cipantes. y Cierre de conexin (liberacin de recurs os)

Esto se traduce en que tenemos un ancho de banda garantizado.Adems, si la fuente est conform ada por un cubo de tokens (r,b) y el conjunto de routers implementan un planificador WFQ, tendremos un delay acotado. Por tanto, si tenemos BW garantizado y un delay acotado, tendremos QoS garantiza do. Veamos como acotar el retardo extremo a extrem o. Sea b el tam ao del cubo de tokens en bytes, sea r la velocidad de generacin de tokens en bytes/s, el trfico mxim o de salida del conformador ser en el intervalo T: b+rT b ytes. Si Rj es la velocidad de transmisin de la lnea j, usando un conformador de trfico con un cubo de tokens y una estrategia de planificacin WeightedFairQueueing, tal que el peso para un flujo dado garantice que se pueden tener R bytes/s, el retardo extremo-extrem o D verifica:

Una entidad solicita el cierre, y l a otra res ponde con un ACK, con el fla g FIN a 1 o a 0. Si FIN=0, la conexin en el senti do invers o no finali za (quedan datos por enviar). Despus, para fi nalizar es ta conexin, es necesari o otro ha nds ha ke pa ra cerra rla (en TCP para cierre de conexin s e hace un handshake a 4 bandas). Como no hay ga rantas de que el ACK llegue al otro lado, se acti va un meca nismo de timeout , en el que se espera un tiempo igual a 2 MSL (Ma ximum Segment Lifetime); tra nscurri do este tiempo, la conexi n fi naliza (si se pierde el ACK, la otra entida d repi te el mensa je FIN antes de que pas e 2 MSL).

TEMA 3 R O. CALIDAD D E SERVICIO (QoS). Introduccin El problema a plantear es el siguiente: qu tengo que aadirle a Interne t para garanti zar cierta QoS requerida por ciertas aplicaciones? Definam os QoS: es un parmetro multidimensional que caracteriza lo que demanda la aplicacin y/o lo que ofrece la red. Principios de calidad de servicio en Internet: QoS El objetivo es aadir nuevos componentes arquitectnicos a Internet para aislar a las aplicaciones de los problemas relativos a la QoS. Veamos varios escenarios ejemplo: - Escenario 1: Una aplicacin telefnica de 1Mbps y una aplicacin FTP comparten un enlace de 1.5Mbps. Las rfagas FTP pueden saturar el router -> se descartan paquetes (audio perjudicado). Es deseable distinguir y priorizar el trfico de audio frente al de FTP. Necesitamos C LASIFIC AC IN y PLANIFIC AC IN. - Escenario 2: El escenario anterior, pero suponiendo que la aplicacin que requiera reserva de recursos incum ple su compromiso de 1Mbps -> perjuicio en exceso al trfico no prioritario. Es deseable tener una entidad que supervise esta situacin y acte si es necesario. Necesitamos SUPER VISIN. - Escenario 3: El mismo, pero suponiendo una supervisin estricta (asignar una fraccin del ancho de banda a cada flujo o cada clase, y no modificarla) -> uso ineficiente de los recursos si uno de los flujos no utiliza su ancho de banda. Necesidad de SUPERVISAR C ONSIDERANDO LA OPTIMIZACIN DE RECURSOS. -Escenario 4: El mismo escenario. Cuando la demanda de recursos es superior a lo disponible, qu se hace? Y si hay varias aplicaciones que requieren QoS y no hay re cursos para atenderlas simultneamente? Necesitamos CON TR OL DE ADMISIN (las aplicaciones declaran sus necesidades, y la red puede bloquear la retransmisin de paquetes si no puede satisfacer las necesidades. Conmutacin y QoS - Clasificacin: Determinacin del contexto al que pertenece el datagram a. Hay 2 esquem as. Monocam po: en el contexto de IPv4, la IETF ha definido el campo ToS (Type o f Service) para utilizarlo como diferenciador de prioridad o clase. C omo son 6 bits, son 64 niveles de prioridad. En el contexto de IP v6 se utiliza el campo TC (TrafficC lass), definido para este fin.Multicam po: esta estrategia no est estandarizada. El conte xto del datagrama se establece segn varios criterios y/o campos. Lo im portante es que el mecanismo de clasificacin debe evitar cualquier tipo de retardo o encolado. Por ejemplo, podemos clasificar utilizando los campos dirIP, protocolo o puerto . - Control de adm isin, supervisin y m arcado: Tenem os que caracterizar el trfico generado mediante un descriptor: Velocidad media VM, velocidad de pico VP, duracin mxim a de rfaga DMR . Estos parmetros describen un perfil de trfico. Por otro lado, introducir mecanismos de control de admisin implica determinar si hay recursos disponibles y posteriormente monitorizar el trfico generado. Tenemos 2 aproxim aciones:

Para es pecifi car un protocol o lo i deal es especifi car un diagrama de estados fini tos .

1.3.3. Control de errores y de flujo En TCP se ha implem entado el control de errores /flujo con un esquema basado en realimentacin ARQ con ventana deslizante con confirm aciones positivas y acumulativas. El tam ao de la ventana es variable/adaptable, reali zndose as el control de flujo. Los campos involucrados en el control de errores : Secuencia: el offset (en Bytes ) dentro del mensa je ori ginal . Checks um : i ncl uye ca becera TCP + datosTCP + pseudo-cabecera IP . Se incluyen las cabeceras de di recciones IP de origen y des tino. Acuse: n de Byte espera do en el receptor. Bit ACK : del campo de control . Si se produce y detecta un error, el mecanism o de recuperacin se basa en tim eouts : cuando no se entrega un mensaje, el receptor no ha ce nada y espera a que se dispa re un timeout de algn conta dor que le indique el fallo y soli cite la retrasmisin. Escenarios de Retransm isin Algunos eventos que generan ACKs: Ahora dis cuti rem os cm o estimar el mejor i nterval o para el timeout : si es demasiado corto se dispara rn m uchos timeouts prema turos y si es muy largo, habr que espera r ante la prdida de segmentos. La mejor s oluci n es la a dapta ble. Cua ndo ini ciamos un segm ento, iniciamos un contador y medimos cunto ta rda en vol ver el ACK. Es te es el RTT (Round Tri p Time), y a la medi da la llama remos RTTmedido. Es obvi o que TIMEOUT > RTTmedido. donde RTTviejo = m edia de lo anteri or A pa rti r de es te RTTnuevo/es timado, el TIMEOUT se cal cula como: donde Des via cin es un margen de confianza

La congestin se puede controlar en bucle cerrado de dos formas : M ediante RATE el emisor transmite a un bit-rate El formato del pa quete SCTP es el si guiente: dado y no lo modifica hasta que es notificado por la red, es un metodo sencillo y agresivo La etiqueta de inici o identifica a la asociacin. puesto que no se detiene si no hay realimentacin La ventana de recepcin, con 32 bits, es t amplia da respecto de TCP (puede dar lugar a situaciones no deseadas (que tena 16). Hace control de flujo. puesto que si no llegan notificaciones se Para el control de errores , se usa el TSN (Transmission Sequence bloquea). Number). Numera los troz os de datos (no l os de control). M ediante VENTANAS el emisor enva mientras Para gestiona r el multihoming , s e utili za n los cam pos parmetros la ventana se lo permita. Cada paquete enviado opcionales , que pueden ser de de diferentes longi tudes (en Bytes ). va cerrando la ventana y se detiene cuando la ventana est cerrada hasta que no haya y Ges tin de una asociaci n realimentacin. Es conservador puesto que no se generan paquetes hasta que los anteriores no Una vez es tableci da la asociaci n, una entidad SCTP puede s er multihoming , son servidos. La des ventaja es que puede teniendo disponibles va rias IPv4 y/o IPv6. No permite el envo en paralelo de funcionar a rfagas y ser bloqueante. Si la paquetes S CTP. Todos los paquetes se enva n por una IP, por defecto, denominada ventana es pequea perdemos recursos y se convierte en S&W. Lo ideal es una ventana PRIMARY PATH . Ca be des taca r que las retransmisiones se pueden sobre otros adaptativa =RTT*BW. caminos, si existen y es tn acti vos . Pretendemos que no haya bloqueos, pero que no se genere congestin, con RTT*BW damos tiempo a que el ACK vuelva Por las otras IPs disponibl es se enva n HEARTBEATS (la ti dos), mensa jes utiliza dos pa ra co antes de que se cierre la ventana misma IP por la que se envi el H EARTBEAT. Si el nm ero de HEATBEATS no contes tados o 4. N OTIFICACION IM PLCITA. NOTIFICACIN n de retra nsmisiones supera n un umbral, el camino pasa a inacti vo . EXPLCITA. La notificacin explicita es menos agresiva y no s e recom ienda.--> 1.)Choke Si el PRIMARY PATH cae, se conmuta s te a otra direccin dis ponible, sin termina r packets: va desde el router al emisor (Source Quench en ICM P): es rpido y la asociaci n. Ca da IP del mul tihomi ng tiene asocia do un esta do: ACTIVO , preciso, es costoso para los routers, generar ms paquetes aun en sent ido INACTIVO o PRIMARY PATH . contrario no es aconsejable y es un s istema poco escalable. 2.) Realimentacin explicita del rate extremo a extremo (celdas RM en ATM) Una IP activa enva/recibe HEATBEATS/H EARTBEATS ACK. se generan cedas de control para que los routers es criban salto a salto el rate Una IP inactiva NO enva/reci be HEATBEATS/H EARTBEATS ACK disponible y al llegar al destino se informa al emisor. El clculo es costoso. 3.)Control salto a salto cada router informa al salto anterior y se realiza el y Cierre de una as ocia cin control, hay posible efectos de parlisis y no se usa excepto en s istemas reducidos. Se trata de un handsha ke a 3 bandas : Con notificacin implcita el emisor debe adivinar s i las prdidas experimentadas se deben a congestin o a otras causas (errores). 5. IM PARCIALIDAD. En el mensa je SHU TDOWN, se confirma el l tim o Byte recibido consecutivo, NO El objetivo es que si K sesiones comparte un enlace con ancho de banda R, el hace repeticin selecti va (como ha ce SCTP con los da tos). Adems , hay al gunos control de congestin debera proporcionar un media un rate igual a R/K , para mensa jes (trozos ) pa ra ges ti ona r errores en las conexi ones/des conexiones : s on l os cada ses in. M edir la imparcialidad es sencillo si la demanda de todas las trozos ABORT (6) y ERROR (9): i ncluyen campos Cause , pa ra i ndi car por qu se fuentes es la misma, pero si tenemos N conexiones cada una con un rate X i, produjo el error. suponiendo que todas tienen la misma longitud: es un factor que me indica cuan lejos estoy de la imparcialidad. y Tra nsferencia de da tos La imparcialidad a nivel de transporte no implica imparcialidad a nivel de aplicacin, nada impide que una aplicacin abra conexiones en paralelo entre Tenem os 3 conta dores : dos host tal y como hacen los navegadores Web. TSN: cuenta trozos de da tos . Es un ra ndom especi fi ca do en el INIT. Las aplicaciones multimedia que no usan TCP no les conviene retardos por Stream Identifier: conta dor que empieza en 0 e identi fica a los realimentacin de control de errores y control de congestin. UDP dis ti ntos s treams . Ni vel extra de direcci onamiento (si se tra ta del generalmente emplea un Rate constante aunque se toleran algunas perdidas y se est empleando T CP Friendly con el que se asignan recursos siempre por s tream de audio, el de vdeo, etc.). debajo de lo que hara un TCP SSN (Stream Sequence Number) : numera los trozos de datos 6. CONTROL D E CONGEST ION EN TCP. perteneci entes al mismo stream . TCP es un sistema extremo a extremo sin intervencin de la red en el que se sigue un principio de cons ervacin de paquetes. No se envan nuevos paquetes SCTP es orientado a mensajes (mientras que TCP es orienta do a Bytes ): la hasta que no salgan los antiguos. El emisor adopta un control de congestin a pli cacin genera un mensaje y es pera que se entregue tal cual en el des tino. Pa ra basado en ventana (CONG WIN) gara nti zar es te servi cio, los trozos de da tos utiliza n 2 fla gs: El emisor limita sus envos de tal forma que se verifica: Bit B (Begin): i ndi ca que el trozo es el comienzo de un mensaje. LastByteS ent-LasByteAckedCongWin; Bit E (End): i ndi ca final de un mensaje. Flag U (Unordered): el trozo i ncl uye total o pa rcialmente un mensaje

Donde              Solo queda destacar lo que significa cada trmino: el primer trmino, es servir una rfaga en tiempo 0 de mxim o tam ao (peor caso); el segundo trmino, es lo mxim o que tardan todos los routers en enviarme el paquete; el tercer trmino, est relacionado intuitivamente con el mximo tiempo de espera (peor de los casos) para lo servido en cada router. Modelos de servicios de la red - Internet de servicios integrados. Protocolo RSVP: El modelo de SI fue propuesto por la IETF. La idea es asegurar que un flujo reciba una QoS demandada. Para ello hay que realizar una solicitud/reserva expl cita de recursos. Vamos a ver qu im plica este mecanismo de reserva: Clasificador de paquetes en los router (hay que distinguir las clases); control de admisin (hay que determ inar si se dispone de recursos); supervisor, gestor y planificador de paquetes; protocolo de sealizacin (para llevar a cabo la comunicacin necesaria para demandar la QoS). El protocolo de sealizacin utilizado es RSVP (ResourcereSerVationProtocol). ste se basa en:1) C ada fuente caracteriza su demanda (mediante descriptor de trfico), 2) Se reservan los recursos (problemas de tarificacin y de interoperabilidad entre operadores), 3) C ada router en el camino tiene que hacer: 3.1) Mediante el mdulo de routing determinar el siguiente salto que verifica la solicitud, 3.2) Usando el control de admisin determ inar si tiene suficientes recursos, 3.3) Una vez admitida se actualiza la BBDD de control de trfico , 3 .4) Cada flujo, una vez clasificado, recibir de acuerdo con la BBDD un tratamiento diferencial en el planificador (un peso). Vamos a estudiar el mecanismo de sealizacin de los extremos a la red para realizar la demanda de reserva de recursos. C omo la reserva se hace por cada flujo, esto putea la de los routers. El protocolo es complejo, pero es muy operati vo y funciona bien. Antes de hacer la reserva, el emisor tiene que especificar su flujo. Esto lo hace mediante un descriptor de trfico (esto ya es terminologa R SVP). U n descriptor de trfico incluye: 1 Quien es el flujo (filterspec es la cla ve para el clasificador), 2 Cmo es el trfico (caracteri zar el perfil de generacin>cubo de tokens (tspec), mediante 5 parm etros: b=TMR, 3 r=VM, p=VP , M=tamm axpaq y m =tam min paq), Qu demando (se especifica en trminos que conocemos: BW y delay (rspec)). servidor DN S. Este servidor DNS, si no puede resolver   

protocolo de sealizacin que v a utilizar MPLS a Las tablas de l os routers a partir de la cual se deci de el si guiente nodo y la etiqueta se denomina n Lebel Forwa rdi ng Informa tion Base(LFIB) Dado que ahora se enruta segn MPLS, se le es ta qui tando es ta tarea al ni vel de red que sustenta , IP entonces no dejara IP de ser necesa rio? NO, MPLS esta pensado para enruta r en el core de la red, no en las redes exteri ores o de a cceso; por tanto, una vez el paquete sal ga del core, comienza a funciona r IP Todos los paquetes que s on tra tados de i gual manera se les denomina FEC(Fa rwa rdi ng Equi v alence Class) El etiqueta do ini cial es el que determina ra siempre la ruta y el trato que reci bir n el paquete por pa rte de la red Las rutas se pueden m ezclar: al confl uir en un punto dos trafi cos dis tintos con eti quetas dis tintas pueden perder s u si ngula ri dad y ser trata dos de igual forma . Esto permi te di fernciar los pa quetes en la peri feria, pero darl es el mism o trato en el core MPLS permite tunela r, que consis te en a adi r una cabecera o eti queta extra ; as , 2 FEC di ferentes pueden tener un tra tamiento dis tinto fuera de los extremos del tnel(esto requiere aadi r una columna adi ci onal a la ta bla , pa ra que el router sepa cuando termina un tnel pa ra una eti queta dada ) Las eti quetas son asi gnadas y anunciadas de a ba jo a a rriba (en contra del senti do del tra fi co). Hay dos aproxima ciones : Sin soli citud expli ci ta : cada LSR a nali za s u tabla de routing, anunciando una FEC y una etiqueta por ca da una de las i nterfa ces de salida . Problema: es cos tos o y pueden anuncia rse rutas no optimas . Con solici tud expli ci ta : cuando llega una FEC nueva , que no es ta i ncl uida en la tabla LFIB del router, se ma nda por todas las interfa ces de salida (menos por la que llega) PROTOCOLOS DE SEALIZACIN La norma LD P intercam bia 4 ca tegorias de m ensajes entre pares de LDP(un pa r LDP son dos LSRs que usan LD P pa ra i ntercambiar etiquetas ) Des cubrimi ento: se usan para ini cia r una rela cin ady cente entre 2 LSRs. Se basa a en el envio de mensajes Hello, uni cas t o, mas efi cientem ente, mul ticast. Normalmente, los mensajes Hell o s olamente se intercambia n entre routers directamente conectados , sal vo si ha y un tnel MPLS previamente es tableci do, en cuyo caso el mensa je Hello puede dar mas de un sal to. El bit U de la ca becera s e utiliza pa ra aadi r funcionalida des extra : cua ndo vale 0, el mensa je es no des cartable, si no que hacer con l , se debe noti fi ca r error; cua ndo vale 1 si gnifi ca que el mensaje es de alguna funcionali dad extra y se puede ignorar si no se sabe procesa r. La rela cin de adya cencia es soft-s ta te (s e manti ene una relacin de adyacencia refres cando peri di camente con mensa jes hello); se termi na si expi ra un conta dor y se ha actualiza do la as ociacin. El intercambio de Hello ini cia una s esio LD P entre routers ; la sesi n se define con el campo Label Spa ce Identifier. En el campo LSR ID se usa pa ra intercambia r las dirIP de l os LSRs ; el LSR con ma yor ID ini cia una sesin TCP para i ntercambia r mensa jes LDP. Sesin: una vez intercambiado el Hello y es tablecida la conexin TCP, s e intercambian mensa jes de i ni ciaci n, en los que se intercam bia : La versi n LD P El timeout pa ra mantener la sesin a cti va El modo de distribuci n (ba jo demanda o sin solici tud expli ci ta) Un campo(Pa th Vector Limi t) para detectar bucles de encaminamiento El tama o m xim o de PDU a recibir Si l os parmetros reci bidos no son a ceptados , se notifi ca un error con causa y s e cierra la conexi n TCP. Es to puede genera r bas ura en la red, que consis ti ra en paquetes para reini cia r las sesiones . Pa ra evi tar esto, l os mensa jes Hell o pueden incluir Configura tion Sequence Num ber, asi cua ndo se recibe un Hello con este cam po igual a otro Hello anteri or que cerro una conexi n por un error, no s e procesa pa ra i ni ciar una sesin porque sabemos que va a generar error. Si no hay errores, se aceptan l os parmetros en el receptor, este genera una configura ci n expli cita (keepalive) y su propio mensa je de ini cializa cin. Es te mensa je se enva peri di camente en ambos sentidos de la sesi n. El periodo de envi o de estos mensajes es tpi cam ente 1/3 del Keepalive time negociado en el esta blecimiento de sesin. Pos teriorm ente hay un intercambio de mensa jes a dress pa ra envia r las direcci ones IP de los routers o cual quier otra di reccin que si rva de ID de un router(el protocolo prev que no sea la dirIP la LPDID de mi router). As el otro extremo asocia dirIP<->LSRID , coinci dan o no esos nmeros . Anunci os : es tos mensa jes si rven para crea r, cam bia r o borra r asignaciones de eti quetas a las FEC(FEC=desti no). Ha y dos modos de intercambio de etiquetas (A=0 o 1), un val or i ndi ca si n s oli citud y el otro bajo dema nda . El es cenario sera el siguiente: el ups tream ma nda un mensaje de solici tud de etiqueta pa ra una FEC especi fi ca . El downs tream responde con un mensa je Lebel Mapping, as ociando una eti queta a ese FEC. Cua ndo se recibe un Lebel Mapping sin s oli citud, se procede como sigue: El router cons ul ta su ta bla LFIB Si la asociacin FEC<->Lebel no es ta conteni da en la LFIB, es ta se actuali za y la informa ci n se propaga ha cia arri ba Si exis te una entrada para esa FEC pero con dis tinta eti queta, se elige la mejo r opci n y s e a ctuali za la ta bla(esto ti ene senti do cuando la nueva entrada llega por otra interfaz) Si es ba jo demanda , la s oli citud de etiquetas se realiza mediante el mensa je Lebel Reques t. Puede i ncluir TLV opcionales: Hop Count: i ni cialmente a 1. Para evi tar bucles . Path Vector: contiene la lis ta de l os LSRs atravesa dos . Tambin pa ra evi tar bucl es . Si un router recibe por dos rutas disti ntas una as ocia ci n FEC<->La bel con eti quetas dis tintas, elegim os la m ejor ruta Qu hacem os con la asi gna cin FEC<>La bel que ya no necesi tamos ? Hay dos aproxima ciones : Liberal : la i nformaci n s e gua rda o ma ntiene aunque no se utili ce. Implica recurs os a adi dos(memoria). Es te m todo es preferi ble cuando el m odo de i ntercambi o de eti quetas sin soli ci tud y que si te borran la FEC puedes recurrir al histri co o a his torial pa ra no queda rte sin entrada para esa FEC. Conservador: pa ra poder reutiliza r las etiquetas se desca rta la informaci n no til . En es te modo, excepcionalmente, si es tamos en el es quema sin s olici tud, el protocolo permi te emi ti r La bel Request si hay problemas . Para eliminar eti quetas : Se enva upstream un mensaje es peci fico Lebel Wi thdraw Cua ndo un LSR reci be este mensa je: Modo conservador: genera un Lebel Wi thdraw ha cia arri ba Modo li beral : conmuta ra eligiendo un nuevo LSP Tras recibi r un LW, se res ponde con un mensa je Lable release. El campo opcional Lebel TLV sirve para eliminar una eti queta especifi ca pa ra la FEC, deja ndo las otras operati v . as Noti fi ca cion de error: hay dos tipos de flags de error Error fa tal : el error ci erra la sesin.(bi t F=1) Flag F: indi ca que la noti fi cacin de error debe propaga rse. Se incluye un cam po Messege Identifier con la ID del mensaje que produjo el error La norma CR-LDP aa de nuevas funcionalida des: Opera siempre en modo ba jo demanda Permi te hacer un encaminamiento expli ci to des de el ori gen. Al ha cer los Lebel Reques t uno puede especifi car un conjunto de LSRs que van a conforma r el camino. Puede ser es tri cto(no puede haber ni ngn salto intermedio entre los routers especifi cados) o no-estri cto(permi te sal tos intermedios entre l os routers especi fi ca dos ) Reserva de recursos : rela ci onado con QoS, al s oli cita r un routing desde el origen s e puede soli ci ta r una reserva de recurs os en ca da sal to. Se define un TLV para especi fi ca r pa rmetros de QoS Ges tin de reasi gna cin de recursos y priori dades: si se dema nda n recursos y no se dispone de ellos , el LSR puede eliminar LSPs previas pa ra sa tis facer las nuevas , segn cri teri o de prioridad La norma RSVP-TE permi te usar los mensajes PATH como Lebel Reques t, y l os mensa jes RESV como Lebel Mapping. El problema es que es soft-s ta te(tpi camente refres ca la conexin cada 30 segundos): genera mucho tra fico pa ra di nami cas poco cambiantes(las rutas no suelen cambiar ca da 30 segundos), lo cual a fecta a su escalabilidad. Es to se sua v za aadiendo un campo #contador a la cabecera i RSVP, de forma que s olo cambia si el mensaje di ce algo nuevo. En otro cas o no s e procesa .

ejemplo ha ces una peti cin IP, si nuestro servi dor no la conoce, trasla da la peti cin al servi cio raz y este, puede ocurrir dos cosas : si conoce el regis tro nos lo da , y si no lo conoce traslada la petici n ( ha ce un query a otro servi dor), de manera que si no lo conoce tiene la obliga ci n de conocer todos sus hi jos , de forma que al final l o encontra r . Deci r que con DH CP ca da cliente sabe la IP de ese DN S ( asocia IP DNS). En la res olucin recursi va , se actualiza la cach de cada servi dor ( sobre tcp), y en la i terati va, el servi dor DN S devuel ve otro servidor si el no sabe el regis tro ( sobre TCP tb). Ges tin de la base de datos dis tri bui da y jerrqui ca: Est formada por un conjunto de servidores cooperati vos que alma cenan parcialmente la base de da tos ( BIND ), de manera que cada servidor es res ponsa ble de una zona que es un conjunto de nombres de dominiocontiguos, de los que el servi dor tiene toda su informa cin y es su a utoridad. Servidores autorida d: Deben contener toda (no ca cheada) la i nforma ci n de su zona. La a utorida d se puede delegar jer rquicamente a otros servidores . Servi dor con responsa bilida d: Va de a rriba a bajo; la autorida d se del ega ha cia aba jo ( liberndose de la obliga cin de mantener y conocer l os servi cios). Al conjunto compl eto de todos l os nombres de domi nio de un rbol se le llama zona . En la realidad ha y 13 servidores repa rtidos por todo el mundo ( ver imagen anterior), identi fi cados por las letras A-M. Uno de ellos est en Ma dri d. Cada zona debe tener , al menos un servidor de a utorida d, y en ca da zona , hay servidores prima rios ( que obtienen copia mas ter de la base de datos ), y secundari os ( que obtienen la base de da tos por trans ferencia de un primario), mediante DN S, que tam bin si rve de Queri ng. Tam bin hay un servici o ca ch pa ra mejora r las pres taciones que funciona con res oluciones recursi vas ( realimenta do) as se a ctuali za. Cundo un cliente (res ol ver) soli cita una resolucin de nom bres a su servi dor puede ocurri r: Respuesta con a utori dad: el servi dor tiene a utoridad sobre la zona en la que se encuentra el nombre solici tado y devuel ve la di reccin IP. Respuesta SIN autori da d: el servidor no tiene autori dad s obre la zona en la que se encuentra el nombre solici tado, pero lo tiene en la ca ch. No conoce la res puesta : el servidor preguntar a otros servidores de forma recursi va o itera ti va . Normalmente se eleva a uno de los servidores raz. La base de da tos DN S es un conjunto llamado Res ource Record que conti ene todos los recursos que consti tuye la bas e de datos , ca da uno con cinco campos . El RR es por tanto una tupla con ci nco campos: 1) Nombre de domi nio: ( www.ugr.es) al cual le corresponde ese registro. 2) Tiempo de v da ( TTL); especi fi cado a cada IP. i Especi fi ca la estabilidad ; si la IP es es table , el TTL es muy al to. 3) Clase en Internet siempre IN 4) TIPO: puede ser: SOA ( en datos tienen el nombre de do ini o asocia do a la autori dad que ges tiona ese DN), NS ( Regis tro que contiene un servidor de nom bres), A (Regis tro que defi ne una di reccin IP), MX ( regis tro que define un servi dor de correo electrni co), CN AME ( regis tro que define el nom bre ca nni co de un nom bre de dominio),HINFO ( Informacin del tiepo de mquina y sis tema operati vo), TXT ( i nforma ci n del domini o). 5) Val or, son los da tos , contenido que depende del cam po TIPO. Tam bin exis te una base de da tos asocia da de resolucin inversa que sirve pa ra tra duci r di recci ones IP a DN. Al hacer un quering a una direcci n IP (250.x.y.z), l a res pues ta del DNS sera del tipo clase=A, name = www.ugr.es Resolucin inversa IP nombre? Res uel to por una es tructura pa ralela , consistente en un rbol de DN de forma que todos estn jera rqui zados . Nota: Tam bin exis ten ls regis tros PTR( una clase), dnde ca da rama jera rqui zada de estas tiene un regis tro clase PTR con el nom bre. y Telnet. Acces o Remoto: Los servicios Telnet son concurrentes , ya que pueden da r servi cio a varios clientes de forma simul tnea. Se ofrece siempre el puerto 53, que ofrece un mecanismo de E/S rem oto: cliente se convierte en un terminal local del S.o, que est residente en el servidor remoto. Se invoca con > tel net [IP/nombre] [port] (23 por defecto). As, el servidor ofrece una consola tras l ogin y password como estuv semos en el S.O rem oto. Tam bin se usa si es peci fi camos un i puerto determina do establecemos conexi n a ese puerto para un determina do servici o, que no tiene por qu ser lo de la cons ola . Pa ra ell o, si especi ficamos por ejem plo el puerto 50, crearams una conexi n TCP. Pa ra eso, telnet, ha ce uso del N VT o terminal vi rtual de red, que independientemente de las ca racters ti cas del cliente, lo que es cribe en el terminal se escri be en el NVT que tambin es conoci do por el s ervi dor particularidades del cliente son independientes. Cliente tra duce a NVT. Tambin es in-band protocolo de sealizacin en el cul la sealiza cin y da tos van por la misma conexi n ( o banda ). FTP: File transfer protocol: Tel net y FTP son pre-http y casi no se usa n a ctualmente. Son servici os orientados a conexin mediante TCP que ti`picamente son oferta dos en el puerto 21. A di ferencia de TELN ET, es un protocolo out of band s eali zacin y da tos por dis ti ntas conexioesn( 21 pa ra sealizaci n y 20 pa ra datos) comandos y datos por distintas conexiones . y Servicio de correo electrnico.

Rate=CongWing/RTT(bytes/sec) CongWin es adaptable en funcin de la congestin percibida. Para identificar la congestin s e emplea un timeout que indica prdida y 6.2 CIFRADO. Ata que fuerza bruta : es un procedimiento que consis te en ba rrer todo el espacio de posi bilidades . Di rem os que un sis tema est comprom etido si encontramos un al gori tmo que reduzca la complejidad de la fuerza bruta . Cifrado: es un al gori tmo que tra ns forma el texto plano basado en una cla ve tal que en tanto en cua nto no se conozca esa clave el sis tema es i rreversible: Asociado a el ha y un algori tmo de des cifra do, tal que operando sobnre el espacio ci frado nos recupere P. Requisi tos : Necesi tamos que sea reali zable, de ba jo coste computa cional querem os E(), D(), de ba jo cos te com putaci onal y que sean sencillos. Propiedad de no colisin, que el al gori tmo de cifrado no colisione, que pa ra todo p dis tinto de p , no exis te una clave Ek(p ) que permi te desci fra r. Robus te4z ante cri ptoanlisis , que es la metodol oga pa ra reverti r el proces o. Tipos: Texto cifrado, texto pla no conoci do, texto lla no seleccio nado y anlisis diferencial . Tipos de cifrado clsi cos : Sus titucin: Sm bolo a sm bol o del texto de entrada ha cem os una correspondencia unvoca. El texto de entrada con una clave que asigna a cada s mbolo de entrada uno de salida . La com plejida d de fuerza bruta est rela cionada con el ca rdi nal del nmero de cla ves habr que proba r todas las claves n!.

Supervisin, los paquetes que no cumplen su perfil se rechazan; Marcado, los paquetes que no cumplen su perfil se marcan. Una ve z adm itido un trfico /flujo, qu Por l timo para da rle al go ms de integridad se usa el Hash, cuy a propiedad princi pal es que sol o s e puede hacer en un sentido, no tiene des cifra do no colisin. Permi te un uso muy efica z en a taques a la integri dad. FIRMAS U SANDO COMPENDIOS. PROCESO GEN ERAL: Si R= hash(P) es tamos garanti zando integri da d ( no repudi o, priva ci dad, a utenti ca ci n). MD 5 ( Messa ge Digest 5 ) : Es la forma de ha cer l os resmenes de 128 bi ts. Pa ra ello, da do el mensa je, se di vi de con relleno pa ra que se mlti plo de 512 bits . El ltimo campo nos dice la longi tud del relleno. Tras eso, se pa rte en bloques de 128 bi ts, mediante una funcin lgi ca , que junto a una semilla y un procesamiento, hace que sea i rreversible, generando una huella digi tal : SHA ( Secure Has Al gorithm 1 ) Hace l o mismo que MD 5, pero con bloques de 160 bits huella genera da es de 160 bi ts, queremos evitar que es t comprometi do, es deci r, que no haya ninguna pis ta ni nada que reduzca la forma de obtener T disti nto T. Queremos garanti zar la asocia cin identi dadclave con certi fi cados digi tales. Un certi fi cado es la asocia cin entre A y su clave pbli ca , y es muy importa nte pa ra que no ha ya repudio. Para hacer esta as ociaci n debe exis ti r una a utoridad que ga ra nti ce bien (feh) esa asociaci n. La autoridad tiene Kpri vAut y KpubAut, l o que ha ce es cifra rla con su cla ve, de ma nera que na die podr falsifi ca rla. En cuanto a las a utoridades de certifi ca cin (AC), deci r que s on enti dades que ga rantiza n es o. Cmo cada usua ri o tiene s u clave pbli ca y privada , para asociarlas de una forma i rresoluble, se manda a la a utorida d, que te exi ge que te pers ones con tu DNI , para autenti ca rte delante de un funcionari o que vea que eres tu

Tra nsposi ci n: tenemos una cla ve K en funcin de la cual ordenamos las columa nas en orden cardinal tal que por el orden alabti co de es ta por columnas.

Los al gori tmos de clave secreta pueden ser simtricos (k=k ) o asimtri cos ( k dis t k ), que son ms complejos computa ci onalmente habla ndo. Si un algori tmo es conoci do claves des conocidas . Se usa la misma clave para el cifra do y el descifrado pero son ms efi cientes que los a nteri ores. DES (Data Encrypta tion Standard) D ES es el al gori tmo prototipo del ci frado por bloques un algori tmo que toma un texto en cla ro de una longi tud fija de bits y l o transforma mediante una seri e de operaciones bsi cas en otro texto ci fra do de la misma l ongitud. En el caso de DES el tamao del bloque es de 64 bi ts . D ES utiliza tambin una clave criptogrfi ca para m odi fi ca r la transforma cin, de modo que el des cifra do slo puede ser realizado por a quell os que conozca n la cla ve concreta utili zada en el ci frado. La clave mide 64 bits , aunque en realida d, s lo 56 de ell os s on empl eados por el algoritm o. Los ocho bits res tantes se utilizan ni camente para comprobar la parida d, y despus son des cartados. Por tanto, la longitud de clave efecti va en DES es de 56 bits , y as es como se s uele especi fi car. Para mejorarl o se emplea un encadenamiento de sistemas D ES de tal forma que ahora la salida no dependa sol o de la entrada en el mismo insta nte si no tam bin de la salida a nterior (D ES doble y 3D) se emplea ms lgi ca y es menos s us titutivo IDEA (Interna ti onal Da ta Encrypta tion Al gorithm ) D()=E-1(), s e emplean claves de 128bi ts y se opera en tiempo real es r pido y al gortmi camente sencillo DEA opera con bl oques de 64 bi ts usando una clave de 128 bi ts y consiste de ocho tra nsformaciones i dnti cas (cada una llama da un ronda) y una transforma cin de salida (llamada media ronda). El proceso pa ra ci frar y des cifra r es similar. Gran parte de la seguri da d de ID EA deri v del intercalado a a di cin y mul ti plica cin modula r y Ode opera ci ones de dis tintos grupos exclusi vo (XOR) bit a bi t que son al gebrai camente "incompatibl es" en ci erta forma . IDEA utiliza tres operaciones en su proceso con las cuales logra la confusin, se realizan con grupos de 16 bi ts y s on: Opera cin O-excl usi va (XOR) bi t a bi t (indi cada con un a zul ) Suma mdulo 216 (i ndi cada con un verde) Mul tipli ca cin m dulo 216+1, donde la palabra nula (0x0000) s e i nterpreta 16 como 2 (indi cada con un rojo) (216 = 65536; 216+1 = 65537, que es prim o) En primer l ugar, el a taque por fuerza bruta res ul ta impracti cable, ya que sera 38 necesa rio proba r 10 cla ves , ca nti dad imposi ble de manejar con l os medios inform ti cos a ctuales. Los diseadores analiza ron IDEA para medir su fortaleza frente al criptoanlisis diferencial y concluyeron que es inm une bajo ciertos supues tos . No se ha n informado de debilidades frente al criptoa nlisis lineal o algebraico. Se han encontrado algunas cla ves dbiles , las cuales en la prcti ca son poco usa das siendo necesa rio evi tarlas explci tamente. Es considerado por muchos como uno de l os cifra dos en bloque ms seguros que exis ten.

6.5 VU LNERABILIDADES: SYN ATACKS: Consis te en aprovechar que en el es tablecimiento de la conexi n hay conta dores de 75 s pa ra la devolucin de SYN+ ACK , a dems en algunas implementa ciones el lis ten se limita a pocos (5) conex pendientes. Durante esos 756 s im pli ca que el server se va a vol ver vulnerable a ciertos a taques Cu ndo se ha confi rmado puede que ha ya a ceptado una conexin tel net a quien no es quien dice ser para evi ta r que A verdadero mande el reset, se le ha ce desde el falso a A verdadero una denega cin de servi ci o no reci be SYN +ACK y no manda el reset. IP SPOOFING : Consis te en la suplantaci n de la IP ori gen en el esta blecimiento de la conexin TCP. La res puesta SYn+ACK ti ene el ISN que se encami nar al suplanta do. Se conocen procedimientos para suplantar el ISN. Pa ra evi tar el reset que enva el hos t s uplanta do al i gual que a ntes, mediante denega ci n de servi cio ( muchos). Source Routi ng: Usamos esta opci n IP pa ra que las respues tas pasen por un hos ts accesi ble por pa rte del ata ca nte. EN IP ha y un campo que es pecifi ca la Ip y otro los da tos una opcin nos permi ta poner en IP ( Ip1,..,Ipn) los routers si guen esas rutas en vez de las de desti no, a briendo un a gujero de segurida d, porque te puedes aduear del tr fi co y ver por dnde van l os da tagramas Secues tro de conexi ones : Desincronizamos los nmeros de secuencia , suplantando al otro extrem o con un ata que ma n in the mi ddle una vez ya hecha la cnex , se aduea de es os mensa jes . Ha y dos variantes : en el establecimi ento de la conexi n o durante el intercambi o de da tos ( usa ndo x ejemplo NOOPs , que incrementan el nmero de secuencia en tel net). Otras vulnerabilidades : RIP ATACKS: Se pone una entida d falsa con coste mnimo , anunciamos rutas ms cortas todos nos van a elegi r a nos otros . DNS Atacks: Se introduce un DN S s uplantado tal que evi te filtros de wa rppers , res pondiendo falsamente a soli ci tudes DNS inversas ( dada una IP obtener el domi nio). Si el objeti vo es nombre.domini o.x, lo normal es que tenga all ow from *.dominio.x , de tal forma que cundo nombre pregunte por el dominio crrespondiente a la IP origen del a taca nte, el DNS siempre responda falsamente confa -enmi .dominio.x . Posible medida de precauci n: ha cer dos preguntas DNS; la inversa y di recta y comprobar la coherencia en las respues tas . 6.6 Protocolos de comuni cacin seguros : Nivel de red: IPSEC Nivel de trans porte: SSL Nivel de a pli cacin: PEM , SSH , PG P. PGP es un protocol o de correo seguro que ha ce doble ci frado con hash. El cos te de RSA >> cos te DES / IDEA ( cos te de las cla ves s ecretas), lo malo es que en D ES/ID EA no tenemos la certi fi ca cin que si ha y en RSA, por l o que se ha ce es : mandamos la cla ve secreta ci frada con la pbli ca de B. Nivel de RED: IPSEC: Objeti vo: garanti za r autenti ca cin, pri vaci dad e integrida d a ni vel IP. IPs ec es t compues to por tres procedimientos : Esta blecimiento de una asocia cin de seguridad IKE: Internet Key Exchange. El objetivo es es tablecer una cla ve secreta entre ambas entidades. Esa clave s ecreta es dinmi ca , ya que se es tablece en cada sesin. Se esta blecen m ediante Di ffie-hellma n, y el al gori tmo i nvol ucra do es IKE. Incluye autenti ca cin, de ma nera que se evi te el a ta que man-i n-themiddle ( 4 es quemas = clave simtri ca , 2 va ria ntes de clave pbli ca , certi fi cado di gital ). Se basa siempre en una hiptesis , que pueden ser los certifi cados digi tales. IKE tiene modo Ks esin+SPI: Compa rten una clave de sesin y l o identi fi can mediante el SPI implica que ambas entida des negocian una K. Rompe con el ca r cter N oC. En el modo main , usa cookies (exi ge), pa ra evi ta r a taques por denegaci n de servici o. Cookie=com pendi o (Ipori gen,Ipdes ti no,da,hora , s ecreto); Es s m plex, un ni co sentido. Para identifi car: IP + SPI ( 32 bi ts ). Recientem ente IKEv2 s oporta r movilidad y m ul tihoming. 1,2,3 s on protocolos que las entidades IP pueden usa r. Sol o garanti za integri dad y a utenti caci n: protocolo cabecera de a utenti ca ci n I+A+pri v ci da d de los da tos : Es IPSEC con modo de encaps ulado de a seguridad de carga Encapsulado de seguri dad de ca rga . Exi ge que una vez ha ya sido es tableci da la clave, una fase que requiere de un conocimiento previo para la autentifi cacin de am bos . Cundo una entidad mediante IKE intenta conectarse a otra enti da d, el otro extrem o parte de la hiptesis de que ha y un secreto compartido, y cal cula C=f(IP,secret), envindoselo a la otra enti da d, que mientras no conzca ese secreto no conocer la cooki e y no podr evi ta r la denega cin de servi cio. El problema es que no tiene ma rca de ti empo podr ser a ta cado f cilmente. Tam bin hay otra versi n ms agresi va de IPSEC que no exi ge ese conocimiento previo con 3 mensa jes ( negociaci n pa rm etros e intercambiar): ( NO ENVA LA IDENTIDAD).

tam poco el nombre, har lo m ism o, y si s puede resolverlo, devol ver al primer servidor DNS la resolucin, y este al cliente que la demando. En cambio si la consulta hubiera sido iterativa , el primer servidor DNS hubiera devuelto al cliente solo la IP del otro servidor DNS que si resuelve el nombre. Pues aplicando esto al ejercicio: El cliente de la red A enva una consulta recursiva al servidor R3. El servidor R3 consulta al servidor R0(raz), y este le contesta una referencia a R 1. Ahora R 1, como no puede resolverla, consulta a R 0(raz), y le contesta una referencia a R2. Ahora R2, como tampoco puede resolverla, consultara a R 0(raz), y le contesta una referencia a R 6. Entonces R6, como si sabe resolver el nombre, contestara a R3, y R 3 al cliente A. Por que es necesario tom ar precauciones de seguridad en todos los nive les de TCP/IP Son bastantes las vulnerabilidades que la arquitectura TCP/IP puede ofrecer. Ejemplos: -SYN Attacks: ataque de denegancion de servicio, ya que TCP reserva recursos nada mas recibir una mensaje SYN. Basta con enviar mil SYN para llenar la cola y denegar el servicio. IP Spoofing: suplantacin de IP. Es muy fcil hacer a nivel software. Se evita el m ensaje RST del suplantado mediante un ataque de denegacin de servicio. Source R outing: utilizando esta opcin de IP, puedo aduearme de un flujo, haciendo que los mensajes de respuesta pasen por unos host accesibles por el atacante. Secuestro de cone xiones: intento de desincronizar las ventanas de emisin/recepcin. Tambin son ataques de denegacin de servicio. RIP Attacks: anunciar rutas falsas para hacerte con el trafico a un destino dedo y suplantarlo. DN S Attacks: suplantar servidores DNS reales Que tipo de respuesta adopta TCP Adopta un cc que es bsicamente una variante de AIMD basado en ventanas con notificacin implcita en el que los timeouts(o 3 ACKs consecutivos) siempre son interpretados como perdidas De que factores y en que m edida de pende la velocidad de tra nsmisin en una fuente TCP Suponemos: no inicio lento, no compresin de cabeceras, estacionalidad, y probabilidad p de perdidas. Suponemos un modelo peridico: -n paque tes enviados en un periodo es 1/p. n paquetes transm itidos en cada periodo esta relacionado con el area de la curva en un periodo: npaquetes=0,5T/R TT(W/2+W)=1/p. En la zona de prevencin de congestion la ventana crece 1 MSS por cada RTT. Por tanto, T=RTT.W/2 y W=sqrt(8/3p). la velocidad de transm isin TCP ser x(p)=(1/p)/T=(1/R TT)sqrt(3/2p) paq/s Funcionamiento de los mensajes PATH y R ESV de RSVP para garantizar un retardo acota do extremo a extremo Qu elementos deben te ner los routers intermedios? La demanda de la reserva se origi na en el receptor. La fuente, por su parte, cara cteriza su trafico y s us demandas(tSpec y rSpec), s u fillerSpec, IPorigen-#PortOrigen, y s u clase de servi ci o. Evi dentem ente, todo es to lo necesita sa ber el receptor antes de hacer la reserva . Pa ra ello, RSVP tiene un ti po de mensa je PATH que informa s obre esta ca racteri zaci n: va por la red sal to-a -sal to; en cada sal to informa al router a ctual s obre la di rIP uni cast del router anteri or, a dems de recabar la info durante el tra yecto, en un objeto llamado AdSpec, por ejemplo, del numero de sal tos dados . As , cuando llega el PATH, el receptor conoce toda la info necesa ria para a cota r el retardo extremo a extrem o. Tr

Funcionamiento : ha y dos enti dades di ferencia das : MU A: Mail User Agent: Es una entida d compues ta por el cdi go. Es el s oftwa re, que permi te a los usuari os componer, envia r y recibir y l eer el correo ( son agentes de usuari o), pero es to no se hace entre MU AS, si no que ha y unas segundas enti da des MTA o mail trans fer Agent, que se pone en conta cto a travs de una s erie de protocolos con otra MTA remota , que a su vez, con una serie de protocolos se comuni ca con la MU A remota . Es to se hace porque cliente-servidor necesi tan esta r a coplados temporalmente mediante esta a rquitectura los desa coplamos temporalmente, no ha ce fal ta que estn conecta dos a la vez. Por tanto la MTa tiene rol doble: interacciona con us uari os y MTA rem ota . Hay un s pool o cola de correo saliente, y tambin tiene buzones de entrada sol o a ccesibles al des ti nata rio del correo. Proporciona ms seguri dad. SMTP Protocolo de envo de correo PoP o IMAP Protocolo de des carga / lectura de correo. y SMTP: Sim ple Mail Transfer Protocol: Usa servi cio de transporte FTP y se si rve siempre en el Puerto 25. Es in band siempre ha y un proceso que a tiende ese puerto. Tiene tres fases: Saludo, trans ferencia y cierre. El cliente enva s oli citudes en texto ASCII, y el servidor respues tas en cdigo numri co texto explica dti vo. Es un protocolo orienta do a texto mientras no se diga l o contra ri o. Despus se mejor a Enha nced SMTP, que permi te qui ta r el l mi te de 64 KB, evita bucles de alias, y es el ms usado. Ejem plo servici o SMTP:

Algoritmos de clave asimtrica: Cada usua rio tiene dos cla ves , una pbli ca y una privada , ambas claves son dis ti ntas para ci frado y des cifrado: A ci fra con la cla ve pbli ca de B , la cual la conoce todo el m undo, pero s lo es des cifra ble con la pri v da de B, a la cul solo B tiene acces o. Texto a Cifrado=C=Kpubli ca (P) : KprivB(C)=Kpri vB(KpubB(P))=P RSA: RIVER SH AMIR VADLEMAN: Es un mtodo por el cual creamos claves que res ul van los as pectos anteriores . Se ha converti do casi en si nnimo de cla ve pblica . El procedimeinto es el siguiente: Se eli gen dos nmeros primos muy gra ndes : P,Q > 10^100: n=(P,Q), Z= (P-1)* (Q-1), y elegimos un nm ero d primo respecto de z, es to quiere deci r que su des com posici n en factores ( de z y d ) no tenga n fa ctores en comn. Tras es to, se cal cula un e tal que e*d mod(z)=1 Kpub = (e.n), Kpi rv = (d,n). Hoy en da no se ha desarrollada o nada capaz de des cri fra r es te al gori tmo reduciendo el cmputo ( es imposible comprometerl o).

6.3 AU TEN TICACIN . Bsi camente, consis te en que tengamos gara ntas de que el otro extremo es quien dice ser, de una forma segura ( feh) la autentia ci n exige la hiptesis de que tenem os una cla ve secreta entre nosotros , pa ra esta r seguros de ell o. Esquema reto respuesta : Hola s oy A. Reto de B A ci fra con clave K el reto de B Reto de A B ci fra con cla ve el reto de A Esto es pa ra comproba r que cada uno es quien di ce ser. Se puede simplifi car mejor ndolo en el sentido de que enviamos tres mensajes en vez de 5. Son: 1 A,Ra 2. B, Kb(RA), RB 3. KAB(RB). Lo malo de es to es que ti ene un a gujero de seguri dad. Supongamos que A malo suplanta a A. No tiene cla ve K. Tras B ma nda r el segundo mensa je ( model o simpli fi cado), A manda A,RB, hacindole un a taque por reflexin, ya que ha y una nueva sesi n. La forma de sol uci ona rl o es gua rda r l os retos enviados en B que tienen enviada os a una Ip dada. Otra solucin mejor : que los retos de A el conjunto de retos sea diferente de l os de B C(RA) interseccin C(RB)=0. Intercambi o de clases con Di ffue -Hellman: Es un mecanismo de esta blecimiento de cla ve secreta , mediante el cual , A eli ge una serie de nmeros x,n,g y enva x,g,g^x m od n. Le llega a B, que eli ge un nm ero y y enva g^y m od n. De es te m odo podemos es ta blecer una cla ve a unque es cuchen otros : Tiene una debilidad: s i no tenemos autenticado a B pueden hacer un a taque ti po man in the mi ddle. Solo funciona si sa bems que B es B, pero pa ra a utenti ca r a B necesitamos una Ks, que necesi ta Di ffie Hellma n, que a s u vez necesi ta a utenti car Centro de dis tribuci n de claves (KDC): Usando el reto respues ta se obli gaba a que A debe tener N^2 claves para N conexi ones . Un usua ri o solo necesi ta una clave para comunica rse con el KD C, simpli fi ca ndo todo, de ma nera que el KDC ha ce de intermediario. Ka clave entre KDC y A: Autenti caci n y ci fra do de cla ve s ecreta : Repeti cin: L debilidad de los protocolos de reci bi r va rias veces uun mismo mensa je, es deci r, coger un mensa je y env rlo otra vez para que el que lo ia recibe piense que eres tu. Sol ucin gua rdamos un his tri co ( no es demasiado buen ni es calable). Soluci n 2: Incluim os en l os mensajes un mensa je que solo usa una v Si se repite, o ms de una vez, el receptor lo ez. detecta . Esos campos se llama n nonce. F cil. Son marcas de tiempo, de ma nera que podamos saber cundo un paquete es una repeticin, de ma nera que tu ma rcas el tiempo y formas un ma rgne de confianza de recibir mensa jes primer problema : relojes sincroniza dos y conges ti n. Se usa el algortimo Kerberos, basado en el protocol o Needham Schroeder. Y es un protocolo de a utenti ca ci n : guardin mi tol gi co del a verno. Firma digi tal . Certifi cados digi tal es: Se quiere dar servici os que la fi rma normal no ofreca . Si hubiese un repudio la cosa no funciona ra bien. Los objeti vos perseguidos s on: Receptor puede a utenti ca r al emisor No repudio, si B di ce que A ha generado P A l o ni ega , B coe la tupla, se la ensea ra al juez y con eso vera que ha pasado realmente Emisor quiere ga rantas de no-falsi fica cin ( i ntegri dad). Firma digi tal con cla ve secreta : bi g brother: Antes de nada vamos a es tablecer dos hi ptesis: Todo el mundo va a confiar en esta identi dad, de maner que no va a tener ningn tipo de comportamiento a nmal o. Todas las entida des tienen una clave secreta solo conoci dad por ellas ( entida d y a utoridad) si por ejem plo queremos conecta rnos con un banco: Se le enva una tupla con 5 campos : i dentida d, ci fra do con clave secreta ( id des tina tario, nmero alea tori o, tupla de ti empo, texto plano). Es to se le ma nda al BB que responde . Kbb(A,t,P) signi fi ca fi rma ci frada con la clave secreta de BB que no conoce nadie. La Ka es la cla ve secreta entre A y BB. El t es el nonce, para evi ta r los a taques de repeti ci n. BB des cifra KA y cifra a B con KB. Se di ce que Kbb(A,t,P) es una firma ci frada con la cla ve secreta que no compa rte con nadi e si la hiptesis se ma ntiene como nos fiamos del BB A es quien tiene ga ra ntas. En el casod e que hubiese un ata que de integrida d, es deci r: B di ce que A ha genera do P dis ti nto de P para demostrarl o tendra que usa r Kbb(A,t,P ). Es con la tupla con l o que se ve y se demuestra que es l o que ha pasado realmente. FIRMA DIGITAL CON CLAVE ASIMTRICA. DOBLE CIFRADO: Cada entidad tiene dos cla ves : A ( Kpub, Kpri v), B ( Kpub, Kpri v). La s cla ves pri vadas s olo las ti enen las entida des y se des cifran con las pblicas , conoci das por todo el mundo, pero solo son des ci frables por las privadas A B Kpub_B (Kpirv_A(P)), que al ll ega r a B tiene esa asociaci n al revs : KpubA(KPRIVb)=P. As , nos aseguramos que sea i na ccesi ble. Tambi n nos asegura que B no pueda engaa r, al hacer KpubB(KPi rvA(P)) como B no conoce la pri vada de A ah es dnde se ve lo que ha ma nda do. Lo ni co que le fal ta a es to es que no hay una forma de dem os trar que la cla v pbli ca es t e gara nti zada y no se la pueda i nventa r o cambiar alguno de los 2 usamos el certi fi cado di gital , que es el enca rgado de as ocia r de una ma nera i rrefuta ble un usuario y s u clave pbli ca . Pa ra ello se usa una autoridad , ci frando con la clave priva da de la autori dad: KprivAut(A <--> KpubA) Solo la autoridad la ha podido guardar. La ni ca debilida d de esto es que A puede denunciar que le han robado la cla ve, lo cual es al go inevi table.

y Extensiones MIME: Multimedia Mail Extension: Estas extensi ones i dentifi can que el correo en particular tiene da tos extendi dos : Permi te ca ra cteres no ASCII en l os mensajes Permi te mensajes ms largos Define un conjunto extendi do de ca beceras Usa base 64 para codifi car , coge los bi ts de 6 en 6 y los repone por un car cter ( A-Z, a-z, 0-9 , +/), que en total s on 64: Protocolos de entrega final de correo: Son los encargados de interaccionar con el buzn de correo. Cada ci erto tiempo es tablece una conexin al puerto correspondiente en funci n de usa r IMAP/PoP, y mediante las reglas del protocolo el egi do se enca rga r de interaccionar. Ma ntener un MTA/hos t de us ua rio es cos toso se usa una es tafeta central de clientes de a cceso remoto. PoP: Post offi ce protocol : Dow n a nd delete. Funciona de manera que al hacer una lectura de correo, es te s e borra del servidor necesi tam os menos memoria pero al conecta rl o en otra MU A, ya no esta ba se a cab mejora ndo. Tiene tres es ta dos : Autoriza cin, transa cci n y actuali za cin.Sus limi ta ci ones son que no permi te des cargas pa rciales y no tiene ges tor de ca rpetas . IMAP4: Internet Messa ge Access Protocol : Nos permi te trabaja r con el correo com o si fuese local, y una ges tin remota de di rectorios mediante carpetas, as com o una des ca rga parcial de mensa jes ( ins peccin de ca beceras ). Tiene cua tro estados : No a utenti cado ( A), a utenti cado (A), selecci ona do (S), y des conexin (D): y WWW y transferencia de H ipertexto ( H TTP) WWW es una aplica cin basa da en transacciones ( s olici tudes/res puestas), segn el model o cliente- servi dor, que proporci ona una interfa z uni versal para el a cceso a informa ci n ( texto, im genes , audi o, vdeo, etc.. ) en Internet. Es els ti co, no requiere regis tros RTP. Ca da transaccin WWW es un intercambi o segn protocol o HTTP. Versin H TTP 1.0 No perm utado. Cli ente realiza apertura acti v ( conexin TCP al puerto 80). Soli ci ta tra nsacci n con a HTTP: usa GET-POST-HEAD -PUT-DELETE. EL servidor enva respues ta y tras eso, se cierra conexin. Servidor en modo pasi vo en puerto 80. HTTP usa TCP (Oa C) a ni v el de transporte. CC: hi pervncul o. Para identi fica rse usa U RL. El diagrama es SYN, SYN +ACK,ACK,GET,D ATA,FIN. Versin H TTP 1.1 Permutado: Es un protocol o s tateless sin es ta do, que no guarda el es ta do ( informaci n sobre soli ci tudes anteri ores). Hay un mecanism o aa dido de ma nera que en el cliente se guarda informa ci n s obre esa historia ; el server no la gua rda ( s tateless ) en funcin de la informaci n del cliente el servi dor da r un tratamiento diferencial . Es persis tente y usa pipeli ning. El dia grama es (Cliente primero) SYN , SYN + ACK, ACK, (otro GET CLIENTE tras ACK), DATA , G ET, ( 2 GET MAS D E CLIEN TE, IMPLEMENTA PIPELINING ). Una vez le ha llegado el recurso al cliente, este anali za la respuesta tras el get; esa res puesta tendr entre otras cosas extensiones MIME, y homeless type, que dir que es , si es audio, puede que se abra a utom ticamente un reproductor, etc.. Tras eso, en 1.0 se cerra ra la conexin, y en 1.1 se queda r esperando. El protocolo H TTp es t forma do por soli ci tudes y respues tas ( ambas orienta das a texto). Las soli ci tudes se llaman reques t line , y siem pre empiezan as . Se le indica al servidor cul es nues tro hos t, user Agent, etc.. de ma nera que pueda devolvernos una respuesta personai zada. En la cabecera i r n las cookies . Las respuestas ser n del tipo s tatus li ne ( Ok / ERROR / VERSION + CN + TEXTO EXP). NOTA: El get es el que ms se usa , y se le pueden pasar varia bles vinculndolas. Tema 6 RO. Seguridad en las Redes de Com uni cacin. Para que una red de comunica cin sea segura se tienen que garanti zar todos los aspectos que son: Confidencialidad y priva cidad: Aspecto ms clsi co, querem os que se ga rantice que ningn tercdero a cceda a esa i nformacin Integri dad: Pa ra todo intercam bio de i nforma cin, si un tercero al tera el conteni do, el sistema debe detecta r ese cam bio. Autenti ca ci n: Las enti dades tienen ga rantas de que la enti dad es t gara nti zada para ambas entidades de forma buena (feh). Irrepunciabili dad: U n sis tema no permi te el renunciamiento de la informa cin. Accesibili dad: El sis tema debe ser accesi ble. La s eguri dad hay que si tua rlas en todos los ni veles. La segurida d es un probl ema de la falta de saber, ha y que s ubi rlo has ta el ni vel que seam os capaces, ya que el grado de seguri dad l o fi ja el punto ms dbil . Los ataques s on atentados contra la seguridad del sis tema. Algunos tipos de ata que son: Sni ffing: Es cuchas ( husmear): Herramientas que permi ten la ca ptura de todas las transi ci ones. Spoofi ng: Suplantaci n de identi dad: a taque di recto a la a utenti cidad. Man in the middle: Hombre en medio ( interceptacin): ponemos un intermediario que interprete el tr fico suele i r acompaado de un spoofi ng. Deni d of servi ce: denegaci n de serv cio: confabula cin de m uchas entida des que i ponen en jaque la disponibilidad de un servi cio a ta que masi vo a un sis tema.

Una vez se ha es tableci do la as ociacin, ha y dos modos de operacin: Tra nsport: Permi te QoS al res petar la cabecera ori ginal . Es End to End. Implica que la entidad A extremo a extremo va a esta blecer la asocia cin de segurida d. Res peta la cabecera origi nal , i ntroducindole una pseudo cabecera. Puede que sea algo menos seguro porque se puede acceder a las Ips ( si hem os v to una p gina que no debiera). is Permi te QoS, porque D SCP tiene 6 bi ts en la cabecera con el perhop behaviour se puede ver el etiquetado permi tiendo realiza r as QoS: Tunnel : En es te caso, la asocia cin no es extremo a extrem o, en un sal to o router, de pronto entramos en una zona de seguri dad se esta blece esa asocia cin de seguridad entre dos routers sin necesida d de que sea extrem o a extremo. Coge el da to ori ginal y lo ca rga a s us es paldas , definiendo una nueva cabecera, que tendr la entra da y la salida del tnel. A la salida del tnel se hacen las operaciones inversas : Para ga ra nti zar la autenti cacin del ori gen e integridad de los da tos es necesa rio el protocolo de Cabeceras de a utenti caci n y se exigen por tanto la existencia de una autori dad previa . El numero de secuencia se incrementa por ca da data grama enviado. En los da tos de a utenti ca ci n ha y un com pendio MD5 o SHA fi rmado con clave secreta de la a utoridad. Se considera todo el da tagrama excepto los cam pos que cambia n a l o largo de la ruta para el compendio. Para el encaps ulado de seguri dad de la ca rga tambin se exige el esta blecimiento previo de la autoridad 5.2.SSL Secure Socket La y es un portocolo pa ra garanti zar la seguri dad en las er transacciones entre clientes y serv dores. Se reali za una a utenti caci n i mediante ci fra do con cla ve secreta . Permi te fragmentacin, com presin, encriptacin y transmisin. 1.H andshake protocol: i ntercambi o de m ensajes para negocia r e impl ementar (al gori tmo de ci fra do, autenti ca cin de servidor con cla ve publica -secreta) se genera la cla ve pri vada mediante Diffie Hell 2.SSL record protocol: forma to pa ra transmi tir los da tos proporcionando una conexin con pri v cida d, integridad y a confidencialidad (cla ve pri vada )

Tema 5. Los objeti vos de este tema son conocer como desarrolla r aplica ciones en Internet y en concreto familia ri zarnos con el model o cliente-servidor. En la capa de a pli cacin ha y procesos que tienen la necesidad de comuni carse entre s, entre hos ts diferentes son regulados mediante protocolos de apli caci n. y Modelo cliente-servidor: N os si tuamos en la ca pa de apli caci n. Objeti vo: procesos pueda n comuni ca rse entre s , y nos interesa ver como las a pli caciones interaccionan con la ca pa de trans porte, para lo que usan la capa de tra ns porte. A la interfa z entre la capa de apli cacin y de transporte se le llama interfaz socket. Toda rela cin a ni vel de aplica cin en i nternet rela ci ona entida des cliente y servidor, que son procesos en un S.O, que implementan una lgica en base a unos protocolos y que ofrece un determinado servi ci o. El cliente inicia mandando soli citudes y el servi dor respuestas. El modelo tiene un par de debilida des: 1) Rela ci n C-S fuertemente a coplada en el tiempo ( s e tienen que ejecutar a la vez en tiempo real 2) Acoplamiento espacial ( cliente necesita saber IP servidor). Tam bin hay otros mecanismos disti ntos como RSS o APLC. La publi ca cin/suscripci n funciona de ma nera que pueden es tar cliente y servidor fuertemente desacopla dos , por ejem plo ha y un sensor de tempera tura que publica peridicamente en un da taSpace las tempera turas del coche. No importa el a coplamiento espacial y temporal . Has ta la i nterfaz, la capa de trans porte es para el So y entre a pli caci n y us ua rio, ha y una serie de llama das al sistema de ma nera que se encarga de ha bla r con el SO, llamada API. Si tenemos una apli caci n en C, y necesi tam os pasa rle el control al So esta se encargar de traducirl o a ensambla dor. Se puede deci r que la i nterfa z Socket es el punto de pa rti da, ya que la gestin E/S del SO se basa en a bri r-leer/cerra r-escribi r. Se im plementa con llamadas al sistema ( open, read, wri te ,close). Es importante el concepto de des cri ptor de ficheros: las apli caci ones tambin pueden i ntera ctua r con fi cheros . Necesi tamos aadi r la identifi caci n de puntos finales , IP local , remota, puerto local y rem oto. Socket: Es un des criptor de una apli cacin a tra vs del cual la a pli caci n puede enviar y/o reci bi r informaci n ha cia y/o des de otro proceso de apli ca cin. Es una puerta de acces o entre apli ca ci n y servi ci os de trans porte. TCP/IP pa rte del SO, pa ra usarl o, se usa la Api , que consta de llamadas al sis tema . La i nterfa z socket no es pa rte de ningn protocol o ni es t vi nculado a ninguno. Funciones de la API BSD : Los tipos de servidores se pueden clasifi ca r en orientados/no orientados a conexi n y en iterati vos / concurrentes . Iterati vo no orientado a conexin: Iterati vo orientado a conexin: Para ver ejem plo cliente i tera ti vo el cdi go ( transp 12, 13) dijo q no entraba el cal vo.

y Sistemas de nom bres de dom inio: D NS. Se tiene una base de da tos muy grande, dis tri bui da por muchos s ervi dores que contribuyen a esa base de da tos. DN S es uno de los primeros protocolos creados, que an si gue siendo vlido fncional y trans pa rente ( tiene entre 10^3 -10^9 redes), y es es calable. Ofrece un servi ci o dis tribuido , jer rqui co y es calable de transla cin IP <--> DNS. Tam bin hay otro us o de DNS que consis te en determina r que mquina es el @domi nio.com con s u direcci n IP. DNS es un servici o end-to-end que reci be en los hos ts, por l o que la complejidad est en los extremos . Pa ra cada mquina ha y 10-15 s ervi dores DN S, lo que hace que sea bas tante tol erante a fallos , aparte de ser es calable, con m ucha cobertura y sea de f cil ma ntenimiento. El domini o ra z est gesti ona do por el ICANN. Se basa en consul ta respues ta . Siempre hay esa rela cin solici tud respuesta o quering. Procedimientos de resol uci n: Resolutor local: Lo pone el sistem a operativo para que gestiona la cach . Viene de inicializacin y guarda registros aprendidos. Lo normal es que no se tenga el registro. El puerto reservado para DNS es el 53. Por configuracin los So tienen servidor DNS. Por ejem plo, cada conjunto jerrquico tiene un conjunto de servicios. Si por

Explicar las difere ncias entre SCTP y TCP al transferir datos La diferencia mas im portante que introduce SSCTP es la siguiente: m ientras que TCP necesita una conexin por cada fluojo de datos, STC P permite varios streams de datos en un mismo paquete(paquete STCP=segmento). Esto requiere un nivel de direccionam iento extra: ha y que identificar el stram. Adems, SCTP incluye la posibilidad de m iltihoming: si emisio y/o receptor disponen de una dirIP puede enviarse una misma secuencia de paquetes por las distintas IPs. Identificar bajo que condiciones el inicio lento afecta ms a la latencia en TCP El inicio lento puede increm entar significativamente la latencia: si el objeto es grande y el R TT m oderado solo si R es alto; si el objeto es pequeo y el RTT moderado(no es tan severo, siem pre peor cuando el R es mayor); si el objeto es pequeo y el R TT es relativamente grande, incluso para R bajo. Algoritmo del c ubo de tokens Es un procedim iento que sirve para supervisar el tamao mximo de las rfagas y la velocidad m edia. Se generan tokens de forma periodica a la velocidad media a supervisar. El cubo tiene tam ao b(tamao de la rfaga a supervisar). Si el cubo se llena los tokens se pierden. Los paquetes superan el test cuando hay suficientes tokens en el cubo. Los tokens se eliminan al ir aceptando paquetes. C onsideraciones: 1)el numero mximo de paquetes cumplidores que pueden llenar el intervalo de tiempo t es rt+b. 2)los paquetes de entrada son no cumplidores si no hay tokens en el cubo. Estimar la latencia en transm itir un fichero mediante conex in TCP Suposiciones: no hay congestin, no hay retransmisiones, cabeceras de protocolos despreciables, tamao del objeto es numero entero de MSS, todo segmento TC P que no sea dato tiene un tiem po de tramision despreciable y no se entra en la zona de pre vencin de congestion. D isponemos de varios casos: a) CongWin=W(#MSS) estatica y RTT cte: si WS/R >R TT+S/R delay=2R TT+O/R si WS/R <R TT+S/R delay=2R TT+O/R+(k1)[S/R +R TT-WS/R] b)CongWin=W(#MSS) dinmica inicio lento y RTT cte. La latencia esta compuesta por tres trm inos: 2R TT pasa SYN y solicitud del objeto; O/R para transmitirlo; y las paradas del servidor debido al arranque lento. Sea P=nparadas=m in{k-1,Q}; Q=nparadas si el objeto fuera infinito y k=nventanas que cubren el objeto delay=O/R+2RTT+P(RTT+S/R )-(2^P-1)S/R donde Q=log2(1+R TT/S/R )+1; K=log2(O/S+1) Ejercicio de los r outers En primer lugar, vam os a explicar un poco en que consiste las consultas recursivas e iterativas: el tipo de consulta depende del cliente, si solicito una resolucin com pleta, esto generar una consulta recursiva; si no solicito una resolucin completa, se generar una resolucin iterativa. En primer lugar, el servidor raz nunca consulta a otros servidores. C uando un servidor(no raz) no puede resolver un dominio, consulta al raz otros servidores

habilitados para ese dominio y el raz le devuel ve la IP para contactarlos. As, si la consulta era recursiva, el servidor DN S que no puede resolver el nom bre, solicita al raz la direccin para consultar a un servidor D NS que pueda resolverla, el raz le consta y el servidor D NS enva la consulta recursiva a otro