要約

  • RFC 9899はIETF Proposed Standardであり、RFC 8519のACLモデルを拡張する。置き換えるものではない。
  • IPv4/IPv6プレフィックス、ポート、プロトコル、ICMPタイプ、エイリアスを名前付きの再利用可能なセットとして定義でき、ACLエントリーは繰り返しのリテラルではなくセットを参照できる。
  • IPv6拡張ヘッダー、TCP flags-bitmask、フラグメント、ペイロード、MPLS、VLAN、I-SIDのマッチングが追加される。ただし一部はfeature-gatedで、すべての装置が全機能を実装するわけではない。

仕組み：ルールと集合を分離する

RFC 8519が基礎となるACLデータモデルを提供し、RFC 9899がdefined set、追加マッチ、追加アクションをその上にaugmentします。セットは管理ドメイン内で複数のネットワーク要素から再利用できます。必要なパラメーターが一種類だけなら単一パラメーターセットを使い、プレフィックス、プロトコル、ポート、VLANなどを組み合わせる場合はエイリアスを使えます。この分離により、親ACLルールを再定義せずにセットのエントリーを追加または削除できます。

ただし再利用は自動的な安全性や一貫性を意味しません。共有セットは変更の影響を集中させ、セットのライフサイクル、所有権、承認を重要にします。defined setへの不正な書き込みは、本来拒否すべき通信を許可したり、許可すべき通信を拒否したりする可能性があります。不正な読み取りも、どのリソースが束ねられているかを示し、トポロジー秘匿を弱める可能性があります。

拡張マッチと相互排他

追加されるマッチは、IPv6拡張ヘッダー、TCP flags-bitmask、IPv4/IPv6フラグメントタイプ、ペイロードパターン、MPLSヘッダー、VLAN、I-SIDです。enhanced flags-bitmaskとRFC 8519のflagsフィールドの両方をサポートするクライアントは、同じリクエストで両方を設定してはなりません。enhanced fragment matchingとRFC 8519のflagsフィールドにも同様の相互排他があります。検証は装置側の暗黙の解釈に任せず、提出前に行う必要があります。

ペイロードマッチングはfeature-gatedで、offset type、offset、length、バイナリーパターン、operatorを指定します。これは復号機能ではありません。暗号化パケットで有効になるかは、変化しない観測可能なパターンがあるかに依存するため、暗号化通信全般に一律に有効だとは言えません。rate-limit、logging、counterのアクションも追加されますが、defined versionが対応するのはローカルアクションだけです。

管理アクセスと実装差

RFC 9899は、ICMPv4タイプ、ICMPv6タイプ、IPv6拡張ヘッダータイプのためのIANA管理YANGモジュールも初期提供します。YANG 1.1のモデル化に関する基盤はRFC 7950にあり、管理プロトコルには安全なトランスポートと相互認証が想定されます。RFC 8341のNACMは操作とコンテンツへのアクセス制限に利用できます。実装ごとのfeature対応は確認が必要で、RFC 9899は性能向上、ルール数削減、普及率、共通の規模上限を測定していません。

検証フィクスチャと判断経路

具体的な検証フィクスチャとして、二つのIPv4プレフィックスだけを持つセット、ポートだけのセット、プレフィックス・プロトコル・VLANを組み合わせるエイリアス、enhanced flags-bitmaskと基礎flagsを別々に使うリクエスト、offset・length・パターン・operatorを備えたペイロード条件、さらにMPLS、I-SID、フラグメント、IPv6拡張ヘッダーを参照するACLを用意します。各ケースで受理結果、拒否理由、読み取り権限、実際の参照先を確認します。

Theo Marchの分析： 導入前にセットの所有者を決め、どのACL、装置、リソースが依存するかを見える化し、限定的な範囲で段階検証を行い、実行可能なロールバックを準備するべきです。これは本稿の運用分析であり、RFC 9899、RFC 8519、RFC 7950、RFC 8341が一律に要求する手順ではありません。命名ライフサイクル、承認方式、展開間隔、ロールバック閾値もRFCは定めていません。

出典