요약

  • RFC 7145는 iSER 이니시에이터가 로컬 STag의 무효화를 피어에 의존할 수 없다고 규정합니다. Invalidate 포함 Send는 선택 사항이며, 무효화가 예상되는 경우 로컬 계층이 직접 태그를 확인하고 해지해야 합니다.
  • 이 규칙은 메시지 정확성뿐 아니라 리소스 수명을 보호합니다. 유효 상태로 남은 STag는 그 태그를 노출한 작업이 끝난 뒤에도 RDMA 지원 프로토콜을 통해 I/O 버퍼에 대한 접근 가능성을 유지할 수 있습니다.

명령은 끝났지만 권한은 그렇지 않을 수 있다

스토리지 명령에는 눈에 보이는 종료가 있습니다. 응답이 도착하고, 작업이 퇴역하며, 소프트웨어는 그 버퍼를 재사용하려 할 수 있습니다. RDMA는 여기에 덜 보이는 질문을 하나 더합니다. 그 메모리에 대한 원격 접근 능력은 실제로 사라졌는가? iSER에서는 스티어링 태그(Steering Tag, STag)가 한 노드가 광고한 I/O 버퍼를 식별하여 다른 노드가 RDMA 읽기나 쓰기를 수행할 수 있게 합니다. 식별자는 데이터 그 자체가 아니라, 피어가 데이터에 도달하는 경로의 일부입니다.

2014년에 RFC 5046을 갱신하는 문서로 발표된 RFC 7145는 최종 확인의 소유자가 누구인지 명확히 합니다. Invalidate 포함 Send는 타깃의 응답이 태그를 자동으로 무효화하도록 할 수 있지만, 그 메시지의 지원과 사용은 선택 사항입니다. 따라서 표준은 이니시에이터 측 iSER 계층이 원격 피어가 그 메커니즘을 채택하리라 기대해서는 안 된다고 규정합니다. 작업의 예상 결과가 유효하지 않은 STag라면, 로컬 계층은 그 태그를 확인하고 아직 유효하다면 무효화해야 합니다.RFC 7145

이 문구는 "타깃이 응답을 보내므로 버퍼는 안전하다"는 식보다 훨씬 신중합니다. 응답과 로컬 등록 상태는 서로 다른 사실입니다. 정상 완료는 광고된 STag를 무효화하라는 안내이며, 양방향 명령과 비정상 완료는 자동 무효화를 복잡하게 만듭니다. 양방향의 경우 하나의 Send-with-Invalidate 메시지는 하나의 태그만 지명할 수 있으므로, 이니시에이터는 다른 태그를 명시적으로 무효화해야 할 수 있습니다. 명령이 응답 PDU 없이 끝나는 경우, RFC 7145는 이니시에이터의 관련 태그를 찾아 무효화하는 별도의 작업 리소스 해제 경로를 규정합니다.

표준은 이 구분이 왜 중요한지 설명합니다. STag가 유지되면—예를 들어 재사용을 위해 캐시된다면—관련 I/O 버퍼는 원래의 iSCSI 작업을 넘어 RDMA 지원 프로토콜을 통한 네트워크 접근에 계속 노출됩니다. 문제는 유지된 모든 태그가 오용의 증거라는 것이 아닙니다. 완료된 명령만으로는 접근 창이 닫혔음을 증명할 수 없다는 점입니다. RFC 7145의 보안 섹션은 이 모호성에 대한 통제로 로컬 검증을 두고 있습니다.

이 설계는 유용한 유연성을 남겨 둡니다. 구현은 하위 RDMA 지원 프로토콜이 지원하는 경우 자동 무효화를 사용할 수 있고, 리소스 처리를 최적화할 수도 있습니다. 그러나 편리한 원격 동작만으로 로컬 상태 전이의 유일한 증거가 될 수는 없습니다. 이는 범위가 좁은 프로토콜 의무이며, 침해 사고의 보고도, 특정 벤더 구현에 대한 주장도, iSCSI와 하위 RDMA 프로토콜의 인증 및 더 넓은 보안 요구를 대신하는 것도 아닙니다. 이전 RFC 5046 문서는 이러한 메시지 변형에 더 많은 의존을 요구했고, RFC 7145의 변경 이력은 후속 문서가 보안상의 이유로 이니시에이터 측 무효화가 이니시에이터의 책임임을 명확히 했다고 밝힙니다.RFC 5046·RFC 7143출처:RFC Editor 정보 페이지.