要約

  • RFC 3055は、四つのPINTサービスを四つの時間窓と、全体・クライアント・利用者・ゲートウェイの切り口で観測するMIBを作った。
  • 「成功」はエージェントが付けた分類であり、応答、聞き取り可能な音声、読めるファクスといった最終結果を独立に観測した証拠ではない。

インターネットの依頼と電話網の実行

PINTでは、インターネット側が依頼し、電話網側が行為を実行する。二者を呼び出す、ファクスを送る、電話網内の文書をファクスバックする、コンテンツを電話で読み上げる。RFC 2848が示した四つのサービスは、依頼と実行が異なる技術領域と管理領域にまたがることを前提にしていた。

だから監視には層が必要だった。サーバーが要求を受け入れても、ゲートウェイは拒否できる。ゲートウェイが受理しても、電話網で呼が成立するとは限らない。呼が成立しても人が内容を聞いたとは限らず、ファクスの伝送終了も紙面の可読性を保証しない。

RFC 3055は2001年2月にProposed Standardとして公開され、SMIv2のMIBを定義した。IANAはpintMIBにmib-2の93番を割り当てた。対象はPINT固有の性能監視であり、ネットワーク要素の管理や一般的なホスト・ネットワーク性能は範囲外だった。狭さは弱点ではない。観測者の立ち位置を誤魔化さないための境界だった。

同じ業務を四方向から切る

サービス種別はRequest-to-Call、Request-to-Fax、Request-to-Fax-Back、Request-to-Hear-Content。期間は直近30秒、15分、24時間、再起動以降である。

全体表は、受信、成功、切断を数え、認可、サーバー、ゲートウェイに起因すると分類された失敗を分けた。クライアント表は文字列で表されたアドレスをキーにし、利用者表はUserIdNameを使った。ゲートウェイ表は登録済みゲートウェイ名ごとに受信、成功、切断を集計した。

ただし、これは四人の証人ではない。エージェントはPINTサーバーで動作する想定であり、ゲートウェイ統計もサーバーから見た接続の監視だった。複数の切り口が一致すれば診断は絞れるが、電話網や利用者側の独立した観測にはならない。

「成功」はどこで決められたのか

MIBにはSuccessfulCallsという明快な名前が並ぶ。しかしRFCは、各受話器の横に観察者を置いたわけではない。実装がある事象を成功と分類し、その結果をオブジェクトとして報告する仕組みを定めたのである。

サーバー受付、ゲートウェイ引き渡し、電話網での接続、端末出力、利用者が得た有用な結果は別の受領証だ。どこでカウンターを増やすかが明示されず、下流のログもなければ、「成功」はその実装の観測境界を越えられない。

カウンターを否定する必要はない。むしろ有用だからこそ、何を見た数字かを残す必要がある。

Counter32は履歴なしでは読めない

性能値にはCounter32が使われた。SMIv2では2^32−1まで増えた後にゼロへ戻る。さらに、単一のカウンター値は一般に情報を持たないと説明される。

値が17,000でも、混雑、停止、回復、再起動のどれかは分からない。意味のある差分には、時刻付きの前後サンプルと、その間の連続性が必要だ。RFC 3055自身も「再起動以降」の値について回り込みを処理する責任を利用側アプリケーションに置いた。

短い窓にも曖昧さがある。30秒の境界はいつか。別のエージェントと揃っているか。欠測は比較を壊さないか。後のApplication MIBは不連続性表示を詳しくしたが、それを過去の全実装へ投影してはならない。

行がないことはゼロではない

利用者別・クライアント別の表は資源を消費する。RFCは利用者行のエージングをローカル実装に任せ、将来のtop-N表示にも触れた。したがって行の欠落は、活動なし、期限切れ、未実装、資源制限、識別子不一致のどれでもあり得る。

UserIdNameには複数サーバーやゲートウェイをまたぐ一意性が期待され、クライアント識別子や時刻を組み合わせる案も示された。表のキーは交通量だけでなく、識別方針を映す。欠落をゼロと読むと、その方針を事実と取り違える。

通知がないことと障害がないこと

RFC 3055は固有のtrapを定義せず、継続的な認証失敗や迷惑呼の検出をRMONの閾値機構に委ねた。RMON側では対象変数、周期、サンプル方式、上昇・下降閾値、イベントを選ぶ必要がある。

通知が来ない理由は、閾値未到達だけではない。設定がない、表を読めない、サンプリング境界が変化を隠した、イベント配送が失敗した可能性もある。沈黙は健全性の受領証ではない。

読み取り権限が漏らすもの

書き込み可能なのは管理連絡先だけで、read-createオブジェクトはなかった。それでもGETは安全とは限らない。利用者名、クライアントとゲートウェイの関係、サービス量、失敗率は顧客情報や事業情報になり得る。

RFCはSNMPv1だけでは安全な環境にならないとし、当時のUSMとVACMを勧告した。下位層の暗号化だけでは、誰がどのオブジェクトを読めるかは決まらない。後のRFC 3414とRFC 3415はその枠組みを更新したが、PINT実装への採用証明ではない。

Sources

Lu HengはRFC 3055の著者でも承認者でもない。本稿では公開論考を分析レンズとしてのみ使う。RFC 2458のH. Luを、独立した本人確認なしに同一人物とは扱わない。