13 Oct
2008
13 Oct
'08
3:46 p.m.
El día 13 de octubre de 2008 13:16, Raúl Alexis Betancor Santana
<rabs(a)dimension-virtual.com> escribió:
Yo creo que es mejor la opción de no crear la
transacción hasta que llegue
autenticada, lo que comenta Bogan me parece una soberana estupidez.
En el escenario 1 es muy dificil (o directamente imposible) agotar los recursos
del servidor, en el segundo caso es tremendamente fácil agotar los recursos
del servidor, de hecho con el segundo escenario no se evita el potecial
problema de DoS que per sé genera.
El argumento que da él es que en el primer si llega una retransmisión
(que no es detectada como tal pues fue rechazado el request original
stateless) entonces el servidor debe procesar de nuevo la
autenticación, lo que conlleva tareas de IO (consulta SQL, LDAP...).
NOTA: Siempre estamos hablando del segundo request que envía el UA
tras solicitársele autenticación, que será una transacción nueva
(nuevo branch). Es cecir:
- UA envía INVITE (req1).
- Proxy responde 407 stateless
- UA envía INVITE con Authorization (req2).
- Proxy procesa la autenticación. Dura tiempo porque hay LDAP...
- Durante ese procesamento llega una retransmisión de req2.
- Como el proxy no ha creado una transacción aún, considera este
request como nuevo y procesa también la autenticación (LDAP...).
Esto último es negativo pues cuanto más se estrese al servidor de
autenticación (LDAP o lo que sea) peor. Yo creo que en un escenario
así (donde la autenticación toma tiempo) sí que puede ser bueno crear
la transacción justo antes del proceso de autenticación (eso sí, sólo
para requests que contengan la cabecera "(Proxy-)Authorization".
--
Iñaki Baz Castillo
<ibc(a)aliax.net>