요약

  • RFC 1459는 프리픽스가 메시지의 프로토콜상 출처를 지명할 수 있게 했지만, 수신 서버는 자신의 기반에서 그 출처를 찾아 실제로 도착 링크에 의존하는지 확인해야 했다.
  • 고유한 닉네임, 로컬 등록, 일치하는 브랜치, 수용된 메시지는 서로 다른 네 가지 사실이었으며, 어느 것도 키보드 앞의 사람을 인증하지 않았다.
  • 침묵 속 거부는 분산된 트리를 보호하면서, 동시에 운영이 사라짐을 설명하는 시간이 기록된 상태를 메시지 밖에 보존하도록 강제했다.

정확한 한 줄이 거짓된 관계를 담을 수 있었다

RFC 1459는 1993년 5월에 실험적 프로토콜로 공표되었다. IRC는 전자 게시판 시스템에서 출발한 기원을 떠나 클라이언트와 서버의 글로벌 네트워크가 되어 있었다. 문서는 단순해 보였다: CR-LF로 끝나는 줄, 명령, 파라미터, 그리고 경우에 따라 프리픽스. 그러나 각 줄은 사용자와 경로에 대한 공통 표현을 유지하는 서버 트리를 통해 흘렀다.

프리픽스는 서버의 이름이나 클라이언트의 닉네임을 담을 수 있었고, 경우에 따라 사용자와 호스트가 덧붙여졌다. 문서는 그것을 메시지의 출처로 제시했다. 프리픽스가 없으면 서버는 그 줄을 전달한 연결에서 출처를 추론했다.

이 등록은 결코 독립적인 증거가 아니었다. 클라이언트는 프리픽스를 만들어서는 안 되었고, 보낸 경우 자신이 등록한 닉네임만 인정되었다. 서버는 이어서 내부 기반을 조회해야 했다. 이름이 알려지지 않았거나, 출처가 다른 링크 뒤에 등록되어 있으면 메시지는 응답 없이 무시되어야 했다.

따라서 구문과 출처는 두 개의 층위를 이루었다. 파서는 형식을 인식했다. 기반은 네트워크의 한 객체에 이름을 붙였다. 링크 테이블은 그 객체가 어느 브랜치를 통해 합법적으로 나타날 수 있는지를 말했다. 수용은 특정 순간에 이들의 일치에서 나왔다.

‘진짜’ 출처는 프로토콜에 국한되어 있었다

이 검증은 유용하지만 좁은 질문에 답했다: 이 줄에 놓인 이름이 이 서버가 이 연결 뒤에서 아는 IRC 출처에 해당하는가? 그것은 로컬 클라이언트가 단순히 다른 이의 닉네임을 빌려 쓰는 것을 막았다. 또한 피어가 잘못된 브랜치로 알려진 출처를 아무런 결과 없이 유입하는 것도 막았다.

그러나 “이 글을 쓴 사람은 누구인가?”라는 질문에는 답하지 않았다. 닉네임은 네트워크의 현재 상태에서의 라우팅 키였다. 서버는 사용자 이름, 호스트, 소속 서버도 알고 있었다. RFC 1459는 DNS 검증, 선택적 비밀번호, 그리고 Ident에 대한 의존의 증가를 기술했다. 그럼에도 문서는 비밀번호가 없으면 연결 끝에 누가 있는지 신뢰할 수 있게 판단하기 어렵다는 점을 인정했다.

링크 비밀번호조차 각 문장에 서명하지 않았다. 그것은 연결의 수용을 강화할 뿐이었다. 프리픽스는 여전히 IRC 상태와 마주했고, 시민 신원, 기계의 실질적 통제, 메시지의 인간 저자, 최종 독자는 다른 증거를 요구했다.

닉네임은 하나의 상태 안에서 고유했지, 영원히 소유되는 것이 아니었다

프로토콜은 네트워크 차원에서 고유한 닉네임을 요구했고, 당시에는 아홉 자로 제한되었다. 이 고유성 덕분에 서버들은 클라이언트를 찾아낼 수 있었다. 그러나 이름에 대한 지속적인 권리를 부여하지는 않았다.

동일한 두 개의 공지가 도착하면 닉네임 충돌이 선언되었다. 분산된 응답은 합법적 소유자를 찾지 않았다: 양쪽 항목을 모두 삭제하고 KILL 명령을 전파했다. 직접 로컬에서 일어난 충돌의 경우 서버는 새 요청만 거부할 수 있었다.

이 메커니즘은 레지스트리의 본질을 드러낸다. 고유성은 상태 복사본들이 유지하는 불변 조건이었다. 한 사람이 네트워크를 떠나거나, 이름을 바꾸거나, 다른 세션이 나중에 같은 문자열을 다시 취할 수 있었다. WHOWAS는 최근의 이력을 보존했지만, 운영 아카이브가 닉네임을 개인 인증서로 바꾸지는 않았다.

RFC 1459는 또한 몇 가지 위험한 명령에 대해 닉네임 변경을 추적할 것을 권고했다. KICK, MODE, KILL 명령은 닉네임 변경과 교차해 잘못된 클라이언트를 겨냥할 수 있었다. 이력은 이 위험을 줄였지만 제거하지는 않았다. 따라서 이름의 해석은 이미 시간적인 것이었다.

파티션은 메시지가 비교되는 장부를 바꾸었다

서버 트리에서 각 노드는 자신의 복사본으로 결정한다. 분단은 네트워크를 나누어 구성원과 닉네임에 대한 두 개의 시각을 만들고, 재접속 시 양쪽이 자신들의 믿음을 재조정하도록 강제할 수 있었다. 같은 텍스트라도 다른 시점에 수신되면 서로 다른 두 상태와 마주할 수 있었다.

침묵 속 거부는 비일관적이라고 판단된 출처와의 추가 대화를 피하게 했다. 그러나 진단을 어렵게 만들었다. 수신자 측에서 메시지가 없다는 사실은 그것이 구문 분석, 이름 조회, 브랜치 검증, 이후의 릴레이, 클라이언트 표시 중 어느 단계에서 실패했는지 말해 주지 않았다.

사건을 재구성하려면 수신된 바이트, 시각, 연결 식별자, 기반 버전, 기대 링크, 관측 링크, 그리고 결정을 보존해야 했다. 패킷 캡처만으로는 프리픽스가 보일 뿐, 그것을 수용 가능하게 하거나 거짓으로 만든 관계는 보이지 않았다.

2000년의 문서들은 비용을 더욱 가시화했다

RFC 2810은 IRC 아키텍처를 분리하고, 모든 서버가 전역 상태의 복사본을 유지해야 한다는 의무를 주요 문제로 기술했다. 이 복제는 단순한 발견의 사치가 아니었다: 그것이 출처 검증을 지탱했다.

RFC 2812는 클라이언트 측에서 프리픽스 규칙을 유지했다. 프리픽스가 없으면 연결로 돌아갔고; 프리픽스를 제공하는 클라이언트는 자신이 등록한 닉네임만 사용할 수 있었다. RFC 2813은 서버 간의 규율을 상세히 기술했다. 알려지지 않은 출처는 거부를 강제했고; 알려지지 않은 서버는 링크의 폐쇄로 이어질 수 있었다. 다른 브랜치로 알려진 출처는 언제나 메시지의 폐기로 이어졌으며, 경우에 따라 클라이언트의 삭제 또는 잘못된 연결의 단절이 뒤따랐다.

따라서 그 결과는 텍스트 이상에 미쳤다. 출처의 불일치는 클라이언트의 존재나 전체 그룹의 연결성을 바꿀 수 있었다. 링크를 닫는 것은 트리의 무결성을 보호했지만, 동시에 그 브랜치에 의존하던 모든 합법적 교류를 제거했다.

서버 문서는 또한 서버 토큰이 피어 투 피어 관계 안에서만 고유하다는 점을 상기시켰다. 그 값에는 전역적 범위가 없었다. 이 한계가 프리픽스를 비춘다: 식별자는 자신을 부여한 공간과 관계 속에서 의미를 가진다.

한 자리 숫자의 오류가 여전히 텍스트와 코드를 갈라놓고 있다

RFC 1459는 콜론의 16진수 값을 잘못 0x3B로 제시했는데, 0x3B는 실제로 세미콜론이다. 기록된 문자와 문법은 0x3A를 명백히 만들었고, 검증된 정오표 4091이 이 수정을 공식화했다.

이 실수는 프로토콜을 무효화하지 않는다. 그것은 명세, 유지되는 정오표, 작동 중인 파서가 세 개의 증인임을 상기시킨다. 첫째는 한 바이트를 잘못 알 수 있고, 둘째는 수정 시점을 기록하며, 셋째는 실제로 상호운용되는 것이 무엇인지 보여준다. 충실한 역사는 이 증인들 중 어느 하나를 다른 것으로 대체하지 않는다.

암호화는 서로 다른 경계를 보호한다

1993년의 연결 검증은 여전히 제한적이었다. 비밀번호는 주로 서버 간에 권고되었다. 이후의 서버 문서는 PASS와 OPER가 평문으로 흐른다고 관찰하고 스트림 암호화 메커니즘을 제안했다. RFC 7194는 이어서 TLS를 사용하는 IRC의 기본 포트를 등록했다.

전송 보호는 링크의 관찰자로부터 식별자와 메시지를 숨길 수 있고, 피어 인증은 반대편 끝에 대한 신뢰를 강화할 수 있다. 그러나 그것은 프리픽스 검증을 대체하지 않는다. 암호화된 링크는 로컬 기반과 양립하지 않는 출처를 운반할 수 있다. 일관된 프리픽스는 암호화 없이 흐를 수 있다. 마지막으로 포트 등록은 배포, 검증된 인증서, 또는 수신된 메시지를 아무것도 증명하지 않는다.

전체 사슬은 여전히: 등록, 구문 분석, 등록된 객체, 입구 관계, 로컬 결정, 릴레이, 클라이언트의 수신, 인간의 읽기다. RFC 1459가 흥미로운 이유는 첫 고리를 뒤따르는 고리들과 혼동하지 않았기 때문이다.