要約
- PRR成功はアドレスやポートを将来のために予約する。bindingもpinholeも作らず、パケット処理は変わらない。
- PER成功はローカルmiddleboxの処理規則をENABLEDにする。PRRと同じIDを使えても、予約時点まで遡って通信許可を証明しない。
監査画面には一つのルールIDと現在値ENABLEDだけが残っていた。担当者は、そのIDが最初に現れた時刻を「開通時刻」と報告した。実際には、その時点の状態はRESERVEDだった。
RFC 5189は、予約と有効化を二つのactionとして定義する。識別子を引き継ぐ設計は追跡を容易にする一方、履歴をスナップショットへ潰すシステムでは誤った時間軸を生む。
RESERVEDが持つ権限
Policy Reserve Ruleは、完全な通信相手が決まる前にNAT資源を確保する。外側だけ、内外の両側、あるいはどちらも予約しない場合がある。port rangeとparityも対象になり得る。
PRRはアドレスbindingやfilter pinholeを設定しない。したがってパケット処理は不変である。純粋なfirewallなら、予約値が空でも成功できる。これは欠損ではなく、装置能力に沿った応答だ。
受領記録はrequest ID、rule ID、group、要求tuple、返却tuple、空値、要求寿命、許可寿命を保持する必要がある。「success」だけでは、資源が確保されたのか、意味上の状態だけ進んだのか判断できない。
ID再利用は状態変化を隠してはならない
PERはNAT binding、firewall allow、または両方を設定する。PRRを参照して成功すると、予約は別通知なしに終了し、新しいenable ruleが同じIDを使う。
この時、IDは因果関係の鍵になる。予約されたtupleがどの有効化に使われたかを結べる。しかしイベント時刻と状態を捨てれば、RESERVED期間にもpinholeが存在したように見える。
必要なのは上書きではなく遷移台帳である。UNUSED → RESERVEDをPRR応答時に、RESERVED → ENABLEDをPER応答時に記録する。各区間で可能だった操作とデータ面への影響を分ける。
PERが失敗した場合、参照したPRRは残る。同じIDはRESERVEDのままで、再試行または削除を待つ。失敗を「ロールバック完了」と翻訳すると、使用中の予約を見失う。
ENABLEDも到達証明ではない
PER応答は、そのmiddleboxが規則を受け入れたことを示す。方向、protocol、wildcard、A0/A3、生成されたA1/A2、bindingやpinholeをローカル証拠として扱える。
だが、その装置の外側は観測していない。別のACL、route、相手host、transport listener、application authorizationは残る。ENABLEDから導けるのはローカル設定であり、遠端受領ではない。
運用上は、予約、規則有効化、装置両側のpacket、remote receipt、application outcomeを五段階に分ける。最後の二つがなければ「通信成功」ではなく「ローカル規則成立」と報告する。
寿命とsessionは別の時計
agentが提示したlifetimeは提案である。middleboxは要求値とsession開始時に示した最大値以下の時間をgrantする。requested値をexpiryとして保存してはならない。
RLCは延長、短縮、ゼロによる終了を要求できる。middleboxや別のauthorized agentが状態を変え、非同期イベントを送る場合もある。誰が要求し、何が許可され、いつ観測したかが必要だ。
MIDCOM sessionが正常終了、非同期終了、接続断のどれで終わっても、既存ruleは自身の寿命まで残り得る。control channelの死はrule IDの死ではない。逆にsessionが生きていてもruleは期限切れになり得る。
ownerとgroupは履歴の代用品ではない
rule ownerは作成したauthenticated agentで、rule寿命中は変わらない。別agentが変更できるなら、それは明示されたauthorizationの結果である。
各ruleは一つのgroupに属し、同じgroupのownerは共通する。groupは最初のmemberで生まれ、最後のmemberで消える。独立した永続物ではない。
group lifetimeはmemberから導かれ、GLCは全memberへ共通時間を与えたりゼロで全削除したりする。同じgroupにRESERVEDとENABLEDがあれば、削除のデータ面影響は同じではない。member別状態を残す必要がある。
原子性と競合
request transactionは相互にatomicで、中間の安定状態をagentへ見せない。一方、asynchronous transactionは処理を中断できる。具体protocolが一つの意味操作を複数操作へ分割すれば、そのatomicityも検証対象になる。
既存ruleと矛盾する新規ruleはfirst-come-first-servedで拒否される。非矛盾のoverlapや同一ruleは受理できる。どちらもrule admissionの事実であり、packet outcomeではない。
証拠objectにはchange、session、agent、request、middlebox、owner、capability、interface、rule、group、prior stateを置く。続けてPRR/PER parameter、寿命三値、conflict、failure reason、予約残存、status read、REN/GEN/STNを時系列で追加する。
最後に両側capture、遠端受領、application結果、expiryとrollbackを結ぶ。同じIDを守るだけでは不十分だ。同じIDがいつ何を意味したかを守って初めて、running codeの履歴になる。
情報源
会員向け解説
プロフィールの詳細
適切な会員レベルでログインすると、解説全文と出典メモをご覧いただけます。
Strategic Circle 限定
Strategic Circle
すべての読者に公開されています。参加してログインすると プロフィール解説 を閲覧できます。
Strategic Circle に参加Leadership Alliance 会員限定
Leadership Alliance
対象となる IP 資産の所有者・管理者向けです。ログインすると Leadership Alliance の解説を閲覧できます。
Leadership Alliance に参加