モバイル ネットワーク インスペクションの概要
次の項では、LTE などのモバイル ネットワークで使用されるプロトコルに対応するインスペクションについて説明します。インスペクションに加えて SCTP トラフィックで利用できるサービスは他にもあります。
GTP インスペクションの概要
GPRS トンネリング プロトコルは、General Packet Radio Service(GPRS)トラフィック用に GSM、UMTS および LTE ネットワークで使用されます。GTP は、トンネル制御および管理プロトコルを提供します。このプロトコルによるトンネルの作成、変更、および削除により、モバイル ステーションに GPRS ネットワーク アクセスが提供されます。GTP は、ユーザ データ パケットの伝送にもトンネリング メカニズムを使用します。
サービス プロバイダー ネットワークは、GTP を使用して、エンドポイント間の GPRS バックボーンを介してマルチプロトコル パケットをトンネリングします。GTPv0-1 では、GTP は gateway GPRS support node(GGSN)と serving GPRS support node(SGSN)間のシグナリングのために使用されます。GTPv2 では、シグナリングは Packet Data Network Gateway(PGW)と Serving Gateway(SGW)および他のエンドポイント間で行われます。GGSN/PGW は、GPRS 無線データ ネットワークと他のネットワークとの間のインターフェイスです。SGSN/SGW は、モビリティ、データ セッション管理、およびデータ圧縮を実行します。
ASA を使用して、不正なローミング パートナーに対する保護を行えます。デバイスをホームの GGSN/PGW エンドポイントと訪問した SGSN/SGW エンドポイント間に配置し、トラフィック上で GTP インスペクションを使用します。GTP インスペクションは、これらのエンドポイント間のトラフィックでのみ動作します。GTPv2 では、これは S5/S8 インターフェイスとして知られています。
GTP および関連する規格は、3GPP(第 3 世代パートナーシップ プロジェクト)によって定義されます。詳細については、http://www.3gpp.org を参照してください。
次に、GTP インスペクションに関する制限事項の一部を示します。
-
GTPv2 ピギーバック メッセージはサポートされていません。これらは常にドロップされます。
-
GTPv2 emergency UE attach は、IMSI(International Mobile Subscriber Identity)が含まれている場合にのみサポートされます。
-
GTP インスペクションは初期のデータは検査しません。つまり、セッション要求の作成直後かつセッション応答の作成前に PGW または SGW から送信されたデータのことです。
-
GTPv2 の場合、インスペクションは 3GPP 29.274 リリース 10 バージョン 13 までサポートしています。GTPv0/v1 の場合、3GPP 29.060 のリリース 9 までサポートされます。
-
GTP インスペクションは、セカンダリ PDP コンテキストへの SGSN 間ハンドオフをサポートしていません。インスペクションは、プライマリおよびセカンダリ両方の PDP コンテキストに対しハンドオフを実行する必要があります。
Stream Control Transmission Protocol(SCTP)インスペクションとアクセス制御
SCTP(Stream Control Transmission Protocol)は RFC 4960 で説明されています。プロトコルは IP 経由のテレフォニー シグナリング プロトコル SS7 をサポートしており、4G LTE モバイル ネットワーク アーキテクチャにおける複数のインターフェイス用の転送プロトコルでもあります。
SCTP は、TCP や UDP と同様、プロトコル スタックの IP の最上部で動作するトランスポート層プロトコルです。ただし、SCTP は、1 つ以上の送信元 IP アドレスまたは宛先 IP アドレス上の 2 つのエンド ノード間でアソシエーションと呼ばれる論理的な通信チャネルを作成します。これはマルチホーミングと呼ばれます。アソシエーションでは、各ノード(送信元と宛先)での IP アドレスのセットと、各ノードでのポートが定義されます。セット内の任意の IP アドレスは、複数の接続を形成するためにこのアソシエーションに関連付けられたデータ パケットの送信元または宛先 IP アドレスとして使用できます。各接続内では、メッセージを送信するために複数のストリームが存在する可能性があります。SCTP 内のストリームは、論理的なアプリケーション データ チャネルを表します。
次の図は、アソシエーションとそのストリームとの関係を示しています。
ASA を通過する SCTP トラフィックがある場合、SCTP ポートに基づいてアクセスを制御し、アプリケーション層のインスペクションを実行して、接続を有効にし、オプションでペイロード プロトコル ID でフィルタリングを行い、アプリケーションを選択的にドロップ、ログに記録、またはレート制限できます。
(注) |
各ノードは、最大 3 つの IP アドレスを持つことができます。上限である 3 を超えたアドレスは無視され、アソシエーションに含まれません。セカンダリ IP アドレスのピンホールは、自動的に開きます。これらを許可するアクセス制御ルールを記述する必要はありません。 |
次の項では、SCTP トラフィックで利用できるサービスについて詳しく説明します。
SCTP ステートフル インスペクション
TCP と同様、SCTP トラフィックは、正しく構造化されたトラフィックと RFC 4960 の限定的な適用についてレイヤ 4 で自動的に検査されます。次のプロトコル要素が検査され、適用されます。
-
チャンクのタイプ、フラグ、および長さ。
-
検証タグ。
-
送信元ポートと宛先ポート。アソシエーション リダイレクト攻撃を防ぐため。
-
IP アドレス。
SCTP ステートフル インスペクションは、アソシエーションの状態に基づいてパケットの受け入れまたは拒否を行います。
-
最初のアソシエーション確立のための 4 方向開閉シーケンスの検証。
-
アソシエーションおよびストリーム内の TSN の転送進捗状況の確認。
-
ハートビートの障害による中断チャンクを確認した場合のアソシエーションの終了。SCTP エンドポイントは、爆弾攻撃に応答して中断チャンクを送信する場合があります。
これらの強制チェックを行わない場合は、特定のトラフィック クラスの接続の設定(すべてのサービス) で説明されているように、特定のトラフィック クラスに対し SCTP ステート バイパスを設定できます。
SCTP アクセス制御
SCTP トラフィックのアクセス ルールを作成できます。これらのルールは TCP/UDP ポート ベースのルールと似ており、プロトコルとして単に sctp を使用し、ポート番号は SCTP ポートです。SCTP 用のサービス オブジェクトまたはグループを作成するか、またはポートを直接指定できます。次の項を参照してください。
SCTP NAT
SCTP アソシエーション確立メッセージのアドレスにスタティック ネットワーク オブジェクト NAT を適用できます。スタティック Twice NAT を設定できますが、SCTP アソシエーションの宛先部分のトポロジが不明であるため、これは推奨されません。ダイナミック NAT/PAT を使用することはできません。
SCTP 用の NAT は、SCTP アプリケーション レイヤのインスペクションではなく、SCTP ステートフル インスペクションによって決まります。したがって、SCTP ステート バイパスを設定している場合は、NAT トラフィックはできません。
SCTP アプリケーション レイヤのインスペクション
SCTP アプリケーション SCTP インスペクションとフィルタリングを有効にすることにより、アクセス ルールをさらに絞り込むことができます。ペイロード プロトコル ID(PPID)に基づいて、SCTP トラフィック クラスを選択的にドロップ、ログに記録、またはレート制限することができます。
PPID でフィルタリングする場合は、次の点に注意してください。
-
PPID はデータのかたまりの中にあり、特定のパケットは複数のデータ チャンクまたは 1 つの制御チャンクを持つことができます。パケットに 1 つの制御チャンクまたは複数のデータ チャンクが含まれている場合、割り当てられたアクションがドロップされてもパケットはドロップされません。
-
PPID フィルタリングを使用してパケットをドロップまたはレート制限する場合は、トランスミッタによりドロップされたパケットが再送されることに注意してください。レート制限が適用された PPID のパケットは再試行で通過する可能性がありますが、ドロップされた PPID のパケットは再びドロップされます。ネットワーク上のこのような反復的ドロップの最終成果を評価することができます。
SCTP に関する制限事項
SCTP サポートには次の制限事項が含まれます。
-
各ノードは、最大 3 つの IP アドレスを持つことができます。上限である 3 を超えたアドレスは無視され、アソシエーションに含まれません。セカンダリ IP アドレスのピンホールは、自動的に開きます。これらを許可するアクセス制御ルールを記述する必要はありません。
-
使用されないピンホールは、5 分後にタイムアウトします。
-
マルチホーム エンドポイントのデュアル スタック IPv4 および IPv6 アドレスはサポートされません。
-
ネットワーク オブジェクト スタティック NAT は、唯一サポートされているタイプの NAT です。また、NAT46 および NAT64 はサポートされません。
-
SCTP パケットのフラグメンテーションとリアセンブリは、Diameter、M3UA、および SCTP の PPID ベースのインスペクションで処理されたトラフィックにのみ実行されます。
-
SCTP で IP アドレスを動的に追加または削除するために使用される ASCONF チャンクは、サポートされません。
-
IP アドレスに解決できるホスト名を指定するために使用される、INIT および INIT-ACK SCTP メッセージ内のホスト名パラメータは、サポートされません。
-
ASA、またはネットワーク内の他の場所で設定されているかどうかにかかわらず、SCTP/M3UA は等コスト マルチパス ルーティング(ECMP)をサポートしません。ECMP を使用すると、復数のベスト パスを介してパケットを宛先にルーティングできます。ただし、単一の宛先への SCTP/M3UA パケット応答は、送出されたときと同じインターフェイスに戻る必要があります。応答が M3UA サーバから送信される可能性があるとしても、常に送出されたときと同じインターフェイスに戻る必要があります。この問題の症状として、SCTP INIT-ACK パケットがドロップされます。これは、show asp drop flow sctp-chunk-init-timeout カウンタで確認できます。
Flow drop: SCTP INIT timed out (not receiving INIT ACK)(sctp-chunk-init-timeout)
この問題が発生した場合は、M3UA サーバへのスタティック ルートを設定するか、またはポリシーベース ルーティングを設定して、INIT-ACK パケットが INIT パケットと同じインターフェイスを確実に通過するネットワーク設計を実装することで解決できます。
Diameter インスペクション
Diameter は、LTE(Long Term Evolution)および IMS(IP Multimedia Subsystem)用の EPS(Evolved Packet System)などの次世代モバイルと固定電気通信ネットワークで使用される認証、認可、およびアカウンティング(AAA)プロトコルです。RADIUS や TACACS がこれらのネットワークで Diameter に置き換えられます。
Diameter はトランスポート層として TCP および SCTP を使用し、TCP/TLS および SCTP/DTLS によって通信を保護します。また、オプションで、データ オブジェクトの暗号化も提供できます。Diameter の詳細については、RFC 6733 を参照してください。
Diameter アプリケーションは、課金のユーザ アクセス、サービス認証、QoS、およびレートの決定といったサービス管理タスクを実行します。Diameter アプリケーションは LTE アーキテクチャのさまざまなコントロール プレーン インターフェイスで使用されますが、ASA は、次のインターフェイスについてのみ、Diameter コマンド コードおよび属性値ペア(AVP)を検査します。
-
S6a:モビリティ マネージメント エンティティ(MME)- ホーム サブスクリプション サービス(HSS)
-
S9:PDN ゲートウェイ(PDG)- 3GPP AAA プロキシ/サーバ
-
Rx:ポリシー/課金ルール機能(PCRF) - コール セッション制御機能(CSCF)
Diameter インスペクションでは、Diameter エンドポイント用にピンホールを開いて通信を可能にします。このインスペクションは、3GPP バージョン 12 をサポートし、RFC 6733 に準拠しています。TCP/TLS(インスペクションをイネーブルにするときに TLS を指定する場合)および SCTP には使用できますが、SCTP/DTLS には使用できません。SCTP Diameter セッションにセキュリティを提供するには IPsec を使用します。
パケットや接続のドロップまたはロギングなどの特別なアクションを適用するために、オプションで、Diameter インスペクション ポリシー マップを使用し、アプリケーション ID、コマンド コード、および AVP に基づいてトラフィックをフィルタリングできます。新規に登録された Diameter アプリケーション用のカスタム AVP を作成できます。フィルタリングにより、ネットワークで許可するトラフィックを微調整できます。
(注) |
他のインターフェイス上で動作するアプリケーションに対する Diameter メッセージはデフォルトで許可され、渡されます。ただし、アプリケーション ID によってこれらのアプリケーションを破棄するための Diameter インスペクション ポリシー マップを設定できますが、これらのサポートされていないアプリケーションに対してコマンド コードまたは AVP に基づいてアクションを指定することはできません。 |
M3UA インスペクション
MTP3 User Adaptation(M3UA)は、SS7 Message Transfer Part 3(MTP3)レイヤと連動する IP ベース アプリケーション用の SS7 ネットワークへのゲートウェイを提供するクライアント/サーバ プロトコルです。M3UA により、IP ネットワーク上で SS7 ユーザ パート(ISUP など)を実行することが可能になります。M3UA は RFC 4666 で定義されています。
M3UA は SCTP をトランスポート層として使用します。SCTP ポート 2905 がデフォルト ポートです。
MTP3 レイヤは、ルーティングおよびノード アドレッシングなどのネットワーク機能を提供しますが、ノードの識別にポイント コードを使用します。M3UA 層は、発信ポイント コード(OPC)および宛先ポイント コード(DPC)を交換します。これは、IP が IP アドレスを使用してノードを識別する仕組みと似ています。
M3UA インスペクションは、限定されたプロトコル準拠を提供します。オプションで、厳密なアプリケーション サーバ プロセス(ASP)のステート チェックおよび選択されたメッセージの追加のメッセージの検証を実装できます。厳密な ASP のステート チェックが必要なのは、ステートフル フェールオーバーが必要な場合、またはクラスタ内での動作が必要な場合です。ただし、厳密な ASP のステート チェックは、上書きモードでのみ動作し、ロードシェアリングまたはブロードキャスト モードで実行している場合は動作しません(RFC 4666 より)。インスペクションは、エンドポイントごとに ASP が 1 つだけあると仮定します。
オプションで、ポイント コードまたはサービス インジケータ(SI)に基づいてアクセス ポリシーを適用できます。また、メッセージのクラスおよびタイプに基づいてレート制限を適用できます。
M3UA プロトコル準拠
M3UA インスペクションでは、次の限定されたプロトコルを強制できます。インスペクションは、要件を満たさないパケットをドロップしてログに記録します。
-
共通のメッセージ ヘッダー。インスペクションでは、共通ヘッダー内のすべてのフィールドを確認します。
-
バージョン 1 のみ。
-
メッセージの長さが正しく設定されている必要があります。
-
予約済みの値を使用したメッセージ タイプのクラスは許可されません。
-
メッセージ クラス内での無効なメッセージ ID は許可されません。
-
-
ペイロード データ メッセージ。
-
特定のタイプの 1 つのパラメータのみが許可されます。
-
SCTP ストリーム 0 でのデータ メッセージは許可されません。
-
-
[Affected Point Code] フィールドは次のメッセージに含まれている必要があり、含まれていない場合、メッセージはドロップされます。利用可能な宛先(DAVA)、利用できない宛先(DUNA)、宛先の状態監査(DAUD)、シグナリング輻輳(SCON)、利用できない宛先ユーザ部(DUPU)、制限された宛先(DRST)。
-
次のメッセージについてメッセージ タグの検証を有効にすると、特定のフィールドの内容が確認および検証されます。検証で合格しなかったメッセージはドロップされます。
-
利用できない宛先ユーザ部(DUPU):ユーザ/理由フィールドが存在し、有効な理由およびユーザ コードのみが含まれている必要があります。
-
エラー:すべての必須フィールドが存在し、許可された値のみが含まれている必要があります。各エラー メッセージには、そのエラー コードの必須フィールドが含まれている必要があります。
-
通知:ステータス タイプおよびステータス情報フィールドには、許可された値のみが含まれている必要があります。
-
-
アプリケーション サーバ プロセス(ASP)の厳密な状態検証を有効にすると、システムは M3UA セッションの ASP の状態を維持し、検証結果に基づいて ASP メッセージを許可またはドロップします。ASP の厳密な状態検証を無効にすると、すべての ASP メッセージが検査されずに転送されます。
M3UA インスペクションの制限事項
次に、M3UA インスペクションに関する制限事項の一部を示します。
-
NAT は、M3UA データに埋め込まれている IP アドレスではサポートされません。
-
M3UA の厳密なアプリケーション サーバ プロセス(ASP)状態の確認は、SCTP ステートフル インスペクションと依存性があります。SCTP ステート バイパスと M3UA の厳密な ASP 確認は、同じトラフィック上で実行しないでください。
-
厳密な ASP のステート チェックが必要なのは、ステートフル フェールオーバーが必要な場合、またはクラスタ内での動作が必要な場合です。ただし、厳密な ASP のステート チェックは、上書きモードでのみ動作し、ロードシェアリングまたはブロードキャスト モードで実行している場合は動作しません(RFC 4666 より)。インスペクションは、エンドポイントごとに ASP が 1 つだけあると仮定します。
RADIUS アカウンティング インスペクションの概要
RADIUS アカウンティング インスペクションの目的は、RADIUS サーバを使用した GPRS ネットワークの過剰請求攻撃を防ぐことです。RADIUS アカウンティング インスペクションを実行するには、キャリア ライセンスは必要ありませんが、GTP インスペクションを実行し、GPRS セットアップをセットアップしない限り、意味がありません。
GPRS ネットワークの過剰請求攻撃は、コンシューマに対して、利用していないサービスの請求を行います。この場合、悪意のある攻撃者は、サーバへの接続をセットアップし、SGSN から IP アドレスを取得します。攻撃者がコールを終了しても、攻撃者のサーバはパケットの送信を続けます。このパケットは GGSN によってドロップされますが、サーバからの接続はアクティブなままです。攻撃者に割り当てられていた IP アドレスが解放され、正規ユーザに再割り当てされるので、正規ユーザは、攻撃者が利用するサービスの分まで請求されることになります。
RADIUS アカウンティング インスペクションは、GGSN へのトラフィックが正規のものかどうかを確認することにより、このような攻撃を防ぎます。RADIUS アカウンティングの機能を正しく設定しておくと、ASA は、RADIUS アカウンティング要求の開始メッセージと終了メッセージに含まれる Framed IP 属性との照合結果に基づいて接続を切断します。終了メッセージの Framed IP 属性の IP アドレスが一致している場合、ASA は、一致する IP アドレスを持つ送信元との接続をすべて検索します。
ASA でメッセージを検証できるように、RADIUS サーバとの事前共有秘密キーを設定することもできます。共有秘密が設定されていない場合、ASA は、ソース IP アドレスが RADIUS メッセージを送信できるよう設定された IP アドレスであるということだけをチェックします。
(注) |
GPRS をイネーブルにして RADIUS アカウンティング インスペクションを使用すると、ASA はアカウンティング要求の STOP メッセージで 3GPP-Session-Stop-Indicator をチェックして、セカンダリ PDP コンテキストを正しく処理します。具体的には、ASA では、アカウンティング要求の終了メッセージがユーザ セッションおよび関連するすべての接続を終了する前に、メッセージに 3GPP-SGSN-Address 属性が含まれる必要があります。一部のサードパーティの GGSN は、この属性をデフォルトでは送信しない場合があります。 |