요약

  • RFC 1215는 등록 권한, 순서화된 변수, 텍스트적 의미, 정수를 SNMPv1 Trap-PDU로 매핑하기 위한TRAP-TYPE규약을 제공했습니다. 이 정의는 이벤트가 발생한 시점이 아니라 구현 과정에서 작성된 것입니다.
  • 트랩은 송신 애플리케이션이나 프로토콜 개체가 인식한 내용을 기술했습니다. 이 송신 측 단언이 물리적 고장, 근본 원인, 고객 영향, 인증된 신원을 독립적으로 증명하지는 못했습니다.
  • SNMPv1은 비신뢰성 데이터그램 서비스를 사용했으며, 목적지는 구현에 따라 결정되었습니다. 정의, 인식, 생성, 전송, 수신, 확인, 운영자 조치, 복구는 각각 별개의 기록이었습니다.

알림은 사건보다 앞서 존재했다

RFC 1215에서 가장 유용한 문장은 예제들 앞에 나옵니다.TRAP-TYPE매크로의 전개는 런타임이 아니라 개념적으로 구현 시점에 일어난다는 것입니다.

이 시점 차이는 그 산출물의 의미를 바꿉니다. 구현자는 링크가 끊어지기 전에myLinkDown을 정의하고, 엔터프라이즈를 지정하고, 순서화된 변수를 선택하고, 설명을 작성할 수 있습니다. 컴파일러나 관리 도구는 그 형태를 이해할 수 있습니다. 수신 측은 표시 규칙을 미리 준비할 수 있습니다. 그 어떤 작업도 센서의 관측이 아닙니다.

이 구분이 놓치기 쉬운 이유는 트랩 정의가 이벤트 같은 언어를 사용하기 때문입니다. 정의의 설명은 송신 개체가 링크 장애를 인식한다고 말할 수 있습니다. 정의의 정수는 인시던트 스트림의 코드와 비슷하게 생길 수 있습니다. 변수 목록은 미리 준비된 증거 묶음처럼 보일 수 있습니다. 그러나 정의는 완성된 보고서보다는 빈 양식에 가깝습니다. 정의는 인스턴스가 생성될 경우 어떤 필드가 의미를 담게 될지를 기술할 뿐입니다.

RFC Editor 기록은 이 메모를 1991년 3월로 날짜를 매기고 Informational로 분류합니다.IETF Datatracker 기록도 같은 식별 정보를 보존하고 있습니다. 문서 본문은 트랩이 인터넷 표준 관리 프레임워크에서 논쟁적이었으며 그 사용을 강하게 만류한다고 명시합니다. 이 규약은 기존 트랩을 간결하게 기술하기 위한 것이었지, 새로운 트랩의 난립을 장려하기 위한 것이 아니었습니다.

이러한 주의는 트랩이 없거나 쓸모없었다는 증거가 아닙니다. 그것은 이 문서의 야망에 관한 증거입니다. RFC 1215는 공유된 기술 표면을 제공하면서도 그 표면을 일반적 승인이나 인터넷 표준으로 만들지 않았습니다.

네 개의 절이 하나의 타입을 만들었다

TRAP-TYPE매크로는 서로 다른 네 종류의 정보를 결합했습니다.

ENTERPRISE는 필수였습니다. 이 절은 트랩이 정의되고 SNMPv1 Trap-PDU의 enterprise 필드로 매핑되는 등록 권한을 가진 관리 엔터프라이즈를 명명했습니다. 등록 권한은 “이 정의는 누구의 이름공간에 속하는가?”에 답했습니다. 그것은 “이 데이터그램을 보낸 자연인은 누구인가?”나 “현재 이 장치를 소유한 이는 누구인가?”에는 답하지 않았습니다. 개체 식별자는 서명도, 자격 증명도, 행위 권한도 아니었습니다.

VARIABLES는 선택이었습니다. 존재할 경우, 이 절은 그 트랩 타입의 모든 인스턴스에 포함될 것으로 기대되는 MIB 개체들의 순서화된 열을 지정했습니다. 개체들이 순서대로 variable-bindings 필드에 복사되기 때문에 순서가 중요했습니다. 에이전트는 더 많은 변수를 추가할 수도 있었습니다.

이는 그 목록이 운영적으로 완전하다는 주장이 아니라 최소 형태임을 의미합니다. 목록은 미래의 인스턴스 값들을 담지 않았습니다. 추가된 모든 개체가 모든 관리자에게 동일하게 해석될 것이라고 말하지 않았습니다. 인터페이스 인덱스를 케이블, 포트, 회선 또는 고객 서비스의 고장 증명으로 바꾸지도 않았습니다.

DESCRIPTION은 타입에 텍스트적 의미를 부여했습니다. MIB 모듈이 다른 곳에서 동등한 텍스트를 정의하지 않았다면 이 절은 반드시 존재해야 했습니다. 그러나 모듈 안의 산문은 여전히 명세 산문이었습니다. 런타임 PDU가 나중에 그 타입을 참조했다고 해서 산문이 독립적 증인이 되지는 않았습니다.

REFERENCE는 다른 곳에서 정의된 관련 트랩, 이벤트 또는 알람을 가리킬 수 있었습니다. 상호 참조는 정의들을 연결합니다. 그러나 그것은 참조된 알람이 특정 배치에 존재한다거나, 두 이벤트가 동일하다거나, 어느 하나가 실제로 발생했다는 것을 증명하지 못했습니다.

마지막으로, 매크로의 정수 값은 PDU로 매핑되었습니다. 엔터프라이즈별 트랩의 경우 그 값은specific-trap이 되고,generic-trap은enterpriseSpecific(6)이 됩니다. 특수한snmp규약에서는 값이generic-trap에 들어가고specific-trap은 0이 됩니다.

따라서 그 수는 하나의 이름공간을 차지했습니다. 그것은 심각도, 신뢰도, 빈도, 시간순서, 인시던트 수 또는 확인 상태가 아니었습니다. 그것을 그중 하나로 다루는 것은 소스가 부여하지 않은 의미를 추가하는 일입니다.

레지스트리 이름은 송신자를 인증하지 않았다

enterprise 필드는 익숙한 제도적 지름길을 부추겼습니다. 트랩이 조직과 연관된 엔터프라이즈 개체 식별자를 담고 있다면, 운영자는 조직의 신원을 패킷에 직접 읽어 들일 수 있습니다.

RFC 1215는 더 좁은 주장을 지지합니다. 이 필드는 트랩이 정의되는 등록 권한을 식별합니다. 표준 SNMP 트랩용 규약에서는 에이전트의sysObjectID가 enterprise 필드에 배치됩니다. 둘 다 해석에 유용합니다. 그러나 어느 쪽도 암호학적 출처 증명이 아닙니다.

여러 기록이 분기할 수 있습니다. 벤더가 정의를 등록할 수 있습니다. 이후 회사가 제품을 인수할 수 있습니다. 통합 업체가 에이전트를 배치할 수 있습니다. 로컬 관리자가 목적지를 구성할 수 있습니다. 프로세스가 커뮤니티와 개체 식별자를 사용해 패킷을 발송할 수 있습니다. 개체 식별자만으로는 이 당사자들을 하나의 인증된 행위자로 묶지 못합니다.

RFC 1215의 보안 절은 보안 문제가 논의되지 않는다고만 말합니다. 그 침묵을 인증, 무결성, 기밀성 또는 재전송 방지로 격상시킬 수 없습니다. 관리 시스템은 이러한 속성에 대해 별도의 증거를 필요로 합니다.

예제는 물리적 진실이 아니라 인식을 보고했다

RFC 1215는 엔터프라이즈별myLinkDown트랩을 보여줍니다. 그 설명은 송신 SNMP 애플리케이션 개체가 에이전트 구성에 표현된 통신 링크 중 하나의 장애를 인식한다고 말합니다.

문법상의 주어가 중요합니다. 인식하는 것은 송신 애플리케이션입니다. 트랩은 독립적인 테스터가 물리적 경로를 측정했다거나, 통신사가 책임을 받아들였다거나, 사용자가 서비스를 잃었다고 주장하지 않습니다. 구성된 개체는 하위 계층이 변한 인터페이스를 나타낼 수 있습니다. 로컬 임계값, 드라이버 상태, 폴링 결과 또는 구현 규칙이 그 인식을 만들어냈을 수 있습니다. 근본 원인과 영향은 열려 있었습니다.

RFC 1157의 일반 link-down 예제도 같은 경계를 사용합니다. 송신 프로토콜 개체가 장애를 인식합니다. 그 첫 번째 변수 바인딩은 영향을 받은ifIndex인스턴스를 식별합니다. 이 식별자는 구성된 인터페이스 기록을 찾아줍니다. 그것이 전체 고장 트리는 아닙니다.

Trap-PDU 타임스탬프에도 비슷한 한계가 있습니다. 그것은 네트워크 개체의 마지막 재초기화와 트랩 생성 사이에 경과한 시간을 측정합니다. 케이블이 끊어진 벽시계 시각, 사용자가 성능 저하를 처음 알아차린 순간, 관리자가 패킷을 받은 시각과는 다를 수 있습니다.

따라서 유용한 인시던트 연표에는 최소 네 개의 시계가 필요합니다. 의심되는 조건의 첫 관측, 애플리케이션의 인식, PDU 생성, 수신자 도착이 그것입니다. RFC 1215는 그중 어느 것도 서로 바꿔 쓸 수 있다고 정의하지 않았습니다.

생성에는 또 다른 행위자가 필요했다

타입 정의는 영원히 사용되지 않을 수 있습니다. RFC 1157은 다음 행위를 SNMP 애플리케이션 개체에 두었습니다. 프로토콜 개체는 애플리케이션 개체의 요청이 있을 때만 Trap-PDU를 생성했습니다.

이는 이벤트 감지 정책과 전송 형식을 분리했습니다. 무언가가 알림에 해당한다고 판단하는 것은 애플리케이션이었습니다. 프로토콜 개체가 PDU를 구성하고 보냈습니다. 목적지 주소는 구현에 따른 방식으로 선택되었습니다.

따라서 구성이 정의와 수신자 사이에 개입했습니다. 완벽하게 정의된 트랩은 목적지가 구성되지 않아 어디에도 도달하지 못할 수 있습니다. 낡은 관리자에게 갈 수 있습니다. 억제될 수 있습니다. PDU를 파싱하지만 그 엔터프라이즈별 의미에 대한 규칙이 없는 수신자에게 라우팅될 수 있습니다.

RFC 1215의 인증 실패 예제는 억제를 명시적으로 만듭니다. 구현은 그 트랩을 생성할 수 있어야 하고, 구현에 따른 메커니즘을 통해 그 발산을 억제할 수도 있어야 합니다. 트랩이 없다는 것은 “인증 실패가 없다”를 의미할 수 있지만, 똑같이 “인식되지 않음”, “요청되지 않음”, “억제됨”, “잘못 주소됨”, “분실됨”, “처리되지 않음”을 의미할 수도 있습니다.

부재는 그 뒤에 여러 메커니즘이 있는 미지의 상태였습니다. 깨끗한 부정적 사실이 아니었습니다.

네트워크는 약속이 아니라 데이터그램을 실었다

SNMPv1은 의도적으로 비신뢰성 데이터그램 서비스만을 요구했습니다.RFC 1157은 각 메시지를 하나의 전송 데이터그램으로 표현하고 교환에 UDP를 지정했습니다. 트랩을 보고하는 메시지는 후속 처리를 위해 UDP 포트 162에서 수신되도록 되어 있었습니다.

“수신되어야 한다”는 서비스 관례를 명명한 것입니다. 리스너가 존재하고, 방화벽이 패킷을 통과시키고, 버퍼가 그것을 담고, 수신자가 파싱하고, 저장소가 보존하고, 운영자가 보았다는 것을 확립하지 않았습니다. UDP는 내장된 전달 확인 없이 시도를 실어 보냈습니다.

RFC 1157은 수신 시 무슨 일이 일어나는지는 기술합니다. 수신 프로토콜 개체는 Trap-PDU의 내용을 자신의 SNMP 애플리케이션 개체에 제시합니다. 수신은 따라서 프로토콜적 의미를 가졌습니다. 그러나 그것은 인간의 해석이나 교정 작업 앞에서 멈췄습니다.

이후의 SNMP 문서들은 1991년 증거를 다시 쓰지 않으면서 전송 구분을 명시적으로 만들었습니다.RFC 2578은 RFC 1215를 SMIv1의 일부로 다루고, SMIv2의NOTIFICATION-TYPE을 알림 문법과 의미의 간결한 기술로 정의합니다. 새로운 매크로 역시 알림 타입을 기술할 뿐이지, 그 발생 자체가 아닙니다.

RFC 3416은 SNMPv2-Trap의 알림 전달 메커니즘에는 관련된 확인이 없다고 말합니다. 또한 InformRequest를 확인된 것으로 정의하면서, 확인이 전달을 보장하지 않는다는 점을 경고합니다. 수신 시 수신자는 내용을 제시하고 Response-PDU를 보냅니다.

그 응답은 침묵보다 강한 증거입니다. 수신자와의 프로토콜 교환을 뒷받침합니다. 그러나 그것이 원래의 조건을 독립적으로 검증하거나, 운영자가 그 해석에 동의했다는 것을 증명하거나, 복구가 성공했다는 것을 보여주지는 않습니다. 확인은 한 간격을 좁힐 뿐, 사슬을 지우지는 못합니다.

알림 파이프라인은 관리 사슬이다

RFC 1215의 영속적 교훈은 알림이 약하다는 것이 아닙니다. 모든 유용한 알림에는 관리 사슬(custody trail)이 있다는 것입니다.

정의 작성자는 타입의 문법과 산문을 통제합니다. 등록 권한은 이름공간을 통제합니다. 애플리케이션은 인식 정책을 통제합니다. 프로토콜 개체는 PDU를 구성합니다. 로컬 구성은 목적지와 억제를 통제합니다. 네트워크는 전송을 제공합니다. 수신 개체는 프로토콜적 수용을 통제합니다. 관리 애플리케이션은 상관관계와 표시를 통제합니다. 운영자나 자동화 시스템은 조치를 통제합니다. 이후의 측정은 복구의 증거를 통제합니다.

이 역할들을 압축하면 깔끔해 보이는 코드가 인시던트 판결이 됩니다. 역할들을 보존하면 트랩은 본래의 모습이 됩니다. 독립적 증거가 결합할수록 가치가 커지는 경계가 있는 단언이라는 모습입니다.

출처