요약

  • RFC 1504는 내보내진 네트워크의 신원 — 도메인 식별자와 원래 번호 범위 — 를, 각 외부 라우터가 그에게 부여할 수 있는 로컬 번호와 분리했다.
  • 이 로컬 번호가 터널 식별자 없이 이중 경로를 통해 되돌아오면, 라우터는 그것을 실제 네트워크로 오인해 다시 매핑하고 "유령 네트워크"를 만들어낼 수 있었다.
  • 따라서 일관성은 유효한 경로 이상을 요구했다: 매핑의 시대(epoch), 입력 포트, 초기 교환 상태, 수신한 업데이트, 그리고 제어 패킷의 결과가 서로 연결 가능하게 남아 있어야 했다.

더 이상 증언할 수 없게 된 체크섬

RFC 1504는 당시 Apple Computer에 재직하던 Alan Oppenheimer의 이름으로 1993년 8월에 발표되었다. 이 문서는 정보성(informational) 문서였다. 그 의도는 AURP를 인터넷 표준으로 바꾸는 것이 아니라, 인터넷을 넘어갈 수 있는 Apple 프로토콜을 매우 정밀하게 기록하는 것이었다.

바로 이 정밀함 때문에 그 경고가 두드러진다. 외부 라우터는 DDP 헤더 안의 네트워크 번호, NBP 엔티티 주소, 또는 AURP 라우팅 데이터 속 번호를 수정할 수 있었다. DDP 체크섬은 재작성 이전에 검증된 뒤 0으로 바뀌어야 했다. 연산이 끝나면, 옛 체크섬은 더 이상 전송된 바이트를 기술하지 않았다.

따라서 변환 전의 유효성은 변환 후의 유효성이 아니었다. 그리고 변환 그 자체는 새 번호가 새로운 대상을 가리키는지, 아니면 같은 대상의 다른 모습인지 말해주지 않았다.

두 개의 관리 주체, 하나의 번호

AURP는 IP 같은 외부 네트워크나 지점 간 링크로 연결된 대규모 AppleTalk 집합을 겨냥했다. 두 조직은 서로 독립적으로 번호 체계를 구축했을 수 있다. 같은 범위가 터널의 양쪽에서 모두 합법적일 수 있었다.

이 프로토콜은 어느 한쪽에게 즉시 자신의 로컬 이력을 포기하라고 요구하지 않았다. 내보내진 각 네트워크에 대해 고유 식별자인 UI를 형성했다. 터널에서 재매핑을 수행하는 라우터는 도메인 식별자 DI를 원래의 번호 또는 범위와 결합했다. 도착지에서는 다른 라우터가 이 UI를 자기 로컬 네트워크 안의 예약된 빈 범위에 연결했다.

로컬 기계들은 평범한 AppleTalk 번호로 계속 통신했다. 라우터는 로컬 표현과 터널의 신원을 연결하는 표를 보관했다. 이 해법의 효율은 바로 이 분리에 의존했다.

그러나 로컬 번호는 자신의 계보를 갖고 있지 않았다. 두 라우터는 같은 원격 네트워크를 서로 다른 두 숫자로 보여줄 수 있었다. 서로 다른 두 도메인은 시점에 따라 같은 로컬 숫자를 받을 수 있었다. 보이는 필드만 읽어서는 동일성을 결론짓는 것도, 차이를 결론짓는 것도 불가능했다.

데이터 속에 숨은 주소는 번역기를 피해 갔다

재매핑은 일부 위치 — DDP 헤더, NBP 주소, AURP 라우팅 데이터 — 를 알고 있었다. 그러나 제3의 프로토콜 전체의 문법을 훑을 수는 없었다. 애플리케이션은 네트워크 번호를 자신의 페이로드 다른 곳에 묻어 두었을 수 있다.

이 경우 패킷의 바깥쪽은 자신의 경로를 찾았지만, 안쪽 참조는 여전히 옛 세계를 가리켰다. 그래서 하나의 세션은 터널이 열리고, 업데이트가 확인되고, 라우팅 항목이 올바른 뒤에도 실패할 수 있었다. 이것은 모순이 아니었다: 두 증거는 서로 다른 계층을 가리켰다.

네트워크 관리에서도 같은 어긋남이 나타났다. SNMP나 다른 프로토콜의 응답은 재매핑되지 않은 번호를 담을 수 있었다. 관리 스테이션은 로컬로 표시된 번호를 찾기 위해 AURP 재매핑 베이스를 별도로 질의해야 했다. 원본을 표시하는 콘솔과 별칭(alias)을 표시하는 콘솔은 반드시 두 개의 네트워크를 기술하는 것은 아니었다.

RFC 1742는 이후 AppleTalk 관리 객체 — 포트, RTMP 테이블, 라우팅 카운터, 포트별 관찰 — 를 표준화했다. 이 객체들은 조사를 개선했지만, MIB 값을 신원이나 서비스의 완전한 증거로 만들지는 않았다.

동적 재매핑은 시대를 만들었다

정적 매핑은 하나의 UI에 정확한 번호를 예약했다. 이는 상관관계 분석과 감독을 쉽게 했지만, 유한한 범위를 소모했다. 동적 매핑은 발견되는 대로 번호를 할당했다; 더 많은 네트워크를 연결하는 대가로 더 취약한 이력을 감수했다.

RFC 1504는 다른 가능성이 모두 소진된 뒤에야 번호를 재사용할 것을 권고했다. 특히 사라진 네트워크의 UI를 방금 나타난 새 네트워크에 곧바로 붙이는 것을 경계했다. 현재 테이블은 옛 보유자를 잊었을 수 있지만, 지연된 패킷, 캐시, 측정 도구는 여전히 그 이름을 부르고 있을 수 있다.

따라서 시간은 신원에 속했다. "47은 X에 해당한다"는 완전한 데이터가 아니었다. "라우터 R의 포트 P에서, 시대 E 동안, 47은 이 DI와 이 범위로 구성된 UI를 표현했으며, 그 철수는 T에 관찰되었다"라고 써야 했다. 이 문장 없이는, 번호의 재사용은 숫자의 절약을 지속적인 모호성으로 바꾸었다.

유령 네트워크는 이중 경로에서 왔다

위험한 시나리오는 하나의 터널과, 같은 AppleTalk 집합들 사이의 두 번째 경로를 결합했다. 입력에서 재매핑된 번호는 로컬 네트워크를 돌아다니다가 이중 경로를 타고, 그것을 만들어낸 라우터에게 되돌아올 수 있었다.

돌아온 시점에, 그 범위는 번역을 인식하게 해줄 DI와 UI를 더 이상 동반하지 않았다. 라우터에게 그것은 자기 로컬 네트워크의 진짜 범위처럼 보였다. 그러면 라우터는 그것을 다시 매핑해 터널 안으로 내보낼 수 있었다.

두 개, 이어서 세 개의 범위가 같은 물리 네트워크를 가리켰다. RFC 1504는 이런 출현을 유령 네트워크(shadow network)라고 불렀다. 이 순환은 겉보기 거리가 홉(hop) 한도를 넘어설 때까지 계속될 수 있었다. 한도는 결국 순환을 막았지만, 이미 복제된 신원의 대장을 고쳐주지는 않았다.

유령을 만든 것은 이중 경로 자체가 아니었다. 원점을 보존하지 않은 채 번역 경계를 넘는 이중 경로였다. 예비 경로는 매핑의 실제 적용 범위가 가정된 범위보다 넓다는 것을 드러냈다.

멀티포인트 터널은 자신이 주장하는 링크가 아니었을 수 있었다

AURP는 멀티포인트 터널을 단일 가상 링크로 제시했다. 외부 라우터들은 스플릿 호라이즌(split horizon)을 적용했다: 자기 로컬 네트워크의 경로는 보내지만, 다른 외부 라우터에게서 배운 경로를 같은 터널로 재수출하지는 않았다.

이 규칙은 모든 피어가 직접 참여한다고 가정했다. 그러나 터널은 의도든 실수든 부분적으로만 연결될 수 있었다. 라우터는 일반적으로 이 두 의도를 구분할 수 없었다. 두 개의 가상 링크로 이루어진 토폴로지가 때로는 멀티포인트 터널 하나가 가려는 것을 정직하게 표현했을 것이다.

재매핑이 라우터별로 켜지는 만큼, 혼합 배포는 비대칭적인 보안 속성을 낳았다. 번호를 재매핑하는 라우터는 루프 탐지를 수행했고; 나머지는 하지 않았다. 후자들 사이의 루프는 복사본을 전자에게 되돌려 보낼 수 있었고, 전자는 그것들을 추가 별칭으로 기록했다.

또한 두 개의 재매핑 라우터가 이중화되려면, 로컬 네트워크에 대해 동일한 DI와 정확히 동일한 UI–로컬 번호 대응이 필요했다. 이 문서는 공통 구성이나 미래의 공유를 상정하면서도, AURP가 아직 그 기능을 제공하지 않는다고 명시했다. 두 번째 경로는 존재했다; 신원 상태의 일관된 두 번째 복제본은 존재하지 않았다.

유사성은 조사의 시작이지 판결이 아니었다

RFC 1504는 "루프를 시사하는 정보"를 기술했다: 범위 크기와 존(zone) 목록이 이미 알려진 로컬 네트워크와 일치할 수 있었다. 그러나 이 유사성만으로는 부족했다. 라우터는 패킷을 터널로 보내고, 그것이 로컬 네트워크의 포트로 되돌아오는지 관찰해야 했다.

이 시험은 가설과 관찰을 올바르게 분리한다. 패킷의 귀환은 실험 동안 본 경로를 증명한다. 그것은 행정적 의의, 토폴로지의 미래 지속, 각 서비스에 대한 영향을 증명하지 않는다. 이것은 제한된 로컬 결정만 허용한다.

보안 절도(security consideration) 절은 같은 겸손을 요구한다. 그 절은 네트워크와 장비의 은닉을 약한 보안으로 규정하고, 일반적 보안 우려는 문서 밖에 남긴다. Chooser에서 존이 사라진다고 누군가 인증되는 것은 아니다. 인터페이스 상의 부재가 네트워크 상의 부재를 확립하지 않는다.

확인 응답은 세계를 동기화하지 않았다

AURP는 주기적 트래픽의 일부를 초기 교환과 이벤트로 대체했다. 단방향 연결은 식별자를 가졌고; 각 패킷은 시퀀스를 실었으며; 발신자는 진행 전에 RI-Ack를 기다렸다.

그러나 이벤트가 전송을 기다리는 동안 새 연결이 시작될 수 있었다. 수신자는 먼저 한 장의 사진(스냅샷)을 받고, 그 다음 그것과 양립하지 않아 보이는 이벤트를 받았다. 프로토콜은 실용적인 변환을 규정했다: 알려지지 않은 네트워크의 거리 변화는 추가로 간주되고; 알려진 네트워크의 추가는 변화로 간주되며; 특정 알려지지 않은 철수는 무시된다.

이 관용은 사용 가능한 상태를 재구성하는 데 도움이 되었다. 그러나 모든 피어에 공통된 원자적 순간을 만들지는 않았다. RI-Ack은 하나의 패킷과 하나의 시퀀스를 증명할 뿐, 로컬 RTMP 전파, 재매핑 테이블의 정렬, 페이로드의 도착을 증명하지 않았다.

수신자의 테이블이 넘쳐흐르면, 잃어버린 데이터가 반드시 재전송되지는 않을 수 있었다. 권고는 RI-Req로 전체 테이블을 다시 요청하는 것이었다. 결손 이후, 마지막 업데이트는 빠진 이력을 치유할 수 없었다; 사진의 경계를 다시 열어야 했다.

사용 가능한 신원을 이루는 여섯 조각

성실한 조사는 최소한 다음을 보존해야 했다: 원래의 UI<DI, 범위>; 라우터, 포트, 시대를 동반한 로컬 별칭; 메시지의 연결과 시퀀스; 사진 또는 이벤트 여부; 입력 경로; 전달 결정과 그 관찰된 결과.

서로 다른 두 숫자는 같은 UI로 귀결될 수 있었다. 같은 숫자는 재사용 후 다른 UI로 바뀔 수 있었다. 유효한 경로는 번역되지 않은 내부 주소로 인해 깨진 애플리케이션으로 이어질 수 있었다. 이 조각들의 대조 — 번호의 겉모습이 아니라 — 만이 충돌, 유령, 과거 상태, 진짜 새 네트워크 사이에서 선택하게 해주었다.

출처가 증명하지 않는 것

RFC 1504는 메커니즘을 기술한다, 그 확산을 기술하지 않는다. 출처는 배포 수, 명명된 사건, 준수율, 현재 제품의 행동 중 어느 것도 제공하지 않는다. RFC 지위는 어떤 라우터도 인증하지 않는다.

RFC 1378은 PPP가 AppleTalk를 협상하고 지점 간 링크 위에서 AURP 정보를 운반하는 방법을 정의한다. 그것은 AURP 세션이 수렴했음을 증명하지 않는다. RFC 1742는 관리 객체를 정의한다; 그것은 완전한 재매핑 베이스를 보장하지 않는다. Lu Heng의 문서들은 여기서 하나의 판독 규칙을 제공한다: 규격, 로컬 표현, 행정적 권한, 그리고 관찰된 효과는 서로 구별되는 영수증으로 남아야 한다.

유령 네트워크는 효과 없는 환상이 아니었다. 테이블을 채우고 전달을 바꿀 수 있었다. 그러나 그 기원은 명확히 범주 오류였다: 되돌아온 표현을 새로운 신원으로 받아들인 것이다.

출처