요약

  • RFC 791의 타입 130 옵션은 보안, 컴파트먼트, 취급 제한, 전송 제어 필드를 담은 고정 11옥텟 라벨이었으며, 이후 RFC들은 타입 값을 유지한 채 그 형식을 교체했습니다.
  • RFC 1108의 기본 보안 옵션(Basic Security Option)은 분류 레벨과 보호 권한을 인터페이스별 수용 정책의 입력으로 만들었고, 배포 환경에 따라 명시적 또는 암묵적 라벨을 사용했습니다.
  • RFC 1108이 Historic(역사적) 상태가 되고 이런 패킷은 공개 인터넷에서 원칙적으로 나타나지 않아야 함에도, 이후 지침은 일반 장비가 기본 설정으로 이를 제거하거나 폐기하지 않도록 경고했습니다. 그렇게 하면 폐쇄형 MLS 네트워크 내부의 데이터에 잘못된 민감도를 부여할 수 있기 때문입니다.

라벨을 제거하면 정보 자체가 달라질 수 있다

이 이야기에서 가장 영향력 큰 행위는 보안 필드를 추가하는 것이 아니라 삭제하는 것입니다.RFC 7126은 전송 도중 기본 보안 옵션이 제거되면 수신 측이 더 이상 제대로 라벨링되지 않았다는 이유로 패킷을 거부할 수 있다고 경고합니다. 어떤 상황에서는 데이터를 수용하되 잘못된 민감도를 그 데이터에 연결할 수도 있습니다.

오류는 양방향으로 발생할 수 있습니다. 정보를 실제보다 민감한 것으로 다루는 상향(업그레이드) 오류는 정당한 사용을 차단하고 상위 시스템을 오염시킬 수 있습니다. 실제보다 덜 민감한 것으로 다루는 하향(다운그레이드) 오류는 정보를 받아서는 안 되는 영역에 노출시킬 수 있습니다. "보안처럼 보이는" 필드를 제거한 방화벽은 위협을 중화한 것이 아니라, 수신자의 대체 규칙을 모른 채 정책 입력을 바꾼 것입니다.

타입 130은 바로 이 관점에서 읽어야 합니다. 이 옵션은 암호학이 아닙니다. 페이로드를 암호화하거나, 발신자를 인증하거나, 보안 등급을 증명하지 않습니다. 신뢰 시스템이 소비하는 라벨이며, 패킷 자체에 없는 권위는 그 시스템의 구성이 공급합니다.

첫 번째 형식은 네 가지 제어를 담으려 했다

RFC 791은 보안(Security)을 타입 130의 옵션으로 정의하며 길이를 고정 11옥텟으로 정했습니다. 타입과 길이 뒤에는 네 개의 필드가 이어졌습니다. 16비트의 보안(Security), 16비트의 컴파트먼트(Compartments), 16비트의 취급 제한(Handling Restrictions), 24비트의 전송 제어 코드(TCC)입니다.

보안 필드는 이름 붙은 레벨 집합 중 하나를 선택했습니다. 컴파트먼트 필드는 트래픽을 통제된 범주로 나눴습니다. 취급 제한은 통제 및 해제 마킹을 가리켰습니다. TCC는 통제된 관심 집단을 정의했습니다. 헤더는 "기밀" 또는 "비기밀"이라고만 말한 것이 아니라 외부 정보 통제 체계의 여러 차원을 함께 담으려 했습니다.

이 옵션에는 복사 비트가 설정되어 있었습니다. 단편화 시 모든 단편에 배치되었고, 하나의 데이터그램에는 최대 한 번만 담길 수 있었습니다. IPv4가 패킷을 나눈다고 해서 단편이 라벨에서 벗어나도록 의도된 것은 아니었습니다.

RFC 791은 옵션에 대해 이례적으로 넓은 선언도 했습니다. 특정 데이터그램에 옵션이 존재하는 것은 선택 사항이지만, IP 모듈이 옵션을 구현하는 것은 선택이 아니라는 것입니다. 일부 환경은 모든 데이터그램에 보안 옵션을 요구할 수 있다고 명시했습니다. 전역 패킷 형식은 그 필요성이 전적으로 접속된 보안 환경에 의존하는 규칙을 수용하고 있었던 것입니다.

그 어떤 필드도 암호학적 무결성을 공급하지 않았습니다. 라벨을 복사한다고 그것이 참이 되지 않습니다. 그 효과는 신뢰할 수 있는 출처, 신뢰할 수 있는 중계자, 구성, 보호된 네트워크에 의존했습니다.

타입 연속성은 형식 교체를 감췄다

1988년RFC 1038은 타입 130을 가변 길이의 기본 보안 옵션으로 개정했습니다. 고정된 컴파트먼트, 취급 제한, TCC 배치를 분류 레벨과 보호 권한 플래그로 대체한 것입니다. 동일한 숫자 옵션 타입이 이제 전혀 다른 본체를 도입했습니다.

이 구분은 파서와 역사 연구자 모두에게 필수적입니다. 레지스트리의 값은 그대로 유지되면서 그 명세가 호환되지 않게 바뀔 수 있습니다. 바이트가 130이라는 사실만으로는 부족하며, 길이와 적용되는 RFC가 나머지를 어떻게 읽어야 하는지를 결정합니다.

RFC 1038은 이 라벨을 신뢰 구성 요소가 발신 전송을 검증하고, 경로와 목적지가 요구되는 수준으로 보호되는지 확인하고, 정보 통제 모델에 공통 라벨을 제공하는 데 사용할 수 있는 것으로 묘사했습니다. 그 주장은 옵션의 존재가 아니라 보안 인식 라우팅과 인가된 구성 요소에 의존했습니다.

그 개정 자체도 과도기적 것이었습니다.RFC 1108은 RFC 1038을 폐기하고 국방부 기본 및 확장 보안 옵션을 규정했습니다. 타입 130은 기본 보안 옵션으로 남았지만 최소 길이마저 달라졌습니다. RFC 1108은 보호 권한 필드가 없을 때 세 옥텟을 허용합니다.

분류 값은 의도적으로 나쁜 산수였다

RFC 1108은 분류 레벨(Classification Level)에 한 옥텟을 배정했습니다. 유효한 비트 패턴은 드물었습니다. 특정 비트열은 기밀(Top Secret), 비밀(Secret), 취급 제한(Confidential), 비분류(Unclassified)를 뜻했고, 나열된 다른 비트열들은 예약 상태로 남았습니다.

수 값의 순서는 분류 순서가 아니었습니다. 순서는 표가 정의했습니다. 구현은 비트열 비교로 등가 여부를 검사할 수 있었지만, 단순 산술 범위 검사로 한 바이트가 Confidential과 Secret 사이에 있다고 판정할 수는 없었습니다. 그런 범위에는 무효 또는 미할당 패턴이 포함됩니다.

인코딩은 유효한 값들 사이에 최소 해밍 거리 4를 유지하도록 선택되었습니다. 소수의 비트 반전이 한 유효 분류를 다른 유효 분류로 바로 바꿀 가능성을 낮추기 위함입니다. 이것은 오류 감지 거리이지 암호화나 진위 보증이 아닙니다. 공격자나 결함이 있는 발신자는 여전히 유효한 코드를 쓸 수 있으며, 이 필드는 출처에 대한 어떤 증명도 제공하지 않습니다.

설계는 정책 순서를 수치 순서 밖에 두었습니다. 소프트웨어는 크기에서 의미를 추론하는 것이 아니라 할당된 표를 알아야 했습니다. 라벨은 바이트에 인코딩된 통제된 어휘였지, 민감도를 크기로 표현하는 정수가 아니었습니다.

권한 플래그는 자격 증명이 아니라 규칙이었다

분류 바이트 다음으로 RFC 1108은 가변 길이의 보호 권한(Protection Authority) 필드를 허용했습니다. 각 옥텟의 상위 7비트는 플래그였고, 최하위 비트는 옥텟이 하나 더 이어지는지를 나타냈습니다. 여러 권한이 하나의 데이터그램에 적용될 수 있었고, 최소한의 준수 구현은 최소 두 옥텟의 플래그를 처리할 수 있어야 했습니다.

플래그는 그 보호 규칙이 정보에 적용되는 프로그램들을 식별했습니다. RFC 1108은 표면적으로 유사한 의미에도 불구하고 이것이 인가(accreditation) 권한이 아니라고 명시적으로 경고했습니다. 호스트를 인증하거나 사용자에게 등급을 부여하지 않습니다.

인코딩은 최소여야 했습니다. 뒤에 붙은 모든 0인 연속 옥텟은 없어야 했습니다. 표시된 플래그 필드 길이는 옵션 길이와도 일치해야 했습니다. 잘못된 형식의 확장은 프로토콜 오류이지, 알려지지 않은 배지의 무해한 목록이 아니었습니다.

이 확장 가능한 필드는 패킷 밖에 있는 또 하나의 권위 원천을 드러냅니다. 누군가는 플래그 할당을 승인하고 공표해야 했습니다. 옵션은 그 관리되는 네임스페이스에서 선택한 것을 담을 뿐, 자신이 호출하는 규칙을 만들지 않았습니다.

모든 인터페이스는 분류 경계가 될 수 있었다

RFC 1108은 시스템 전역 및 포트별 보안 매개변수를 기술했습니다. 여기서 "포트"는 TCP 또는 UDP 포트 번호가 아니라 네트워크 접속 지점 또는 인터페이스 정책 경계를 뜻합니다. 구성은 송신 시, 수신 시, 둘 다, 혹은 둘 다가 아니도록 기본 보안 옵션을 요구할 수 있었습니다.

분류된 데이터를 처리하는 시스템은 일반적으로 이 옵션을 생성해야 했습니다. 예외는 전용 또는 system-high 네트워크로, 트래픽이 각 데이터그램에 명시적 라벨을 담는 대신 인터페이스로부터 암묵적 라벨을 받을 수 있었습니다. 로컬 정책이 라벨 없는 패킷을 허용한다면, 수신 포트에 구성된 암묵적 라벨이 빠진 문맥을 공급했습니다.

이 치환이 제거가 위험한 이유를 설명합니다. 동일한 라벨 없는 패킷이 어떤 인터페이스에서는 "보통의 비분류 트래픽"을, 다른 인터페이스에서는 "이 보호 수준에 암묵적으로 해당하는 트래픽"을 의미할 수 있습니다. 명시적 라벨을 제거하는 것은 중립적인 값을 만들어내는 것이 아니라, 정책이 다른 라벨 원천을 선택하게 만들 수 있습니다.

입력 처리는 먼저 분류 바이트가 할당된 값인지 검증합니다. 이어서 데이터그램 레벨을 수신 포트의 최대값과 비교하고, 권한 플래그가 인바운드로 허용되는지 확인합니다. 출력 정책도 마찬가지로 데이터그램 레벨이 포트에 구성된 최소값과 최대값 사이에 있고 플래그가 아웃바운드 권한 집합에 맞는지를 요구합니다.

패킷은 제안된 라벨 데이터를 제공합니다. 인터페이스는 허용 가능한 범위를 공급합니다. 수용 여부는 이 둘의 비교에서 나옵니다.

오류 역시 보안 결정이었다

인터페이스가 BSO를 요구했는데 아무것도 받지 못했다면, RFC 1108은 요구된 필수 옵션이 없다는 의미의 코드 1을 사용하는 ICMP 매개변수 문제(Parameter Problem) 응답을 지정했습니다. 형식이 잘못된 라벨에는 일반 매개변수 문제 형식을 사용했고, 범위를 벗어난 라벨에는 행정적으로 금지된 목적지 도달 불가(destination-unreachable) 응답을 내보낼 수 있었습니다.

그러나 이것들은 허용된 조치 중 가장 제한이 적은 것이었습니다. 로컬 정책은 로깅을 요구하거나, 보안 담당관에게 경보를 보내거나, 어떤 응답도 금지할 수 있었습니다. 진단 경로조차 응답이 나가게 될 인터페이스의 분류를 존중해야 했습니다.

이것은 모든 누락된 IPv4 옵션이 동일한 응답을 유발한다는 재사용 가능한 주장이 아닙니다. 침묵, 오류, 응답 라벨링 모두가 통제된 결정이었던 정책이 풍부한 환경입니다. ICMP의 누락 옵션 코드를 다룬 이전 글이 그 오류 문법을 연구했고, 여기서는 라벨이 강제되는 입장 시스템의 일부였다는 증거로만 중요합니다.

호스트는 구 형식을 폐기라고 불렀고 라우터는 수정된 것을 유지했다

RFC 1122는 RFC 791과 RFC 1038이 기술한 보안 옵션들이 폐기되었다고 말했습니다. 그러나 모든 보안 라벨 환경이 사라졌다고는 말하지 않았습니다. 국방부(DoD) 응용에 대해서는 RFC 1108이 된 수정 지침으로 공급업체를 안내했습니다.

RFC 1812는 이 구분을 운영 수준으로 만들었습니다. RFC 791 및 RFC 1038 버전이 폐기되었다는 점을 반복하면서도, 라우터는 수정된 RFC 1108 옵션을 구현해야 한다고 말했습니다. 다중 보안 레벨용 라우터는 IPSO 라벨 기반 필터링을 지원해야 했습니다.

그 모델은 각 인터페이스에 하한과 상한 민감도 한계를 부여했습니다. 그 범위를 벗어난 패킷은 조용히 폐기되어야 했고, 범위 이탈 이벤트는 카운터에 기록되어야 했습니다. 이것은 일반적인 소스 라우팅이나 경로 목록이 아니었습니다. 라우터는 각 경계에서 로컬 허용 가능성 검사를 적용했습니다.

따라서 표준 지위를 단일 스위치처럼 읽을 수 없습니다. 한 형식이 폐기되고, 그 교체품은 조건부 라우터 기능으로 남으며, 프로토콜 문서는 나중에 Historic이 되고, 운영상의 필요는 제한된 영역 안에서 계속됩니다.

Historic은 부재를 의미하지 않았다

RFC 7126은 이런 라벨들이 전역 공개 인터넷에서는 원칙적으로 나타나지 않아야 한다고 말합니다. 그러나 결정적인 예외도 기록합니다. 민간의 다중 레벨 보안(MLS) 네트워크들이 상용 및 오픈소스 시스템에서 기본 및 확장 보안 옵션을 사용하고 있었다는 것입니다. 이 문서는 그 MLS 배포, 따라서 IPSO 배포가 IESG가 이 옵션을 표준 트랙에서 제외할 때보다 더 클 수 있다고 판단했습니다.

이것은 단순한 폐기 서사의 정반대입니다. 메커니즘은 공개 표준의 주류에서 물러나면서 전문화된 운영 영역 안에서 성장할 수 있습니다. "Historic"은 RFC의 표준 지위를 묘사할 뿐, 패킷 수가 0이라는 측정도, 등록을 지우라는 명령도 아닙니다.

동일한 상용 라우터나 방화벽이 어느 환경에든 설치될 수 있습니다. 장비는 사전에 타입 130이 무의미한 공개 인터넷 짐인지, 폐쇄 네트워크 내부의 필수 라벨인지 알 수 없습니다. 따라서 제품 기본값은 실제로 아는 관리자를 위해 옵션성을 보존해야 합니다.

기본값은 보편적 처리가 아니라 보존이었다

RFC 7126의 권고는 신중하게 조건부입니다. 폐기하거나 제거하면 BSO가 필요한 환경에서 실제 장애를 일으키는 반면, 그냥 전달하는 것은 필요 없는 환경에서 특정한 새 해악을 만들지 않으므로, 기본 구성은 옵션을 제거하거나 BSO를 담고 있다는 이유만으로 패킷을 폐기해서는 안 됩니다.

IPSO를 사용하지 않는 것으로 알려진 환경의 관리자는 폐기를 구성할 수 있습니다. 장비는 인터페이스별 BSO 패킷 수를 로깅하는 기능과, 존재 여부와 값 모두에 대해 필터링할 수 있는 기능을 갖춰야 합니다. 정책은 "공개 인터넷이 분류 라벨을 이해해야 한다"는 것이 아니라, "일반 장비는 배포 정책이 발언하기 전에 라벨을 조용히 파괴해서는 안 된다"는 것입니다.

존재 자체는 이 문서에 따르면 특정한 새 위협을 만들지 않습니다. 다만 예외적인 IPv4 옵션 처리는 여전히 아키텍처적 주의를 요합니다. 라벨의 보안성은 올바른 강제에 온 것입니다. 해석하지 않는 시스템이 라벨을 그대로 전달하는 것은 그것을 신뢰하는 것과 다릅니다.

TCP는 화석을 조건부 부록에 보존했다

현대 TCP 명세인RFC 9293은 이 어색한 상속을 기록합니다. 구형 TCP 로직은 IP 보안/컴파트먼트 정보를 연결 처리의 일부로 다루었습니다. 2022년까지 RFC 1108은 Historic이 되었지만, RFC 791 자체는 보안 옵션을 제거하도록 개정되지 않았습니다.

이 문서는 남은 논의를 구현 참고 사항에 둡니다. 보안/컴파트먼트 정보에 대한 참조는 MLS 구현자에게 여전히 중요할 수 있고, 비 MLS 구현은 무시할 수 있습니다. 모든 환경에 하나의 보편적 행동이 맞는다고 가장하는 것보다 이 경계가 더 정직합니다.

또한 보안 컴파트먼트나 프리시던스 값이 일치하지 않을 때 연결을 리셋하는 것이 가능한 공격 경로로 인식되었다는 점도 언급합니다. 보안 라벨은 주변 신뢰 모델이 건전할 때 입장을 보호하고, 구형 교차 계층 규칙이 기계적으로 적용되면 혼란을 일으키는 표면이 될 수 있습니다.

타입 130이 확립할 수 있는 것과 없는 것

캡처된 타입 130 옵션은 패킷이 역사적으로 할당된 라벨 슬롯에 바이트를 담고 있다는 사실을 확립합니다. 길이와 형식은 발신자가 어떤 명세를 따르는 것으로 보이는지 식별하는 데 도움을 줄 수 있습니다. 유효한 RFC 1108 분류 코드와 잘 구성된 권한 필드는 구조적 적합성을 보여줍니다.

그러나 이것들은 발신자의 등급, 라벨의 진실성, 페이로드의 기밀성, 경로 보호, 다음 인터페이스의 수용을 증명하지 않습니다. 그런 결론에는 보호된 할당, 신뢰할 수 있는 종단과 중계자, 구성된 범위, 실제 네트워크에 대한 증거가 필요합니다.

반대로 라벨의 부재가 항상 비분류를 뜻하는 것도 아닙니다. 암묵적 라벨링으로 구성된 포트에서는 부재가 로컬로 지정된 레벨을 획득할 수 있습니다. 인터페이스 정책에서 분리된 캡처는 따라서 완전한 보안 결정을 복원할 수 없습니다.

타입 130의 내구성 있는 교훈은 보안이 모든 IP 헤더에 있어야 한다는 것이 아닙니다. 메타데이터 제거는 의미론적 작업이라는 것입니다. 패킷 필드가 강제 접근 제어에 참여하는 경우, 수신 환경을 이해하지 못한 채 그것을 제거하는 것은 낯선 옵션을 그대로 전달하는 것보다 더 위험할 수 있습니다.

출처와 증거의 한계

이 폐쇄된 증거 집합은RFC 791,RFC 1038,RFC 1108,RFC 1122,RFC 1812,RFC 7126,RFC 9293입니다. 이 문서들은 변화하는 형식, 처리 모델, 표준 역사, 조건부 필터링 권고를 확립합니다. 그러나 분류된 배포를 공개하거나, 현재 트래픽을 측정하거나, 공급업체 준수를 검증하거나, 관찰된 어떤 패킷의 라벨도 참된 것으로 확립하지는 않습니다.