要約

  • draft-ietf-rtgwg-qos-model-16は分類器、メーター、キュー、スケジューラー、ポリシー適用、運用統計をモデル化する。インターフェース上の有効な参照は意図を示すが、ハードウェア資源の実体化や期待したサービスを証明しない。
  • 運用モジュールには統計を消去するアクションもある。監視を妨げ、異常の証拠を隠し得るためnacm:default-deny-allである。観測期間と消去履歴を欠くゼロは、通信、混雑、損失、攻撃がなかった証拠にならない。

ゼロには来歴が付いていなかった

事故調査で、送信側ポリシーは正しく見え、分類一致、meterのexceedとviolate、キュー深度、tail drop、ECNがすべてゼロだったとする。疑わしいバーストが通らなかった可能性はある。しかし再起動直後、新しいカウンター、更新停止、ポリシー交換、調査前のclearでも同じ表示になる。

改訂16はこの緊張を一つのモデル群に収める。設定側はフィルターとアクションをポリシーにまとめ、ingressまたはegressのインターフェースへ結び付ける。運用側は分類器、メーター、キューの統計を公開し、さらに全部または指定カテゴリを直ちに、あるいは予約時刻に消去できる。

草案はclearを既定拒否とする。理由は、監視を壊し、異常や攻撃の痕跡を隠し得るからだ。これは補足的な注意ではなく、証拠保全の条件である。

ポリシー参照は命令であり、パケットの受領証ではない

分類器はパケットを選び、アクションはmark、meter、count、discard、queue、scheduleや子ポリシーを実行する。順序付けられた分類器とアクションがポリシーとなり、qos-target-policyが種類と方向を指定してインターフェースへ結ぶ。

共通参照は自動化に有用だが、設定木はシリコンの観測ではない。ラインカードがキューを割り当てたか、要求レートが装置粒度へどう丸められたか、次のパケットが想定クラスへ入ったかは別に確認する必要がある。

RFC 8342が区別するintended、applied、operationalは交換できない。NETCONFやRESTCONFの成功は認可された変更の受理を示す。資源不足、非対応アクション、ベンダー固有の実装差、後続パケットの扱いまでは証明しない。

ベンダー固有のpolicy typeやaugmentが許されるのも重要だ。同じ形のYANGを受け付ける二装置が、同じデータプレーン動作をするとは限らない。子ポリシーの自己参照や循環を拒否できても、非循環の連鎖が実行可能で所期の結果を生む保証にはならない。

カウンターは局所的な証人である

運用モデルは分類器のpacket、byte、rate、メーターのconform、exceed、violate、drop、キューの現在・平均・最大長、tail drop、RED/WRED、ECNを表す。これらは「この測定点に届いたか」「契約曲線を超えたか」「この方向のキューが詰まったか」に答えられる。

しかし分類一致は期待キューへの投入を、キュー出力は次ホップの配送を、ECN markは端末の反応を証明しない。dropがゼロでもアプリの遅延やSLAは確定しない。各値の権限はその測定点までである。

named statisticsは複数の分類器、メーター、キューを集計でき、非集計でも保持できる。総数は経営画面に便利だが、どの要素が寄与したかを失う。説明責任に用いるなら非集計値か、寄与を再現できる対応表が要る。

証拠の順序は次のようになる。

  1. 責任者がサービス目的と対象通信を承認する。
  2. レビュー済み版が分類とアクションを表す。
  3. 管理書込みとdatastore応答が受理を示す。
  4. 装置状態が分類器、メーター、キュー、スケジューラーの実体化を示す。
  5. 既知の試験通信が限定期間内に期待値を動かす。
  6. キュー、drop、ECN、rateが当該インターフェースの局所処理を示す。
  7. 下流測定が経路とアプリ結果を示す。
  8. clearには装置外へ保存した前後スナップショットと実行記録がある。

前段の受領証に後段の権限を持たせてはならない。

消去の認可は、消去すべきとの判断ではない

NACMの既定拒否により、明示ルールがなければclearを呼べない。相互認証と安全な管理通信は、誰が要求し、途中で改変されなかったかを示せる。それでも「今この証拠を失ってよいか」には答えない。認可は正当化ではない。

消去記録には要求者、承認者、理由、インターフェース、方向、ポリシー、カテゴリ、予定時刻、実行時刻、消去前、消去後、外部保管先が必要だ。予約clearなら取消状態と時計も要る。同じ装置が統計と唯一の監査記録を持てば、故障や侵害で事実と説明を同時に失う。

設定、観測、消去は役割を分けるべきだ。meterを変更する権限が履歴消去を自動的に伴う必要はない。混雑を読む分析者に設定変更は不要だ。リセット自体は試験開始や保守境界に役立つ。誤りは、新しいゼロを過去の無通信という主張に変えることだ。

観測面も機密である

filterは重要なprefix、port、protocol、DSCPを明かす。action、meter、queueはmark、drop、rate、capacityの設計を示す。攻撃者がprobeを注入して統計を読めれば、どの規則が一致したかを推定できる。queue depthやRED、ECNは混雑時刻と容量を漏らし、policy nameが顧客名を含むこともある。

したがってread、write、clearは別の最小権限判断を要する。全読取り禁止では設定を検証できず、広い読取りは管理面をpolicy oracleにする。限定アクセス、独立監査、影響に応じた保存が必要である。

DiffServも逐ホップである。不正なremarkはサービス窃取を、discardやmeter改変はDoSを生む。正規のmarkでも下流で変更され、アプリは失敗し得る。局所ポリシーはエンドツーエンド約束ではない。

検証成功は標準化や配備を意味しない

対象は2026年9月25日付の改訂16で、2027年3月29日に失効する。DatatrackerではRTGWGのactiveなWG DocumentかつI-D Existsである。本文はStandards Trackを意図するが、Datatrackerのintended statusは空欄だ。RFCではない。

抽出YANGの検証結果はエラー0、警告6である。これは当該版の機械検査結果で、実装、資源実体化、相互運用、配備、SLA成果ではない。結論は限定的である。草案はQoS意図と局所証拠の共通語彙を作り、clearアクションはその証拠を誠実に読むための統治条件を示している。

出典