Diameter は、コンピュータ ネットワークの認証、承認、アカウンティング (AAA)プロトコルです。以前のRADIUSプロトコルから進化したものです。インターネット プロトコル スイートのアプリケーション層プロトコルに属します。
Diameter アプリケーションは、拡張認証プロトコル(EAP)で使用するためのものなど、新しいコマンドや属性を追加することで基本プロトコルを拡張します。
RADIUSとの比較
この名前は言葉遊びで、前身であるRADIUSプロトコルに由来しています (直径は半径の 2 倍です)。Diameter は直接下位互換性はありませんが、RADIUS のアップグレード パスを提供します。Diameter が提供するが RADIUS にはない主な機能は次のとおりです。
- SCTPのサポート
- 能力交渉
- アプリケーション層の確認応答。Diameter はフェイルオーバー方法とステートマシンを定義します (RFC 3539)
- 拡張性; 新しいコマンドを定義できる
- 32ビット境界に揃える
また、RADIUS と同様に、ローカル AAA とローミング AAA の両方の状況で動作するように設計されている。UDP を使用する RADIUS とは異なり、TCP または SCTP を使用する。RADIUS とは異なり、暗号化は含まれないが、トランスポート レベルのセキュリティ (IPSEC または TLS) によって保護できる。AV 識別子の基本サイズは 32 ビットであるのに対し、RADIUS は基本 AV 識別子のサイズとして 8 ビットを使用する。RADIUS と同様に、ステートレス モードとステートフル モードの両方をサポートする。RADIUS と同様に、アプリケーション レイヤーの確認応答をサポートし、フェイルオーバーを定義する。Diameter は、3GPP 標準で定義されているさまざまなインターフェイスに使用され、各インターフェイスでは通常、新しいコマンドと属性が定義されます。
アプリケーション
Diameterアプリケーションはソフトウェア アプリケーションではなく、 RFC 6733 (RFC 3588 は廃止) および RFC 7075 で定義されている Diameter ベース プロトコルに基づくプロトコルです。各アプリケーションはアプリケーション識別子によって定義され、新しいコマンド コードや新しい必須 AVP (属性値ペア) を追加できます。新しいオプションの AVP を追加しても、新しいアプリケーションは必要ありません。
Diameter アプリケーションの例:
- Diameter モバイル IPv4 アプリケーション (MobileIP、RFC 4004)
- Diameter ネットワーク アクセス サーバー アプリケーション (NASREQ、RFC 7155)(廃止: RFC 4005)
- Diameter 拡張認証プロトコル アプリケーション (RFC 4072)
- Diameter クレジット管理アプリケーション (DCCA、RFC 8506])(廃止: RFC 4006)
- Diameter セッション開始プロトコル アプリケーション (RFC 4740)
- 3GPP IPマルチメディアサブシステムのさまざまなアプリケーション
(汎用ブートストラップアーキテクチャ):ブートストラップサーバー機能
歴史
Diameter プロトコルは、RADIUS の制限を克服できる認証、認可、アカウンティング ( AAA ) のフレームワークを提供するために、1998 年に Pat R. Calhoun、Glen Zorn、Ping Pan によって最初に開発されました。RADIUS には、信頼性、スケーラビリティ、セキュリティ、柔軟性に関する問題がありました。RADIUS は、リモート アクセス、IP モビリティ、ポリシー制御を効果的に処理できません。Diameter プロトコルは、クライアントがポリシー、AAA、およびリソース制御を実行するために使用するポリシー プロトコルを定義します。これにより、単一のサーバーで多くのサービスのポリシーを処理できます。[1]
RADIUSと同様に、DiameterはAAA機能を提供しますが、UDPではなくTCPとSCTPを使用するため、通信の問題の検出と処理はこれらのプロトコルに委任されます。Diameterプロトコルは、3rd Generation Partnership Project(3GPP)IPマルチメディアサブシステム(IMS)の開発によってさらに強化されています。S6a、S6b、Gx、Gy、Sy、Rx、Cx、Dh、Dx、Rf、Ro、Sh、およびZhインターフェイスは、Diameterアプリケーションによってサポートされています。[2] 拡張機能を使用することで、プロトコルはプロキシ、ブローカー、強力なセキュリティ、モバイルIP、ネットワークアクセスサーバー(NASREQ)、アカウンティング、およびリソース管理をサポートするように拡張可能になるように設計されました。
プロトコルの説明
Diameter 基本プロトコルは RFC 6733 (廃止: RFC 3588 および RFC 5719) で定義され、 AAA プロトコルの最小要件を定義します。Diameter アプリケーションは、新しいコマンド、属性、またはその両方を追加することで基本プロトコルを拡張できます。Diameter のセキュリティはIPsecまたはTLSによって提供されます。RFC 6733 のセクション 11.4 に記載されているように、IANA はDiameter にTCPおよびSCTPポート番号 3868 を割り当てています。
パケットフォーマット
パケットは、Diameter ヘッダーと、Diameter メッセージに関連する情報をカプセル化するための可変数の属性値ペア (AVP) で構成されます。
バージョン
このフィールドは、Diameter Base Protocolのバージョンを示します。2014年現在、サポートされている値は1のみです。[3]
メッセージの長さ
メッセージ長フィールドは、ヘッダー フィールドとパディングされた AVP を含む Diameter メッセージの長さをバイト単位で示します。
コマンドフラグ
「R」(リクエスト)ビット – 設定されている場合、メッセージはリクエストです。クリアされている場合、メッセージは応答です。
「P」(プロキシ可能)ビット – 設定されている場合、メッセージはプロキシ、リレー、またはリダイレクトされる可能性があります。クリアされている場合、メッセージはローカルで処理される必要があります。
「E」(エラー)ビット – 設定されている場合、メッセージにはプロトコル エラーが含まれており、メッセージはこのコマンドで説明されている CCF に準拠しません。「E」ビットが設定されたメッセージは、通常、エラー メッセージと呼ばれます。このビットは、要求メッセージでは設定しないでください。
「T」(再送信の可能性があるメッセージ)ビット – このフラグは、リンク フェイルオーバー手順の後に設定され、重複した要求の削除に役立ちます。リンク障害による重複の可能性を示すため、まだ確認されていない要求を再送信するときに設定されます。
コマンド
各コマンドの要求/応答ペアにはコマンド コードが割り当てられます。要求か応答かは、ヘッダーのコマンド フラグ フィールドの「R」ビットによって識別されます。
値 0 ~ 255 は、RADIUS の下位互換性のために予約されています。値 256 ~ 16777213 は、IANAによって割り当てられた永続的な標準コマンド用です。値 16777214 と 16777215 (16 進数 0xFFFFFE と 0xFFFFFF) は、実験およびテストの目的で予約されています。
コマンド コードは、特定のメッセージに対して実行されるアクションを決定するために使用されます。プロトコル (ベースおよびアプリケーション) で定義されている一般的な Diameter コマンドには、次のものがあります。
アプリケーションID
アプリケーション ID は、メッセージがどの Diameter アプリケーションに適用可能かを識別するために使用されます。アプリケーションは、認証アプリケーション、アカウンティング アプリケーション、またはベンダー固有のアプリケーションです。
特定の Diameter 拡張に準拠する Diameter エージェントは、Capabilities-Exchange-Request (CER) コマンドと Capabilities-Exchange-Answer (CEA) コマンドの Auth-Application-ID 属性に特定の値を含めることで、そのサポートを公表します。
ヘッダーのアプリケーションIDフィールドの値は、メッセージに含まれる関連するアプリケーションID AVPと同じです。たとえば、Diameterクレジット制御アプリケーションのクレジット制御要求(CCR)コマンドとクレジット制御応答(CCA)コマンドのアプリケーションIDとAuth-Application-ID属性の値は4です。[4]
ホップバイホップ識別子
ホップバイホップ識別子は、要求内の同じ値が応答で使用されるため、要求と応答を一致させるために使用される符号なし 32 ビット整数フィールド (ネットワーク バイト順) です。
Diameter プロトコルでは、リレー エージェントとプロキシ エージェントがトランザクション状態を維持する必要があります。このトランザクション状態は、フェイルオーバーの目的に使用されます。トランザクション状態とは、リクエストを転送すると、そのホップバイホップ識別子が保存されることを意味します。このフィールドはローカルで一意の識別子に置き換えられ、対応する応答が受信されると元の値に復元されます。リクエストの状態は、応答を受信すると解放されます。受信した応答が既知のホップバイホップ識別子と一致しない場合、Diameter エージェントは無視します。
エージェントをリダイレクトする場合、Diameter エージェントが応答メッセージで応答すると、ホップバイホップ識別子がヘッダーに保持されます。
エンドツーエンド識別子
エンドツーエンド識別子は、オリジンホスト AVP の組み合わせとともに重複メッセージを検出するために使用される、符号なし 32 ビット整数フィールド (ネットワーク バイト順) です。
リクエストを作成すると、エンドツーエンド識別子はローカルで一意の値に設定されます。エンドツーエンド識別子はいかなる種類の Diameter エージェントによっても変更されず、対応するリクエストの同じ値が応答で使用されます。
属性値ペア (AVP)
簡単に言うと、AVP フラグの「V」ビットはベンダー固有、「M」ビットは必須、「P」ビットは保護を意味します。
ベンダー固有ビットとして知られる「V 」ビットは、オプションのベンダー IDフィールドが AVP ヘッダーに存在するかどうかを示します。設定されている場合、AVP コードは特定のベンダー コード アドレス空間に属します。
必須ビットと呼ばれる「M」ビットは、AVP のサポートが必要かどうかを示します。「M」ビットが設定された AVP が Diameter クライアント、サーバー、プロキシ、または変換エージェントによって受信され、AVP またはその値が認識されない場合、メッセージは拒否される必要があります。Diameter リレー エージェントとリダイレクト エージェントは、認識されない AVP を含むメッセージを拒否して はなりません。
「P」ビットは、エンドツーエンドのセキュリティのために暗号化が必要であることを示します。
ステートマシン
RFC 3588 は、ピア間の接続を維持し、メッセージを処理するためのコア ステート マシンを定義します。これは基本的なプロトコル機能の一部であり、すべてのスタックがこれをサポートし、接続関連の操作を抽象化する必要があります。
-
ピア ステート マシン パート 1
-
ピア ステート マシン パート 2
さらに、アプリケーション固有のステート マシンは、後から、またはより高度な抽象化レイヤーで導入できます。RFC 3588 では、認証およびアカウンティング ステート マシンが定義されています。
-
Diameter 認証ステートマシン (クライアント)
-
Diameter 認証ステートマシン (サーバー)
-
Diameter アカウンティング ステート マシン (クライアント)
-
Diameter アカウンティング ステート マシン (サーバー)
メッセージフロー

2 つの Diameter ピア間の通信は、トランスポート接続 ( TCPまたはSCTP ) の確立から始まります。次に、イニシエーターは Capabilities-Exchange-Request (CER) を他のピアに送信し、そのピアは Capabilities-Exchange-Answer (CEA) で応答します。RFC3588 準拠のピアの場合、TLS (トランスポート層セキュリティ) はオプションでネゴシエートできます。RFC6733 準拠のピアの場合、TLS ネゴシエーションは CER/CEA の前にオプションで発生することがあります。
これで、接続はアプリケーション メッセージの交換の準備が整います。
一定時間メッセージが交換されていない場合、どちらかの側が Device-Watchdog-Request (DWR) を送信し、もう一方のピアは Device-Watchdog-Answer で応答する必要があります。
どちらの側も Disconnect-Peer-Request (DPR) を送信して通信を終了することができ、もう一方のピアは Disconnect-Peer-Answer で応答する必要があります。その後、トランスポート接続を切断できます。
RFC
Diameter プロトコルは現在、次のIETF RFC で定義されています。廃止された RFC は取り消し線で示されます。
参照
参考文献
- ^ Pat R. Calhoun、Glen Zorn、Ping Pan (2001 年 2 月)。「DIAMETER Framework Document」。IETFデータトラッカー。IETF。2009年4 月 30 日閲覧。
{{cite news}}: CS1 maint: 複数の名前: 著者リスト (リンク) - ^ Naman Mehta (2009 年 3 月 20 日)。「Diameter プロトコルの概要 - Diameter プロトコルとは?」Sun Microsystems。2011年 7 月 4 日時点のオリジナルよりアーカイブ。2009年4 月 30 日閲覧。
- ^ Arkko, J.; Loughney, J. (2012). Fajardo, V; Zorn, G (編). 「RFC 6733 - Diameter Base Protocol」.提案標準. 標準化過程. doi : 10.17487/RFC6733 . ISSN 2070-1721 . 2014年10月12日閲覧。
- ^ Hakala, H.; Mattila, L.; Stura, M.; Loughney, J. (2005). 「RFC 4006 - Diameter Credit-Control アプリケーション」.提案された標準。標準化過程。doi : 10.17487/RFC4006。
外部リンク
- Diameter の紹介 - 次世代 AAA プロトコルを入手する
- RADIUS と DIAMETER の違いを説明した Cisco のページ
- Diameter: 次世代の AAA プロトコル Håkan Ventura による Diameter に関する論文
- Diameter ゲートウェイ、Diameter シグナリング コントローラ、および Diameter スタックのベンダーを一覧表示するリファレンス ページ
