요약

  • RFC 1108은 IPv4 옵션 133을 추가 보안 레이블을 담는 반복 가능한 컨테이너로 정의했으며, 각 형식 코드는 자체적인 상호운용 가능한 명세로 규율되었습니다.
  • 모든 확장 보안 옵션(ESO)은 짝이 되는 기본 보안 옵션(BSO)과 공유 구성에 의존했습니다. 이 확장을 제거하면 패킷이 사용 불가능해지거나 잘못된 민감도 레이블이 붙을 수 있었습니다.

의미가 다른 곳에 살던 컨테이너

확장 보안 옵션(Extended Security Option)은 타입 133, 최소 3옥텟의 가변 길이, 그리고 1옥텟짜리 추가 보안 정보 형식 코드(Additional Security Info Format Code)로 시작했습니다. 그 뒤에 오는 모든 내용은 해당 코드가 지정하는 구문에 속했습니다. 정의하는 형식이 허용한다면 추가 필드 자체가 비어 있을 수도 있었습니다.

RFC 1108은 단순한 레지스트리 등록 이상을 요구했습니다. 각 형식 코드에는 자신의 구문을 기술하는 RFC와, 서로 다른 벤더들이 상호운용할 수 있을 만큼 상세한 알고리즘적 수용-거부 절차가 있어야 했습니다. 비트를 사람이 읽는 레이블로 대응시키는 매핑은 비공개로 남을 수 있었지만, 기계에는 공개된 처리 계약이 필요했습니다.

이 옵션은 조각으로 복사되어 여러 번 나타날 수 있었고, IPv4 헤더 크기 제한만이 그 상한이었습니다. 그러나 이러한 다중성이 옵션을 독립적으로 만들지는 않았습니다. ESO를 담는 모든 데이터그램은 기본 보안 옵션도 함께 담아야 했습니다. BSO 없이 ESO만 있는 것은 오류였고, 미등록 코드, 길이 불일치, 코드의 정의 RFC에 위배되는 데이터도 오류였습니다. 이런 경우 RFC 1108은 ICMP Parameter Problem 처리를 요구했습니다.

지원 여부가 전부 아니면 전무의 문제도 아니었습니다. 한 시스템은 ESO 없이 BSO만 구현할 수 있었고, 선별된 ESO 형식 코드만 인식할 수도 있었습니다. BSO의 보호 권한 비트는 ESO의 형식 코드 네임스페이스에 대응하지 않았습니다. 따라서 인접한 두 필드가 서로 다른 레지스트리와 기능 집합에 규율되면서도 같은 보안 판단에 참여할 수 있었습니다.

기본 레이블과 마찬가지로, 경로 강제에는 헤더 파싱 이상이 필요했습니다. 중간 시스템은 라우팅 프로토콜도 해당 정보를 담기 전까지는 일반적으로 ESO 레이블만으로 보호된 경로를 선택할 수 없었습니다. 이 옵션은 주장을 운반할 뿐이었고, 네트워크는 그에 따라 행동하기 위해 여전히 구성된 포트 매개변수, 지원 코드 지식, 경로 상태가 필요했습니다.

제거가 바꾼 것

RFC 7126은 나중에 이 옵션이 사설 고보안 네트워크에서 제한적으로 사용된 사실을 기록했습니다. 그 문서는 ESO를 제거하면 수신자가 패킷을 부적절하게 레이블된 것으로 폐기할 수 있다고 경고했습니다. 더 나쁘게는, 수신자가 데이터에 잘못된 민감도 레이블을 연결해 그 취급을 격상시키거나 격하시킬 수 있었습니다.

이 비대칭성이 권고를 만들었습니다. 장치는 자신이 그런 환경에 설치되어 있는지 미리 알 수 없었습니다. 따라서 기본 동작은 옵션을 제거하거나 ESO가 존재한다는 이유만으로 패킷을 폐기해서는 안 되었고, 환경이 ESO를 사용하지 않음을 아는 관리자가 폐기를 구성할 수는 있었습니다. 감사 가능한 패킷 계수도 권고되었습니다.

이 출처들은 현재의 배포 비중, 현재의 지원 코드 목록, 보편적인 제품 동작을 확립하지 않습니다. 그들의 지속적인 요점은 아키텍처적입니다. 확장성은 조율을 없애지 않는다. 조율을 레지스트리, 별도의 명세, 그리고 정렬을 유지해야 하는 구성으로 옮길 뿐이다.

출처