요약

  • RFC 831은 분단 상황에서 SATNET 장비에 도달하기 위한 논의용 설계를 제안했다. 멀티홈드 "Munger"는 게이트웨이와 유사한 소스 라우트 처리를 수행하고 양방향 패킷을 다시 쓰지만, 여전히 호스트로 남고 어떤 경로도 광고하지 않았다.
  • 선호된 하이브리드 방식은 구식 단말이 소스 라우트를 되돌려 보낼 수 없을 때 역방향 주소 대응을 학습했으며, 이를 메모에서는 "soft state"라고 불렀다. 이 문서는 타이머도, 인증·정리·감사·크래시 복구도 규정하지 않았으며, 모호한 키 구조로 인해 한 번에 SATNET 목적지당 미국 호스트 하나만 접근할 수 있었다.
  • 이 사례는 비상 접근 논의에서 자주 뒤섞이는 네 가지 주장을 분리한다. 패킷이 들어올 수 있다, 운영자를 식별할 수 있다, 행위가 승인될 수 있다, 의도된 유지보수가 완료될 수 있다. RFC 831은 첫 번째 주장만 다루었고, 나머지는 여전히 현지 통제와 증거를 필요로 했다.

게이트웨이의 권한 없이 게이트웨이 알고리즘만

1982년 12월, Robert Braden은 좁은 비상 상황에 대한 논의에 초점을 맞추도록 RFC 831을 배포했다. SATNET이 연결이 끊긴 두 부분으로 나뉜다면, 미국의 엔지니어들은 어떻게 유럽 쪽 장비에 접속해 소프트웨어 유지보수를 할 수 있을까? 이 메모는 대안 입구를 "back door"라고 불렀지만, 그 제안이 당시 기준으로 표준이 되도록 의도된 것은 아니라고 명시했다. 이는 배포 기록이 아니라 논의할 아키텍처를 서술한 것이다.

결정적 규칙은 패킷 역학보다 앞서 등장했다. 대안 터널의 University College London 측 단말은 게이트웨이가 아니라 호스트여야 했다. VAN 게이트웨이가 그 단말을 통해 UCLNET으로 가는 일반 경로를 학습하면, 평범한 UCL 또는 RSRE 트래픽을 VANNET 터널로 우회시킬 수 있었다. 유지보수 예외는 그렇게 되면 우연한 트랜짓 경로가 되었을 것이다.

따라서 RFC 831은 한 기계에 게이트웨이의 소스 라우팅 알고리즘을 부여하면서, 그 역할에 보통 결부되는 사회적·라우팅 권한은 부여하지 않았다. 그 기계는 선정된 패킷을 검사하고 소스 라우트를 진행시키며 헤더를 변경할 수 있었다. 그러나 도달 가능성을 광고하거나, 토폴로지 교환에 참여하거나, 네트워크 나머지에 자신을 사용하도록 초대하지는 않았다.

이 부정적 허가는 구현 각주가 아니었다. 그것이 안전 경계를 정의했다.이 예외적 교환에 대해서만 이 포워딩 동작을 수행하되, 그 예외를 경로로서 발견 가능하게 만들지 않는다.

일반 경로는 양방향에서 모두 실패했다

정상 진단 경로는 미국 제어 호스트 H에서 시작했다. H는 인터넷을 지나 BBN 게이트웨이 B에 도달하고, 위성 인터페이스 메시지 프로세서 S1을 통해 SATNET에 들어가, 위성 네트워크를 가로질러 S2에 이르고, 그다음 UCL 게이트웨이 G에 도달했다. 분단 동안 S2, G, 그리고 UCL 터미널 접속 제어기의 주소는 미국 게이트웨이에서 도달할 수 없었다. 일반적인 방식으로 주소가 지정된 패킷은 폐기되고 ICMP Unreachable을 유발할 수 있었다.

역방향도 똑같이 중요했다. 같은 분단 동안 H는 영국 측에서 도달할 수 없었다. 엔지니어가 어떻게든 S2 근처에 요청을 놓을 수 있더라도, H로 되돌아가도록 일반적으로 주소가 지정된 응답은 실패했을 것이다. "들어갈 수 있는 대안의 길이 있다"는 것은 설계의 절반이었을 뿐이고, 쓸 수 있는 유지보수 경로에는 돌아가는 그래프가 필요했다.

제안된 그래프는 H → 인터넷 → VAN 게이트웨이 → VANNET IP 터널 → UCL 단말 → UCLNET → G → S2로 이어졌다. RFC 831은 H와/또는 UCL 단말에는 특수 코드를 허용했지만, G, S2, VAN 게이트웨이에는 허용하지 않았다. 복구 논리는 길을 따라 모든 장비에 새로운 요구를 강제하는 대신, 그것을 담을 의사가 있는 두 시스템에 집중되었다.

평범한 UCL 터널 호스트 U를 단순히 라우터로 승격시킬 수는 없었다. 대신 이 문서는 Header Munger라 불리는 멀티홈드 변형인 M을 도입했다. M은 VANNET에서는 M2, UCLNET에서는 M1으로 나타났다. 이 두 정체성은 장식적인 별칭이 아니었다. 그것들은 그렇지 않으면 라우팅 불가능한 대화를 방향 전환시키는 접점이었다.

하나의 요청에는 두 번의 변환이 필요했다

H는 M의 VANNET 쪽에 도달할 수 있었으므로, 유지보수 요청을 M2를 향해 보냈다. 그러면 M은 UCLNET으로 전달하기 전에 패킷의 출발지를 M1으로, 목적지를 S2로 바꿨다. 영국 측 네트워크에 이 교환은 이제 현지에서 도달 가능한 단말을 갖게 되었다.

응답은 S2에서 M1을 향해 돌아왔다. M은 그것을 다시 다시 써서, VANNET과 인터넷을 거쳐 H를 향해 갈 수 있는 패킷을 만들었다. 이 두 편집은 서로 다른 도달 실패를 해결했다. 출발 방향의 목적지만 바꾸는 것은 유효한 응답 경로를 만들지 않았다. 출발지만 바꾸는 것은 원래의 SATNET 목적지를 미국 라우팅에서 도달 가능하게 만들지 않았다.

헤더 재작성은 또한 하류 시스템이 관찰할 수 있는 주소를 바꾸었다. 성공적인 응답은 H, M2, 재작성 기능, M1, G, S2라는 특정 체인이 이 교환을 위해 충분한 트래픽을 실었다는 것을 증명했다. 그것은 S2가 H의 평범한 주소를 알았다는 것, M이 인간 운영자를 인증했다는 것, 또는 요청된 유지보수 작업이 완료되었다는 것을 증명하지 않았다.

그렇기 때문에 이 설계를 현대의 단어 "NAT"로 축소해서는 안 된다. 훨씬 나중에 발표된 RFC 3022는 정적 및 동적 주소 변환을 형식화하고, 네트워크 내부에 상태를 두는 대가로 종단간 주소 의미를 잃는 비용을 서술했다. 유용한 비교이지만, RFC 831을 NAT나 그 발명자 또는 기록된 선조로 만들지는 않는다.

세 가지 복귀 전략이 상태 문제를 노출했다

RFC 831은 경로를 작동시키기 위한 세 가지 방법을 검토했다.

첫째는 고정 대응이었다. M은 미국 호스트와 SATNET 목적지가 연결된 M1/M2 주소 집합에 대해 응답할 수 있었다. 기계적으로는 단순했지만 행정적으로는 경직되었다. 유용한 쌍마다 계획된 주소 상태를 소모했다.

둘째는 양방향으로 IPv4 소스 라우팅을 사용하는 것이었다. RFC 791은 Loose 및 Strict Source와 Record Route 옵션을 정의했다. 송신자가 중간 주소를 제공했고, 패킷이 목록의 주소에 도달하면 다음 주소가 IP 목적지로 대체되고 현재 인터페이스 주소가 경로 기록에 들어갔다. 기록된 경로를 역전할 수 있는 수신자는 응답을 구성할 수 있었다.

G는 소스 라우팅을 지원했지만, S2와 터미널 접속 제어기는 기록된 경로를 역전하는 방법을 모를 수 있었다. 따라서 선호되는 대안은 하이브리드였다. H는 발신 소스 라우트에 예외적 경유지를 넣었다. M이 그 요청을 진행시키면서 미국 출발지와 SATNET 목적지 사이의 대응을 학습했다. 복귀 소스 라우트가 없는 응답은 그 후 M1에서 인식되어 H를 향해 다시 쓰일 수 있었다.

RFC 831은 이 매핑을 "soft state"라고 불렀다. 이 문구는 문서의 규모 안에 그대로 두어야 한다. 이 메모는 대응이 어떻게 학습되고 사용되는지를 서술했지만, 갱신 간격, 만료 타이머, 삭제 규칙, 재시작 절차 또는 감사 기록은 제공하지 않았다. 오래된 기록이 여전히 승인된 유지보수 세션과 어떻게 구별되는지도 말하지 않았다.

키 또한 모호했다. 이 체계를 통해 한 번에 한 미국 호스트만 특정 SATNET 호스트에 접근할 수 있었다. 두 출발지가 동일한 목적지를 공유하면, 소스 라우트가 없는 응답에는 M이 올바른 H를 선택할 만한 정보가 충분하지 않았다. 이 한계는 초기 용량 목표가 아니라, 역방향 경로가 숨겨져 있고 정보를 잃는 맥락에 의존했다는 직접적 증거다.

물리 회선과 전화 요금 경제가 그래프를 만들었다

패킷 다이어그램은 교환형 X.25 서비스 위에 놓여 있었다. 통화를 걸은 쪽이 요금을 지불했다. 평소에는 UCL이 U에서 터널을 열었고, 미국 쪽은 M2를 향해 터널을 열었다. 따라서 방향은 누가 요금을 부담하는지, 어떤 단말이 연결성을 먼저 개시해야 하는지에 영향을 미쳤다.

UCL에는 물리적 PSS 회선도 하나 있었다. 평범한 U 단말과 M을 그 회선에서 모두 호스팅하려면, 설계는 별도의 X.25 서브어드레스를 요구했다. VAN 게이트웨이는 12자리 X.121 주소뿐 아니라 14자리 주소도 받아들여야 했다. 우아한 IP 계층 제안이 두 계층 아래의 주소 지정 필드에서 실패할 수 있었다.

이 세부 사항을 네트워크 경제의 보편 이론으로 확대해서는 안 된다. 그것들이 보여주는 것은 더 실용적인 무언가다. 복구 아키텍처는 자신이 거치는 서비스의 통화 방향, 주소 폭, 과금 경계, 인터페이스 재고를 그대로 물려받는다. 이러한 사실이 운영 매뉴얼에 없으면, 올바른 패킷 알고리즘도 사용 불가능한 채로 남을 수 있다.

이후의 호스트 규칙은 예외적 역할을 명시적으로 만들었다

RFC 1122는 나중에 호스트가 소스 라우트된 패킷의 중간 홉 역할을 할 수 있도록 허용했지만, 게이트웨이 수준의 규율 아래에서만 가능했다. TTL, ICMP 오류, 옵션 처리를 적절히 다루어야 했다. 비로컬 소스 라우트의 포워딩은 기본값이 비활성이고 정책 필터의 적용을 받는 설정 가능한 스위치를 요구했다.

그 규칙은 RFC 831이 활용한 범주를 명확히 했다. 호스트는 일반 라우터가 되지 않고 중간 라우팅 작업을 수행할 수 있다. 그러나 그 작업은 여전히 라우터급 결과를 가졌다. 실행 코드가 호스트 프로세스 안에 있다는 이유만으로 TTL, 오류, 경로 기록, 정책을 무시할 수 없었다.

운영 기본값이 갑자기 바뀐 것은 아니었다. RFC 1812는 1995년에도 라우터가 포워딩하는 패킷에서 소스 라우트 옵션을 지원하도록 요구했으며, 기본적으로 활성화되지 않은 폐기 스위치를 서술했다. 이 지점은 역사적이며, 지금 그 자세를 재현하라는 권고가 아니다.

2011년까지 RFC 6274는 소스 라우팅의 보안 위험이 진단 유용성보다 크다고 판정했다. 그것은 방화벽 우회, 그렇지 않으면 도달 불가능한 시스템에 대한 접근, 은닉 연결, 토폴로지 탐지, 자원 고갈을 열거하고 기본 드롭을 권고했다. 이어서 RFC 7126은 광범위한 필터링이 LSRR을 트러블슈팅용으로 사실상 사용 불가능하게 만들었다고 관찰했다. 그 조언은 옵션별로 구체적이며 통제를 문서화했고, 기본은 드롭이며 명시적으로 정당화된 예외에 한해서만 현지 처리를 허용했다.

이 이후의 역사는 RFC 831의 논리를 지우지 않는다. 그것은 제안 안에 숨어 있던 의존성을 드러낸다. 자발적 IP 옵션에 기반한 비상 경로는, 경로상의 각 독립 운영자가 그 옵션을 받아들이는 동안에만 작동한다. 공개된 메커니즘은 트랜짓에 대한 약속이 아니다.

이후의 분류법은 중개자를 명명하되 그 권한은 명명하지 않는다

RFC 3234는 나중에 평범한 IP 라우팅 이상을 수행하는 중개자, 즉 흐름을 변형하거나 우회시키는 중개자를 "middlebox"라고 불렀다. 그 분석적 어휘에서 M은 middlebox와 비슷하게 보인다. M은 주소를 바꾸고, 흐름별 대응에 의존했으며, 구성이나 상태가 실패할 수 있는 지점을 하나 추가했다.

그러나 어휘는 드러내는 것만큼이나 감출 수도 있다. M을 middlebox라고 부르는 것은 M이 패킷에 무엇을 했는지는 말해준다. 누가 M을 호출할 수 있었는지, 어떤 목적지가 적격이었는지, 학습된 지도가 얼마나 생존했는지, 누가 예외를 닫을 수 있었는지는 답하지 않는다. 게이트웨이라고 부르는 것은 더 나쁘다. 그 라벨은 이 메모가 명시적으로 부인한 일반 포워딩 권한을 암시할 수 있었다.

가장 깨끗한 서술은 여전히 제안 자체가 부호화한 것이다. M은 선정된 유지보수 트래픽을 위해 게이트웨이와 유사한 작업을 수행하고 어떤 라우팅 업데이트도 보내지 않는 멀티홈드 호스트였다. 그 권한은 실행 가능했지만 의도적으로 광고되지 않았다.

유지보수 도달 가능성은 유지보수 권한이 아니었다

RFC 831은 주소와 경로 연속성에 관한 공학 질문을 해결했다. 그것은 신원 증명, 목적지 승인, 암호화, 응용 명령, 변경 승인, 유지보수 성공 확인을 정의하지 않았다. 이 메모에서 "back door"라는 단어는 대안 경로를 명명할 뿐, 취약점 악용의 증거가 아니다. 그럼에도 대안 도달 가능성은 통제 표면을 만든다. 그것은 평범한 토폴로지가 더 이상 넘지 않는 경계를 트래픽이 넘게 하기 때문이다.

그럴 수 있는 운영자는 네 가지 판정을 분리해서 유지해야 한다.

  1. 요청이 예외적 입구에 도달했다;
  2. 주체가 식별되었다;
  3. 요청된 목적지와 작업이 승인되었다;
  4. 목적지가 의도된 결과를 보고했다.

다시 쓰인 응답은 첫 번째 판정을 지지할 수 있다. 그것이 나머지 셋을 조용히 대체할 수는 없다.

RFC 831의 오래 남는 성과는 그 토폴로지 안의 절제였다. 설계자들은 유지보수가 급하다는 이유만으로 네트워크가 새로운 일반 경로를 믿도록 요구하지 않았다. 그들은 특수 코드를 국지화하고, 보이는 경로를 한정했으며, 복구 단말이 자신을 트랜짓으로 광고하게 하지 않았다.

비상구는 경로가 아니었다. 그래야만 문으로 남을 수 있었다.