Summary

  • RFC 3430は、大量のSNMP交換でTCPのフロー制御を利用できるようにしたが、信頼性のあるバイトストリームは操作が処理された証拠ではない。
  • 操作の種類は依然として重要だった。snmpV2-trapは未確認のままで、inform-requestは受信側で定義された意味を持つSNMP応答を返す。

「信頼性のあるトランスポート」という言葉から、層を飛び越えて推論したくなる。接続は開いたままで、TCPはバイトを確認応答し、最後は正常に閉じた。だから管理アプリケーションにもイベントが届いた、と言えるのだろうか。RFC 3430の第2.4節は「信頼性のあるトランスポートと確認済み操作」と題し、まさにこの混同を避けている。

2002年12月、RFC 3430はExperimentalとして、Simple Network Management ProtocolをTCPに載せる任意のトランスポート対応付けを定めた。SNMPのメッセージモデルを置き換える文書ではなく、すべての通知を確認付きに変えるものでもない。主な目的は大容量転送の効率化だった。この対応付けを実装するSNMPエンジンは、RFC 3417のSNMP over UDPも実装しなければならない。また要求応答トランザクションの開始側が全体のトランスポートを選び、途中で変更することはできない。

TCPのフロー制御とセグメント化は、大きな管理データをUDPで送る際に増える小さな要求応答の往復を減らし得る。一方、接続の確立と切断には追加の通信があり、開いた接続はOSの資源を占有する。RFC 3430は、必要なら新規TCP接続を拒否して資源を守れるとした。また、アプリケーション側のSNMP再送タイマーをTCPのタイマーより遅く設定し、TCPが復旧を試みている最中にSNMP側が先にタイムアウトしないよう勧めた。

データグラムからバイトストリームに移ると、メッセージの区切り方も変わる。UDPではデータグラム境界がメッセージの境界になる。TCPではアプリケーションが受け取る読み出し単位とSNMPメッセージの境界が一致するとは限らない。そのためRFC 3430は、BERエンコード内の長さフィールドを使って、一つのSNMPメッセージと次のメッセージを区別するよう要求した。送信側は複数メッセージのバイトを交互に混ぜてはならない。永続的な全二重接続では複数の要求応答を同時進行でき、応答順も要求順に揃える必要はない。順番が変わっても、メッセージ境界は明示されなければならない。

フレーミングがあっても、アプリケーションが動作したとは証明できない。RFC 3430が述べる範囲では、TCPは両端間の順序付けられたバイトストリームを保護する。しかしリモートのSNMPプロセスがメッセージを解析し、処理したことまでは示さない。正常なTCPクローズであっても、受信側TCPエンジンがすべてのバイトをアプリケーションに渡した証明にはならない。TCPだからといって、送信済みデータが最終的に必ず届くわけでもない。

操作そのものは、別種のより強い受領証を与える。RFC 3430は未確認のsnmpV2-trapと、確認されるinform-requestを対比する。TrapをTCPで運んでもSNMP確認応答は追加されない。InformへのSNMP応答は、通知がトランスポートとセキュリティモデルを通過し、通知受信アプリケーションへの配送待ちキューに入ったことを示す、とRFCは定義する。set-requestへの応答は、コマンド応答側が書き込みを処理したことを示す。どちらもプロトコル上の意味ある受領証だが、人が警報を見たこと、業務プロセスが反応したこと、現実の状態が変わったことまでは証明しない。

TCP接続の確立失敗も、意図と受領証の間に隙間を残す。RFC 3430では、接続を確立できなければトランザクションを中止し、アプリケーションにタイムアウトとして報告する。付録AではUDPへのフォールバックなども検討するが、別のトランスポートが不確実性を消すとはしていない。通知を確実に届ける必要があるなら、接続できなかった通知をローカルログに残す必要がある。ログは未処理の義務を保存するが、宛先での受領を証明しない。

セキュリティも別の層にある。TCP対応付けはSNMPv3のセキュリティ機構を変えない。RFC 3430はユーザベースのセキュリティモデルとビューに基づくアクセス制御を推奨する一方、SYN floodのようなサービス拒否リスクにも触れる。認証、認可、バイト配送、通知のキュー投入、運用上の効果はそれぞれ別の受領証である。

RFC 3430の歴史的貢献は、「SNMP over TCPなら信頼できる」という一言より狭く、実用的だ。大きな管理交換にストリームを使い、その内部でのメッセージ境界を定め、トランスポートの信頼性は確認済み操作の代わりにはならないと明記した。TrapはTrapのまま、Informは応答を伴う操作のまま。ストリームはどちらも運べるが、受信側が何をしたかは決めない。

この記事はRFCのプロトコル契約を扱い、現行の普及率、製品対応、性能測定、個別障害を主張しない。証拠は、接続、BERフレーミング、バイト配送、SNMPエンジンでの受信・処理、受信アプリケーションのキュー投入、その後の操作という段階に分ける。RFC 3430の応答が定義するのはその一部にすぎない。

Sources: RFC 3430; RFC 3417; RFC 3411; RFC 3413; RFC 3414; RFC 3415; RFC 3419; RFC 9293。状態：RFC Editor。