4. セキュア QOS 転送 English
インターネットが特定のパケット フローについて特別な QOS （qualities-of-service）をサポートするとき、一連の新しいセキュリティ問題があります。ネットワーク資源において高価な、そのような QOS の価値を求めるユーザを認証・認可する必要性があり、これらの資源の盗用を防ぎ、他者によるサービス妨害攻撃を防ぐことが必要不可欠です。この章は、我々が「セキュア QOS 転送」と呼ぶこれらの問題についての概念的なモデルを含みます。ここにある諸論点は、「エンド to エンド」セキュリティやファイアウォールとは異なります。それは、QOS 転送セキュリティは、パス上のすべてのルーターに強制される必要があるからです。
これは新しい問題ではないことが注意喚起されました。； これは、Radia Perlman による論文中において論理的なやり方で記述・解決されています。
パス設定は、いかなる QOS メカニズムにおいても肝要な部分です。しかし、「たとえ QOS サポートが無くても、いかなるインターネット層セキュリティメカニズムにおけるパス設定もまた、エンジニアリング上の良い理由があること」ともいえます。理論上は、各 IP パケットが、それぞれ、転送パス上のすべての段階において必要不可欠な認可情報を運ぶ純粋なデータグラム モデルを想定することができます。 実際には、これは、現実的ではありません。なぜなら、セキュリティ情報は、すべてのパケットに入れるには、受容不能なほど大きく、かつ、計算能力を要求する可能性があるからです。このことは、セキュリティのための何らかの形態の状態設定の必要性を意味するかに見えます。
それゆえ、我々は、純粋なデータグラムモデルからは、いささか離れた 2段階の仮定を想定します。最初の段階（パス設定段階）で、ルーター（と他のネットワーク要素）において、どのように以降のパケットのストリームが扱われるべきかを記述する何らかの状態が確立されます。2番目の段階（クラス分け段階）において、到着パケットは、正しい状態情報と付き合わされ、処理されます。今日の用語法では、これらの異なる状態記述を「クラス」と呼び、ソートする過程を 「クラス分け（classification）」と呼びます。
パス設定は、多くの形態をとることができます。これは、動的である可能性があり、上述のように、アプリケーションによって、ネットワーク越しに呼び出される可能性があります。また、このパス設定過程は、SNMP もしくは遠隔ログインのようなプロトコルの手段によって、ルーターを手作業でパス設定する可能性 もあります。例えば、大西洋を横断するようなネットワークリンクは、共同で購入する数多くのユーザによって共有される可能性があります。彼らは、各共有ネットワークにおいて使うことが許されているパケットを記述する仕様 （すなわち、フィルタ）に基づいて、ルーターを設定することによって、共有を実装します。パス設定は、それが動的であれ、手作業であれ、また、短期間であれ、半永久的であれ、同様の 効果をもちます。： つまり、ルーターにおいてパケット クラスを作成し、パケットが到着したときに、それらがどのようにクラス分けされるかを定義します。
リアルタイム サービスのような QOS のための IP 拡張についての現在の研究の多くは、明示的なパス設定段階とクラス分け段階を想定してきました。パス設定段階は、RSVP もしくは ST-II のようなプロトコルを使って達成され、これらのプロトコルは、どのように以降のクラス分けがなされるべきかも規定します。それゆえ、パス設定段階におけるセキュリティは、 単に、そのようなプロトコルの拡張となります。ただし、「リアルタイム QOS について、暗黙のパス設定過程に基づいた代替的提案があること」を銘記する必要があります。
4.2 パス設定プロセスにおいてセキュアにする English
パス設定プロセスをセキュアにするために、我々は、「パス設定リクエストには、要求者が既知で、かつ、当該リクエストを行う権限をもつことを示す信用に足る保証を提供するユーザクレデンシャル を伴うこと」を要求します。我々は、パス設定段階において使われるクレデンシャルを HLID （高レベル ID）と呼びます。
この認可のシンプルなバージョンは、ルーターの管理インターフェイス上のパスワードである可能性があります。（このようなパスワード スキームの限界は、よく知られており、ここにおける論点ではありません。）設定が個々のアプリケーションによって行われることを要求する場合、いくつかのユーザ固有の認可が想定されなければなりません。
HLID を構成するには、無数のやり方の可能性がありますが、拡張の目的は、グローバルなユーザ命名と認証のためのフレームワークが有用であることを示唆します。命名フレームワークの選択の詳細については、5章 において検討されています。「ネットワーク資源とセキュリティ デバイスへのアクセスをコントロールすることに関するこの検討は、 「エンド to エンド」認証およびアクセス制御とは区別されること」を銘記してください。； しかし、同一の認証インフラストラクチャを両者について使うことができます。
一般に、インターネットのためのパス設定アーキテクチャを規定するために、相当なエンジニアリングの労力が要求されますが、新しいセキュリティ テクニックを開発する必要はありません。しかし、 クラス分け過程のセキュリティの観点については、性能と費用に関わる重要な問題があります。それゆえ、我々は、全体の枠組みの観点から、より詳細に議論します。
上記において、我々は、パス設定リクエストの一部として提供される一式の情報としての「高レベル ID (HLID)」を規定しました。しばしば「クッキー」と呼ばれる、 クラス分けのために各パケット中で運ばれる「低レベル ID (LLID)」というものもあり得ます。QOS についての IP 拡張のための現行の提案において、パケットは、既存のパケット フィールド（例： 発信元アドレス、宛先アドレス、ポート番号およびプロトコル種別）に基づいて、 クラス分けされます。
「LLID は、少なくとも概念的には、ユーザのアドレスとは区別されること」を銘記することは、重要です。この区別を押し進めることによって、我々は、「ユーザの権限は、使われているアドレスによって判定されないこと」を明らかにします。ユーザのアドレスが変わる場合、権限は変わりません。
パケット中の LLID は、このパケットに許可されている QOS について判断するために、パス上の一部又はすべてのルーターによって使われるタグの １形態の役割を果たします。LLID は、1つの発信元と宛先のアドレスの対の間のデータ ストリームを指すか、あるいは、より一般的であり、データ ストリームの範囲を指す可能性があります。「LLID は、それが表現する QOS パラメータをルーターが識別できるようにする構文を具現する」 ことについて特に要件はありませんが、そのような構造を強いることについて、妨げるものもありません。
我々は、「IP データグラムが、ネットワークの様々な段階において、パケットをクラス分けするために使うことができる 1つの LLID を含むこと」を提案します。我々は、「パケットは、 可変数の LLID もつ必要があり、各々は、ネット中の異なる点のためのものとする」という代替案を却下します。繰り返しになりますが、これは、単なるセキュリティのコメントではなく、セキュリティ上の示唆を含むものです。
LLID の属性は、可能な限り、広範な要件に適合するように抽出される必要があります。
- （後述する）有効期間は、セキュリティ プロトコルの要求（堅牢さと効率性のバランスをとること）と、アプリケーションの要求（LLID が期限切れとなったとき、再度、新規のパス設定を扱う必要があること）の両方に適合しなければならない。自動的に再度、新規のパス設定リクエストを行うサービス は、有用な端末機能となるであろう。
- 信頼の程度は、我々が合理的に適合させられる最も厳正な要件に適合するように、十分に高くなければならない。
- LLID 構造の粒度は、ネットワーク中のいかなる資源選択についても、パケットクラス分けを十分に細かく分類できるものでなければならない。それゆえ、我々は、 「アプリケーションからの各パケットのストリームが個別の LLID をもつこと」を期待する必要がある。複数のストリームを 1つの LLID または 1つの認証子に集約することは、ほとんどあり得ない。
少なくとも、内容的に LLID の利用を検証することが必要不可欠です。すなわち、「認可されたやり方において言明されていること」を確認することです。認可されていない LLID の使用は、サービスの盗用またはサービス妨害攻撃をもたらす可能性があります。この場合、認可された送信者によって送られたものではないパケットが、その送信者 （あるいは、送信者がメンバーとなっているグループ）のために予約された QOS に従って処理されてしまいます。それゆえ、LLID の利用は、LLID に基づいて QOS の判断を行うルーターによって認証される必要があります。（すべてのルーターが LLID に「注意を払う」わけではないことに注意。）
原則として、LLID 言明の有効性は、すべてのルーターにおいて必要不可欠ではありませんが、すべてのパケットについてチェックされる必要があります。； セキュリティ境界 にチェックを限定することは、可能でしょう。LLID を検証しなければならないこれらのルーターにおいては、性能への影響について明らかな懸念があります。それゆえ、ルーターは、LLID 検証のために、厳密性の低いアプローチを採用する可能性があります。例えば、ルーターは、データ ストリームを試査するために抽出し、すべてではないが、いくつかのパケットを検証する可能性があります。ルーターは、また、転送されたパケットを最初に抽出し、選択的検証を背後で行う可能性もあります。最も緩いアプローチにおいて、ルーターは、選択されたパケットのログを取得し、後で監査活動の一環として、それらを検証します。
LLID の利用を検証するための、いくつかの候補となるテクニックがあります。我々は、3つの基礎的なテクニックを識別しました。これらは、計算上の性能、帯域オーバーヘッド、および有効性（様々な形態の攻撃に対する耐性）の観点において異なります。
* デジタル署名 English
最初のテクニックは、公開鍵暗号技術とデジタル署名の利用を伴います。各パケットの送信者は、パケット上の一方向性ハッシュを算出し、LLID と関連づけられた私有鍵を使って、そのハッシュ値を変形することによって、パケット（ヘッダーとペイロード）に署名します。結果としての認証子の値は、そのパケット ヘッダーの中に含められます。公開鍵と LLID の結合は、はるかに長い有効期間をもつ公開鍵を利用するパス設定手順 を通じて確立されます。公開鍵暗号技術の利用は、いかなるルーターでもパケットを検証できる優位性をもたらしますが、有効な認証子 （すなわち、他のルーターは、これを有効と見なされる）をもったパケットを生成できるようにするデータを委託されているルーターはありません。この性質は、「最小権限の原則」の観点から、このテクニックを理想的なものにします。
RSA のような公開鍵暗号システムは、「署名の検証は、署名することよりも、はるかに速い」という優位性をもち、これは、ルーター処理負荷を軽減します。それにもかかわらず、現在の公開鍵暗号アルゴリズムの性能では、このアプローチは、ルーターによる選択的チェックを行うこと以外には、実現可能ではないようです。
* 印付け（sealing） English
次のテクニックは、デジタル署名のために使われる同一種類の一方向性ハッシュ関数を使うことに基づいていますが、これは、ハッシュ値 を署名することを要求しません。ここで、送信者は、パケットに付加された秘密の数（本質的なのは「鍵」）で一方向性ハッシュを算出します。この過程は、しばしば、より一般的に暗号技術的「印付け（sealing）」として呼ばれるものの一例です。ハッシュ算出の最後に、この鍵を含めることは、鍵を保持していない、いかなる主体によっても予期できないハッシュ値をもたらします。結果としてのハッシュ値は、認証子であり、パケット ヘッダーに含められます。ルーターは、同一の秘密の数が付加された受信パケットについてのハッシュ値を再計算することによって、パケットを検証します。送信されたハッシュ値が再計算したハッシュ値と一致する場合、そのパケットは、有効であると宣言されます。署名テクニックとは異なり、印付けは、「印を検証できるすべてのルーターは、印を生成（偽造）することもできること」を意味します。それゆえ、このテクニックは、「送信者は、ルーターが鍵を濫用しないと信頼すること」を要求します。
このテクニックは、送信者と LLID と関連づけられたパケットを検証する必要があるすべてのルーターの間で共有された単一の秘密鍵を前提として記述されています。関連する代替的戦略は、同じ認証子テクニックを使いますが、秘密鍵を ペア単位で共有します。（例： 送信者と最初のルーターの間、最初のルーターと、その次のとの間、等。）このことは、秘密鍵を大規模なルーター群に配信する必要性を避けますが、「 パス設定メカニズムに、ルーター A がその近隣（ルーター B）に『ルーター A は、特定の LLID もしくは一式の LLID についてのトラフィックを表すことが認可されている』と確信させることができるようにすること」を要求します。このことは、リンクの両端が検証できるラッパーの内側のパケットをカプセル化することによって、最もうまくできます。一旦、この戦術が行われたら、ルーターにとって、LLID 単位でない認証を提供しつつ、それらの間のトラフィックを集約することが、最も効果的でさえある可能性があります。それは、ルーターの対は、データ ストリーム LLID を正確に表現するために、相互に「信頼」する準備ができているからです。
ユニキャスト データ ストリームについて、ルーター間でペア単位の鍵を使うことは、秘密鍵の対称的共有により、ルーター 、もしくは、パス設定メカニズムについて要求される信頼における実際の変更をもたらしません。しかし、マルチキャスト接続について、このペア単位の鍵を使うアプローチは、マルチキャスト木の中の 1点にあるルーターが、木の中のその他の点に注入可能なトラフィックを生成できることを防ぐことにおいて優れています。最悪の場合、ルーターは、マルチキャスト木中の「下流の」ルーターのみに対して、偽の認証可能なトラフィックを生成することができます。
「ネットワーク管理障害隔離テクニック（例： データ ストリーム上の異なる点におけるルーター トラフィック統計の試査）の利用で、データ ストリーム パス中の悪いルーターによって乗せられたパケット偽造攻撃の事後（post hoc）検出を 可能にする必要があること」に注意してください。このテクニックの使用は、ルーターによるそのような活動を抑止する可能性があり、ペア単位の鍵を使うアプローチについて、さらに検討します。
印付けテクニックは、デジタル署名テクニックよりも速いです。それは、暫増的な（付加された秘密の数を含めた)ハッシュ計算は、ハッシュ に署名するために要求される暗号技術的変形よりも、はるかに速いからです。ここで、処理負荷は、対称的です。すなわち、送信者と各ルーターは、パケットに印付けするためと、印付けを検証するために、同じ処理能力を供出します。また、印付けされたハッシュは、たとえ 同じ関数が使われたとしても、署名されたハッシュよりも小さい可能性があります。（これは、公開鍵署名アルゴリズムのモジュールの大きさと、署名されたハッシュ値の大きさ を増加させる傾向があるいかなる補助的な変数に起因します。）さらに、オーバーヘッドを低減することが必要不可欠である場合、「広域」値ととともにハッシュ関数を使い、それを切り詰め ることができます。； 認証子が署名されたハッシュ値であるとき、このオプションは利用できません。
このテクニックの 1流派として、認証子を生成・検証するために使われる秘密鍵を送信者から受信する「クリアリングハウス」を想像することができます。パケットを検証することを必要とするルーターは、パケットの複製をクリアリングハウスに送ります。クリアリングハウスは、パケットをチェックし、「これが懸案の LLID と関連づけられた有効なパケットであったか否か」をルーターに示します。明らかに、この流派は、そのルーターがめったにない選択的パケット検証を行っている場合のみ、実行可能です。しかし、パケットを検証しなければならないすべてのルーター間で認証子の秘密を共有する ことを要求しません。
これらのテクニック両方について、データ ストリームの有効期間内における有効なパケットのリプレイに基づく、サービス妨害攻撃に対する残存脆弱性があります。パケットがシーケンス番号を運び、ルーターが各データ ストリームについてシーケンス番号域を捕捉しないかぎり、（外部）攻撃者は、有効なパケットを複製して、それらを再送することができます。この形態の攻撃 に対して防護するためには、ルーターペアの間のすべてのトラフィックを 1つの流れに集約し、データ ストリーム単位 ではなく、フロー全体に対してリプレイ対策を提供することによるのが、最も容易でしょう。
* 一時的パスワード English
ワークショップにおいて披露された最後のテクニックは、パケット検証に対して、非常に異なる戦術を採用します。先に紹介したテクニックは、 パケット中のビットについての関数を計算し、その値を変形することにより、侵入者が有効な認証子によってパケットを生成することを防ぎます。与えられた LLID について有効な認証子をもったパケットを生成するためには、送信者のみ、または 、送信者と与えられたデータストリームに参画しているルーターのみに利用可能な秘密値にアクセスできることが必要です。
対照的に、この 3 番目のテクニックは、認証子が、短期的で、パケットヘッダーによって運ばれる秘密の数量であり、より強固な防御の利益を受けないことを要求します。要するに、このテクニックは、短期の「パスワード」を各パケット ヘッダーに結合するものです。このアプローチは、 先に紹介した原型と同様に、「LLID を検証するすべてのルーターが 、この認証子を密かに知っていること」を要求します。さらに、この認証子は、いかなる他のルーター、もしくは、パス中の他の機器から見ることができ、それゆえ、このテクニックは、前のものよりも、はるかに脆弱です。
認証子は、それが認証するパケットの機能でないため、同一の認証子が、同一の LLID を持つすべてのパケットに適用される可能性があります。事実、これは、「LLID を認証子として使うことが実現可能であること」を示唆しています。しかし、この戦術の採用は、明示的で個別の認証子を必要とする前述の 2 つのテクニックとは整合しないでしょう。それゆえ、我々はこの最適化をしないことを推奨します。
それにもかかわらず、「認証子がパケットのコンテキストと独立である」事実は、あらゆる正規パケットから認証子が傍受された場合に、明らかに本物のパケットを偽造することを意味のないものにします。また、認証子が推測できる場合、攻撃者は、このスキームをうち破るために受動的回線盗聴に関与する必要さえありません。この後者の観察は、「認証子は、推測を困難にするために十分な大きさをもたなければならず、この要件をサポートするように、LLID と、その認証子を分離しなければならないこと」を示唆します。
このアプローチの主要な優位性は、性能の 1つです。この認証子は、単純な比較によって極めて早く検証される可能性があります。推測攻撃に対する防護の必要性と整合するように、この認証子は、パケットヘッダー中の相当量の空間を費やす必要はありません。 ルーターに可視のシーケンス番号を使用することは、脆弱性を含むこれらの方法をより堅牢にするために興味深いテクニックです。
各ストリーム（パケットの各送信元）が、そのパケットに番号を振るものとすると、ネットワーク資源の使用を試みる侵入者は、正規のパケットを削除しなければならず、多くの場合、これは困難でしょう。そうでなければ、攻撃を受けているルーターは、シーケンス番号の重複やそれに類似する異常を感知します。正規のストリームパケットは喪失する可能性があり、これによってシーケンス空間に穴をもたらすため、正確な採番が機能しなければなりません。
我々は、ここでは、ユーザが与えられた LLID と 認証子をその他の認可されたユーザと故意に共有する共謀の論点を考慮しません。「この活動、ひいては、現実の脅威に実践的な優位性があるか」を見極めるために、この可能性は、開拓される必要があります。
o LLID の有効期間 English
LLID の利用における鍵となる質問は、「どれだけの期間有効であり続けるか」です。 一つの極端な例では、非常に短い期間（おそらく数秒）だけ有効です。これは、LLID 用の認証子が盗まれた場合、起きる可能性がある被害を制限します。逆の極端な例では、LLID がクレジットカード番号のように半永久的に有効です。LLID をセキュアにするために提案された上記テクニックは、「LLID の有効期間の制限により危険が制限される」という仮定に基づき、強度と引き換えに効率を得ています。
長期的、つまり半永久的な LLID に釣り合う利点は、ルーターの手動設定でパケットクラスを確立するといった原始的なパス設定手法が実用的なものになることです。このことは、短期的には、重要です。なぜなら、セキュリティと動的資源割り当てプロトコルの実用化時期が性格に一致しない可能性があるからです。
我々は、「短期的には、LLID の有効期間が相当短いという仮定に基づいて LLID を設計し、より長い有効期間にも耐えうるようにすべきである」という結論に達しました。これは、「最初の段階では。代わりに許容可能なレベルの長期間メカニズム （これは、運用的なセキュリティレベルは低くなる）を採用であろうこと」を示唆します。自動的パス設定のための良いツールを手に入れた時、パケット転送パス中のメカニズムを置き換えることなく、有効な期間を個別に短縮することができます。
o パス設定による遅延 English
インターネットの伝統では、端末間の通信パスにおいて、いかなるパス設定遅延をも生じさせません。これは、速いトランザクション用の古典的データグラムモデル等をサポートしており、 維持される必要がある特徴です。
管理インターフェイスを使うか、背後の末端によるか、いずれかによって「事前に」行われるパス設定によって、遅延の論点は、発生しません。この遅延問題は、特定のアプリケーションのリクエストの 対応する動的資源確保によって発生します。
我々は、「遅延は、重要な論点ではあるが、セキュリティの関心事によって影響を受けない題材である」とみています。RSVP や ST-II のような資源確保プロトコルの設計者は、今日、これらのプロトコルの 遅延について議論しています。パス設定リクエストメッセージに認証子を追加することは、それを検証するのに必要とされる処理を増やし、認証サービスをもったメッセージ交換さえ意味する可能性がありますが、パス設定段階 に要する時間は、既にラウンドトリップ遅延のオーダーとなっており、実質的には影響を与えません。しかし、パス設定プロトコルのための高レベルの認証と認可の手法の設計は、「この過程は、パケット毎処理レベルまでは要求されませんが、かなり時間的に厳しい処理であること」を理解する必要があります。
高額なパス設定過程を扱うやり方の 1つは、暫定的にパス設定リクエストを受け入れ、検証を背後で行うことです。このことは、1つの悪いパス設定リクエストによる被害を短期間に制限します。しかし、「少なくとも、システムは、短期において、認可されていない用法を許す 一連のパス設定リクエストを使う攻撃に対して脆弱であること」を銘記してください。
「サービス妨害攻撃は、パス設定過程を無効なパス設定リクエストによって溢れさせることによって上乗せされる可能性があり、これらのすべては、処理され、棄却される必要があること」も銘記してください。このことは、有効なユーザがいかなる状態を設定すること さえ妨げることもありえます。しかし、溢れさせることに基づくサービス妨害攻撃は、非常に大きな「指紋」を残します。； それらは、通常、重要な脅威とはなりません。これが問題である場合、パス設定処理レベルにおいて、FQ（fair queueing） （パケットレベルにおけるフラッディング攻撃による被害を制限するために使用）と等価の機構を組み込める可能性があります。
インターネットのための QOS 拡張についての最近の作業（RSVP プロトコルに埋め込まれたもの）は、受信者が資源を確保するモデルを使います。このスキームは、 現行 IP マルチキャストの全体構図と整合性があります。これは、受信者がマルチキャスト グループに参加することを要求します。受信者は、マルチキャスト トラフィックが受信者に、要望された QOS で到達するようにするために資源を確保します。この場合、パス設定段階に与えられるのは、受信者のクレデンシャル（HLID）です。
「受信者の加入は、明示的パス設定段階を要求すること」を銘記してください。設定が、パケット中の既存のフィールドによって暗黙的になされると仮定します。このとき、パケットを特定の受信者と関連づける方法がありません。それは、マルチキャストにおいては、受信者のアドレスは、このパケットには無いからです。
さらに、この場合、送信者と受信者が非常に密接に協調していない限り（さもなくば、受信者は、事前に「パケット中にどの LLID があるか」を知りません）、「事前に」 パス設定を行うことは不可能です。この場合、受信者が流入してくるマルチキャスト トラフィックのために「半永久的」な資源確保のパス設定を行うことは、確かに不可能です。繰り返しになりますが、このことは、セキュリティ論点ではありません。； この問題は、セキュリティ問題を追加するものではありませんが、セキュリティ アーキテクチャは、これを考慮しなければなりません。
4.6.1 暗号化するファイアウォールとバイパス English
我々のセキュリティの視点（端末とネットワークの両方の防護）は、ファイアウォールの利用を含みます。これは、ネットワークを信用の程度差がある区分に区分けします。このアイディアは、軍事／諜報コミュニティにおいて使われている暗号化するファイアウォール モデルと共通するところがあります。： （信用できる）レッド ネットワークが、（信用できない）ブラック ネットワークから区分されます。軍事的モデルにおける顕著な差異は、「ブラックネットワーク区画を越えて、レッドネットワーク区画に至るパケットの旅において、可能な限りパケットをエンコードする暗号化ユニットを使うこと」です。すなわち、暗号化ユニットの 最大の目的は、レッドネットワーク中に格納されたデータの開示に対して非常に高度な防護を提供することです。対照的に、我々の（通常の）ファイアウォールは、せいぜい信用できる（レッド）区画のネットワークを外部からの攻撃から防護する 程度のものです。「何が入ってくるか」と「何が出ていくか」の両方に関心が払われます。また、信用できるネットワーク上の端末と信用できない部分ネットワーク中の端末の間の通信を許容しま す。
我々は、我々のセキュア QOS のモデルを、軍事的な暗号化ファイアウォールの事例に適用できるようにしたいと考えます。しかし、この暗号化の利用は、パス設定と クラス分けの2段階の過程に基づいた、上述の我々のセキュアな資源管理モデルに問題を提起します。このモデルには、問題があります。それは、レッド区画からブラック区画に、クリアな形で転送する情報を要求するからです。この情報は、（パス設定が端末から動的に行われる場合は）パス設定パケット自体と、データ パケット中のクラス分けフィールド（LLID）の両方を含みます。明らかに、この情報は、レッド区画のネットワークを出るとき、暗号化できません。ブラック ネットにとって無意味となる からです。暗号化され、無意味になれば、ブラックネットワークは、それに基づいて資源配分の意思決定を行うことは、不可能でしょう。
この種の制御スキームを動作させるためには、暗号化デバイスおいて、特定のパケットやパケット中のフィールドが暗号化器をクリアな形で通過できるようにプログラムされていることは、必要不可欠です。この ような暗号化の迂回は、極めて望ましくないものと考えられています。高セキュリティ環境において、迂回する情報を生成する過程は、 うまく働かず、コントロールされるべき情報をパケットのバイパスされたフィールド中に隠すことによって、それがセキュア ネットワークから削除される結果を招く可能性があります。
しかし、我々は、「このバイパス問題は、克服できないことはない」と結論づけました。鍵となるアイディアは、（すべてのバイパスの事例と同様に）全体が無制約ではなく、クリアな形態で転送される情報を制限することです。バイパスのために必要とされる情報を制限するために、ブラック環境中の統合的管理機能としての パス設定を実行するか、この過程を 2段階に分割するか、のいずれかを行うことができます。最初の段階は、再度、全体としてブラック な（信用できない）ものとして、限定数のパス設定状況を規定します。2番目の段階は、レッドネットより事前に定義されたセットの中から 1つのリクエストを選択する非常に小さなメッセージを送ることに関するものです。
おそらくより困難な論点は、パケット ヘッダーの中の LLID です。LLID が明示的フィールドである場合、（我々が、これまで検討してきたように。（ただし、下記も参照。）これは、各パケット中において、おそらく 32 bit までの新しいフィールドを表現します。繰り返しになりますが、解決策は、このフィールドを使うことができる方法を制限することです。 端末がパス設定を行うとき、使われる LLID の値を規定します。この事実は、レッド／ブラックの暗号化ユニットによって観測でき、これは、このフィールドの構成要素を現在使用中の値に制限することができます。状況を改善するために、暗号化ユニットは、ブラック ネットを横断する目的のために、数多くの流れを 1つの流れに集約することができます。これは、レッド区画をカプセル化しなければならない区別された LLID の数 を、さらに減少させます。
この場合における LLID の有効期間のような、いくつかの重要な論点を含む、この提案の詳細は、さらに検討しなければなりません。しかし、これは、「軍事用と商用の両形態のセキュリティは、同様の構成要素から構築できること」を示唆するので、「バイパスが一般的な資源コントロール フレームワーク に組み込むことができる」という当初の結論は、非常に励みになります。
4.6.2 整合性ある権限の原則 English
よく理解されたセキュリティの原則のひとつに「最小権限の原則」があります。これは、「システムは、その構成要素に最小権限を求めるように構築されたときに最も堅牢である」とします。
我々が知る関連したルールは、「整合性ある権限の原則」です。これは、これが特に関連するサービス妨害の事例において、シンプルに描写することができます。特定の経路について、我々がパケットを配信するルーターを信頼しないかぎり、サービスの仮定に、正当化できるものはありません。ルーターが侵され、パケットを転送しない場合、唯一の解決策は、このルーターを 含まない別の経路を見つけることです。この話題は、おそらく、その他の話題（ネットワーク インフラストラクチャをセキュアにすること）の一部であるので、我々は、ここでは、侵されたルーターがあるときに新しい経路を発見するためのプロトコルに関心を持ちません。我々は、「 我々は、そのルーターからサービスを受けるか、もしくは受けないか、のいすれかである」と考えているだけです。そのルーターが侵された場合、「どのように、それが我々を攻撃する選択をしたか」は、問題となりません。それゆえ、ルーターが転送パス（最も一般的なのは、マルチキャスト転送木）の一部である限り、我々は、それに共有された資源鍵もしくは LLID 検証子を与えることによるような、他のやり方で信用することを躊躇してはいけません。
これは、「整合性ある権限の原則」を表しています。この原則は、「ホップ by ホップ」のスキーム中、もしくは、マルチキャスト木の中の LLID を検証するための秘密のペア単位の利用において、努められます。木全体のために 1つの鍵が発行された場合、権限には、整合性がありません。我々は、木の中における「下 流」の端末に関するルーターを信用する必要だけがあります。これがトラフィックを転送することに失敗する場合、これは、それらの端末にのみ影響を与える可能性があります。しかし、我々がグループ鍵を与える場合、これは、偽のトラフィックを生成し、木のいかなる点にも注入することができ、木の他の部分のためのトラフィックに影響を与えます。他方、我々が ペア単位の鍵を使う場合、侵されたノードは、トラフィックにおいて直接、受け取る鍵をもった偽のトラフィックを生成できるのみで 、結局、その木の一部を加害できるにすぎません。
その他に我々がネットワーク上に配備しなければならない要件は、ルーティングに関するものです。ファイアウォールがある場合、我々は、そのルーティングアーキテクチャがそのファイアウォールを迂回しないことを信頼しなければなりません。これを達成する方法の 1つは、そのファイアウォールを通るもの以外の区画間のいかなる物理的なパスをも絶つことです。このシンプルな物理的制限が受容可能な制約であるかを見極めるためには、運用的な経験が要求されます。
4.6.3 暗黙の LLID English
我々は、パケット中のアドレスと、パケットをクラス分けするために使われる LLID との強固な概念的区別の重要性を強調します。概念的な区別は重要ですが、制限された状況下では、一部のパケットフィールドを犠牲にし、現行のパケットヘッダーから LLID を作成することは可能でしょう。例えば、IPv4 の現行のパケットクラス分け機構（classifier）（セキュアではありませんが、パケットをサービスクラスにクラス分けする働きをするようです。）は、LLID の形態としていくつかのパケットフィールドを共に使用します。
この種の「黙示的（implicit）」 LLID は、特にホストが、移動するときに、その IP アドレスを変更できる場合、短命でなければなりません。しかし、LLID が何らかの動的パス設定プロトコルによって確立される場合は、必要に応じて LLID を再確立できることが必要です。
現行 IPv4 ヘッダーは、LLID を検証する認証子フィールドをもちません。認証子フィールドは、オプションとして運ばれる可能性があります。； それを追加することは、ネットワーク資源確保に堅牢さをもたらします。認証子の作成について上述した、あらゆるスキームが利用可能です。例外は、シンプルなパスワードによる認証子が使われた場合、LLID は、無作為に抽出できないので、これは、明示的な分離したフィールドでなければなりません。
4.6.4 パス設定無しのセキュリティ English
このアーキテクチャを記述するとき、パス設定段階は、順序において肝要な部分です。このことは、「パス設定プロトコルをもたない現在のインターネットは、サービス妨害攻撃に対してセキュアにすることができないこと」を示唆します。この点の限界を開拓することは、重要です。我々が上記において強調したように、パス設定は、多くのやり方でできます。今日のルーターは、プロトコル種別やヘッダー中の他のフィールドに基づいてパケットを クラス分けするためのマネジメントオプションを提供しており、このクラス分けを使用すると、1 つのクラスによってネットワークが過負荷になりそれ以外のクラスが除外されるのを防ぐことが可能ないくつかの FQ（fair queueing）クラスを作成できます。
ここには、2つの問題があります。最初の問題は、「管理インターフェイスを使って行われるパス設定について、LLID を検証するためには、発信元とルーターの間で共有された秘密は、長期に渡って維持管理されなければならず、これは、手作業でパス設定されなければならないこと」です。2 番目の問題は、クラス分けの粒度が粗い可能性があることです。しかし、Radia Perlman 氏の論文において、「ルーターは各送信元アドレスごとに個別の FQ（fair queueing）クラスを暗黙的に作成できること」が提案されています。アドレスを暗黙の LLID として使うこのアプローチは、堅牢性確保のために、何らかの形態の認証子をもたなければなりません。しかし、LLID が信頼できる場合、この枠組みは、暗黙のパス設定操作にのみ基づくトラフィックの クラス分けを提供します。クラス分けの粒度は、いかなる QOS 仕分けを提供するためにも不十分です。唯一の目的は、ある送信元からのトラフィックが、その他を排除してしまうほどにネットを溢れさせることを防ぐことです。
4.6.5 アドレスを検証する English
我々は、ここで、「パケット中の LLID とアドレスが概念的に区別される場合、かつ、LLID を検証するのに適する手段がある場合、そのアドレスを検証する理由は無いこと」を主張します。しかし、偽の 送信元アドレスで作成されたパケットは、その LLID が検証できる場合、何らセキュリティ問題をもたらすようには考えられません。
この例外は、移動ホストによる通信にある可能性がありますが、これは、完全な脅威のモデルと、移動環境において確保されるべき要件を要求します。しかし、我々は、議論の出発点として、「LLID がアドレスによって区別される場合、移動性についてのセキュリティの関心事の多くは、 緩和され、おそらく除去される」と主張します。この点は、移動性問題の、より詳細な考察によって検証される必要があります。
a) パケット中で運ばれる LLID (Low-Level IDentifier) を、パケット中のアドレスと概念的に分離することが重要です。
b) 各パケット中で 1つの LLID が運ばれます。これは、複数の LLID が使われている場合よりもルーターにおける追加的な状態（保持の必要性）を意味する可能性がありますが、1つだけ LLID を使うことは、より拡張性があります。
c) ホップごとの LLID 認証メカニズムは、秘密の配布を制限する、高度に拡張可能なアプローチを提供する可能性があります。しかし、その堅牢さの限界は、網羅的に調査されなければなりません。
d) 統計的サンプリングもしくは事後検出メカニズムは、性能問題に対応するためにルーターに採用される可能性があります。