Resumen
- RFC 7145 establece que el iniciador iSER no puede confiar en que el par invalide un STag local: Send with Invalidate es opcional y, cuando se espera la invalidación, la capa local debe comprobarla y ejecutar la revocación si hace falta.
- No es solo una regla sobre mensajes: un STag todavía válido puede mantener accesible por RDMA el búfer de E/S después de la tarea que lo anunció.
La tarea terminó; el acceso quizá no
El final de una orden de almacenamiento parece claro: llega la respuesta, se cierra la tarea y el software puede querer reutilizar el búfer. Con RDMA queda una pregunta menos visible: ¿se retiró realmente la capacidad de acceso remoto a esa memoria? En iSER, el Steering Tag (STag) identifica un búfer de E/S que un nodo anuncia para que el otro lo lea o escriba directamente mediante RDMA. No contiene los datos: ayuda a localizar la región que queda expuesta a la operación.
Publicado en 2014 como actualización de RFC 5046, RFC 7145 define quién debe hacer la última comprobación. Send with Invalidate puede invalidar automáticamente un tag al llevar la respuesta de la entidad de almacenamiento, si el protocolo RDMA lo admite. Sin embargo, su uso es opcional. Por eso, el iniciador no debe dar por hecho que el par eligió esa vía. Si al terminar la tarea el STag debe quedar inválido, la capa iSER local tiene que comprobarlo e invalidarlo si continúa vigente. RFC 7145
La respuesta recibida y el estado del registro de memoria local no son el mismo hecho. El estándar recomienda invalidar el STag anunciado al completar normalmente la tarea, pero las órdenes bidireccionales y las finalizaciones anómalas complican la invalidación automática. Además, el mensaje Send with Invalidate solo puede nombrar un STag; en ciertos casos bidireccionales el iniciador debe invalidar el otro de forma explícita. Si la orden termina sin una PDU de respuesta, RFC 7145 prescribe otra ruta: liberar recursos de la tarea, localizar los tags asociados e invalidarlos.
La motivación es la vida útil del recurso. Si se conserva un STag —por ejemplo, para reutilizarlo—, el búfer asociado sigue expuesto al acceso de red por la capa RDMA después de la operación iSCSI que lo anunció. Conservarlo no prueba que alguien lo haya usado indebidamente; sí prolonga el intervalo de exposición. La conclusión de una orden, por sí sola, no prueba que la ventana de acceso se haya cerrado.
El diseño permite optimizar: cuando el protocolo RDMA subyacente lo admite, puede aprovecharse la invalidación automática. Lo que no permite es usar una acción remota opcional como única prueba de una transición de estado local. RFC 7145 no documenta un ataque, un defecto de proveedor ni la frecuencia de incumplimiento. Tampoco sustituye los requisitos de autenticación y seguridad de iSCSI y del transporte RDMA. El historial de RFC 5046 explica que la nueva redacción aclaró que la invalidación local corresponde al iniciador por motivos de seguridad. RFC 5046 · RFC 7143 Fuentes: Ficha informativa del RFC Editor.
Informe para miembros
Contexto ampliado del perfil
Inicia sesión con el nivel de membresía adecuado para desbloquear el informe completo y las notas de las fuentes.
Solo para Strategic Circle
Strategic Circle
Abierto a todos los lectores. Desbloquea informes de perfil después de unirte e iniciar sesión.
Únete a Strategic CircleSolo para Leadership Alliance
Leadership Alliance
Para propietarios y directivos cualificados de activos de propiedad intelectual; inicia sesión para desbloquear los informes de la alianza.
Unirse a Leadership Alliance
