요약

  • RFC 3019는 MLD 인터페이스와 멤버십 캐시 상태를 SNMP로 노출했지만, 일부 행·타이머·프록시 설정을 쓰기 가능하게 만들었다. 관리 시스템은 캐시 항목을 생성·삭제하고 로컬 멤버십을 선언할 수 있었다.
  • 캐시 행, 최종 보고자 주소, 성공한 SET은 에이전트의 제한된 상태를 증명할 뿐, 현재의 원격 수신자·인증된 의도·포워딩·패킷 전달·애플리케이션 수신을 증명하지 않았다.

그 표는 출석부처럼 보였다.

각 인터페이스의 각 IPv6 멀티캐스트 그룹에 대해 RFC 3019는 캐시 행을 제공했다. 그 행은 멤버십 보고를 마지막으로 보낸 주소를 기록할 수 있었다. 항목이 존재한 기간과 만료까지 남은 시간도 보여줄 수 있었다. 별도의 인터페이스 행은 쿼라이어, 타이머, 그룹 수, 누적 조인을 노출했다.

그런 다음 사양은 관리자에게 펜을 들려주었다.

관리자는 캐시 행을 생성하거나 삭제할 수 있었다. 로컬 시스템 자체를 멤버로 간주할지 설정할 수도 있었다. 인터페이스에서 MLD를 켜거나 끄고, 쿼리 및 손실 허용 파라미터를 조정하고, 학습된 멤버십을 프록시 인터페이스로 향하게 할 수 있었다.

이것이 MIB를 기만적으로 만든 것은 아니다. MIB를 관찰 표면인 동시에 제어 표면으로 만든 것이다. 오류는 모든 행을 단일 출처만 가능한 것처럼 읽거나, 관리 응답을 관리 대상 에이전트 너머의 수신자 증명으로 취급하는 데서 나온다.

2001년 1월에 발표된 RFC 3019는 원래의 Multicast Listener Discovery 프로토콜을 위한 IPv6 MIB를 정의했다. 그 영속적인 교훈은 행의 문법적 의미와 조사자가 그 행으로 뒷받침하고 싶은 운영상 주장 사이의 간극에 있다.

두 개의 표가 여러 현실을 압축했다

RFC 3019는 두 개의 개념적 표를 정의했다. MLD 인터페이스 표는 MLD가 활성화된 각 인터페이스마다 하나의 행을 담았다. MLD 캐시 표는 구현이 멤버십을 표현하는 각 멀티캐스트 그룹·인터페이스 쌍마다 하나의 행을 담았다.

호스트와 라우터 모두 이 표를 구현하는 것이 의도되었지만, 일부 필드는 라우터에만 적용되었다. 같은 열이 서로 다른 소유자의 사실 옆에 놓일 수 있었기 때문에 이것은 중요했다.

인터페이스 행은 프로토콜 관리와 현재 제어 상태를 기술했다. 쿼리 간격, 최대 응답 지연, MLD 버전, 쿼라이어 주소, 누적 조인 수, 현재 그룹 수, 견고성 변수, last-listener 쿼리 간격, 프록시 인터페이스, 두 개의 쿼라이어 타이머가 포함되었다.

캐시 행은 그룹/인터페이스 쌍을 기술했다. 인덱스는 멀티캐스트 주소와 인터페이스였다. 로컬 시스템 자체가 멤버인지 여부, 마지막 멤버십 보고의 출처, 행 가동 시간, 남은 만료 시간,RowStatus가 포함되었다.

이 필드들은 하나의 불가분 스냅샷이 아니었다. 조인 카운터는 시간에 걸친 누적 활동이었다. 그룹 게이지는 현재 행 수였다. 최종 보고자 주소는 과거의 출처 필드였다. 만료 타이머는 에이전트의 현재 타이머 상태에서의 예측이었다. 쓰기 가능한 상태는 관리 조작 지점이었다.

함께 읽으면 유용할 수 있었다. 그러나 그것들을 서로 교환 가능한 증거로 취급하면 치명적이었다.

“최종 보고자”는 “현재 수신자”를 뜻하지 않았다

mldCacheLastReporter의 정의는 좁았다: 해당 인터페이스에서 그 그룹에 대해 마지막으로 수신한 멤버십 보고의 IPv6 발신 주소. 보고가 수신된 적이 없으면 값은0::0이었다.

이 객체는 수신자를 열거한다고 주장하지 않았다. MLD 자체가 설계된 것은 직접 연결된 링크에 최소 한 명의 수신자가 존재하는지를 라우터에 알려주는 것이었고, 애플리케이션이나 사람의 인증된 명단을 유지하는 것이 아니었다. 수신자는 다른 호스트의 응답을 듣고 중복 보고를 억제할 수 있었다. 타이머는 마지막 관측된 보고 이후에도 그룹 상태를 유지할 수 있었다. 로컬 시스템 자체도 멤버일 수 있었다.

따라서 최종 보고자는 여러 증인 중 하나일 수도, 과거의 증인일 수도, 단지 보고 억제 하에서 가장 최근에 보이는 발신자일 수도 있었다. 관리자가 행을 읽는 시점에 그 주소가 여전히 구독 중임을 증명하지 못했다. 유일한 수신자, 첫 수신자, 그룹의 소유자, 데이터를 소비하는 애플리케이션임을 증명하지도 못했다.

캐시 만료 필드도 이 구분을 강화했다. 이 필드는 항목이 만료되기까지 남은 최소 시간을 노출했다. 값이 0이라는 것은 항목이mldCacheSelf가 참이기 때문에만 존재하며, 라우터가 탈퇴하면 즉시 사라질 수 있음을 의미할 수 있었다. RFC는 로컬 시스템의 보고를 다른 호스트의 보고처럼 처리하도록 구현에 허용했으므로, 그 경우에도 0이 필수는 아니었다.

조사자가 행이 존재하는 이유를 진술하려면 최소한 행, 보고 이력, 로컬 멤버십 상태, 타이머 시점(epoch)이 필요했다. 그래도 유용한 수신 그 자체는 MIB의 주장 범위 밖에 있었다.

관리가 나중에 읽을 사실을 스스로 공급할 수 있었다

캐시에서 가장 중요한 객체는 주소가 아니었다.mldCacheStatus였다.

이 객체의read-create접근은 새 항목의 생성과 기존 항목의 삭제를 허용했다. 기본 적합성 그룹은 명시적으로 관리자가 MLD 캐시 항목을 생성·삭제하도록 허용하기 위해 설계되었다고 말했다.mldCacheSelf역시read-create로, 로컬 시스템이 멤버인지 여부를 나타내며 기본값은 참이었다.

이 조합은 출처 질문을 바꾸었다. 행은 링크에서 학습한 보고를 반영할 수 있었다. 관리 대상 시스템 자체가 조인했기 때문에 남아 있을 수도 있었다. 관리를 통해 생성되거나 수정되었을 수도 있었다. 표만으로는 어떤 경로가 현재 상태를 만들었는지 식별할 수 없었다.

이것은 쓰기 가능한 관리에 대한 반대 논거가 아니다. 관리자는 로컬 멤버십을 설치하거나, 동작을 테스트하거나, 프록시를 유지하거나, 오래된 상태를 제거하기 위해 합법적으로 쓰기가 필요할 수 있다. 논거는 행정적 사실이 독립적으로 관측된 사건의 권위를 빌려서는 안 된다는 것이다.

자동화 시스템이 캐시 행을 만든 뒤 표를 폴링하여 확인한다고 가정해 보자. 반환된 행은 에이전트가 요청된 상태를 표현하고 있음을 증명할 수 있다. 그러나 원격 호스트가 MLD Report를 보냈음을 독립적으로 증명할 수는 없다. 읽는 자와 쓰는 자가 같은 증거 표면에서 작동하고 있었던 것이다.

이 구분은 운영자가 예정된 사건을 기록하고 나중에 그것을 조회할 수 있는 장부와 비슷하다. 조회는 장부에의 지속을 증명한다. 외부 사건이 실제로 발생했음을 증명하지는 않는다.

행을 활성화하는 것이 프로토콜을 비활성화할 수 있었다

인터페이스 표에는 더 강한 제어가 있었다.mldInterfaceStatus를 활성화하면 인터페이스에서 MLD가 켜졌고, 행을 파괴하면 MLD가 꺼졌다.

다른 쓰기 가능 객체들은 프로토콜의 시간과 허용치를 바꾸었다. 관리자는 일반 쿼리 간격, 최대 응답 지연, 견고성 변수, last-listener 쿼리 간격을 설정할 수 있었다. 더 짧은 last-listener 간격은 마지막 멤버의 상실 감지에 필요한 시간을 줄였다. 더 높은 견고성 값은 추가 상태나 제어 작업을 대가로 더 많은 패킷 손실을 허용했다.

mldInterfaceProxyIfIndex는 두 표면을 연결했다. 한 인터페이스에서 학습된 멤버십이 다른 인터페이스에서 Report를 전송하게 할 수 있었다. 보통 값은 프록시 동작이 없음을 뜻하는 0이었다. 0이 아닌 값은 한쪽의 캐시 이벤트가 다른 곳에서 프로토콜 동작을 만들 수 있음을 의미했다.

따라서 관리 요청 하나가 성공하는 것만으로도, 검색이 실행되는지, 상태가 얼마나 빨리 만료되는지, 멤버십이 상류에서 어디에 표현되는지에 영향을 줄 수 있었다. 그 힘은 MIB를 운영상으로 중요하게 만들었다. 동시에 SNMP 응답을 불완전한 결과 영수증으로 만들었다.

성공한 SET은 에이전트가 요청된 값을 수용했음을 보여줄 수 있었다. 그러나 스케줄러가 의도한 시점에 새 간격을 적용했는지, 다음 Query가 인터페이스를 떠났는지, 다른 장치가 그것을 받았는지, 포워딩 상태가 바뀌었는지, 애플리케이션이 트래픽을 보았는지를 증명하지 않았다.

read-create는 상한이었지, 배포 조사가 아니었다

모듈은 여러 객체를read-create로 선언했다. 이를 보고 적합한 RFC 3019 에이전트는 모두 전체 쓰기 표면을 노출해야 한다고 추론하기 쉽다.

적합성 명시가 그 추론을 막았다. 호스트와 라우터의 경우mldInterfaceStatus의 최소 접근은 읽기 전용일 수 있었다. 쓰기 접근은 필수가 아니었다. 더 넓게 말하면, MIB 적합성은 특정 명명된 그룹 하에서 구현이 무엇을 노출할 수 있고 노출해야 하는지를 기술할 뿐, 특정 장치가 그 그룹을 구현한다거나 SNMP 뷰가 호출자에게 쓰기 권한을 부여한다거나 SET이 성공했다는 것을 확립하지 않는다.

여기에는 세 가지 별개의 질문이 있다:

  1. 스키마가 그 객체를 쓰기 가능으로 정의했는가?
  2. 이 에이전트가 그것에 대한 쓰기 접근을 구현했는가?
  3. 이 인증·권한 부여된 주체가 이 시점에 성공적으로 변경했는가?

객체 선언은 첫 번째 질문에만 답한다. 나머지에는 적합성 주장, 기능 기록, 접근 제어 정책이 필요하고, 운영 결과가 중요하다면 관측된 효과가 뒤따라야 한다.

보안 절은 관찰과 제어를 다르게 다루었다

RFC 3019의 보안 절은 두 가지 위험 등급을 명시했다.

읽기 가능 객체는 멀티캐스트 세션에 관한 정보를 노출할 수 있었다. 특히mldCacheSelf와mldCacheLastReporter는 그룹 주소를 수신 중인 기기를 식별하는 데 도움이 될 수 있었다. RFC는 무단 읽기를 상대적으로 무해하다고 평가했는데, 이는 보편적인 프라이버시 결론이 아니라 당시 시대와 맥락에 속한 판단이었다.

쓰기 가능 객체는 더 날카로운 위험을 제시했다. 무단 변경은 서비스 거부를 일으킬 수 있었다. 문서는 보호 없는 불안전한 환경에서 SET를 지원하면 네트워크 운영에 손상을 줄 수 있다고 경고했다.

또한 SNMPv1 자체가 그런 불안전한 환경이라고 명시했다. 네트워크 계층 보호만으로는 그 네트워크의 어떤 주체가 MIB를 읽거나 변경할 권한이 있는지 결정되지 않았다. RFC는 SNMPv3 사용자 기반 보안 모델(USM)과 뷰 기반 접근 제어 모델(VACM)을 권고하며, 최종 구성 책임을 운영자에게 남겼다.

이 순서는 전송 보호, 인증된 주체, 승인된 MIB 뷰, 관측된 운영 효과를 분리한다. 경로를 암호화한다고 해서 허용된 객체가 선택되지 않는다. 사용자를 지목한다고 해서 모든 SET이 승인되지 않는다. 허용된 SET이 멀티캐스트 데이터가 수신자에 도달했음을 증명하지 않는다.

그 아래의 프로토콜은 여전히 소프트 스테이트를 사용했다

RFC 3019는 MLD를 재정의하지 않았다. RFC 2710은 수신자 보고, 쿼리, Done 메시지, 쿼라이어 선출, 타이머의 프로토콜적 원천으로 남았다.

MLD는 의도적으로 제한된 질문을 했다: 이 링크에서 이 주소에 대해 최소 한 명의 수신자가 존재하는가? MLD는 중복 보고를 억제하고 시간으로 상태를 노화시켰다. Done 메시지는 마지막 수신자가 떠났다는 직접 증명이 아니라 검증을 촉발했다.

이러한 메커니즘이 MIB가 신탁(oracle)이 아니라 투영(projection)이었던 이유를 설명한다. 캐시는 보고 트래픽, 로컬 멤버십, 타이머 판단을 관리 가능한 하나의 행으로 압축했다. 그 행은 운영자가 시스템을 검사하고 제어하는 데 도움을 주었다. 압축은 필연적으로 인과 기록의 일부를 버렸다.

보고 억제에 관한 기존 역사는 프로토콜에 속한다. RFC 3019의 고유한 기여는 그 결과 상태를 관리 객체로, 일부 객체에 대해서는 쓰기 가능한 정책으로 바꾼 것이다. 행에 새로운 가능한 원인을 하나 추가했다: 바로 관리 그 자체였다.

후속 표준은 모델을 바꾸었지만 과거를 바꾸지 않았다

RFC 5519는 2009년에 RFC 3019를 폐기(obsolete)했다. 별도의 IGMP MIB와 MLD MIB를 하나의 일반 멀티캐스트 그룹 멤버십 검색 MIB로 통합하고, 호스트 표와 라우터 표를 분리하며, IGMPv3와 MLDv2를 위한 소스 필터 상태를 추가했다.

후속 모듈은 이전의 두 표 모델이 충분히 표현할 수 없었던 구분을 만들었다. 쓰기 가능한 인터페이스·캐시·프록시 객체를 둘러싼 관리 및 보안 우려도 유지했다.

폐기가 RFC 3019의 역사적 경계를 지우지 않는다. 후속 표준이 원래 모듈이 배포되었음을 증명하지도 않는다. 출처는 표준 계보와 바뀐 스키마를 확립할 뿐, 벤더 구현, 운영상 보급, 성공한 마이그레이션, 인시던트를 확립하지 않는다.

이 절제가 중요하다. MIB는 인구조사처럼 보일 수 있지만 실제로는 관리 표면을 위한 어휘와 계약이다. 특정 네트워크에서 무엇이 존재했는지는 실행 중인 에이전트, 승인된 세션, 독립 관측만이 보여줄 수 있다.

Lu Heng의 Running-Code Primacy는 선언과 구현을 분리해 두는 데 도움이 된다. Reality Layers는 스키마, SET 요청, 반환된 행, MLD 프로토콜 상태, 포워딩 상태, 수신자 결과를 분리한다. Minimum Initial Specification은 2001년 모듈이 이후의 일반적이고 소스 인식 모델이 존재하기 전에도 유용할 수 있는 이유를 설명하면서, 독자가 후속 표준의 의미를 과거로 거슬러 끌어오는 것을 금한다.

이것들은 공개된 분석적 관점이다. Lu Heng은 RFC 3019를 저작하거나 승인한 바 없다.

캐시 행은 정확할 수 있었다. 질문은 언제나 이것이었다: 어느 계층에 관해 정확한가, 누가 만들었는가, 어떤 판단에 충분한가?

출처