요약

  • RFC 1044는 송신자가 자신의 32비트FROM주소가 역방향 응답에 적합할 때 HYPERchannel의SRC플래그를 설정할 수 있게 했다. 중간 어댑터는 해당 반환 조건이 충족되지 않으면 이 플래그를 지울 수 있었다.
  • 플래그가 살아남았다는 것은TO와FROM을 맞바꾸면 메시지를 발원한 프로세스에 도달한다는 뜻이었다. 그것은 메시지 바이트를 검사하거나, 사람을 식별하거나, 애플리케이션 요청을 승인하지 않았다. CRC, 프로토콜 서버 선택, 물리적 신뢰는 여전히 별개의 통제였다.

RFC 1044에서 가장 유용한 문장은 동시에 가장 신중하게 범위가 한정된 문장이기도 하다. HYPERchannel 메시지가 Source Address Correct 비트가 여전히 설정된 채 도착했다면,FROM주소는TO와FROM을 뒤집으면 메시지를 발원한 프로세스로 전달된다는 “의미에서” 올바르다고 보장되었다. 이 한정은 중요하다. 그 비트는 반환 경로의 한 속성을 확립했을 뿐, 운영자가 출처에 부여할 수 있는 다른 모든 의미를 정의하지는 않았다.

1988년 2월에 발표된 RFC 1044는 IP 데이터그램과 관련 프로토콜이 Network Systems의 HYPERchannel 장비를 통해 어떻게 전달되는지 문서화했다. 이 문서는 사실상의 16비트 관행을 정형화하고, 호환되는 32비트 주소 형식을 도입하고, 메시지 유형을 등록하고, 주소 결정을 로컬 테이블에서 서버와 향후 브로드캐스트 지원 ARP 쪽으로 옮기려 했다. 그 결과 여러 종류의 근거가 하나의 헤더를 공유하면서도 서로 교환 가능해지지 않는다는 점을 유난히 명시적으로 기록한 문서가 되었다.

FROM은 응답을 위한 주소로 시작했다

기본 HYPERchannel 메시지에서TO는 목적지를 선택했고,FROM은 수신자가 무언가를 되돌려 보낼 수 있도록 메시지와 함께 이동했다. 네트워크는FROM을 사용해 발신 메시지를 전달하지 않았다. RFC 1044에 따르면 일반적으로 두 16비트 주소 필드와 해당 트렁크 마스크를 뒤집으면 응답을 발원지로 안정적으로 반환할 수 있었다.

이는 실용적인 대칭성일 뿐, 사람의 신원에 관한 진술이 아니다. 반환 레이블은 누가 요청을 입력했는지, 어느 계정에 비용을 청구해야 하는지, 발신 프로그램이 침해되었는지, 요청된 작업이 허용되었는지에 대해 아무 말도 하지 않으면서도 응답이 어디로 가야 하는지를 식별할 수 있다. 그 주소는 전달 매체의 전달 모델에 속한다.

이 명세는 또한TO의 논리적 부분 안에 프로토콜 서버를 내장했다. 프로세스는 자신이 수신하고자 하는 완전한 주소를 등록했다. 그 주소가 최종 서버를 선택한 뒤에는 메시지 유형 필드가 전달을 다른 서버로 재지정할 수 없었다. 다만 중간 장비는 전송 중 처리 목적으로 그 유형을 사용할 수 있었다. 따라서 SRC 플래그가 논의에 들어오기 전에도 목적지 선택과 경로 내 분류는 서로 다른 통제였다.

확장 헤더는 반환 가능성을 경로 단언으로 만들었다

32비트 헤더는 도메인 및 네트워크 좌표와 함께 서로 혼동하기 쉬운 세 가지 플래그를 추가했다.GNA는 확장 주소 형식을 알렸다.CRC는 적절한 장비를 갖춘 어댑터에 의한 종단 간 무결성 검사를 요청하거나 보고했다.SRC는 제공된 출처 주소가 역방향 경로에 대해 올바르다고 단언했다.

SRC 규칙은 차감식이다. 송신 호스트는 사용한 어댑터 인터페이스에 대해 올바른FROM주소를 제공하려고 노력한 뒤 그 비트를 설정한다. 전달 경로의 모든 중간 어댑터는 그 주소가 역방향 메시지를 발원자에게 라우팅할 수 있는TO주소가 아니면 비트를 끌 수 있다. 목적지는 그러한 검사의 잔여 결과를 본다.

이는 여러 장치가 신원을 적극적으로 보증하는 투표가 아니다. 권한 있는 송신자만 만들어낼 수 있는 비밀도 아니다. 송신자가 최초 단언을 기록하고, 경로가 이를 철회할 수 있다. 살아남은 비트는 참여한 어댑터 중 어느 것도 자신이 구현한 규칙 아래에서 명시된 역방향 전달 결함을 발견하지 못했다는 뜻이다. 비트가 없다는 것은 원인에 대해 더욱 말해주지 않는다. 송신자가 단언을 생략했을 수 있고, 어댑터가 이를 올바르게 지웠을 수 있으며, 구현이 해당 메커니즘을 지원하지 않았을 수 있고, 물리적 경로가 바뀌었을 수도 있다.

이 비대칭성은 역사적으로 시사하는 바가 있다. 부정적 근거는 수신자가 가장 강한 반환 주소 주장에 의존하지 못하게 할 수 있다. 긍정적 근거는 그것을 보존한 장치들의 관리와 정확성에 여전히 조건부로 달려 있다.

“올바름”에는 하나의 운영적 의미만 있었다

RFC 1044는 ‘올바름’이라는 단어를 무제한으로 남겨두지 않는다. 그것은 결과를 정의한다. 전달 매체 주소를 뒤집으면 응답이 메시지를 발원한 프로세스에 도달한다. 이는 단지 패킷이 도착했다고 관찰하는 것보다 강하다. 수신자에게 시험 가능한 연속 경로를 제공하고, HYPERchannel 전달 시스템에서 주소를 하나의 발원 프로세스에 묶는다.

그래도 인증보다는 좁다. 프로그램은 권한 있는 주체가 아니면서도 메시지를 발원할 수 있다. 기계는 주소가 말하는 물리적 위치에 있으면서도 변조된 코드를 실행할 수 있다. 응답은 성공적으로 반환되지만 원래 요청은 악의적이거나, 오래되었거나, 정책 밖에 있을 수 있다. 반환 가능성은 응답이 어디로 가는지를 답하고, 승인은 효과가 발생해야 하는지를 답한다.

문서 자체가 빠진 조건을 제시한다. 시스템은 어댑터와 중간 링크의 물리적 보안에 세심한 주의를 기울임으로써FROM주소에서 높은 수준의 보안을 얻을 수 있다고 말한다. 이는 아키텍처적 전제이지, 비트가 마법처럼 만들어내는 속성이 아니다. 장비, 구성, 링크가 책임질 수 있는 물리적 경계 안에 있다면 주소는 국지적 정당성 결정을 뒷받침할 수 있다. 그러한 관리의 증명이 없으면 플래그만으로는 그 전제를 확립할 수 없다.

CRC는 요청자가 아니라 바이트를 검사했다

별도의 CRC 플래그는 근거 경계를 드러낸다. 장비를 갖춘 어댑터는 중간 네트워크와 하드웨어를 거치는 네트워크 메시지를 포괄하는 32비트 CRC를 추가하고 검사할 수 있었다. 검사가 작동했다면, 이는 전달된 비트가 해당 경로를 따라 손상되지 않았다는 주장을 뒷받침했다.

CRC는FROM주소를 역방향 가능하게 만들지 않았고, SRC는 관련 데이터가 온전하다는 것을 보여주지 않았다. 어느 플래그도 사람을 식별하지 않았고, 내장된 IP 출처가 정당하다는 것을 증명하지 않았으며, 애플리케이션 작업에 대한 권한을 제공하지 않았다. “검증됨”만 기록한 수신자는 그것이 주소 역방향성, 바이트 무결성, 프로토콜 서버 선택, 애플리케이션 수용 중 무엇을 의미하는지 지워버릴 것이다.

RFC 791은 대체물이 아니라 또 다른 계층을 더한다. 내장된 IPv4 데이터그램은 자체 출발지 및 목적지 필드, 프로토콜 값, Total Length, 헤더 체크섬을 가진다. HYPERchannel 전달 매체는 자체 주소와 플래그를 가진다. IP 출처와 확인된 HYPERchannelFROM주소 사이의 일치는 유용할 수 있지만, 두 개의 일관된 주소 필드만으로는 권한 있는 행위자를 지명하지 못한다.

주소 결정은 또 하나의 독립적 기록이었다

RFC 1044는 하위 비트 주소 절단에서 시작해 로컬 구성 파일과 알려진 ARP 서버를 거쳐 미래의 분산 브로드캐스트 모드로 이동하는 과정을 설명한다. 이 문서는 프로토콜 주소를 링크 계층 주소로 매핑하는 일반 형식을 정의한RFC 826을 명시적으로 인용한다.

주소 결정은 어느 HYPERchannel 헤더가 IP 데이터그램을 로컬 호스트나 다음 게이트웨이로 운반해야 하는지를 답한다. 그것은 결과 주소를 누가 통제하는지, 테이블이 최신인지를 보여주지 않는다. 정적 항목, 중앙 집중식 응답, 브로드캐스트 응답은 서로 다른 출처 기록을 만든다. 어느 것도 조용히 애플리케이션 승인으로 승격될 수 없다.

SRC 비트는 주소 결정 이후 반환 주소에 관한 주장을 보존할 수 있다. 잘못된 주소가 내부적으로 역방향 가능하다는 이유만으로 잘못된 매핑을 고칠 수는 없다. 일관성은 진리가 아니다. 그것은 신뢰할 수 있는 시스템이 요구할 수 있는 하나의 조건일 뿐이다.

수신 드라이버는 과잉 반응하지 말라는 지침을 받았다

IP 캡슐화 섹션에는 마지막 제약이 담겨 있다. 송신 IP 드라이버는 인터페이스의 완전히 올바른FROM주소를 제공하려고 노력했을 때 Source Address Correct 비트를 설정해야 한다. 그러나 수신 IP 드라이버는 당시 그 비트에 대해 아무 조치도 취하지 말라는 지침을 받았다. 실제 또는 상상된 보안 위반에서 플래그가 없을 경우 어떻게 해야 하는지를 결정하려면 더 많은 작업이 필요했다.

그 지침은 매력적인 실수를 막는다. 새로 명세된 근거 비트가 자동으로 입장 허가 게이트가 되는 것은 아니다. 운영자에게는 여전히 실패 정책, 호환성 지식, 관리 전제, 지원되지 않는 신호와 실제 경로 결함을 구별할 방법이 필요하다. 표시되지 않은 모든 메시지를 버리는 수신자는 불완전한 배포를 장애로 바꿀 수 있고, 표시된 모든 메시지를 승인된 것으로 취급하는 수신자는 도달 가능성을 특권으로 바꿀 수 있다.

RFC 1044의 성과는 출처 인증을 해결한 것이 아니었다. 그것은 물리 네트워크 속성을 시험하고, 해제하고, 다른 속성들과 함께 운반할 수 있을 만큼 명시적으로 만들었다. 플래그와 필드를 세심하게 구분한 점은 초기 고속 전달 매체가 하나의 비트가 전체 요청을 지배한다고 주장하지 않으면서도 유용한 근거를 드러낼 수 있었음을 보여준다.

근거의 출처와 한계

RFC 1044는 HYPERchannel 메시지 형식, 주소 역전, 논리 서버 선택, 플래그 의미론, 물리 보안 조건, 드라이버 지침, 주소 결정 단계를 제공한다.RFC 791은 내장된 IPv4 헤더와 그 별도의 길이, 주소, 체크섬 필드를 정의한다.RFC 826은 RFC 1044가 재사용한 일반 프로토콜-링크 주소 결정 모델을 정의한다.

이 출처들은 문서화된 명세와 그 명시된 가정을 확립한다. 특정 설치 환경이 SRC를 구현했는지, 모든 어댑터가 이를 올바르게 해제했는지, 어떤 물리적 경계가 안전했는지, 관찰된 요청이 권한 있는 사람으로부터 왔는지, 요청된 작업이 완료되었는지는 증명하지 않는다.