STOP draft-ietf-simple-msrp-sessmatch
Iñaki Baz Castillo
algunos procesos de estandarización en el IETF, concretamente en el
SIMPLE WG. Me refiero concretamente al draft
draft-ietf-simple-msrp-sessmatch:
http://tools.ietf.org/html/draft-ietf-simple-msrp-sessmatch-11
A modo de introducción MSRP es una especificación para sesiones de
mensajería instantánea y transferencia de ficheros (u otras cosas)
diseñado para funcionar con SIP. La especificación queda definida
básicamente con dos RFC's:
RFC 4975 - The Message Session Relay Protocol (MSRP)
- http://tools.ietf.org/html/rfc4975
- Define el protocolo MSRP en sí (sesiones TCP/TLS negociadas mediante
SDP con INVITE/200, etc).
RFC 4976 - Relay Extensions for the Message Session Relay Protocol (MSRP)
- http://tools.ietf.org/html/rfc4976
- Define servidores MSRP de relay para clientes tras NAT (básicamente).
Aún no hay muchas implementaciones (al margen de los laboratorios de
los grandes fabricantes que se preparan para IMS), pero promete tener
éxito (a mí al menos me gustan los RFC).
Pero de repente resulta que fabricantes de routers y "cosas" SIP
quieren implementar ALG-MSRP para que los propios routers hagan
ciertas modificaciones en los SDP de negociación MSRP y asuntos como
el NAT o "topology hidding" queden resueltos a nivel IP/TCP sin tener
que emplear servidores MSRP relay.
No hace falta que recuerde lo catastrófico que ha sido para el mundo
SIP la proliferación de routers con SIP ALG activado, que en el 90% de
los casos revientan la señalización SIP de una forma u otra:
http://www.voip-info.org/wiki/view/Routers+SIP+ALG
En el caso de MSRP esto es aún peor, ya que en MSRP se usa
(opcionalmente) autenticación TLS basada en nombre (un nodo recibe una
conexión TLS presentando un certificado e indicando un URI en el
mensaje MSRP) ya que al colocarse en medio el router ALG cambia el
origen y dicha autenticación falla. Esto está explicado en el propio
draft:
http://tools.ietf.org/html/draft-ietf-simple-msrp-sessmatch-11#section-6.3
También resulta que con la introducción de esos dispositivos ALG,
aquellos usuarios que usen un MSRP relay no pueden comunicarse con
usuarios tras el router ALG. Y lo peor de todo, un cliente MSRP debe
implementar este draft para poder funcionar en redes en las que haya
un dispositivo ALG-MSRP implementando esta especificación (esto
básicamente significa que el fabricante de los routers ALG-MSRP será
también quien pueda ofrecer los "terminales MSRP certificados para
funcionar con sus routers". Lamentable, ¿no?
Todo esto que digo está claramente documentado y es conocido:
http://blog.tekelec.com/blog/bid/29816/More-on-MSRP-Session-Match-Extension
http://blog.tekelec.com/blog/bid/33138/MSRP-Session-Match-Backwards-Compatibility
Aún así, el draft sigue adelante (ya va por la versión 11) y está
claro que verá la luz como RFC. Un RFC que revienta el protocolo en el
que se basa (MSRP) para satisfacer las demandas de los fabricantes y
convertir MSRP en una nueva utopía (como la presencia SIMPLE, con
éxito cero en Internet y sólo adoptada por los grandes telcos/vendors
de cara a IMS en sus redes privadas).
A mí me parece bastante bochornoso y me ha supuesto una visión muy fea
de cómo funcionan los procesos de estandarización (deciden los que
tienen pasta y en su propio beneficio). En fin... ahí lo dejo.
--
Iñaki Baz Castillo
<i...@aliax.net>