2. MUDモデルと意味論的意味 (The MUD Model and Semantic Meaning)

MUDファイルは、JSON形式でシリアライズされたYANGモデルインスタンスで構成されます [RFC7951]。MUDの目的では、変更可能なノードは、このモデルによって拡張されたアクセスリストです。MUDファイルは、以下のYANGスキーマのみのシリアライゼーションに限定されます:

• ietf-access-control-list [RFC8519]
• ietf-mud (RFC 8520)
• ietf-acldns (RFC 8520)

拡張を使用して、追加のスキーマを追加できます。これについては後述します。

可能な限り広範な展開を提供するために、MUDファイルの発行者は、このメモの抽象化を利用し、IPアドレスの使用を避けるべきです。MUDマネージャーは、IPアドレスを含むMUDファイル、特にローカルな意味を持つ可能性のあるIPアドレスを自動的に実装すべきではありません。アクセスコントロールリストの片側のアドレス指定は、to-device-policyまたはfrom-device-policyとして適用されるかどうかに基づいて暗黙的です。

ACLの"name"、"type"、アクセス制御エントリ (ACE) の"name"、およびTCPとUDPのソースおよび宛先ポート情報を除いて、MUDファイルの発行者は、この仕様で見つかるものに表現されるACLモデルのリーフノードの使用を制限すべきです。拡張がない場合、MUDファイルは以下のACLモデル機能のみを実装すると想定されます:

• match-on-ipv4, match-on-ipv6, match-on-tcp, match-on-udp, match-on-icmp

さらに、"accept"または"drop"アクションのみを含めるべきです。MUDマネージャーは、"reject"を"drop"として解釈することを選択できます。MUDマネージャーは、他のすべてのアクションを無視すべきです。これは、製造業者がローカル展開内でrejectが適切かどうかを知るのに十分なコンテキストを持っていないためです。これは、ネットワーク管理者に任せるべき決定です。

MUDはインターフェースを扱わないため、"ietf-interfaces"モジュール [RFC8343] のサポートは必要ありません。具体的には、ACL YANGモジュールのインターフェース関連の機能とブランチ (例: interface-attachmentとinterface-stats) のサポートは必要ありません。

実際、MUDマネージャーは、記述の特定のコンポーネントを無視することができ、または記述全体を無視することができ、すべてのMUD記述を慎重に検査すべきです。MUDファイルの発行者は、セクション3.9で説明されている場合を除いて、他のノードを含めてはなりません。詳細については、そのセクションを参照してください。