RFC 3115: 실행 코드가 인쇄된 번호를 이긴 순간

요약

RFC 3025는 중요한 벤더 확장에 37을, 일반 확장에 133을 인쇄했다. IANA는 38과 134를 할당했다. RFC 3115는 현재 구현체들이 IANA를 따랐기 때문에 2001년 2월 문서를 4월에 폐기했다.
불일치는 단순한 표기 이상을 바꿨다. Mobile IP에서 128 미만의 알 수 없는 유형은 수신자가 전체 메시지를 조용히 폐기하게 했고, 128 이상의 알 수 없는 유형은 나머지를 계속 처리하면서 건너뛸 수 있었다.

1옥텟이 메시지의 운명을 갈랐다

수신자가 한 번도 본 적 없는 확장을 달고 Mobile IP 등록 요청이 외부 에이전트에 도착하는 상황을 상상해 보자. 확장의 첫 옥텟이 번호 공간의 한쪽 절반에 속하면 에이전트는 멈춘다. 데이터그램을 폐기하고 더 이상 처리하지 않으며 발신자에게 오류도 보내지 않는다. 그 옥텟이 다른 절반에 속하면 에이전트는 길이를 읽고, 알 수 없는 데이터를 건너뛴 뒤 계속 진행한다.

이 두 미래의 차이는 사설 페이로드가 시작되기 전에 이미 인코딩되어 있었다. Mobile IP는 무지가 치명적인지 판단하기 위해 벤더의 데이터를 이해할 필요가 없었다. 바깥 유형이 이미 그 데이터 없이도 메시지가 의미를 유지하는지 선언하고 있었다.

2001년 2월, RFC 3025는 조직별 Mobile IP 데이터를 위한 두 개의 컨테이너를 만들었다. 중요한 벤더/조직별 확장(Critical Vendor/Organization-Specific Extension, CVSE)에는 유형 37을, 일반 벤더/조직별 확장(Normal Vendor/Organization-Specific Extension, NVSE)에는 유형 133을 인쇄했다. IANA 저장소에는 대신 38과 134가 기록되어 있었다. 두 달 뒤 RFC 3115는 이 문서를 대체했고, 서두에 그 불일치를 나열한 RFC 편집자 주석을 두었다.

그 주석은 출간된 RFC를 자동으로 최고 권위로 취급해 갈등을 해소하지 않았다. 대신 현재 구현체들이 IANA 할당을 따랐기 때문에 RFC 3025를 폐기한다고 밝혔다. 새 텍스트는 38과 134를 사용했다.

그 문장은 실행 코드 우선주의(Running-Code Primacy)를 보여주는 작은 기념비다. 문서, 레지스트리, 그리고 실제 네트워크상의 구현체 집단이 있었다. 문서는 최근의 표준 트랙 문서였다. 레지스트리는 할당 권위였다. 구현체들은 운영상의 사실을 제공했다. 세 가지가 서로 어긋나자, 대체 명세는 텍스트를 기계들이 이미 사용하던 값에 맞췄다.

출처는 그 구현체들의 이름을 밝히거나 수를 세지 않는다. 모든 제품이 동의했는지, 또는 그 불일치가 장애를 일으켰는지도 입증하지 않는다. 그 주장은 더 좁지만 여전히 주목할 만하다. 운영 행태가 충분히 확립되어 표준 기록이 그에 맞춰 움직였다는 것이다.

중요와 일반은 호환성 계약이었다

RFC 2002는 Mobile IP 확장을 두 가지 동작 범위로 나누었다. 0부터 127까지 번호가 붙은 인식되지 않는 확장은 그 확장을 포함한 메시지를 조용히 폐기하도록 요구했다. 128부터 255까지 번호가 붙은 인식되지 않는 확장은 무시하되, 나머지 모든 확장과 메시지 데이터는 여전히 처리해야 했다. 길이 필드는 파서에게 얼마나 건너뛸지 알려주었다.

RFC 3115는 CVSE를 38에, NVSE를 134에 의도적으로 배치했다. 따라서 이름은 편집상의 중요도가 아니라 수신자 동작을 설명했다. 중요한 확장은 이를 이해하지 못한 수신자가 메시지의 나머지 부분에 안전하게 작용할 수 없다고 주장했다. 일반 확장은 그 사설 추가분을 해석에서 생략해도 나머지 전체가 무효가 되지 않는다고 주장했다.

37/38과 133/134 수정을 사무적인 정리에 불과하다고 치부할 수 없는 이유다. 두 버전 모두에서 중요한 값은 건너뛸 수 없는 절반에, 일반 값은 건너뛸 수 있는 절반에 남아 있었으므로 큰 정책이 뒤집히지는 않았다. 그러나 38을 인식하는 수신자는 37을 또 다른 알 수 없는 중요 유형으로 취급할 것이다. 37을 내보내는 송신자는 38을 기다리는 구현체와 만나지 못한다. 건너뛸 수 있는 범위의 133과 134도 마찬가지였으며, 그 실패는 더 조용할 수 있었다. 수신자는 사설 기능을 우회하고 다른 면에서는 유효해 보이는 메시지를 계속 처리할 수 있었다.

조용한 폐기 자체도 신중하게 정의되어 있었다. 수신자는 송신자에게 알리지 않고 멈췄다. 그러나 폐기된 데이터그램을 포함해 오류를 기록하고 그 사건을 계수할 수 있어야 했다. 네트워크상에서 응답은 부재였다. 기계 내부에서는 여전히 증거가 기대되었다.

이 분리는 운영상 중요하다. 응답이 없는 것을 관찰한 송신자는 어느 홉이 메시지를 폐기했는지, 바깥 유형이 알 수 없었는지, 인증자가 실패했는지, 응답이 유실되었는지, 아니면 다른 유효성 규칙이 발동했는지 추론할 수 없다. 사건 계수기와 패킷 기록은 결정을 내린 수신자에게 속한다. 그것이 없으면 중요도 실패는 전송 계층의 침묵과 구별할 수 없게 된다.

인식은 두 번 일어났다

RFC 3115에는 두 번째의 더 미묘한 결정이 있었다. 수신자는 바깥 CVSE 유형 38을 인식하면서도 그 안의 엔터프라이즈 번호나 벤더가 통제하는 하위 유형을 이해하지 못할 수 있었다. 그것은 더 이상 유형 38 자체를 인식하지 못하는 것과 같은 실패가 아니었다.

인식된 CVSE 컨테이너를 실었지만 지원되지 않는 Vendor/Org-ID나 Vendor-CVSE-Type을 가진 요청에 대해, 수신 Mobile IP 엔터티는 적절한 거부를 보내야 했다. 응답의 경우 전송 엔터티는 다음 참여자에게 거부를 생성해야 했고, 종단 수신자는 그 응답을 거부된 것으로 처리했다. RFC는 외부 에이전트와 홈 에이전트가 해석할 수 없는 중요 데이터의 출처를 구분할 수 있도록 네 개의 코드를 할당했다.

반대로 수신자가 NVSE 컨테이너를 인식했지만 그 벤더나 내부 하위 유형을 지원하지 않으면 해당 확장을 건너뛰었다. 처리는 계속되었다.

이 구분은 두 개의 파싱 경계를 만들었다. 바깥 유형 인식은 수신자가 컨테이너의 필드를 찾는 방법을 아는지 여부를 결정했다. 내부 네임스페이스 인식은 사설 의미를 이해했는지 여부를 결정했다. 바깥 경계에서 알 수 없는 중요 유형은 조용한 폐기 속으로 사라졌다. 내부 경계에서 알려진 중요 컨테이너는 명시적 프로토콜 거부를 낳았다.

“알 수 없는 벤더 확장”만 기록하는 로그는 이 구조를 지워 버린다. 유용한 기록에는 바깥 유형, 기본 파서가 이를 인식했는지, 엔터프라이즈 번호, 벤더 하위 유형, 메시지 방향, 해석 노드의 역할, 선택된 처리 방식, 그리고 방출된 거부 코드가 필요하다. 그래야만 운영자가 파서 버전 불일치와 사설 기능 불일치를 구분할 수 있다.

레지스트리는 결과가 아니라 네임스페이스를 위임했다

두 컨테이너 모두 4옥텟 Vendor/Org-ID를 실었다. 상위 옥텟은 0이었고, 하위 3옥텟은 조직의 SMI Network Management Private Enterprise Code를 담았다. 그 네임스페이스 안에서 벤더나 조직은 2옥텟 하위 유형과 그 값을 관리했다.

이 구조는 통제를 여러 관리 주체에게 나눴다. IANA는 바깥 Mobile IP 유형과 거부 코드를 할당했다. 사설 기업 레지스트리는 조직 식별자의 기준을 제공했다. 조직은 하위 유형을 정의했다. 송신자는 어떤 인스턴스를 메시지에 넣을지 선택했다. 수신자는 어떤 사설 의미를 구현할지 결정했다. Mobile IP 인증자는 필요한 경우 이를 감싼 교환을 보호했다. 요청된 등록이나 기능이 수용 가능한지는 여전히 로컬 정책이 결정했다.

어떤 식별자도 그 모든 결정을 담고 있지 않았다. 할당된 엔터프라이즈 번호는 네임스페이스 보관을 입증했을 뿐, 패킷이 실제로 그 이름의 조직에서 왔음을 입증하지 않았다. 메시지 인증은 이동성 보안 연관 아래에서 출처와 무결성을 보호할 수 있었지만, 수신자에게 알 수 없는 벤더 값의 의미를 알려주지는 않았다. 인식은 권한 부여와 같지 않았다. 등록 수락은 사용자에게 보이는 서비스가 작동했음을 입증하지 않았다.

RFC 3115는 Mobile IP 메시지의 고정 부분 뒤에 여러 CVSE 및 NVSE 인스턴스를 허용했다. 중간 노드는 그 순서를 바꾸어서는 안 되었다. 이로써 순서는 증거의 일부가 되었다. RFC가 모든 사설 형식이 순서에 의존한다고 주장한 것은 아니지만 그렇다. 편의를 위해 확장을 정렬하는 정규화 로그는 인증자가 보호한 정확한 메시지와 하위 파서들이 본 순서를 잃을 수 있다.

이 문서의 보안 섹션은 Mobile IP 메시지가 기본 프로토콜을 사용해 인증된다고 가정하며 새로운 보안 요구사항을 부과하지 않는다고 밝혔다. 그것은 명세의 가정일 뿐, 어떤 배포든 관련된 모든 경로를 인증했다거나 사설 값이 무해했다는 증거가 아니다. 건전한 감사는 인증자 결과, 보안 연관, 보호된 바이트를 벤더 하위 유형 지원 및 정책 결과와 분리해 보존한다.

네 개의 오류가 세 당사자 경로를 그렸다

Mobile IP 등록에는 모바일 노드, 외부 에이전트, 홈 에이전트가 관련되었다. RFC 3115의 네 가지 새 거부 코드는 그 토폴로지를 드러냈다.

코드 100과 101은 외부 에이전트의 거부에 속했다. 첫 번째는 모바일 노드가 외부 에이전트를 향해 보낸 지원되지 않는 벤더 ID 또는 CVSE 하위 유형을 설명했다. 두 번째는 홈 에이전트에서 도착한 그러한 데이터를 설명했다. 코드 140과 141은 홈 에이전트의 거부에 속했으며, 모바일 노드가 보낸 CVSE 데이터와 외부 에이전트가 보낸 데이터를 구분했다.

이 코드들은 “벤더 확장이 실패했다”는 일반적 증거가 아니었다. 해석하는 역할과 출처의 한 방향을 식별했다. 여전히 사설 값의 의도된 비즈니스 의미를 밝히지도, 거부가 모바일 노드에 도달했음을 보여주지도, 최종 가입자 결과를 입증하지도 않았다. 전송 노드는 이해할 수 없는 응답을 새로운 거부로 바꿀 수 있었고, 종단 노드는 그 응답을 로컬에서 거부된 것으로 처리할 수 있었다. 네트워크상의 결과는 이해 불가능이 어디서 발생했는지에 달려 있었다.

분산 프로토콜을 단일 서버 응답으로 보고할 때 사라지는 종류의 세부 사항이다. 신뢰할 수 있는 사건 체인은 원래 요청, 순서대로의 모든 확장, 각 에이전트의 인식 결과, 변형된 응답이 있다면 그 응답, 최종 등록 상태, 이후 트래픽 경로를 보존한다. 거부 코드는 하나의 연결고리일 뿐, 서사 전체가 아니다.

온라인 레지스트리가 살아 있는 출처가 되어가고 있었다

RFC 3115는 인터넷 파라미터가 유지되는 방식의 더 넓은 전환기에 등장했다. 1994년에 발행된 RFC 1700은 정적인 Assigned Numbers 스냅숏이었다. 이후 RFC 3232는 제도적 변화를 명시했다. 온라인 IANA 데이터베이스가 연속 RFC 스냅숏을 대체했으며, RFC 1700은 불완전하고 일부 경우 잘못되어 있었다.

3115 수정은 RFC 3232보다 1년도 채 앞서지 않았지만, 이미 새로운 운영 현실을 보여주었다. 레지스트리는 할당 속도로 움직일 수 있는 반면 출간된 문서는 고정되어 있었다. 구현자들은 패킷 형태를 설명한 문서만이 아니라 살아 있는 할당 기록을 필요로 했다. 불일치의 비용은 네트워크 위에 직접 나타났다.

그렇다고 산문이 일회용이 된 것은 아니다. 레지스트리는 38이 CVSE를, 134가 NVSE를 뜻한다는 것을 알고 있었지만, 컨테이너 필드, 내부 네임스페이스, 전송 동작, 오류 경로, 인증 가정을 스스로 정의하지는 않았다. 반대로 RFC는 그 모든 것을 설명하면서도 잘못된 유형을 인쇄할 수 있었다. 상호운용성은 의미와 할당 사이의 결합을 요구했다.

현재의 IANA Mobile IPv4 Numbers 레지스트리는 그 결합을 보존한다. 38과 134를 RFC 3115를 참조로 하여 나열하고, 네 가지 거부 코드도 나열한다. 이것은 현재 상태의 증거다. 모든 편집을 재구성하거나 각 구현체가 정확히 언제 바뀌었는지 알려주지는 않는다. 역사 분석에는 여전히 동결된 RFC들과 그 명시적 수정 주석이 필요하다.

후대의 사용은 특정성을 입증하지만 보급을 입증하지 않는다

후속 RFC들은 조직들이 일반 컨테이너 안에 무엇을 넣었는지 보여준다. RFC 4332는 홈 네트워크 프리픽스, 게이트웨이, DNS, DHCP 정보, 구성 URL을 위한 Cisco 확장을 명시했다. RFC 4784는 cdma2000 네트워크의 동적 키 업데이트 절차의 일부로 CVSE 유형 38과 엔터프라이즈 번호 12951을 사용하는 세 가지 Verizon Wireless Mobile IP 확장을 명시했다.

그 문서들은 정의된 사용 사례를 입증한다. 설치 수, 패킷 추적, 상호운용성 결과, 상업적 결과를 제공하지는 않는다. 명세의 요구사항은 특정 외부 에이전트가 그것을 실행했음을 입증하는 것이 아니다. 등록된 엔터프라이즈 번호는 배포 인구 조사가 아니다.

이후 RFC 5612는 문서와 예제를 위해 엔터프라이즈 번호 32473을 할당했다. 그 보호 장치는 같은 거버넌스 문제를 다른 각도에서 비춘다. 샘플 패킷조차 실제 조직의 사설 네임스페이스로 오인되지 않을 식별자가 필요하다. 예제는 코드, 캡처, 테스트로 흘러나갈 수 있다. 네임스페이스 규율은 허구의 소유권이 운영상 소유권과 충돌하지 않게 한다.

이후 RFC 6709는 확장 메커니즘의 위험을 일반화했다. 사설 확장 공간은 로컬 혁신을 가능하게 할 수 있지만, 최소한의 검토, 불확실한 중요도, 알 수 없는 값에 대한 취약한 동작은 상호운용성, 보안, 운영을 노출할 수 있다. RFC 3115는 초기의 구체적 표본이다. 두 컨테이너는 무지의 비용을 명시적으로 매겼으며, 하나는 메시지 실패로, 다른 하나는 기능 상실로 계산했다.

대체 문서가 입증한 것과 입증하지 않은 것

RFC 3115를 실행 코드가 항상 문서를 이긴다는 우화로 만들고 싶은 유혹이 있다. 증거는 더 절제되어 있다. 새 RFC는 “표준을 무시하라”고 말하지 않았다. 할당 권위, 패킷 구문, 기존 구현체가 합치하도록 표준 기록을 수리했다. 검토 가능한 의미를 보존하고, 배포된 번호 선택을 규범적으로 만들었다.

대체 문서가 모든 구현체를 인증한 것도 아니다. “현재 구현체들”이라는 표현에는 이름, 버전, 측정치가 없다. 적절한 강도로 인용해야 한다. RFC 편집자는 RFC 3025를 폐기할 만큼 구현체들이 IANA와 정렬되어 있다고 보고했다. 시장 점유율, 장애, 보편적 채택에 관한 주장은 선택된 출처에 없는 증거를 요구할 것이다.

따라서 오래 남는 교훈은 증거 보관에 관한 것이다. 출간된 RFC는 한 필드에서 틀릴 수 있다. 살아 있는 레지스트리는 올바른 번호를 담고도 완전한 동작을 담지 못할 수 있다. 실행 코드는 상호운용 가능한 값을 드러내면서도 다른 곳에 버그를 여전히 품을 수 있다. 패킷 캡처는 송출을 입증할 수 있지만 수용을 입증하지는 못한다. 수신자 로그는 파싱 결정을 입증할 수 있지만 성공적인 서비스를 입증하지는 못한다.

RFC 3115의 경우 결정적 사슬이 눈에 보인다. RFC 3025는 37과 133을 인쇄했고, IANA는 38과 134를 보유했으며, 구현체들은 IANA를 따랐고, RFC 3115가 그 문서를 대체했다. 수정이 작동한 것은 각 계층의 이름을 댈 수 있었기 때문이다. 레지스트리와 RFC는 서로 어긋났다. 실행 코드는 어느 기록도 지우지 않았다. 네트워크가 이미 어느 기록을 선택했는지 보여주었을 뿐이다.

레지스트리와 RFC가 어긋났다. 실행 코드는 레지스트리를 택했다: RFC 3115

왜 중요한가

요약

1옥텟이 메시지의 운명을 갈랐다

중요와 일반은 호환성 계약이었다

인식은 두 번 일어났다

레지스트리는 결과가 아니라 네임스페이스를 위임했다

네 개의 오류가 세 당사자 경로를 그렸다

온라인 레지스트리가 살아 있는 출처가 되어가고 있었다

후대의 사용은 특정성을 입증하지만 보급을 입증하지 않는다

대체 문서가 입증한 것과 입증하지 않은 것

출처

프로필 심층 컨텍스트

Strategic Circle

Leadership Alliance

Strategic Circle 브리핑

Leadership Alliance 브리핑

요약

1옥텟이 메시지의 운명을 갈랐다

중요와 일반은 호환성 계약이었다

인식은 두 번 일어났다

레지스트리는 결과가 아니라 네임스페이스를 위임했다

네 개의 오류가 세 당사자 경로를 그렸다

온라인 레지스트리가 살아 있는 출처가 되어가고 있었다

후대의 사용은 특정성을 입증하지만 보급을 입증하지 않는다

대체 문서가 입증한 것과 입증하지 않은 것

출처

프로필 심층 컨텍스트

Strategic Circle

Leadership Alliance

추천 읽을거리