요약

  • RFC 1455는 TOS 값 15를 "물리적 링크 보안 최대화" 경로 요청에 할당했다. 이는 네트워크 외부의 은밀한 관찰을 줄이는 데 가장 적합한 경로를 우선하라는 뜻이며, 보장된 보안 수준을 보고하는 것이 아니었다.
  • 각 네트워크는 링크와 라우터 위치에 대한 로컬 상대 비용을 통해 이 요청을 해석했다. 따라서 이 마킹은 발신자의 의도만을 증명했고, 공유 정책이나 실제 경로, 암호화, 기밀성을 증명하지 못했다.
  • 이 제안의 오늘날 가치는 그 입증 한계에 있다. 패킷 헤더의 서비스 서술이 기록을 통하지 않고서는 결과에 대한 주장으로 변해서는 안 된다. 기록은 해석을 결정, 실행, 물리적 상태 및 관찰과 연결해야 한다.

4비트, 그리고 패킷 밖의 전체 맥락

RFC 1455는 1993년 5월에 실험적 문서로 발표되었다. IPv4 서비스 유형(Type of Service) 필드에서 십진수 15, 즉 16진수 F, 이진수1111을 선택했다. 이 패턴은 당시 정의된 다른 TOS 값들과 가능한 최대 해밍 거리를 두어 기호 간 혼동을 줄이려는 것이었다.

1이 많다는 것은 보호 강도의 척도가 아니었다. RFC 1349는 TOS 값을 OR로 결합할 수 있는 플래그가 아니라 별개의 유한한 숫자 집합으로 명시했다.1111은 지연 최소화, 처리량 최대화, 신뢰성, 비용 절감의 합을 의미하지 않았다. 그 값 전체가 가리키는 하나의 새로운 요청이었다.

여기서 표현의 정확성과 결과의 정확성 사이의 차이가 시작된다. 라우터는 기호를 올바르게 읽을 수 있지만, 그 다음에는 무엇을 더 안전하다고 간주할지 정하는 로컬 정책이 필요하다. 다른 노드는 그것을 무시하거나 기본 경로를 사용할 수 있다. 비트는 요청을 담지, 각 네트워크의 사전이나 그 결정에 대한 증거를 함께 담지 않는다.

이 제안이 보호하려던 것은 무엇이었나?

이 문서는 트래픽 분석에서 출발했다. 페이로드가 IP 헤더 뒤에서 종단 간 암호화되더라도, 라우터가 필요로 하므로 발신·수신 주소는 여전히 노출되어 있었다. 흐름을 볼 수 있는 관찰자는 누가 누구와 연결하는지, 연결이 언제 발생하는지, 크기가 어떻게 변하는지를 추론할 수 있었다.

의도된 적대자는 물리적 링크를 은밀히 관찰하려는 네트워크 외부의 행위자였다. 이 제안은 내부 접근 권한을 가진 사람, 침해된 라우터, 악의적인 운영자를 다루지 않았다. 엔드포인트를 라우팅 장비로부터 숨기지 않았고, 발신자의 신원을 증명하지 않았으며, 수신자에게 데이터 읽기 권한을 부여하지도 않았다.

따라서 "링크 보안"은 더 큰 체계의 한 부분이었다. 광섬유는 구리보다 도청이 어려울 수 있다. 점대점 회선은 다중 접속 매체보다 노출이 적다. 경비나 침입 경보가 있는 채널은 개방 회선보다 낫다. 스펙트럼 확산은 일반 방송보다 포착이 어렵고, 링크 암호화는 가로채기의 가치를 떨어뜨릴 수 있다. 그러나 이 성질 중 어느 하나만으로는 전체적인 기밀성이 되지 않는다.

"최대"라는 단어는 최소 기준이 아니라 순위였다

새 값은 네트워크가 은밀한 관찰 가능성을 가능한 한 줄이도록 요청했다. RFC 1455는 이것이 특정 보안 수준을 보장하지 않는다고 분명히 했다. "최대"는 자신이 가정할 수 있는 절대적 기준이 아니라, 네트워크가 자신의 정책에 따라 볼 수 있는 선택지 가운데 가장 나은 것을 뜻했다.

약한 경로 두 개만 존재한다면, 그중 하나가 상대적으로 더 안전할 수 있으면서도 민감한 임무에는 부적합할 수 있다. 어떤 노드가 요청을 이해하지 못했다면, 패킷 헤더에 값 15가 지나갔다고 해서 그 노드가 안전해지는 것은 아니었다. 보장은 자원 예약이나, 이용 가능한 TOS 필드를 넘어서는 정책과 메커니즘에 기반한 라우팅을 필요로 했다.

이 표현은 이름이 가진 권한을 조절한다. 인터페이스나 프로토콜 헤더에 등장하는 형용사는 실제 상태처럼 읽히기 쉽다. 반면 이 문서는 그것을 더 좁은 행위, 즉 "가능하다면 우선해 주십시오"로 제한했다.

척도를 만든 것은 네트워크였다

RFC 1455는 당시 OSPF에 존재하던 기능을 포함해 TOS 인식 라우팅을 제안했다. 운영자는 이 목적을 위해 링크와 라우터 위치 각각에 자체 비용을 부여했다. 문서는 비용 지정이 로컬 정책의 기능임을 명시적으로 밝혔다.

이 문서는 안전한 키 분배와 함께 강한 링크 암호화에 비용 1을 부여하는 예를 제시했다. 물리적으로 보호된 점대점 링크에는 2, 일반 점대점 링크에는 6, 로컬 다중 접속 매체에는 8, 도시형 다중 접속 매체에는 12, 로컬 라디오에는 24, 위성 링크에는 32를 부여했다.

이것들은 측정 결과가 아니었다. 32라는 숫자는 32퍼센트의 가로채기 확률을 의미하지 않고, 위성이 항상 일정한 만큼 더 나쁘다는 것을 증명하지도 않는다. 이 비율들은 운영상의 신념에 대한 예였다. 그 기본 정책에서 일부 매체는 기준이 되는 암호화 링크보다 더 노출된 것으로 취급되었다.

다른 네트워크는 지리, 시설 보호, 키 관리, 신호 도달 범위, 적대자 유형 때문에 다른 순위를 선택할 수 있었다. 패킷에는 비용 표의 버전도 그 추정치의 출처도 담기지 않았다. 그래서 동일한 모델을 서로 다른 방식으로 운영하는 두 서비스를 비교할 때 기호 일치만으로는 부족하다.

50번의 홉이 2번을 이길 수 있었다

이 문서는 "짧을수록 좋다"는 직관에 반하는 결과를 보여주었다. 기본 표에 따르면, 고도로 보호된 링크 50개 이상을 거치는 경로가 위성과 라디오 같은 안전하지 않은 링크 2개의 짧은 경로보다 선호될 수 있었다. 선택된 목표는 홉 수가 아니라 관찰 가능성의 감소였다.

그러나 라우터가 늘어나면 물리적 장소, 사람, 소프트웨어, 설정이 추가된다. 정책이 전송 매체만 고려한다면, 보호가 취약한 라우터실을 지나는 좋은 회선의 긴 사슬을 선택할 수 있다. 이에 RFC 1455는 라우터 보안을 판단에 반영해야 한다고 경고했다.

이 예제는 50개 홉이 안전하다는 것을 증명하지 않았다. 오히려 링크가 라우터 위치 없이 기록되었을 때, 경로 계산이 패킷이 실제로 통과한 경로 없이 보관되었을 때, 지도가 의도된 시점의 시설 상태 없이 알려졌을 때의 증거 부족을 드러냈다.

작업에 적합한 공식, 확률적 증명이 아님

라우팅 알고리즘은 보통 링크 비용을 합산한다. RFC 1455는 안전 전송 확률의 곱이 이론적으로 이 목적에 더 적합하다고 언급하면서도, RFC 1349가 높은 신뢰성을 다루듯 합산을 대부분의 사용에 적합한 근사로 받아들였다.

이 인정은 알고리즘 출력을 직접적인 측정으로 해석하는 것을 막기 때문에 중요하다. 라우터는 실제 기밀성 확률을 계산하지 않았다. 가산 가능한 척도로 공식화된 상대 추정치로 경로를 순위 매겼을 뿐이다. 그 추정치는 오래되었거나, 비교 불가능하거나, 잘못된 공급자에 연결되어 있을 수 있었다.

근사치는 그것이 무엇인지 그대로 명명될 때만 유용하다. 즉, 이 정책과 이 모델에 따른 선호 경로이다. 그것이 암호화 인증서나 가로채기 방지 약속이 되지는 않는다.

접근이 요청의 실행을 증명하지 않음

RFC 1349는 서비스 유형을 "요청됨"으로 서술했다. 네트워크는 불완전할 수 있는 정보로 최소화 또는 최대화를 시도했다. 약한 TOS 라우팅이 채택되었다. 즉, 기본값이 아닌 요청과 일치하는 경로가 없으면 패킷을 버리는 대신 기본 TOS 경로를 사용할 수 있었다.

이 결정은 가용성을 유지하고 점진적 배포를 쉽게 만들었지만, 접근을 모호한 증거로 만들었다. 마킹된 패킷의 수신은 우선 처리가 실행되었는지, fallback이 발생했는지, 노드가 필드를 무시했는지 알려주지 않는다. RFC 1455 자체도 인터넷 전체가 가까운 미래에 새 값을 적용하지 않을 것으로 예상했다.

그래서 종단 간 주장에는 각 도메인 또는 홉에 대한 기록이 필요하다. 누가 기호를 인식했는가? 어떤 정책이 유효했는가? 어떤 경로가 계산되었는가? 실제로 무엇이 실행되었는가? 네트워크의 침묵은 답이 아니다.

보안 분류는 별도의 메커니즘이었다

RFC 1108은 비교의 한계를 보여준다. 기본 보안 옵션은 분류 수준과 보호 권한 플래그를 담았다. 시스템은 패킷이 발신지, 수신지, 보호된 경로에 적합한지 검증할 수 있었고, 라우팅 프로토콜은 그 제약을 강제하기 위해 레이블을 이해해야 했다.

RFC 1455의 값은 분류나 보호 권한을 담지 않았다. 단지 이용 가능한 범위에서 물리적으로 노출이 가장 적은 경로를 요청했다. 두 메커니즘은 결합될 수 있지만, 한쪽에서 다른 쪽을 추론해서는 안 된다. 어느 쪽도 콘텐츠를 자동으로 암호화하지 않는다. 키, 엔드포인트 제어, 실제 노출 사실은 별도의 기록으로 남는다.

옥텟의 언어는 바뀌었다

RFC 2474는 이후 구형 TOS 정의를 폐지하고 차등화 서비스(DiffServ) 필드를 도입했다. DSCP는 홉마다 동작을 선택하게 되었고, 분류기, 트래픽 조정기, 정책이 도메인 경계에서 실제 서비스를 구축하게 되었다.

이 계승은 RFC 1455가 널리 배포되었음을 증명하지 않는다. 그것은 해석하는 주체가 바뀌더라도 비트의 위치가 남을 수 있음을 증명한다. 역사적 스냅샷을 읽으려면 시간, 도메인, 필드 의미, 그 시점에 유효한 정책이 필요하다. 그렇지 않으면 패킷에 그것 이후에 등장하거나 이전에 사라진 의미가 부여된다.

마킹에서 관찰된 기밀성까지

입증 사슬은 다음과 같이 쓸 수 있다:

발신자의 우선 순위 ← 이해된 기호 ← 유효한 로컬 정책 ← 계산된 경로 ← 실제 라우팅 ← 링크 및 라우터 보호 ← 암호화 상태 ← 엔드포인트 권한 ← 관찰된 결과

화살표마다 책임이 바뀌고 입증 가능한 주장이 바뀐다. 발신자는 자신이 요청한 것을 증명한다. 라우터는 자신이 적용한 정책을 증명한다. 측정은 패킷이 어디를 지나갔는지 증명한다. 시설과 키 기록은 특정 상태를 증명한다. 적대자의 결과는 범위가 한정된 특정 관찰만이 증명할 수 있다.

RFC 1455는 기밀성 문제를 해결하지 않았다. 그 가장 정확한 역사적 성과는 요청이 패킷에 들어갈 수 있게 한 뒤, 그 요청에 결과에 대한 권한을 부여하지 않기로 한 것이다.

출처와 한계

문서의 상태, 날짜, 폐지 여부는RFC Editor의 RFC 1455 정보 페이지에 있다. 요청 정의, 위협 모델, 비용 표, 경로 예제, 근사 방식은RFC 1455 본문에 있다. 유한한 값의 규칙, 요청의 의미, 기본 경로로의 약한 복귀는RFC 1349에 있다.RFC 1108은 분류 메커니즘과 별도의 보호 권한을 서술한다. 그리고RFC Editor의 RFC 2474 정보 페이지는 필드 의미의 이후 대체를 증명한다.

이 출처들은 설계와 명시적으로 선언된 한계를 증명한다. 그것들은 RFC 1455의 배포, 운영용 비용 표, 측정된 가로채기율, 역사적으로 보호된 경로, 기밀성 검증, 현재 운영 지침으로서의 제안 타당성을 증명하지 않는다.