要約

  • RFC 7510は、カプセル化装置が生成するフロー・エントロピーを外側のUDP送信元ポートに置き、既存のIPルーターでMPLSトラフィックをECMPやリンク集約へ分散できるようにした。
  • 送信元ポートも宛先ポート6635も、身元や利用許可を示さない。ピア設定、運用範囲、フィルター、輻輳管理、チェックサム、MPLSラベルスタック、認証は別々に確立する必要がある。

6635を許可する前に問うこと

ファイアウォールに「UDP宛先ポート6635を通す」と記述するのは簡単だ。IANAのサービス名・ポート番号レジストリにも、6635はmpls-udpとして登録されている。だが、この登録が答えるのはペイロードの種類であって、誰を通してよいかではない。

受信側は6635を見て、設定済みの文脈において中身をMPLSパケットとして解釈できる。それだけでは送信者を認証できず、その送信者がトンネルを使ってよいとも判断できない。内側のラベルが受信側のラベル空間で有効かどうかも、ポート番号からは分からない。

RFC 7510は、カプセル化側が相手のMPLS-in-UDP終端能力を事前に知る必要があるとする。その手段は手動設定でも動的な広告でもよく、文書の範囲外だ。つまり能力関係はパケットの前に成立する。6635への着信自体がネゴシエーションになるわけではない。

この順序を逆にすると、パーサーの目印が通行証になる。適切な許可は、想定する送信元・宛先アドレス、インターフェース、運用ドメイン、設定状態、必要なら鍵やシグナリングに結び付けるべきである。その関係の内側で初めて、6635という共通の入口が役に立つ。

IP装置に見えるエントロピー

MPLSをUDPで包む理由は、IP網にすでにある機能を利用するためだ。多くのルーターは、送信元と宛先のIPアドレス、送信元と宛先のポート、プロトコル番号からなる五つ組をハッシュし、TCPやUDPのマイクロフローをECMP経路やリンク集約のメンバーに振り分ける。

直接カプセル化されたMPLSパケットでは、途中のIP装置が十分な差異を見つけられない場合がある。複数の内側フローが同じ物理経路へ偏れば、他の経路に余裕があっても混雑が起きる。すべての中継装置にラベルスタックの深い解析を求めるのも現実的ではない。

RFC 7510は外側にIPとUDPを加える。IPアドレスはトンネル終端を示し、UDPヘッダーは既存のハッシュ回路が扱える入力を提供する。送信元ポートに変化を持たせれば、MPLSの複数フローを異なる経路へ分散できる。

フォーマット図は役割を順に並べる。最初に「送信元ポート＝エントロピー」と「宛先ポート＝MPLS」があり、UDP長とチェックサムが続く。その内側にMPLSラベルスタックと本文がある。外側の経路選択、UDPによる分散、MPLSによる転送は重なっているが、同じ意味ではない。

ローカルに決まる「フロー」

送信元ポートは、カプセル化装置がフローを識別するために生成する16ビットのエントロピー値である。ただしRFCは、何を一つのフローとみなすかも、値を生成するアルゴリズムもローカルな判断であり、仕様の対象外だと明記する。

したがって、外側のポート番号には世界共通の逆引き表がない。ある装置は内側のアドレスとポートを材料にし、別の装置はその処理段階で利用できる別のフィールドを使える。同じ数値を見ても、観測者は顧客名、アプリケーション、テナントを確定できない。

エントロピーが不要な場合でも、一つのフローではランダムに選んだ一定値を使うことが推奨される。値を変え続けるとパケットが別経路へ移り、順序が崩れるからだ。ここでの安定性は経路バケットの安定性であり、通信相手とのセッション継続性ではない。

動的・私用ポート範囲に収める必要があれば、14ビットのハッシュを下位に置き、上位2ビットを二進数の11にする方法も示される。結果は49152から65535に収まり、名前付きアプリケーション用の低い番号と衝突しにくい。

それでも値は有限で、生成規則はローカルだ。異なるフローや異なるカプセル化装置が同じ値を使うことはあり得る。セキュリティ主体や課金単位として扱えば、単なる分散信号に文書が与えていない権限を載せることになる。

「往復するUDP」という錯覚

この設計が通常のUDP会話と最も異なるのは方向性である。RFC 7510のトンネルは単方向で、パケットは登録済み宛先ポートへ送られる。応答が、エントロピーとして使われた送信元ポートへ戻ることはない。

多くのステートフルなミドルボックスは、返信で同じポートの組が反転すると想定する。その前提では、双方向のMPLS-in-UDPを通すために方向ごとの設定が必要になる。五つ組を表示する監視画面があっても、タイムアウト管理される一つのアプリケーション・セッションが存在するとは限らない。

観測データは分けて保持した方がよい。外側の五つ組はトンネルパケットとエントロピーの桶を示す。構成管理は期待するピア関係を示す。ラベルスタックは転送文脈を示す。内側の情報が見えるなら、そこで初めて運ばれる通信を分析できる。

これらを関連付けることには価値がある。しかし、一つの「UDPセッション」という欄へ押し込むと、経路ヒント、許可、転送状態が混ざる。可視化の簡潔さが、プロトコルの意味を上書きしてしまう。

内側のラベルは別の仕事をする

UDPを外した後に残るのはMPLSラベルスタックである。RFC 3032はその符号化を定義する。RFC 3031は、ラベルを転送に用いる短い固定長のローカルに有意な識別子として位置付ける。同文書の共同著者はEric Rosen、Arun Viswanathan、Ross Callonである。

ローカルに有意である以上、トップラベルは割り当てられた転送文脈で読まなければならない。UDP 6635が世界共通でも、内側のラベルが世界共通の名前になるわけではない。終端は正しいラベル空間へ入り、上流割当てか下流割当てかという規則も守る必要がある。

MPLS内部にも別のエントロピーがある。RFC 6790はラベルスタック内にEntropy Label IndicatorとEntropy Labelを置く。RFC 7510は外側のUDP送信元ポートに値を置き、IP装置から見えるようにする。配置が違うため、利用する転送装置も異なり得る。

いずれも認証ではない。内側にあるからEntropy Labelが利用者名になるわけではなく、UDPヘッダーにあるから送信元ポートがセッションになるわけでもない。フィールドの位置は可視性を決めるが、権限を決めない。

チェックサムが残す責任

IPv4では、性能または実装上の理由からUDPチェックサムをゼロにすることが推奨される一方、VPNのラベル破損を保護する価値にも触れている。IPv6では原則としてチェックサムを使わなければならない。

RFC 6935はトンネル向けに限定的なIPv6ゼロ・チェックサムを認め、RFC 6936は厳しい適用条件を示す。単一管理下または緊密に協力する網、低いと把握された破損リスク、残余リスクを受け入れる運用者が必要になる。

経路上の装置がIPv6のゼロ・チェックサムUDPを破棄すれば、トンネルはブラックホール化する。RFC 8085の一般的なUDP利用指針も、送信元ポート・エントロピーだけでなくチェックサム、ミドルボックス、輻輳を一緒に考える必要を示す。

計算を減らす最適化は、破損の責任を消さない。均等に分散された壊れたパケットは、依然として壊れている。エントロピーと完全性を一つの「性能」指標で相殺してはならない。

協力範囲が安全範囲になる

RFC 7510は、MPLS-in-UDPを単一運用者のネットワーク、または輻輳を管理できる隣接した協力運用者のネットワークに限定する。輻輳制御を必要とする公開インターネットへ無条件に流す仕組みではない。誤設定やパケット誤りによる流出を防ぐフィルターも推奨される。

これは地理的な囲いではなく、責任を実行できる範囲だ。同じ管理領域なら、容量、流入許可、監視、障害対応を調整できる。協力関係のない網へ広げれば、UDPトンネルが他者のトラフィックに輻輳コストを負わせる可能性がある。

セキュリティ上も、MPLS-in-UDPだけでは完全性、秘匿性、カプセル化装置の認証を実現できない。必要ならIPsecやDTLSを使う。IANAの6636はDTLS付きのMPLS-in-UDPを示すが、鍵とピアと方針は別途確立しなければならない。

信頼境界は、両端のIPアドレス、能力を示す設定またはシグナリング、許可された運用範囲、フィルター、輻輳管理、チェックサム方針、ラベル空間、認証・完全性保護からできている。6635はその境界の一部を読みやすくするが、境界そのものではない。

共有された標準史の中のRoss Callon

Ross CallonのIETF Datatrackerプロフィールには、RFC 3031とRFC 7510を含む8本のRFCが掲載されている。OSIアドレス割当て、IPv6移行、MPLS、事業者VPNへと続く技術的著作の記録である。

ただしRFC 7510には5人の著者がおり、IETFの合意文書でもある。RFC 3031にも3人の著者がいる。実装者、運用者、IANA、標準化コミュニティの判断を、一人の功績へ縮約してはならない。

人物記録が示すのは、より限定された連続性だ。RFC 3031はローカルなラベルの転送意味を整理し、RFC 7510はそのスタックをIP装置が分散できる外側の構造へ入れた。どちらも、フィールドの意味を必要以上に広げないことで機能する。

送信元ポートはエントロピーでよい。登録宛先ポートはペイロード種別でよい。ラベルはローカルな転送文脈でよい。小さな意味を守ることが、分散した装置同士の相互運用を可能にしている。

証拠の限界

公開資料から確認できるのは、RFC 7510の形式、適用制約、チェックサムとセキュリティの指針、IANAの登録、MPLSラベル関連規格、Ross Callonの共同著者記録である。現在の導入数、個別ベンダーのハッシュ方法、衝突が原因となった実在事故、Callonの現在の組織的権限は確認できない。

エントロピーを身元として扱うべきでないという結論は、仕様の明示的な意味と安全性の限界から導く編集上の分析であり、特定事件の報道ではない。外側のUDPエントロピーとラベルスタック内のEntropy Labelが交換可能だとも主張しない。

情報源