メインコンテンツまでスキップ

1. Introduction (はじめに)

1. Introduction (はじめに)​

インターネットは主に汎用コンピュータ, つまりデバイスの所有者が指定した目的に使用できるデバイス向けに構築されてきました。[RFC1984] では, エンドデバイスが自身を最も効果的に保護できると想定されていました。これは典型的なデバイスがワークステーションまたはメインフレームだった時代には理にかなっており, ラップトップ, スマートフォン, タブレットを含む今日の汎用コンピューティングデバイスにとっても理にかなっています。

[RFC7452] はスマートオブジェクトの設計パターンについて議論し, 質問を提起しています。それでは, 汎用コンピューティングタスクに使用されることを特に意図していないオブジェクトのグループを仮定しましょう。これらのデバイス (このメモでは Things と呼びます) には特定の目的があります。したがって, 定義上, 他のすべての用途は意図されていません。少数の通信パターンがこれらの少数の用途から生じる場合, これら 2 つのステートメントの組み合わせは, ネットワーク内のさまざまなポイントで適用できるメーカー使用記述 (Manufacturer Usage Description, MUD) として再記述できます。MUD は主に, デバイスを脅威とするのではなく, デバイスへの脅威に対処します。ただし, 状況によっては, MUD URL の通信方法とデバイスおよびその通信の認証方法に応じて, 後者の場合にある程度の保護を提供する可能性があります。

このコンテキストでは, デバイスの使用目的を述べるエンティティまたは組織を指すために, "メーカー" という概念を緩やかに使用しています。たとえば, 電球のコンテキストでは, これは確かに電球メーカーである可能性があります。組み込み Linux スタックを持つよりスマートなデバイスのコンテキストでは, そのデバイスのインテグレーターである可能性があります。重要な点は, デバイス自体が限定的な目的を果たすと想定されること, およびそのデバイスのサプライチェーンにその目的についてネットワークに通知する責任を負う組織が存在することです。

MUD の目的は次のことを提供することです:

  • メーカーが意図する通信にデバイスの脅威面を大幅に削減します。

  • ネットワーク内の増え続けるデバイスタイプの数にネットワークポリシーをスケーリングする手段を提供します。

  • システムの更新にかかる時間よりも速い方法で, 少なくともいくつかの脆弱性に対処する手段を提供します。これは, サポートされなくなったシステムに特に当てはまります。

  • このようなシステムの実装コストを最小限に抑えます。

  • メーカーが他のデバイス機能または要件を表現するための拡張性の手段を提供します。

MUD は 3 つのアーキテクチャ構成要素で構成されています:

  • 記述を見つけるために使用できる URL;

  • 記述自体 (解釈方法を含む); および

  • ローカルネットワーク管理システムが記述を取得する手段。

MUD は, ネットワークが何らかの方法で Things が通信するリモートエンドポイントを識別できる場合に最も効果的です。

この仕様では, これらの構成要素のそれぞれと, それらがどのように一緒に使用されることを意図しているかを説明します。ただし, それらは独自の目的でローカル展開によって, この仕様とは独立して個別に使用することもできます。

1.1. What MUD Doesn't Do (MUD が行わないこと)​

MUD は, 汎用コンピュータのネットワーク認証に対処することを意図していません。それらのメーカーは記述する特定の通信パターンを想定できないためです。さらに, 単一または少数の用途を持つデバイスでさえ, 非常に広範な通信パターンを持つ可能性があります。MUD 単独ではそれらにも適していません。

デバイスの脆弱性が存在する場合, MUD はネットワーク管理者に追加の保護を提供できますが, メーカーが脆弱性にパッチを適用する必要性に取って代わることは決してありません。

最後に, メーカーが MUD ファイルで何を指定しても, これらは指令ではなく提案です。それらがローカルでどのようにインスタンス化されるかは多くの要因に依存し, 最終的には特定の状況で何が適切かを決定しなければならないローカルネットワーク管理者次第です。

1.2. A Simple Example (簡単な例)​

電球は部屋を照らすことを目的としています。ネットワークを介してリモート制御でき, ランデブーサービスを使用する可能性があります (スマートフォンのアプリケーションからアクセスできます)。その電球について言えることは, 他のすべてのネットワークアクセスは不要であるということです。ニュースサービスに接続せず, 冷蔵庫と通信せず, プリンターや他のデバイスを必要としません。ソーシャルネットワーキングの友達はいません。したがって, 単一のランデブーサービスにのみ接続すると述べるアクセスリストを適用しても, その機能の実行を妨げることはありません。同時に, これによりネットワークは電球や他のデバイスに追加の保護層を提供できます。

1.3. Terminology (用語)​

MUD: メーカー使用記述 (Manufacturer Usage Description)。

MUD file (MUD ファイル): Thing と関連する推奨される特定のネットワーク動作を記述する YANG ベースの JSON を含むファイル。

MUD file server (MUD ファイルサーバー): MUD ファイルをホストする Web サーバー。

MUD manager (MUD マネージャー): MUD サーバーから MUD ファイルを要求して受信するシステム。MUD ファイルを処理した後, 関連するネットワーク要素への変更を指示する場合があります。

MUD controller (MUD コントローラー): 過去に MUD マネージャーに使用された同義語。

MUD URL: MUD マネージャーが MUD ファイルを受信するために使用できる URL。

Thing: MUD URL を発信するデバイス。

Manufacturer (メーカー): Thing に MUD URL を発信するように構成し, MUD ファイルで推奨事項を主張するエンティティ。メーカーは必ずしも Thing を構築するエンティティであるとは限りません。たとえば, システムインテグレーター, またはコンポーネントプロバイダーである可能性があります。

この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "OPTIONAL" は, BCP 14 [RFC2119] [RFC8174] に記載されているように解釈されます。ここに示すように, すべて大文字で表示される場合に限ります。

1.4. Determining Intended Use (意図された使用の決定)​

意図された使用の概念自体は新しいものではありません。ネットワーク管理者は, そのような使用のみを許可するために毎日アクセスリストを適用しています。このホワイトリストの概念は, Chapman と Zwicky によって [FW95] でよく説明されています。ヒューリスティックを使用してシステムのタイプを識別するプロファイリングシステムも何年も存在しています。

Thing は, それがどのようなシステムであるかを詳しく説明することなく, 必要なアクセスの種類をネットワークに同じくらい簡単に伝えることができます。これは事実上 [RFC7488] の逆になります。ただし, 一般的なソリューションを求める際には, デバイスが限定的な目的を果たすために必要な機能を実装すると想定します。これは基本的な経済的制約です。ネットワークがそのようなデバイスへのアクセスを拒否しない限り, その開発者はネットワークに情報を提供する理由がありません。これまでのところ, そのような主張は真実であり続けています。

1.5. Finding a Policy: The MUD URL (ポリシーの検索: MUD URL)​

私たちの作業は, デバイスが汎用リソースロケーター (Universal Resource Locator, URL) [RFC3986] を発信することから始まります。この URL は, デバイスタイプを分類し, ポリシーファイルを見つける手段を提供する両方の役割を果たします。

MUD URL は "https" スキーム [RFC7230] を使用しなければなりません。

このメモでは, MUD URL を発信する 3 つの手段が次のように定義されています:

  • DHCP クライアントが DHCP サーバーに通知するために使用する DHCP オプション [RFC2131] [RFC8415]。DHCP サーバーは, MUD マネージャーとして機能したり, MUD URL を MUD マネージャーに渡すなど, さらなるアクションを実行する場合があります。

  • X.509 制約。IEEE は, [RFC5280] に依存するデバイス特性を通信するための証明書ベースのアプローチを提供するために IEEE 802.1AR [IEEE8021AR] を開発しました。IEEE 802.1AR で要求されているように, MUD URL 拡張は重要ではありません。トンネル拡張認証プロトコル (Tunnel Extensible Authentication Protocol, TEAP) [RFC7170] を含む, その証明書を通信するためのさまざまな手段が使用される場合があります。

  • 最後に, リンク層発見プロトコル (Link Layer Discovery Protocol, LLDP) フレームが定義されています [IEEE8021AB]。

ネットワークが MUD URL を学習する他の手段がある可能性があります。たとえば, 一部のデバイスはすでに展開されているか, MUD URL を通信する能力が非常に限られている可能性がありますが, シリアル番号や公開鍵などの何らかの手段で識別できます。これらの場合, メーカーはこれらの識別子を特定の MUD URL (またはファイル自体) にマッピングできる可能性があります。同様に, インターネット接続が制限されているか存在しない状況では, 代替解決メカニズムが利用可能な場合があります。このようなメカニズムはこのメモでは説明されていませんが, 可能です。実装者は, MUD URL を学習する方法の柔軟性を許可することをお勧めします。

1.6. Processing of the MUD URL (MUD URL の処理)​

可能な MUD マネージャーは, GET メソッド [RFC7231] を使用して [RFC7230] に従って MUD URL と署名ファイルを取得すべきです。[RFC2818] のセクション 3.1 の規則を使用して証明書を検証しなければなりません。

MUD URL のリクエストには, "application/mud+json" を含む "Accept" ヘッダーフィールド ([RFC7231], セクション 5.3.2), "Accept-Language" ヘッダーフィールド ([RFC7231], セクション 5.3.5), および "User-Agent" ヘッダーフィールド ([RFC7231], セクション 5.5.3) を含めるべきです。

MUD マネージャーは 3xx 応答ステータスコードを自動的に処理すべきです。

MUD マネージャーが MUD URL を取得できない場合, MUD ファイルと関連する署名ファイルをインポートするために他の手段を使用してもかまいません。ファイルの署名を検証できる限り, ファイルを使用できます。このような環境では, コントローラーはキャッシュ有効期限が近づいているときに管理者に警告して, 新しいファイルを確認できるようにすべきです。

MUD マネージャーが任意の時点で MUD ファイルを取得できない可能性があります。MUD マネージャーが MUD ファイルの取得に失敗した場合, 少なくともしばらくの間は既存のファイルを安全に使用できると見なすべきです。ある期間後, ファイルを取得できなかったことをログに記録すべきです。MUD マネージャーがオフライン環境にある, ローカルインターネット接続が失敗した, またはリモートインターネット接続が失敗したなど, このような失敗には非常に正当な理由がある可能性があります。攻撃者がデバイスの展開を妨害しようとしている可能性もあります。このような状況をどのように処理するかはローカルの決定です。

1.7. Types of Policies (ポリシーのタイプ)​

MUD URL が解決されると, MUD マネージャーはデバイスが持つように設計されている通信の種類を記述するファイルを取得します。メーカーは, クラウドベースのサービスの特定のホスト, または運用ネットワーク内のアクセスの特定のクラスを指定する場合があります。クラスの例は, "指定されたメーカータイプのデバイス" である可能性があります。ここで, メーカータイプ自体は単に MUD URL のオーソリティコンポーネント (例: ドメイン名) で示されます。別の例は, ローカルアクセスを許可または拒否することです。他のポリシーと同様に, これらは組み合わせることができます。例えば:

  • 同じメーカーのデバイスへのアクセスを許可

  • 制約付きアプリケーションプロトコル (Constrained Application Protocol, COAP) [RFC7252] を介したコントローラーへのアクセスとコントローラーからのアクセスを許可

  • ローカル DNS/NTP へのアクセスを許可

  • 他のすべてのアクセスを拒否

プリンターには次のような記述がある可能性があります:

  • ポート IPP またはポート LPD へのアクセスを許可

  • ポート HTTP へのローカルアクセスを許可

  • 他のすべてのアクセスを拒否

このようにして, 誰でもプリンターに印刷できますが, 管理インターフェースにはローカルアクセスが必要になります。

取得されるファイルは, 展開が容易になるように既存のネットワークアーキテクチャに密接に整合することを意図しています。ネットワークデバイスで使用するための正確で適切なモデルを提供するため, YANG [RFC7950] を使用します。JSON [RFC8259] は, XML に比べてコンパクトさと可読性のためのシリアル化形式として使用されます。他の形式は, MUD の後のバージョンで選択される可能性があります。

ここで示されているポリシーの例はアクセス制御に焦点を当てていますが, これが唯一の焦点であることを意図しているわけではありません。明確な拡張ポイントを持つこの文書で説明されているモデルを構造化することにより, 他の記述を含めることができます。よく思い浮かぶのはサービス品質です。

ここで指定されている YANG モジュールは [RFC8519] の拡張です。このモデルの拡張により, メーカーはデバイスの適切な機能に必要なシステムのクラスを表現できます。2 つのモジュールが指定されています。最初のモジュールは, アクセス制御リスト (Access Control Lists, ACLs) でドメイン名を使用する手段を指定します。これにより, コントローラーがクラウドにあるデバイスがドメイン名で適切に認証されるようにします。ここで, これらの名前からアドレスへのマッピングは急速に変化する可能性があります。

もう 1 つのモジュールは, IP アドレスを特定のクラスに抽象化します。これらのクラスは, ローカル処理によって実際の IP アドレスにインスタンス化されます。これらのクラスを通じて, メーカーはデバイスの通信設計方法を指定できるため, ローカルトポロジ知識を持つローカルシステムによってネットワーク要素を構成できます。つまり, 展開はメーカーが指定するクラスを入力します。以下の抽象化は, 次のように 0 個以上のホストにマッピングされます:

Manufacturer (メーカー): MUD URL のオーソリティコンポーネントで識別される特定のメーカーによって製造されたデバイス。

same-manufacturer (同じメーカー): MUD URL の同じオーソリティコンポーネントを持つデバイス。

controller (コントローラー): ローカルネットワーク管理者が特定のクラスに許可するデバイス。

my-controller (マイコントローラー): Thing が発信した MUD URL のコントローラーとして機能することを意図したデバイス。

local (ローカル): 一部の管理境界内でスコープされる IP アドレスのクラス。デフォルトでは, これはローカルサブネットであることが推奨されます。

"メーカー" クラスはメーカーが簡単に指定できますが, コントローラークラスは当初管理者が指定することが想定されています。

メーカーは誰がデバイスを使用するかを知らないため, 使用記述で参照される機能が比較的普遍的で成熟していることが重要です。これらの理由により, MUD ファイルの YANG ベースの構成は, この文書で指定または参照されているモジュール, または文書化された拡張で指定されているモジュールに限定されています。

1.8. The Manufacturer Usage Description Architecture (メーカー使用記述アーキテクチャ)​

これらのコンポーネントが配置されたことで, アーキテクチャの基礎ができました。これにより ASCII アートが生まれます。

.......................................
.                      ____________   .           _____________
.                     |            |  .          |             |
.                     |    MUD     |-->get URL-->|    MUD      |
.                     |  Manager   |  .(https)   | File Server |
.  End system network |____________|<-MUD file<-<|_____________|
.                             .       .
.                             .       .
. _______                 _________   .
.|       | (DHCP et al.) | router  |  .
.| Thing |---->MUD URL-->|   or    |  .
.|_______|               | switch  |  .
.                        |_________|  .
.......................................

図 1: MUD アーキテクチャ

上記の図では, スイッチまたはルーターが MUD URL を収集し, 処理のために MUD マネージャー (ネットワーク管理システム) に転送します。これは URL の通信方法に応じて異なる方法で発生します。たとえば, DHCP の場合, DHCP サーバーが URL を受信して処理する可能性があります。IEEE 802.1X [IEEE8021X] の場合, スイッチは Radius 上の拡張認証プロトコル (Extensible Authentication Protocol, EAP) [RFC3748] を介して認証サーバーに証明書経由で URL を運び, それが処理されます。これを行う 1 つの方法は, [RFC7170] で説明されている TEAP です。証明書拡張については以下で説明します。

MUD ファイルサーバーから返される情報は, Thing が接続されている限り有効です。有効期限はありません。ただし, MUD マネージャーが Thing の MUD ファイルが変更されたことを検出した場合, 展開で必要な承認フローを考慮して, ポリシーを迅速に更新すべきです。このようにして, メーカーからの新しい推奨事項をタイムリーに処理できます。

MUD ファイルサーバー (Web サーバー) から返される情報は, Thing の接続期間, または記述で指定されているとおりに有効です。したがって, Thing が切断されると, スイッチ内の関連する構成を削除できます。同様に, 新しい機能や通信パターンまたは脆弱性に基づいて, 記述が時々更新される場合があります。

Web サーバーは通常, メーカーまたはメーカーに代わって実行されます。そのドメイン名は MUD URL にあるオーソリティのドメイン名です。Things が URL を発信できないレガシーケースでは, スイッチが適切な URL を決定できる場合, それをプロキシできます。簡単なケースでは, スイッチポート上で MUD URL をハードコーディングするか, L2 アドレスや証明書ハッシュなどの利用可能な識別子から MUD URL へのマッピングを行う可能性があります。

この環境での MUD マネージャーの役割は次のことを行うことです:

  • MUD URL を受信する,

  • MUD ファイルを取得する,

  • MUD ファイルの抽象化を特定のネットワーク要素構成に変換する,

  • 抽象化の必要なマッピングを維持および更新する, および

  • 適切な構成でネットワーク要素を更新する。

MUD マネージャーは, 認証, 承認, アカウンティング (Authentication, Authorization, and Accounting, AAA) システムまたはネットワーク管理システムのコンポーネントである可能性があります。これらのシステム内およびこれらのシステムからネットワーク要素への通信は, このメモの範囲外です。

1.9. Order of Operations (操作の順序)​

上記のように, MUD にはアーキテクチャ構成要素が含まれているため, 操作の順序は異なる場合があります。ただし, ここに 1 つの明確な意図された例があります:

  1. Thing が URL を発信します。

  2. その URL は, 最も近いスイッチによって MUD マネージャーに転送されます (これがどのように発生するかは, MUD URL が発信される方法に依存します)。

  3. MUD マネージャーは, まだコピーを持っていない場合, MUD ファイルサーバーから MUD ファイルと署名を取得します。署名を検証した後, Web またはドメイン評判サービスに対して URL をテストする場合があり, 適切と判断した場合, ファイル内のホストをそれらの評判サービスに対してテストする場合があります。

  4. MUD マネージャーは, Thing と関連するポリシーを追加する許可を管理者に照会する場合があります。Thing または Thing タイプが既知の場合, この手順をスキップする場合があります。

  5. MUD マネージャーは, この文書で定義されている抽象化に基づいてローカル構成をインスタンス化します。

  6. MUD マネージャーは, Thing に最も近いスイッチを構成します。他のシステムも構成される場合があります。

  7. Thing が切断されると, ポリシーが削除されます。

に最終更新