8.1. SR-MPLS

8.1. SR-MPLS

MPLS データプレーンに適用される場合, SR は新しい動作を導入せず, MPLS データプレーンの動作方法も変更しません。したがって, セキュリティの観点から, この文書は MPLS データプレーンに追加のメカニズムを定義しません。

SR は単一のセグメント (Binding SID, バインディングセグメント識別子) を使用してソースルーティングパスを表現できます。明示的なルーティング機能も提供する RSVP-TE と比較して, 提供される情報の観点から根本的な違いはありません。RSVP-TE と Segment Routing (セグメントルーティング) の両方が単一のセグメントを使用してソースルーティングパスを表現できます。

パスが単一のラベルで表現される場合, RSVP-TE [RFC3209] と SR の間でメタデータの構文は同等です。

ソースルーティングパスがセグメントリストで表現される場合, セグメントリストとして表現されたパケットが従わなければならないソースルーティングパスで構成される追加のメタデータがパケットに追加されます。

パスがラベルスタックで表現される場合, ラベルの意味 (つまり, 転送等価クラス, Forwarding Equivalence Class) にアクセスできれば, 明示的なパスの知識を持つことができます。MPLS データプレーンでは, データプレーンの変更が不要なため, 機能に根本的な変更はありません。しかし, ラベルスタッキング (label stacking) の発生は増加します。

SR ドメイン境界ルータは, 信頼されたドメイン内のセグメントに関連付けられたラベルを宛先とする外部トラフィックをフィルタリングしなければなりません。これには, 信頼されたドメインの SRGB 内のラベル, 特定の境界ルータの SRLB 内のラベル, およびこれらのブロック外のラベルが含まれます。外部トラフィックとは, 信頼ドメイン外のノードに接続されたインターフェースから受信したトラフィックです。

ネットワーク保護の観点から, パケットにラベルスタックを課すノードはそうすることを許可されていると仮定される信頼モデルがあります。これは最短パスルーティングを提供する通常の IP と比較して大きな変更ですが, RSVP-TE のような明示的なルーティング機能を提供する既存の技術と比較して根本的に異なるものではありません。デフォルトでは, 明示的なルーティング情報は管理ドメインの境界を通じて漏洩してはなりません。さまざまなプロトコルで定義されている Segment Routing 拡張は, 暗号化, 認証, フィルタリングなど, これらのプロトコルのセキュリティメカニズムを活用します。

一般的なケースでは, セグメントルーティング対応ルータは, ラベルが信頼できるソースによって事前にアドバタイズされている場合にのみラベルを受け入れてインストールします。受信した情報は, 認証とセキュリティメカニズムを提供する既存のコントロールプレーンプロトコルを使用して検証されます。Segment Routing は既存のコントロールプレーンプロトコルに追加のセキュリティメカニズムを定義しません。

SR はソースとソースルーティングパスの中間点との間のシグナリングを導入しません。SR では, ソースルーティングパスは IP コントロールプレーンで事前にアドバタイズされた SID を使用して計算されます。したがって, SR ドメインの境界での SID のフィルタリングと制御されたアドバタイズに加えて, データプレーンでのフィルタリングも必要です。フィルタリングは SR ドメインの境界にある転送プレーンで実行しなければならず, 複数のラベル/指示を調べる必要がある場合があります。

MPLS データプレーンでは, 既存の MPLS アーキテクチャが複数のラベルをスタッキングすることによってこのようなソースルーティングをすでに許可しているため, 新しい要件はありません。また, セキュリティ保護のために, [RFC4381] と [RFC5920] はすでに信頼境界での MPLS パケットのフィルタリングを要求しています。