要約

  • OPSAWGのパケット廃棄モデル草案第16版は、インターフェース、装置、フロー、制御プレーンで起きる廃棄を、エラー、ポリシー、輻輳などに分類する共通構造を示す。一方で、カウンターだけでは運用者の意図を確定できないと明記する。
  • 分類が正しくても応答は誤り得る。設定変更、カウンターの不連続、機能の部分実装、複数理由の優先順、フロー識別の不足、サービス基準の変更は、数値の連続性を保ったまま意味を切断する。
  • そこで自動化の許可を「意図エポック」に限定する。これは一つのカウンター寿命と、設定版、サービス上の許容範囲、対象、許された行動、影響上限、ロールバック責任を結ぶ期間である。Daniel Kadeの提案であり、IETFの要件でもYANGの葉でもない。

共通語彙が整える観測面

従来のインターフェース統計は、異常の存在を知らせても原因の区別が粗い。ifInDiscardsには複数の事情が集約される。ifInErrorsも実装によって、廃棄されたエラーパケットだけを数える場合と、廃棄の有無を問わずエラーを数える場合があった。詳しいベンダー固有統計は存在しても、名前と意味が揃うとは限らない。

draft-ietf-opsawg-discardmodel-16は、この観測のずれを縮めようとする。現在はRFC Editor Queueにある活発なOPSAWG Internet-Draftで、まだRFCではない。二層フレームと三層パケットの廃棄を、制御プレーン、インターフェース、フロー、装置という場所、入出力の方向、層、原因へ分解する。ポリシーにはACL、ポリサー、uRPF、DoS防御、明示的なnull routeが含まれる。エラーは破損、MTU超過、TTL期限切れ、経路なし、内部障害などを分け、バッファ不足はQoSクラス別に扱える。

一つのパケットを同じ文脈で二重計上しないという要件も重要だ。複数の理由が成立し得るなら、どの理由に帰属させるかを明確にし、discard-order-capabilityなどで順序を示す。これによりカウンターは、「この装置のこの処理点が最終的に転送しなかった」という、従来より輪郭のある証言になる。

ただし証言は指令ではない。ACLを入れた変更票、ポリサーに対応する契約、迂回先の空き容量までは分類木に入っていない。観測の標準化と、操作を許可する制度は別の層にある。

policyというラベルは正当性を証明しない

ACLの廃棄数が増えれば、実装済みの規則にトラフィックが一致したことは分かる。意図した規則に一致したかは分からない。攻撃通信を拒むなら期待どおりでも、プレフィックスの記述ミスで正当な顧客通信を拒めば同じカウンターが増える。

草案はこの限界を正面から認める。廃棄クラスだけでは、意図した損失か意図しない損失かを決められない。ローカルポリシー、設定された意図、通常時の基準、継続時間、影響範囲、サービス文脈などを運用者が合わせて判断する。

TTL期限切れも一義的ではない。低い通常値ならtraceroute、短い上昇なら収束、長く続けばルーティングループが候補になる。バッファ不足も、ベストエフォートの合意範囲内か、保護されたクラスのSLA違反かで意味が変わる。Appendix Bの処置表は例示であり、「意図しない」という欄はクラス固有の規範値ではない。

この区別を消すと、policyを「正常だから放置」と読んで誤設定を見逃す。一方、errorを「直ちに装置を外す」と読めば、輻輳装置から退避した通信を、さらに混雑した経路へ押し込むかもしれない。細分類は候補を狭めるが、判断主体を置き換えない。

数字が続いても意味は切れる

実際の自動化は総値よりも差分、速度、基準からの偏差を見る。そのため二つの読取りが同じ履歴に属するかを先に確かめる必要がある。

再起動、ラインカード交換、プロセス初期化、収集欠落はカウンターを不連続にする。草案も集約値が下位カウンターの不連続を扱うよう求める。さらにYANG Libraryで機能の対応を確認できても、対応機能内の全カウンターが常に埋まるとは限らない。同じパス名だけで二装置を同質とみなせない。

設定変更はもっと見えにくい。ACLカウンターが単調増加を続けても、変更前は設定A、後は設定Bを計っている。対象プレフィックスや例外が変わったなら、二値の引き算は算術的に正しくても制度的には別期間をまたぐ。

反対に、再起動でゼロに戻っても、サービス意図までリセットされたわけではない。ゼロを復旧とみなせば、保存状態と運用状態を取り違える。必要なのは、計測状態が始まった時刻と、その意味を決める意図が始まった時刻の二つである。

第16版は、装置統計だけで設定ミスを特定できないとも述べる。導入前の設定検証や、変更前後のACL廃棄の有意な差が追加文脈になる。しかし、どの設定版、どの基準、どのカウンター寿命に属するかを保存しなければ比較は成立しない。

意図エポックを行動単位にする

意図エポックとは、一つの宣言済みサービス意図、一つの関連設定またはポリシー版、一つの解釈可能なカウンター寿命が同時に有効な期間だ。事後的な注釈ではなく、自動化が許可を受ける単位である。

開始時には、装置または論理要素、対象インターフェースや制御プレーン、方向、層、完全な廃棄パスを記録する。モデル版、対応機能、実際に値が入る葉、理由の優先順、初期値、収集間隔、不連続の手掛かりも必要だ。フロー単位で動くなら、フロー識別のアンカーも示す。情報モデルはフローの分類を揃えるが、フロー自体の定義は基礎となるデータモデルに委ねている。

制度側には、設定版と変更票、発効時刻、サービス責任者、SLAまたは通常基準、速度・継続時間・範囲の閾値を置く。そして許される行動を狭く書く。バッファ不足なら、容量確認済み経路へ限定比率だけ移す。受信エラーなら別信号の確認後に一要素だけ隔離する。ポリシー廃棄なら通知だけで、規則を自動削除しない。冷却時間、影響上限、復帰条件、エスカレーション担当を各行動に結ぶ。

カウンターの不連続、設定発効、SLAや基準変更、機能の変化、収集空白、対象の再割当て、理由順の変更、責任移管が起きればエポックを閉じる。次のデータも正しい観測かもしれないが、古い行動許可を自動継承してはならない。

この切れ目は、古い許可が新設定に残る「権限の残留」と、リセットを連続履歴と誤認する「偽の連続性」を同時に防ぐ。データプレーンの処理を中央承認で遅らせず、制御の前提だけを明示的に更新できる。

相関は証拠を強くするが権限を増やさない

インターフェースや装置の廃棄とフロー記録を照合すれば、影響した通信へ近づける。ただし草案はフローの特徴付けを仮定せず、将来のフロー向けモデルに曖昧でないアンカーを求める。アンカーがない広いインターフェース異常から、顧客固有の操作へ飛んではならない。

カウンター、フロー、設定差分、トポロジーを合わせれば原因の確度は上がる。それでも、どれも単独では経路変更、装置切離し、設定ロールバックを命じない。証拠は積み上がるが、権限は事前に定めた行動範囲の内側に残る。

強い処置ほど副作用も大きい。混雑した装置を外すと残りの経路が飽和し得る。ロールバックは可達性と一緒に過去の脆弱性を戻すかもしれない。装置を復帰させれば原因も復帰し得る。正しい分類は分岐を選ぶ材料であって、結果すべての責任者ではない。

読取り権限も保護対象である

このYANGデータは読取り専用で、統計コンテナにはNACMのdefault-deny-allが使われる。詳細な廃棄情報は攻撃や誤設定を露出する。トラフィックを注入し、同時にpolicyカウンターの反応を読める攻撃者なら、試行の効率を測って調整できる。

意図エポックには、観測を出した収集器と認証主体も必要だ。安全な転送、相互認証、アクセス制御は入口を守るが、サンプルの完全性や設定との時間的一致までは証明しない。認証は「誰が証拠を渡したか」、エポックは「何の判断に使えるか」を答える。

目標は廃棄ゼロではない

セキュリティ、QoS、資源保護には意図した廃棄がある。全異常を機械が処理することも目標ではない。証拠または権限が不足したとき、人へ上げるのは正しい処置だ。

目指すべきは、各自動変更を一つの有効エポック内の観測へ戻せることだ。クラス、範囲、速度、期間が実際に対応・記録され、設定と基準が現行で、行動が許可範囲を越えず、必要な独立確認を通り、最後に維持・撤回・人への移管理由が残る。

第16版は記録の観測側に共通語彙を与える。意図側を用意するのは運用者である。カウンターはパケットが止まった場所を言える。ネットワークが動いてよい期間は、別に定義しなければならない。

情報源