요약

  • RFC 3080은 여러 독립적인 교환이 하나의 BEEP 세션을 공유하도록 허용했다. 채널 0이 세션을 관리했지만, 각 애플리케이션 채널은 피어가 명명된 프로필을 수락했을 때에만 구문과 의미를 갖게 되었다.
  • 활성 전송 계층, 유효한 인사말, 광고된 기능, 열린 채널, 성공한 애플리케이션 효과는 서로 다른 증빙이었다. 어느 것도 다음 단계를 안전하게 대변할 수 없었다.

회선은 열려 있었지만 애플리케이션은 아니었다

두 피어 사이에 깨끗한 전송 계층 연결이 있다고 상상해 보라. 양쪽 모두 유효한 인사말을 보낸다. 각자 채널 0을 파싱할 수 있다. 그런데도 첫 애플리케이션 채널에 대해 제안된 모든 프로필이 거부된다.

회선에는 아무 문제가 없다. 세션 관리 교환에도 형식상 결함이 없다. 그러나 여전히 애플리케이션 대화는 존재하지 않는다.

이 진단이 바로 RFC 3080의 중심에 있는 설계 선택을 포착한다. 2001년 3월에 Standards Track으로 발표된 이 문서는 연결 지향 비동기 애플리케이션을 위한 범용 커널인 Blocks Extensible Exchange Protocol Core를 기술했다. 이는 연결에 단일 애플리케이션 의미를 부여하지 않았다. 대신 하나의 애플리케이션 사용자 신원 아래 여러 독립적인 교환이 공존할 수 있는 세션을 만들었다.

이 구분은 애플리케이션 아래에서 시작되었다. RFC 3080은 BEEP 코어를 정의하되, 하위 전송 계층으로의 매핑은 별도 문서에 남겼다. 예를 들어 RFC 3081은 하나의 BEEP 세션을 하나의 TCP 연결에 매핑했다. 따라서 TCP 연결 성립은 전송 계층 증빙이었다. 애플리케이션 선택이 아니었고, 유용한 프로필이 수락될 것이라는 증거도 아니었다.

채널 0은 관리자였지 작업 그 자체는 아니었다

세션 시작 시점에는 채널 0만 존재했다. 채널 0은 채널 관리 프로필을 실었다: 인사말, 지원 프로필 광고, 채널 시작 요청, 채널 종료 요청, 그리고 최종적으로 세션 릴리스.

인사말은 의도적으로 소박했다. 피어는 서버 역할로 동작하면서 자신이 지원할 수 있는 프로필을 나열했다. 상대 피어가 그 프로필로 채널을 갖게 되는 것은 아니었다. 광고는 기능 증거였지 선택이 아니었다. RFC 3080은 심지어 어느 한 인사말이 먼저 나타난 예제에서 순서를 추론하지 말라는 경고까지 담았다: 두 피어는 각각 독립적으로 응답을 보냈다.

동작하는 레인을 얻으려면, 피어가 채널 0에서start를 보냈다. 제안된 채널 번호를 명시하고 하나 이상의 프로필 URI를 제시했다. 수신자는 긍정 응답에서 하나의 프로필을 선택하거나, 수락 가능한 프로필이 없으면 채널을 거부했다. 수락된 URI가 결합 이벤트였다. 그 전까지 번호는 단지 제안일 뿐이었다.

번호 매기기 규칙은 얇은 공통 메커니즘의 작은 예였다. 시작 피어는 홀수 양의 채널 번호를, 수신 대기 피어는 짝수를 골랐다. 각 측은 중앙 할당자에게 묻지 않고도 채널을 만들 수 있었고 상대와 충돌하지도 않았다. 이는 지속적 권위가 아니라 결정론적 분할에 의한 조율이었다.

의미는 프로필이 공급했다

BEEP 채널은 레인이지 완전한 애플리케이션 프로토콜이 아니었다. 그 채널에 결합된 프로필이 메시지 구문과 의미를 정의했다. RFC 3117은 나중에 이 구조를 단순히 요약했다: 애플리케이션 프로토콜은 BEEP에 하나 이상의 프로필을 더한 것이다.

코어는 교환 형식을 제공했다.MSG가 요청을 시작했다.RPY또는ERR이 일대일 교환을 완료했다.ANS는 다중 응답 중 하나를 실었고,NUL이 그 일대다 시리즈를 종료했다. 메시지 번호는 채널 안에서 교환을 구분했고, 페이로드 시퀀스 번호는 채널의 모든 프레임에 걸쳐 진행되었다.

이런 메커니즘은 의미를 무너뜨리지 않으면서 동시성을 허용했다. 서로 다른 채널의 프레임은 섞일 수 있었다. 세그먼트된 메시지는 자기 채널 안에서는 순차를 유지했지만, 여러ANS응답은 인터리빙되고 나중에 응답 번호로 정렬될 수 있었다. 한 채널이 사용 중인 동안 다른 채널이 진행될 수 있었다. 그러나 인터리빙은 공정성, 완료, 동등한 우선순위를 증명하지 않았다; 유효한 순서가 무엇인지만 정의했다.

같은 경계는 이후의 프로필에도 나타났다. RFC 3195는 신뢰성 있는 syslog 전달에 BEEP 프로필을 사용했다. RFC 4227은 SOAP에 자체 프로필 식별자와 부트 투 레디 상태를 부여했다. RFC 4744는 NETCONF를 프로필에 매핑하면서 매니저/에이전트 역할을 BEEP의 개시자/수신자 역할과 분리해 두었다. 각 애플리케이션은 레인 메커니즘을 물려받은 뒤, 메시지가 무엇을 의미하는지 무엇이 준비 상태인지를 직접 정의해야 했다.

보안 튜닝은 세션을 바꿨지 결과를 바꾸지 않았다

RFC 3080은 초기 튜닝 채널과 지속적인 애플리케이션 채널을 구분했다. TLS와 SASL은 지속적인 데이터 교환이 시작되기 전에 세션의 보안 조건을 변경할 수 있었다. 한 번에 하나의 튜닝 채널만 활성화될 수 있었다.

이 순서가 중요한 이유는, 튜닝 전의 관찰이 보안이 변경된 뒤에는 자동으로 신뢰할 수 없었기 때문이다. TLS 논의는 피어가 성공적인 협상 이전에 캐시된 세션 정보를 폐기할 것을 요구했다: 능동적 공격자가 그것을 변경했을 수 있었다. 새로 보호되는 상태에는 새로운 증거가 필요했지, 낡은 가정 위에 장식적인 잠금을 놓는 것은 아니었다.

인증 또한 권한 부여를 지우지 않았다. RFC 3080은 채널이 작업을 수행하기 전에 인증된 신원과 프라이버시 수준에 적합한 접근 제어를 적용해야 한다고 명시했다. 세션은 피어가 누구인지 알면서도 프로필, 채널 또는 특정 작업을 거부할 수 있었다.

하나의 연결을 공유하는 것은 두 번째 제어 문제를 낳았다

하나의 기반 위에 독립적인 채널을 다중화하는 것은 연결 수를 아꼈지만, 자원 경합을 드러나게도 했다. RFC 3081은 TCP 흐름 제어가 연결 단위로 동작한다고 지적했다. 다른 메커니즘이 없다면 느리거나 탐욹스러운 BEEP 채널이 이웃 채널을 굶기거나 교착시킬 수 있었다.

그래서 TCP 매핑은 채널별 슬라이딩 윈도우와SEQ프레임을 추가했다. 새로 만들어진 채널은 4096 옥텟 윈도우로 시작했다. 수신자는 다음 기대 시퀀스 번호와 수용 가능한 페이로드 윈도우를 광고했다. 이것은 재전송이 아니었다; 신뢰성 있는 전달은 이미 TCP가 담당했다. 이것은 공유 전송 계층 안에서의 로컬 입장 제어였다.

이 세부 사항은 RFC 3081에 속하지만, RFC 3080을 비춘다. 독립성은 하나의 스트림에 채널 번호를 그린다고 만들어지지 않았다. 별도의 회계, 별도의 진행, 그리고 누가 공유 용량을 소비할 수 있는지에 대한 규칙이 필요했다.

이후의 포트 릴리스는 이전 계층을 다시 쓰지 않았다

BEEP는 실제 프로필 명세를 갖게 되었다: 신뢰성 있는 syslog, SOAP, 그리고 NETCONF 등이 그 예다. 수명 주기 증거도 갖게 되었다. RFC 9900은 나중에 NETCONF over BEEP와 NETCONF over SOAP에 할당된 포트 번호를 서비스 이름은 유지한 채 릴리스했다.

이 기록을 승리 신화나 실패 신화로 구부려서는 안 된다. RFC는 영구적인 배포를 이루지 못하면서도 일관된 아키텍처를 정의할 수 있다. 서비스 이름은 숫자 포트가 릴리스된 뒤에도 남을 수 있다. 애플리케이션 프로필이 일반적 사용에서 사라져도, 연결과 협상된 의미와 효과 사이의 구분은 덜 유효해지지 않는다.

역사적 교훈은 더 좁다. RFC 3080은 가장 낮은 수준의 눈에 보이는 성공이 모든 상위 주장을 흡수하도록 허락하지 않았다. 프로필이 선택되지 않은 채 회선이 열려 있을 수 있었다. 접근이 거부된 채 프로필이 선택될 수 있었다. 외부 상태가 변하지 않은 채 응답이 수신될 수 있었다.

출처

  1. https://www.rfc-editor.org/info/rfc3080
  2. https://www.rfc-editor.org/rfc/rfc3080.html
  3. https://datatracker.ietf.org/doc/rfc3080/
  4. https://www.rfc-editor.org/rfc/rfc3081.html
  5. https://www.rfc-editor.org/rfc/rfc3117.html
  6. https://www.rfc-editor.org/rfc/rfc3195.html
  7. https://www.rfc-editor.org/rfc/rfc4227.html
  8. https://www.rfc-editor.org/rfc/rfc4744.html
  9. https://www.rfc-editor.org/rfc/rfc9900.html
  10. https://heng.lu/running-code-primary-the-patch-needed-to-preserve-the-internet-original-design/
  11. https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
  12. https://heng.lu/on-reality-layers-symbolic-power-and-why-clarity-feels-so-hostile/