요약

  • RFC 1503은 애플리케이션이 입력 문자열을 ‘context resolver’에 넘기고, 사용자가 SNMPv2 party와 context를 매번 지정하지 않게 하는 방법을 제시했다.
  • 미리 설정된 항목이 없으면 관리자가 임시 noAuth/noPriv party 쌍, context, get·get-next·get-bulk용 ACL을 만들 수 있다. 실제 요청은 애플리케이션의 보안 조건에 다시 걸린다.

장비 하나를 조회하려는 사람에게 프로토콜 내부의 신원 표를 전부 채우라고 하는 것은 이상한 업무 절차다. 키스 매클로그리와 마셜 로즈는 1993년 8월, 그 절차를 관리자 소프트웨어로 옮기는 설계를 적었다. 관리 애플리케이션과 로컬 party 데이터베이스 사이에 해석기를 두고, 입력된 문자열이 어느 문맥을 가리키는지 찾게 한다.

첫 번째 대상은 관리자가 이미 등록한 문맥이다. router.xyz.com-public을 정확히 입력하면 해당 문맥 하나가 나온다. router.xyz.com까지만 입력하면 -public과 -all이 함께 후보가 된다. 예시에서 앞쪽은 조회 작업을 허용하고, 뒤쪽은 인증된 경로로 set까지 허용한다. 사용자가 글자를 덜 썼다고 선택지가 줄어드는 것은 아니다. 요청 작업과 보안 조건을 확인해야 쓸 수 있는 ACL이 정해진다.

등록된 이름이 없다면 입력을 IP 주소 또는 DNS 이름으로 해석한다. 주소 하나마다 관리자는 noAuth/noPriv party 두 개, context 하나, get·get-next·get-bulk를 허용하는 ACL 하나를 휘발성 기록으로 만든다. DNS가 여러 주소를 돌려주면 문맥도 여러 개 생긴다. 식별자 구성에는 앞선 Party MIB의 initialPartyId와 initialContextId 규칙을 쓴다. 이 과정에서 확인된 것은 관리자의 로컬 장부뿐이다. 상대 장비가 요청을 받아들였다는 기록은 아직 없다.

슬래시를 붙이는 길도 있다. 호스트 이름이나 주소 뒤의 문자열을 SNMPv1 community string으로 사용하고, 그에 맞는 임시 조회 문맥을 만든다. 단일 입력 칸이 대상 선택과 프로토콜 설정까지 겸하게 되는 셈이다.

요청을 보낼 때 애플리케이션은 문맥 핸들과 최소 보안 조건을 전달한다. 관리자는 그 작업을 허용하면서 조건을 만족하는 ACL을 찾고, 적합한 SNMPv2 항목을 우선한다. 인증을 요구했는데 맞는 항목이 없으면 작업은 수행되지 않는다. 호스트 이름이 권한을 부여한 것이 아니라, 규칙을 찾는 순서를 시작한 것이다.

RFC Editor 기록에서 RFC 1503의 지위는 Informational이다. 특정 제품의 구현이나 성공한 조회를 보고한 문서는 아니며, 보안 절에서는 그 문제를 논의하지 않는다고 적었다. 그래도 설계의 핵심은 선명하다. 사용자가 입력하지 않은 값은 관리자가 대신 정한다. 편리함 뒤에 남는 것은 그 결정의 기록이다.