요약

  • RFC 3385는 “32비트 체크섬”을 불완전한 설명으로 다뤘다. 미검출 오류 동작은 생성 다항식, 보호 블록 길이, 오류 분포, 실제 데이터 구조에도 달려 있었다.
  • 저자들은 선언된 우발적 손상 가정 아래에서 CRC32C가 iSCSI에 적합한 기본 오류 검출기라고 판단했다. 그러나 이를 암호학적 무결성 메커니즘이나 보편적 확률 보장으로 만들지는 않았다.

iSCSI 데이터 블록 옆에 4바이트 필드 두 개를 놓아 보자. 두 필드는 같은 전선 공간을 차지한다. 트레이스에서 똑같이 무작위해 보이는 값을 담을 수도 있다. 그러나 하나는 군집화된 손상 패턴을 안정적으로 드러내고, 다른 하나는 그냥 통과시킬 수 있다. 보이는 폭은 동일하지만 보호 수준은 같지 않다.

RFC 3385는 2002년 9월 미검출 오류 확률을 추정하고 iSCSI용 오류 검출 코드 선택을 지원하기 위해 공개되었다. 분류는 Informational이었다. 완전한 iSCSI 프로토콜을 규정하거나 구현을 인증하거나 현장 채택을 보고하지는 않았다. 그 역할은 분석적이었다. 안심시키는 레이블이 프로토콜 선택으로 굳어지기 전에 무결성 트레이드오프를 읽을 수 있게 만드는 일이었다.

iSCSI는 SCSI 명령과 스토리지 데이터를 IP 네트워크 너머로 옮기고 있었다. 스토리지 애플리케이션은 심각한 결과 모델을 가져왔다. 탐지를 피한 전송 오류가 겉보기에 유효한 콘텐츠로 장치나 파일시스템에 도달할 수 있었다. 데이터 양도 중요했다. 메모는 페타바이트 규모 전송을 가리켰고 최소한 8 KiB 블록까지 매우 좋은 동작을 요구했다.

이전 iSCSI 요구사항 문서인 RFC 3347은 일반 TCP 체크섬만으로는 충분하지 않은 이유를 설명했다. 연구에 따르면 일부 비트 오류는 TCP 체크섬을 통과할 수 있었다. 프록시나 게이트웨이는 TCP 스트림을 종료하고 iSCSI 헤더를 제거·재구성한 뒤 TCP 체크섬을 다시 계산할 수 있었다. 따라서 SCSI 데이터, 명령, 상태 보호에는 모든 하위 계층이 원래 증거를 보존한다고 맹목적으로 가정하는 대신 iSCSI에 속한 다이제스트 경계가 필요했다.

RFC 3385는 오류를 하나의 균일한 현상으로 취급하기를 거부하는 데서 시작했다. 잡음이 많은 채널의 버스트 오류와 저잡음 채널의 독립적 단일 비트 오류를 고려했다. 메모리 결함이나 소프트웨어 결함도 군집화된 패턴을 만들 수 있었다. 중요한 것은 비트가 얼마나 자주 바뀌는지만이 아니라, 바뀐 비트가 어떻게 분포하는지와 코드가 검사할 때 블록이 얼마나 긴지였다.

순환 중복 검사는 생성 다항식으로 계산한 패리티 비트를 덧붙여 코드워드를 만든다. 수신기에서는 오류 패턴 자체가 유효한 코드워드의 수학적 구조를 가질 때만 오류가 있는 워드가 수용될 수 있다. 따라서 최소 거리와 가중치 분포가 어떤 패턴이 보이지 않게 남는지를 좌우한다. “32비트”는 중복의 양을 말한다. 코드의 기하학을 말하지는 않는다.

그 구분은 단축 코드에서 더 날카로워졌다. 같은 차수의 서로 다른 생성 다항식은 코드워드가 실용적 블록 길이로 단축되면 다르게 동작할 수 있었다. 메모는 특정 버스트 조건에서 32비트 다항식들 사이에 수 자릿수 규모의 차이가 난다는 연구를 인용했다. 폭 비교는 바로 분석이 분기한다고 보여준 지점에서 그 코드들을 동등하다고 분류할 것이다.

익숙한 IEEE 802 다항식과 CRC32C는 모두 32비트 CRC였다. CRC32C는 생성자 0x11EDC6F41을 사용했다. 다른 다항식은 겉치레 구현 세부사항이 아니었다. 관련 범위에서 최소 거리 동작을 바꾸었고, 따라서 어떤 오류 패턴이 보장되거나 검출될 가능성이 높은지를 바꾸었다.

이 논문의 추정치는 명시적으로 조건부였다. 버스트 오류율, 독립 비트 오류율, 버스트 지속 시간 분포를 가정했다. 전송 속도가 높아지면 고정 지속 시간 버스트를 더 많은 손상 비트로 환산했다. 또한 8 KiB 보호 단위에 대해 추론했다. 그 결과 확률은 이런 입력에서 자유롭게 떠다니지 않는다. 채널, 워크로드, 블록, 분포를 바꾸면 할 수 있는 주장도 바뀐다.

이 점은 하나의 숫자가 우주적으로 보일 수 있기 때문에 특히 중요하다. 메모는 선언된 가정 아래에서 CRC32C의 미검출 버스트 오류에 대해 극히 낮은 추정치를 도출했다. 그것은 모든 네트워크에서 측정한 값도 아니고, 어떤 배포가 그 비율을 경험하리라는 보증도 아니다. 그것은 모델의 출력이다. 올바른 증거 형식은 “이 가정들이 주어졌을 때 이 코드는 이 한계를 산출했다”이지, “CRC32C는 상상할 수 없이 많은 사건 중 한 번만 실패한다”가 아니다.

Fletcher 및 Adler 체크섬과의 비교는 두 번째 교훈을 주었다. 분석된 독립 오류 조건에서 메모는 CRC 성능이 Fletcher보다 약 12,000배, Adler보다 약 22,000배 우수하다고 추정했다. 또한 덧셈식 체크섬이 놓칠 수 있는 단순한 다중 바이트 오류 패턴도 강조했다. 실제 데이터는 균일하게 무작위하기보다 편향될 수 있었고, 인용된 실험에서는 체크섬이 이런 핫스폿에서 상당히 취약한 반면 CRC는 민감도를 다르게 분산한다는 점을 발견했다.

요약 표는 동일 폭 비교를 구체화했다. Fletcher32, Adler32, IEEE-802 CRC, CRC32C는 모두 32비트를 가졌지만, 표는 이들에게 서로 다른 최소 거리 범위와 모델 의존적 미검출 오류 추정치를 부여했다. 저자들은 CRC32C가 보호 수준, 편향된 데이터에 대한 상대적 둔감성, 큰 블록 보호 능력을 결합했기 때문에 iSCSI에 좋은 기본 메커니즘이라고 결론지었다.

비용도 결정의 일부로 남았다. 인용된 종합 검토는 후보 다항식에 대해 XOR 게이트와 최적화 셀을 셌다. 그 설정에서 CRC32C는 CCITT-CRC32보다 더 많은 하드웨어 비용이 들었다. 그러나 CRC 회로는 대표적인 100만 셀 칩의 1퍼센트 미만을 차지했다. 문서는 비용을 지우지 않았다. 무결성 이득 옆에 놓아 선택이 올바른 규모에서 판단될 수 있게 했다.

소프트웨어와 하드웨어 경로도 중요했다. 메모는 직렬 및 32비트 병렬 구현을 포함했고, 소프트웨어는 흔히 입력 데이터와 현재 상태로 인덱싱되는 테이블을 사용한다고 언급했다. 표준 다항식만으로는 이름만으로 상호운용성을 확보할 수 없었다. 비트 순서, 초기화, 보수화, 패딩, 최종 나머지 매핑에도 정확한 계약이 필요했다.

CRC의 선형성은 증분 갱신 옵션을 만들었다. 중간 노드가 보호 대상 헤더를 변경하면 전체 데이터 블록을 다시 읽고 재계산하는 대신 알려진 델타를 사용해 CRC를 조정할 수 있었다. 최종 타깃은 경로를 따라 도입된 원치 않는 변경을 포함해 결합된 헤더, 데이터, CRC를 여전히 검증할 수 있었다. 이는 성능과 커버리지 속성이었지, 모든 미들박스 변경을 신뢰하라는 허가가 아니었다.

통합 iSCSI 명세인 RFC 7143은 나중에 운영 계약을 명시했다. HeaderDigest와 DataDigest의 기본값은 None이며, 모든 이니시에이터와 타깃은 CRC32C와 None을 구현해야 한다. 피어가 다이제스트를 협상하면 Full Feature Phase 전체에 적용된다. 명세는 이 다이제스트를 비암호화 방식이라고 부르며, 네트워크 수준 PDU를 수정할 수 있는 요소를 포함해 통신 경로 전반의 오류 검사를 확장한다고 말한다.

그 이후의 계약은 서로 합쳐서는 안 되는 여러 사실을 만든다. 구현이 CRC32C를 지원할 수 있다. 세션이 이를 제공할 수 있다. 피어가 이를 선택할 수 있다. 특정 PDU가 성공적으로 검증될 수 있다. 그 사실들 중 어느 하나만으로 CRC32C가 모든 연결에서 활성화되었다거나, 보호된 바이트가 운영자의 정신 모델과 일치했다거나, 보호 경로가 끝난 뒤에도 저장 콘텐츠가 정확하게 남았다고 증명되지는 않는다.

보안 경계는 명확했다. 데이터를 수정할 수 있는 공격자는 오류 검출 값도 수정해 새 쌍이 검증되게 할 수 있다. 이 메모의 CRC는 의도하지 않은 변경을 검출한다. 송신자를 인증하거나 권한을 결속하거나 악의적 변조를 막지는 않는다. 통과한 CRC는 일부 우발적 오류 패턴에 대한 증거이지, 적극적인 공격자에 대한 증거가 아니다.

같은 CRC32C 다항식은 RFC 3309가 문서화한 SCTP 변경과 RFC 4960, RFC 9260 같은 이후 SCTP 명세에도 등장했다. 그 연대기는 잘 연구된 코드의 재사용을 보여주지만, 모든 사용 사례를 동등하게 만들지는 않는다. 서로 다른 패킷 길이, 보호 필드, 하위 계층, 실패 분포, 복구 규칙은 서로 다른 증거 표면을 만든다.

초기 인터넷 체크섬 작업은 또 다른 유용한 경계를 제공한다. RFC 1071은 인터넷 체크섬의 효율적 계산을 문서화했다. RFC 1141과 RFC 1624는 이전 공식의 오류를 포함해 증분 갱신을 다뤘다. RFC 2151은 대체 UDP 체크섬용 Fletcher 체크섬을 설명했고, RFC 1950은 zlib 형식에서 Adler-32를 사용했다. 이 문서들은 “체크섬”이 하나의 상호 교환 가능한 보증 수준이 아니라 여러 목적과 산술 구조의 계열을 가리킨다는 점을 보여준다.

메모는 시스템 경고로 끝났다. 고정 시간으로 특징지어지는 버스트는 채널 속도가 높아질수록 더 많은 비트를 차지한다. 상위 계층 CRC는 보호 단위에 대한 검출을 개선할 수 있지만, 물리적·하위 계층 조건이 진화할 때 장기 위험을 그 자체로 일정하게 유지할 수는 없다. 더 나은 코딩과 하위 계층의 더 낮은 비트 오류율은 여전히 통제 표면의 일부다.

Lu Heng의 최소 초기 명세 렌즈는 구현이 하드웨어와 소프트웨어 자유를 유지하는 동안에도 다항식과 다이제스트 절차를 고정해야 했던 이유를 설명한다. 명세는 공유 결정을 국지화해야 했다. 정확한 생성자, 비트 매핑, 협상된 보호 범위가 그것이다. 모든 구현이 통과한 다이제스트에 대해 같은 의미를 가진 뒤에야 최적화를 구현자에게 맡길 수 있었다.

그의 현실 계층 렌즈는 폭 레이블의 위험을 드러낸다. 필드 존재, 알고리즘 지원, 다이제스트 협상, PDU 보호, 값 검증, 모델 아래에서 우발적 손상 배제, 적대적 무결성 확립은 서로 다른 사실이다. “32비트 체크섬이 있다”는 이 일곱 가지를 거의 아무것도 증명하지 못하는 하나의 기호로 압축한다.

따라서 RFC 3385의 역사적 기여는 단순히 CRC32C를 권장한 것이 아니었다. 무결성 구호를 경계 지워진 증거 주장으로 바꾸는 방법을 보여주었다. 비트 수는 보이는 껍데기였다. 다항식, 블록, 워크로드, 경로, 위협 모델이 그 껍데기가 정직하게 무엇을 의미할 수 있는지 결정했다.

출처