요약

  • RFC 2908은 멀티캐스트 주소 할당을 클라이언트-서버, 도메인 내 조율, 도메인 간 할당의 세 계층으로 나누었다. 실험적 RFC인 RFC 2909는 MASC를 제안하여 도메인이 임시 프리픽스를 주장한 뒤 이를 세분화하거나 위임하도록 했다.
  • RFC 2909는 IPsec이 두 피어를 보호하더라도 릴레이된 UPDATE의 출처를 인증하지는 못할 수 있다고 경고했다: 토폴로지의 다른 위치에 있는 신뢰할 수 없는 MASC 노드가 악성 갱신을 주입할 수 있었다. 제안된 대응은 배치, 운용, 트래픽 증거가 아니라 피어에 대한 행정적 신뢰에 기반했다.

2000년 9월, 멀티캐스트 주소 할당 아키텍처는 자주 혼동되는 두 질문에 답해야 했다: 누가 애플리케이션에 그룹 주소를 전달하는가, 그리고 누가 그 주소가 선택될 범위를 예약하는가? RFC 2908은 이를 단일 거래로 만들기를 거부했다. 작업을 세 계층으로 나눈 것이다. 클라이언트는 서버에 주소를 요청한다; 서버들은 도메인 내에서 할당을 조율한다; 도메인 간 메커니즘이 이러한 도메인에 범위를 제공한다. MADCAP은 첫 번째 계층에, AAP 또는 수동 구성은 두 번째 계층에, MASC는 세 번째 계층에 쓰일 수 있었다.

이 분리는 멀티캐스트 할당을 하나의 전역 카운터에서 멀어지게 했다. MASC 노드 — 일반적으로 에지 라우터에서 상정됨 — 는 한 도메인, 흔히 자율 시스템으로 간주되는 단위를 위해 행동했다. 더 넓은 범위에서 프리픽스를 선택하고, 구성된 피어들에게 주장을 보내고, 다른 주장들과 충돌하는지 지켜보았다. 이후 부모-자식 계층 구조는 도메인이 받은 프리픽스를 자신의 할당 서버들을 위해 분할하거나 자신의 자식들에게 서브프리픽스를 위임할 수 있게 했다. 얻은 프리픽스는 멀티캐스트 라우팅 정보에도 반영될 수 있었다. 이들은 연관되어 있지만 서로 다른 제어 표면이다: MASC 할당만으로는 라우트, 그룹 가입, 패킷 전달이 만들어지지 않는다.

주장에는 만기가 있었다. 각 프리픽스는 수명과 연결되어 있었고, 도메인이 범위를 유지하려면 만료 전에 갱신해야 했다. 그러지 않으면 사양은 프리픽스 사용을 중단하고 해당 라우트 상태를 철회하도록 요구했다. 따라서 위임된 자원은 기본적으로 영구적이지 않았다. 그러나 운영자가 하나만 관찰하면 할당 상태, 라우팅 상태, 애플리케이션 사용이 서로 갈라질 수 있었다. 제어 항목은 패킷 캡처가 아니다.

이 아키텍처는 자신의 타협도 명시했다. 공간이 희소할 때 엄격한 분할은 충돌을 막을 수 있지만, 분할이나 전환에 필요한 여유가 풀을 조각낸다. RFC 2908은 따라서 충돌 없음에 대한 절대적 보장보다 좋은 주소 밀도와 가용성을 우선했다. 충돌을 피할 확률을 매우 높게 목표로 하되, 그 확률이 100%가 아니어도 받아들였다. 주장, 대기 시간, 충돌 시 다른 프리픽스 선택은 이러한 허용을 표현한 것이지 수학적 확실성이 아니었다.

RFC 2909는 이후 또 다른 경계, 즉 출처의 경계를 분리해 냈다. UPDATE는 처음 수신한 피어에서 반드시 멈추지 않았다. MASC 노드들은 이를 보존하고 부모, 형제, 자식, 내부 피어 사이에서 릴레이했다. 문서는 IPsec이 피어링하는 두 노드를 보호할 수 있다고 명시한다. 그러나 신뢰할 수 없는 MASC 노드가 토폴로지에 합류하면, 다른 노드들이 반드시 악성으로 식별하지 못할 UPDATE를 주입할 수 있다. 따라서 권고는 각 노드가 신뢰할 만한 피어와만 관계를 맺는 것이었다. 재시작 후 상태 복구를 위해서는 부모나 내부 피어의 정보가 일반적으로 신뢰할 만하다고 간주되었다; 반면 노드는 형제나 자식으로부터 받은 자신의 UPDATE를 배제할 수 있었다.

이 관찰은 "IPsec은 쓸모없다"는 뜻이 아니다. 링크 보호는 특정 인접 관계를 보호한다. 결함은 정보가 그 링크를 넘어갈 때 나타난다: 다음 홉은 누가 자신에게 보냈는지는 알지만, 누가 만들었는지, 그리고 각 릴레이가 반복할 권한이 있었는지는 반드시 확립하지 않는다. MASC의 타임스탬프와 노드 식별자는 경쟁하는 주장을 가르는 데 쓰인다; RFC 2909는 이를 출처에 대한 암호학적 인증으로 제시하지 않는다. 실제 악용 사례도 보고하지 않는다. 위협을 기술하고 운영상의 선택을 피어 그래프를 구성하는 사람들에게 남긴다.

쟁점은 주장된 프리픽스가 하나 이상의 할당 서버에 영향을 줄 수 있다는 점이다. 수락되어 전파되면 갱신 하나가 인접한 주장들을 제약하고, 애플리케이션이 주소를 요청하기도 전에 멀티캐스트 라우팅 상태에 반영될 수 있다. 제안된 대응은 모든 주장을 인증할 전역 권위가 아니었다: 릴레이된 UPDATE를 수락하기 위한 경로 민감 규칙과 결합된 피어 간 신뢰 정책이었다. 따라서 토폴로지와 그 행정이 실질적인 권한을 집중시켰다.

RFC의 지위가 역사적 결론의 경계를 정한다. RFC 2908은 제안된 아키텍처를 기술하는 정보성 문서이다; RFC 2909는 실험적이며 인터넷 표준이 아니다. 이들의 출판은 저자들이 다계층 아키텍처와 그 위험을 정식화했음을 증명한다. MASC를 구현한 네트워크 수, 사용 빈도, 악성 갱신으로 인한 서비스 장애의 존재는 드러내지 않는다. RFC 3180의 GLOP와 RFC 3171의 IANA 등록은 다른 할당 선택이다; 어느 것도 MASC 배치를 증명하지 않는다. 교훈은 더 정밀하다: 프리픽스 주장, 보호된 링크, 신뢰할 만한 출처, 라우트, 실제 수신된 플로우는 서로 다른 사실이다. 안전한 제어 평면 설계는 어떤 증거가 각 전이를 승인하는지 명확히 해야 한다.

출처