Hola, el RFC 3261 dice, en alguna parte que no recuerdo, que es
aconsejable que un proxy/server no cree una transacción hasta que no
se haya autenticado el request (si procede). El argumento es que una
transacción consume recursos y que un atacante malicioso podría enviar
una burrada de requests en paralelo para saturar el proxy/server. Es
decir:
1 - Llega un request (req1).
2 - El proxy comprueba que no tiene cabecera de autenticación y lo
rechaza, stateless, con un 401/407.
3 - El UAC repite el request con autenticación (req2).
4 - El proxy lo recibe y calcula el digest y tal y da por buena la
autenticación.
5 - Entonces el proxy crea la transacción.
6 - Llega una retransmisión de req2 y el proxy responde lo último que
se le respondió ("matchea" la transacción).
Pero en un hilo en la lista de OpenSIPS, Bogdan me comenta que crear
la transacción antes de autenticar puede ser positivo ya que evita el
proceso de autenticación en retransmissiones del request. Es decir:
1 - Llega un request (req1).
2 - El proxy crea la transacción.
3 - El proxy comprueba que no tiene cabecera de autenticación y lo
rechaza, stateful, con un 401/407.
4 - El UAC repite el request con autenticación (req2).
5 - El proxy lo recibe y se pone a calcular el digest, pero le lleva un rato.
6 - Llega una retransmisión de req2 y como ya existe la transacción no
se procesa de nuevo la autenticación (BIEN).
7 - El proxy da por buena la autenticación previa.
6 - Llega una retransmisión de req2 y el proxy responde lo último que
se le respondió ("matchea" la transacción).
Ambas formas tienen sus inconvenientes, ¿cuál creéis que es mejor?
Saludos.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>