요약

  • RFC 2012는tcpConnState를 읽기-쓰기(read-write) 객체로 만들었다. 관리 스테이션이 설정할 수 있는 값은deleteTCB(12)뿐이었고, 이 값은 선택된 연결의 전송 제어 블록(TCB)을 삭제하며 로컬 연결을 즉시 종료했다.
  • 테이블은 로컬 및 원격 IPv4 주소와 포트로 연결을 식별했고, 엔진 카운터는 오픈, 실패, 리셋, 세그먼트를 요약했다. 그러나 행도 카운터도 운영자 신원·권한 부여에서 응용과 서비스 결과에 이르는 완전한 연쇄를 기록하지 않았다.
  • RFC 4022는 삭제 동작을 유지하면서 수신 대기(listener)와 연결을 분리하고, 주소 유형과 프로세스 식별자를 추가했으며, 적합성 규정에서 쓰기 지원을 선택 사항으로 두고, 허가되지 않은 쓰기가 임의의 연결을 종료할 수 있다고 명시적으로 경고했다.

행은 서술에서 동작으로 선을 넘었다

RFC 2012의 대부분은 측정 장치처럼 보인다. 재전송 알고리즘과 타임아웃 상한, 현재 established 또는 close-wait 연결 수, 오픈·실패 시도·리셋·수신 세그먼트·재전송·오류·발신 리셋 카운터를 노출한다. 연결 테이블은 여기에 더 정확한 시야를 제공한다. 로컬 주소와 포트, 원격 주소와 포트, 그리고 현재 TCP 상태다.

그러나tcpConnState는 단순한 상태 칸이 아니었다. 이 객체의MAX-ACCESS는read-write였다. 관리자가 일반 상태 값을 쓸 수는 없었고, 관리 목적으로 허용된 유일한 값은deleteTCB(12)였다. 규격이 명시한 효과는 이례적으로 직접적이었다. 관리 대상 노드에서 해당 TCB를 삭제하고 연결을 즉시 종료한다는 것. 에이전트는 선택적으로 피어에게 리셋 세그먼트를 보낼 수 있지만, 문서는 리셋이 신뢰할 수 있게 전달되지 않는다고 경고했다.

이 구분이 중요하다. 로컬 삭제가 규정된 행위이고, 피어 통지는 선택 사항이며, 그 통지의 전달은 불확실하다. 원격 응용이 무엇을 보는지, 재시도하는지, 사용자가 체감하는 서비스가 중단되는지는 그 이후에 일어나는 사건들이다. 성공한 SET 응답은 이것들을 하나의 사실로 압축할 수 없다.

TCB 삭제는 꼬리표 이상을 지운다

RFC 793은 전송 제어 블록을 TCP가 연결을 기억하는 기록으로 묘사했다. 로컬·원격 소켓 번호, 보안과 우선순위, 송수신 버퍼 포인터, 재전송 큐와 현재 세그먼트, 송수신 시퀀스 변수가 그 안에 담긴다. TCB가 존재하지 않으면 연결도 존재하지 않기 때문에, CLOSED는 가상의 상태라고 불렀다.

따라서 이 관리 동작은 대시보드 꼬리표를 편집한 것이 아니라, 이 특정 연결을 가능하게 한 로컬 프로토콜 상태 자체를 제거한 것이다. 그럼에도 행의 식별 정보는 IPv4 주소와 포트의 네 가지 조합뿐이었다. 행은 수명이 짧았고, RFC 2012는 동작 식별자, 요청 사유, 티켓, 발신 주체, 응용 소유자, 삭제 전후의 영구 영수증을 추가하지 않았다.

이 메커니즘은 1996년에 새로 만들어진 것이 아니라 계승된 것이다. RFC 1213은 이미 1991년에 연결의 TCB 삭제를 지원하기 위해tcpConnState를 읽기-쓰기로 바꾸어 놓았다. RFC 2012는 같은 객체들을 SMIv2로 옮겼을 뿐이다. 서문에서는 인증, 권한 부여, 접근 통제, 기밀성이 행정 체계에 속한다고 밝히고, 자체 보안 고려 사항 절에서는 보안 문제가 논의되지 않았다고만 적었다.

카운터는 변화는 보여줄 수 있지만 원인은 증명하지 못한다

삭제 이후 운영자는 현재 established 게이지가 떨어지거나, established-리셋 카운터가 오르거나, 발신 리셋 카운터가 변하는 것을 볼 수 있다. 어느 것도 관리 동작 대장이 아니다.tcpEstabResets는 그 이유와 무관하게 CLOSED로의 특정 상태 전이를 센다.tcpOutRsts는 RST를 실은 세그먼트를 센다. 신뢰할 수 있게 전달된 통지도, 운영자의 의도도 아니다.tcpCurrEstab는 어디까지나 현재 시점의 게이지다.

따라서 귀속에는 MIB가 제공하지 않는 결합이 필요하다. 관측된 정확한 행, 인증된 요청, 보안 맥락과 쓰기 판단, 에이전트의 수락, 로컬 상태의 소멸, 응용의 반응, 피어의 관측, 재시도 경로, 중단 시간, 서비스 결과. 이 연쇄가 없으면 카운터 변화는 관리 삭제와 양립할 수 있어도 그것을 증명하지는 못한다.

RFC 4022는 식별 정보를 넓히고 약속은 좁혔다

2005년의 후속 문서는 이 스위치를 제거하지 않았다.tcpConnectionState는 여전히deleteTCB(12)를 받아들였고, 여전히 선택적이고 신뢰할 수 없는 RST와 함께 즉각적인 로컬 종료를 규정했다. 다만 주변의 증거 지형을 다시 그렸다.

RFC 4022는 기존 테이블이 IPv4 전용이고 수신 대기와 연결을 섞어 놓았다는 이유로 이를 폐기(deprecated) 처리했다. 새 연결 인덱스는 로컬·원격 주소 유형을 주소와 포트와 짝지었다. 별도의 수신 대기 테이블은 와일드카드, 단일 주소군, 특정 주소 수신 대기를 구분했다. 연결 행과 수신 대기 행은 운영체제의 프로세스 식별자를 보고할 수 있어, 호스트 자원 MIB나 응용 MIB와의 상관 분석이 가능했다.

이런 필드는 “어떤 소켓이고 어떤 프로세스인가?”라는 질문을 개선한다. 그러나 “누가, 어떤 운영 사유로 승인했으며 고객은 무엇을 체험했는가?”에는 답하지 않는다. 프로세스 식별자는 0이거나 재사용되거나, 어디까지나 하나의 호스트 안에서만 의미를 가질 수 있다. 주소 유형과 존은 행을 구별해 줄 수 있지만 영구적인 동작 이력을 제공하지는 않는다.

RFC 4022는 중요한 적합성 구분도 만들었다.tcpConnectionState에 대한 쓰기 접근과deleteTCB(12)지원은 필수가 아니었다. 따라서 스키마, 구현된 기능, 부여된 권한, 실행된 동작은 각각 따로 검증해야 한다.

보안 절은 마침내 운영상 위험을 이름으로 지적했다. 쓰기 가능한 상태 객체에 대한 허가되지 않은 접근은 임의의 연결을 종료하고 서비스 거부를 일으킬 수 있다는 것. 또한 읽기 가능한 연결, 수신 대기, 프로세스 데이터를 잠재적으로 민감한 것으로 다루었다.

이후의 보안 모델은 영수증의 일부만 채웠다

SNMPv3는 더 강한 조각들을 제공했다. RFC 3414는 메시지가 발신된 사용자를 인증하고, 무결성과 시효성을 보호하며, 기밀성을 선택적으로 보호할 수 있었다. RFC 3415는 보안 모델, 보안 이름, 보안 수준, 컨텍스트, 읽기 또는 쓰기 뷰, 정확한 객체 인스턴스로부터 접근을 판단할 수 있었다.

이 통제들은 RFC 2012의 행만으로는 확립할 수 없는 훨씬 많은 것을 확립할 수 있다. 읽는 주체와 쓰는 주체를 분리하고 쓰기 주체의 시야를 좁힐 수 있다. 그러나 RFC 3414 자체도 메시지 발신의 명의가 되는 사용자를 인증하는 것이지, 반드시 특정 인간 발신자를 인증하는 것은 아니라고 경고한다. 어느 보안 모델도 변경 티켓, 사업 사유, 응용 확인, 피어 수신, 사용자 영향, 복구 시간을 제공하지 않는다.

역사적 교훈은 원격 연결 삭제 자체가 본질적으로 잘못된 것이라는 게 아니다. 운영자에게 긴급 액추에이터가 필요할 수 있다. 교훈은 관측 테이블 안에 액추에이터를 놓는 순간, 보는 것과 행동이 허용되는 것과 행동하는 것과 결과를 증명하는 것 사이의 경계를 보존할 의무가 생긴다는 것이다. 실행되는 코드는 삭제를 체험하고, 초록불 관리 응답은 그중 한 단계만 서술한다.

출처

근거의 한계

이 출처들은 규격 본문, 문서 계보, 객체 문법, 적합성 선택지, 보안 모델의 의미론을 확립한다. 어떤 벤더가 쓰기 가능한 상태를 구현했는지, 어떤 운영자가 그것을 사용했는지, 장애가 발생했는지, 이 기능이 얼마나 배포되었는지, 그리고 현재의 서비스 수준 목표가 무엇을 요구하는지는 확립하지 않는다.