요약

  • RFC 1445는 모든 SNMPv2 파티에 구성된 전송 도메인과 주소를 부여했고, 새 요청을 보낼 때는 이 로컬 기록을 사용했습니다.
  • 응답은 다른 규칙을 따랐습니다. 응답은 해당 요청이 도착한 도메인과 주소로 전송되었으며, 그 좌표가 파티 데이터베이스와 상충하더라도 마찬가지였습니다.
  • 관찰된 반환 경로가 곧 신원이나 권한이 되지는 않았습니다. 출발 파티, 목적지 파티, 인증, 컨텍스트, 접근 정책, 연산 결과, 영구 구성은 별개의 결정이자 기록으로 남았습니다.

하나의 파티에는 주소 이상의 것이 담겼다

RFC 1445는 파티를 가상 실행 환경이라고 정의했습니다. 파티는 하나의 고유한 신원, 하나의 논리적 네트워크 위치, 하나의 인증 프로토콜, 하나의 기밀성 프로토콜, 그리고 행정적으로 제한된 연산 집합을 가졌습니다. 위치 자체는 전송 도메인과 전송 주소 정보로 나뉘었습니다.

이 구분은 편한 지름길을 막았습니다. 주소는 UDP나 다른 전송 수단을 통해 메시지를 어디로 전달할지만 말해줄 수 있었습니다. 어떤 파티가 동작 중인지, 어떤 암호학적 규칙이 적용되는지, 어떤 관리 컨텍스트가 의도되었는지, 그 파티가 어떤 객체를 다룰 수 있는지는 말해주지 않았습니다.

모든 SNMPv2 개체는 알려진 파티, 관리 대상 자원, 접근 정책에 대한 로컬 데이터베이스를 유지했습니다. 이 기록들이 새로운 교환을 가능하게 했습니다. 그러나 이것들은 기록일 뿐, 매 순간 네트워크를 스스로 증명하는 측정치가 아니었습니다.

RFC Editor 기록은 현재 이 모델을 Historic으로 분류하고 있습니다. 이 파티 프레임워크는 현재 배포 권고 사항이 아닙니다. 다만 그것이 드러낸 절차적 구분은 여전히 유용한데, 구성과 근거가 서로 어긋날 때 시스템이 어느 쪽을 따를지를 다루기 때문입니다.

새 요청은 목록을 신뢰했다

개체가 요청을 생성할 때는 출발 파티, 수신 파티, 컨텍스트, 연산을 지정했습니다. 개체는 양쪽에 연관된 인증 정보와 수신 파티의 기밀성 프로토콜을 로컬 파티 데이터베이스에서 조회했습니다. 메시지를 구성하고 직렬화한 뒤에는 수신자에게 기록된 전송 도메인과 주소로 전송했습니다.

이것이 구성의 일반적 목적입니다. 어떤 패킷도 아직 돌아오기 전에, 관리자는 영구 상태에서 경로를 선택해야 합니다. 이 항목은 교환을 시작하기에 충분할 만큼 강한 가설입니다.

RFC 1445는 요청이 전송되었다는 이유만으로 접근 정책이 적용되지는 않는다고 명시했습니다. 전송은 원격 측의 인가가 아닙니다. 구성된 목적지가 그 파티가 실제로 거기 존재한다는 증명도 아닙니다. 로컬에서 보호된 패킷이 다른 개체가 그 신원, 컨텍스트, 요청된 연산을 수용할 것이라는 증명도 아닙니다.

주소록은 초기 좌표를 제공했습니다. 절차의 나머지 부분을 그 좌표로 환원하지는 않았습니다.

수신은 여러 개의 독립적 관문을 열었다

수신 처리는 출발 소켓을 완전한 주체로 다루지 않았습니다. 먼저 바이트가 예상되는 비공개 메시지 래퍼로 디코딩되어야 했습니다. 지정된 목적지 파티가 로컬에 존재하고 실제로 그 개체에 의해 실현되어야 했습니다. 내부 목적지는 외부 목적지와 일치해야 했습니다.

그다음, 관리 통신 안에 지정된 출발 파티가 로컬 데이터베이스에 존재해야 했습니다. 수신자는 파티에 연관된 인증 프로토콜을 평가했습니다. 지정된 컨텍스트를 해석하고, 대상 파티, 주체 파티, 관리 대상 자원, 허용된 통신 클래스를 결합하는 접근 정책을 조회했습니다.

이 관문들을 통과한 뒤에야 연산은 로컬 MIB 뷰에 대해 또는 프록시 관계를 통해 진행될 수 있었습니다. 역사적인noAuth구성에서는 메시지가 그 선택된 프로토콜에 의해 진본으로 취급되었습니다. 이 사실은 1993년 모델에 속하며, 패킷의 네트워크 출발지가 제공하는 암호학적 증명이 아니었습니다.

순서가 중요합니다. 관찰된 도착, 디코딩된 파티 주장, 구성된 인증 결과, 컨텍스트 조회, ACL 결정은 서로 연관되어 있었지만 어느 것도 다른 것을 대체하지 않았습니다.

응답은 관찰된 여정을 신뢰했다

섹션 3.3은 응답을 생성할 때 한 단계를 바꿨습니다. 출발 파티와 목적지 파티의 신원은 요청에서 역전되었습니다. 컨텍스트는 유지되었습니다. PDU는 요청된 연산을 적용한 결과가 되었습니다.

그다음 예외가 등장했습니다. 직렬화된 응답을 해당 요청이 실제로 발생한 전송 주소와 전송 도메인으로 전송하라는 것입니다. 그 값이 로컬 파티 데이터베이스에 기록된 전송 정보와 다르더라도 말입니다.

따라서 살아있는 교환이 하나의 좁고 한정된 행위에 대해서는 목록보다 우선했습니다. 응답은 목적지 탐색을 다시 열지 않았습니다. 응답을 불러온 요청에 붙은 좌표를 따라 돌아갔습니다.

이 선택은 기록과 경로가 어긋난 경우에도 연속성을 지원했습니다. 요청과 응답 사이의 관계도 보존했습니다. 응답은 일반적인 항목에 보내지는 새로운 미청구 메시지가 아니라, 관찰된 교환에 속한 것이었습니다.

예외는 기록을 다시 쓰지 않았다

RFC 1445는 응답 절차에 자동적인 파티 데이터베이스 갱신을 넣지 않았습니다. 출발지 튜플은 이 응답의 전달을 통제했을 뿐, 조용히 파티의 영구 논리적 위치가 되지 않았습니다.

이것이 결정적 한계입니다. 어긋난 튜플은 낡은 구성, 대체 인터페이스, 프록시 경계, 경로 이동성 또는 다른 원인을 반영할 수 있습니다. 인용된 표준들은 특정 배포에서 어느 설명이 참인지 조사자에게 알려주지 않습니다. 하나를 자동으로 선택하는 일은 패킷 관찰을 행정적 결정으로 바꿔버립니다.

또한 성공적인 반환 자체가 출발지를 인증하지 않았습니다. 파티 주장과 구성된 인증은 별도로 남았습니다. 주소로 바이트를 되돌려 보내는 것이 컨텍스트나 ACL을 넓히지도 않았습니다. 응답 PDU가Set이 재시작을 넘어 살아남았거나 의도된 네트워크 효과가 뒤따랐다는 증명도 아니었습니다.

실행 중인 코드는 실제로 본 패킷에 답하는 것이 허용되었습니다. 그 사실만으로 목록, 주체, 정책을 재정의하는 것은 허용되지 않았습니다.

쓰기 가능한 테이블은 다른 종류의 권한을 담았다

함께 나온RFC 1447 Party MIB는 파티, 컨텍스트, 접근 제어, 뷰 테이블을 노출했습니다. 이 문서 자체의 경고는 냉정했습니다. 네 개 테이블 모두에 대한 전체 접근 권한은, 모든 능력을 갖춘 파티를 구성할 수 있기 때문에, 관리자에게 root에 상응하는 권한을 부여한다는 것이었습니다.

그래서 관찰된 반환 좌표가 아무렇게나 구성 쓰기로 바뀔 수는 없었습니다. 파티 주소를 변경하는 것은 사무적 정리가 아니었습니다. 이 모델에서 위치는 인증, 기밀성, 컨텍스트, 특권과 나란히 놓였습니다. 이러한 영구 결합을 변경할 권한은 제어 평면 특권이었습니다.

하급 관리자에게는 자신의 파티를 유지 관리하는 권한을 줄 수 있지만, 그 능력을 확대하거나 축소할 권한은 주지 않을 수 있었습니다. 설계는 도달성 유지와 정책 권한을 분리했습니다. 두 개 모두 관련 테이블에 나타나더라도 말입니다.

이후의 SNMP는 응답 상태를 명시적으로 유지했다

파티 모델은 SNMP의 최종 행정 아키텍처로 살아남지 못했습니다. 이후RFC 3411은 디스패처, 메시지 처리, 보안, 접근 제어, 애플리케이션, 전송 매핑을 명시적 서브시스템으로 분리했습니다.

RFC 3412는 수신 메시지 처리에서 가능한 응답을 위해stateReference를 전달했습니다. 응답 준비는 그 상태를 사용하여 목적지 전송 도메인과 주소를 산출했고, 디스패처는 메시지를 요청 발신자에게 보냈습니다. SNMPv3에서는 캐시된 상태가 전송 도메인과 주소를 포함했으며, 일반적인 응답 코드가 캐시된 값을 덮어쓰도록 허용하지 않았습니다.

어휘는 바뀌었지만 근거 패턴은 여전히 알아볼 수 있었습니다. 확인된 교환에는 그 교환에 속한 상태가 필요합니다. 일반적인 재고만으로 응답을 재구성하면, 요청을 유효하게 만든 경로, 보안 매개변수, 상관관계를 잃을 수 있습니다.

이 계보를 모든 구현이 모든 절차를 따랐다는 증거나, 1993년 모델이 이후 모델을 만들었다는 증거로 읽어서는 안 됩니다. 이는 응답 상태가 영구 목적지 목록과 아키텍처적으로 구별되는 영역으로 남았다는 것을 보여줄 뿐입니다.

출처