요약

  • RFC 1441은 SNMPv2를 일곱 개의 연결된 사양 영역으로 제시했습니다. 여기에는 메시지 래퍼에 인증 및 권한 부여 의미를 부여한 관리 프레임워크가 포함됩니다. “버전 2”는 하나의 불가분 프로토콜이 아니라 모듈들의 체계를 가리키는 이름이었습니다.
  • 원래의 파티 기반 관리는 지속적인 배포 경로가 되지 못했습니다. 이후 RFC 1901은 SNMPv2 동작과 기존 커뮤니티 메커니즘을 결합했고, 새 버전 값은 강력한 보안이 아니라 PDU 문법을 구분했습니다.
  • RFC 3411은 결국 이 교훈을 형식화했습니다. 메시지 처리, 보안, 접근 제어는 별개의 모델이며, 하나의 엔진이 여러 모델을 동시에 지원할 수 있습니다. 운영자는 버전 필드에서 이들을 추론해서는 안 되고, 선택된 모듈과 관측된 정책을 조사해야 합니다.

래퍼는 하나라고 했고, 제품 라벨은 둘이라고 했다

분석가가 패킷을 열어 버전 정수가1인 SNMP 메시지를 발견했다고 가정해 봅시다. 일반적인 세기로 읽으면 이 필드는 첫 번째 버전을 알리는 것처럼 보입니다. 그러나 커뮤니티 기반 SNMPv2 래퍼에서는 0이 SNMPv1을, 1이 SNMPv2c를 나타냈습니다. 이 값은 산문이 아니라 열거(enumeration)였습니다.

이것은 번호 매기기에 관한 호기심 이상의 문제입니다. 래퍼는 커뮤니티 문자열과 SNMPv2 PDU도 함께 담고 있었습니다. 한 필드는 메시지 문법을 선택했고, 다른 필드는 물려받은 관리 토큰을 제공했으며, PDU는 동작을 담았습니다. 이 인접한 바이트들은 서로 다른 주장에 속해 있었습니다.

그 패킷 뒤에 있는 역사는 부분들이 보존되고, 교체되고, 재결합된 역사입니다. 버전 1에서 버전 2, 그리고 버전 3으로 나아가는 단순한 행진으로 이해할 수 없습니다. 이름은 넓게 유지되었지만, 그 아래의 조립체는 바뀌었습니다.

RFC 1441은 패킷 형식이 아니라 지도였다

1993년 4월에 발행되어 현재는 Historic으로 분류된RFC 1441 기록은 두 번째 인터넷 표준 네트워크 관리 프레임워크에 대한 소개를 담고 있습니다. 여기서 중요한 명사는프레임워크입니다.

RFC 1441 본문은 SNMPv2를 일곱 영역으로 나누었습니다. 관리 정보 구조(Structure of Management Information)는 관리 대상 객체의 문법을 정의했습니다. 텍스트 관례(Textual conventions)는 원시 인코딩에 더 정밀한 인간적 의미를 부여했습니다. 프로토콜 동작은 PDU를 기술했습니다. 전송 매핑은 메시지를 특정 캐리어 위에 놓았습니다. 계측(instrumentation)은 SNMP 엔티티의 동작을 설명했습니다. 관리 프레임워크는 인증과 권한 부여 정책을 공급했습니다. 적합성 명시(conformance statements)는 요구되는 하한과 구현된 역량을 구분했습니다.

그 어떤 영역 하나도 나머지를 진실하게 대표할 수 없었습니다. MIB 객체 정의는 전송 방식을 선택하지 않았습니다. 전송 주소는 권한을 부여하지 않았습니다. PDU는 발신자를 인증하지 않았습니다. 적합성 명시는 광고된 기능이 이 장비에서 실제로 활성화되어 있음을 증명하지 않았습니다.

RFC 1441은 메시지 래퍼의 형식과 의미가 관리 프레임워크에 의해 결정된다고 밝혔습니다. 이 문장은 권한을 동작 자체 밖에 두었습니다.Get,Set또는 알림이 형식적으로 올바를 수 있었지만, 프레임워크는 여전히 그 메시지가 누구의 것인지, 그 주체가 무엇을 할 자격이 있는지 확립해야 했습니다.

원래의 조립체에는 파티가 포함되어 있었다

1993년 관리 설계의 중심에는 SNMPv2파티(party)가 있었습니다. 파티는 엔티티의 가능한 동작 중 관리적으로 정의된 부분집합으로 제한된 개념적 실행 맥락이었습니다. 각 파티는 하나의 인증 프로토콜과 하나의 프라이버시 프로토콜을 가졌습니다. 파티 MIB가 관련 속성을 노출했습니다.

이것은 PDU 사양 끝에 덧붙인 장식적인 보안 용어가 아니었습니다. 동작이 관리적 의미를 얻는 맥락을 정의하기 위한 것이었습니다. 래퍼와 파티 체계가 바뀌면, “동일한 SNMPv2 동작”은 더 이상 동일한 인증·권한 부여 이야기를 담지 않았습니다.

이 설계는 되풀이되는 표준 문제도 드러냅니다. 프레임워크는 종이 위에서는 기술적으로 분해될 수 있지만, 사회적으로는 하나의 버전 이름으로 판매될 수 있습니다. 그러면 제품 스펙 시트, 자산 목록, 대화가 그 번들을 다시 단일 라벨로 압축합니다. 한 구성 요소가 나머지와 함께 이동하지 못하면, 라벨은 그 대체를 감춥니다.

커뮤니티 기반 SNMPv2는 동작은 유지하고 거래를 바꿨다

1996년 1월,RFC 1901은 흔히 SNMPv2c라고 불리는 커뮤니티 기반 SNMPv2를 정의했습니다. 이것은 파티 모델을 더 단순한 철자로 되살린 것이 아니었습니다. SNMPv1을 위해 정의된 관리 프레임워크를 가져와 각 메시지를 커뮤니티에 연결하고, 그 프레임워크를 SNMPv2의 더 새로운 PDU와 오류 코드와 짝지었습니다.

래퍼는 이 대체를 드러냈습니다. 버전 정수는1이 되었으며, 이전 래퍼에서 바뀐 이유는 더 새로운 PDU 유형과 오류 코드 때문에 수신자가 올바른 문법을 선택해야 했기 때문입니다. 커뮤니티 문자열은 그 옆에 그대로 남았습니다. 따라서 그 숫자는 좁지만 중요한 무언가를 증명했습니다. 페이로드를 해석해야 할 메시지 처리 규칙이 무엇인지입니다. 더 새로운 PDU에 붙는다고 해서 커뮤니티 메커니즘이 산업 수준의 인증으로 변하지는 않았습니다.

이것이 이 이야기의 경첩입니다. 유용한 개선은 살아남았습니다. 확장된 유형, 대량 조회(bulk retrieval), 확인 가능한 알림, 더 풍부한 오류, 더 나은 행(row) 연산이 그것입니다. 그러나 동작 집합이 살아남았다는 것은 원래의 보안 프레임워크도 함께 살아남았다는 뜻이 아닙니다. 호환성은 데이터와 동작이 서로 다른 관리 체계 사이를 이동할 수 있게 했습니다. 동시에 넓은 버전 이름을 어떤 하나의 체계에 대한 설명으로 믿기 어렵게 만들었습니다.

표준 기록과 구동 중인 코드는 갈라졌다

IETF의 2002년 회고,RFC 3410은 그 결과에 대해 이례적으로 솔직합니다. 이 문서는 파티 기반 SNMPv2p를 1993~1995년의 노력으로 기술합니다. 이후의 SNMPv2 프레임워크에는 자체적인 표준 기반 보안·관리 프레임워크가 없었고 여러 대안과 연관되었습니다. SNMPv2c는 IETF의 가장 많은 지원을 받았지만 보안과 관리를 갖추지 못했고, 보안을 담는 대안들은 합의를 얻지 못했습니다.

SNMPv3의 보안과 관리가 완전한 Standard에 도달하자, 평문 커뮤니티 문자열 인증이 근본적으로 불안전하다는 이유로 SNMPv1과 실험적 SNMPv2c는 Historic으로 선언되었습니다. 파티 기반 SNMPv2p와 다른 버려진 대안들은 Historic이거나 표준 트랙에 도달한 적이 없었습니다.

그러나 같은 RFC는 공급업체와 사용자가 v3와 함께 v1 및/또는 v2c를 지원하는 다중 언어 엔진을 계속 배포할 것으로 예상했습니다. 표준 절차는 그 배포 선택을 통제할 수 없다는 제도적 한계를 분명히 밝혔습니다. 상태, 권고, 구동 중인 구현은 서로 다른 층위에 있었습니다.

이 구분은 정반대의 두 오류를 막습니다. Historic이라고 네트워크에서 부재라는 뜻은 아닙니다. 배포되어 있다고 보증되거나 안전하다는 뜻도 아닙니다. SNMPv2c 응답을 본 스캐너는 도달 가능한 구동 코드의 증거를 가진 것입니다. 그것을 계속 사용하라는 IETF 권고를 발견한 것은 아닙니다. RFC 1901을 Historic으로 표시한 표준 목록은 하나의 판단을 기록한 것입니다. 모든 커뮤니티 경로가 사라졌음을 증명하지는 않습니다.

버전은 디스패처의 입력이 되었다

RFC 3411은 이 얼킨 역사를 더 깔끔한 아키텍처로 정리했습니다. 그 문서 지도는 전송 매핑, 메시지 처리 및 디스패치, 보안, 프로토콜 동작, 애플리케이션, 접근 제어를 분리했습니다. 구성 요소들은 정의된 인터페이스 뒤에서 서로 다른 시기표에 따라 진화할 수 있었습니다.

그 정의는 일상적인 제품 어휘보다 날카롭습니다. 프레임워크는 하위 시스템들의 집합입니다. 모델은 하나의 하위 시스템에 대한 특정 설계입니다. 구현은 하나 이상의 모델을 인스턴스화합니다. 가장 인상적인 것은, 이 문서가 SNMPv2에는 메시지 정의가 없으며 SNMPv2c가 SNMPv1과 유사한 메시지 형식으로 그것을 보완한다고 말한다는 점입니다.

이 아키텍처에서 버전 필드는 보통 메시지 처리 모델(Message Processing Model)을 식별합니다. SNMP 엔진은 그러한 모델을 여러 개 포함하고 여러 메시지 버전을 보내거나 받을 수 있습니다. 보안은 별개의 하위 시스템입니다. 인증, 암호화, 시효 검사는 메시지 수준 보안에 속합니다. 접근 제어는 다른 질문, 즉 동작이 관리 대상 객체에 도달할 수 있는지에 답합니다. 엔진은 여러 보안 모델을 동시에 지원할 수도 있습니다.

결과적으로 패킷 앞머리의 필드는 엔진 내부의 라우팅 좌표입니다. 그 뒤를 따르는 모든 것에 대한 서명된 요약이 아닙니다. SNMPv3라는 라벨조차 관측된 교신이 인증과 프라이버시를 사용했다는 보장이 되지 못합니다. 선택된 보안 수준과 모델은 여전히 중요합니다. 아키텍처는 조합(composition)의 여지를 만들었고, 조합은 조사(인벤토리)를 불가피하게 만듭니다.

버전 열보다 모듈 대장이 더 정직하다

많은 자산 인벤토리에는 SNMP 필드가 하나뿐입니다. “v2”, “v2c”, “v3” 같은 값은 편리하지만, 복합 체계를 단일 셀에 강제로 담습니다. 이행 기간 동안 그 셀은 오히려 적극적으로 오도적이 됩니다. 같은 엔진이 여러 메시지 모델에 응답할 수 있고, 한 인터페이스는 커뮤니티 경로를 유지하는 동안 다른 워크플로는 더 강한 보안 모델을 사용할 수 있으며, 접근 뷰는 주체와 맥락에 따라 다를 수 있습니다.

유용한 기록은 최소한 다섯 가지 관측을 구분합니다. 첫째는 실제로 도달한 전송 엔드포인트입니다. 둘째는 디코딩된 메시지 처리 모델입니다. 셋째는 보안 모델과 선택된 보안 수준입니다. 넷째는 인증되었거나 단지 주장된 신원, 맥락, 접근 제어 모델, 허용된 뷰입니다. 다섯째는 PDU, 응답, 그리고 주장된 장비 효과에 대한 독립적인 관측입니다.

이 기록들은 요청 식별자와 시간 창을 공유할 수 있습니다. 그러나 서로를 대체할 수는 없습니다. 버전 값은 주체를 증명하지 않습니다. 주체가 이 객체에 대한 접근을 증명하지 않습니다. 권한 부여 결정이 물리적 변경을 증명하지 않습니다. 성공한 응답이 재시작 이후의 지속성을 증명하지 않습니다.

RFC 1441의 실패한 번들은 따라서 생산적인 교훈을 남겼습니다. 모듈화 덕분에 가치 있는 정보와 동작 설계는 하나의 관리 체계보다 오래 살아남을 수 있었습니다. 보안 아키텍처가 바뀔 때 관리 언어 전체를 버려야 할 필요를 줄였습니다. 그러나 같은 모듈화가 버전 이름을 완전한 운영적 진실로 다루는 어떠한 핑계도 제거했습니다.

출처

  • RFC 1441 기록과 현재 상태.
  • RFC 1441 프레임워크 소개.
  • RFC 1901 커뮤니티 기반 보완.
  • RFC 3410 적용 가능성 및 표준 역사.
  • RFC 3411 모듈형 아키텍처.