第4回 資料編：プロトコル詳解
Diameterの通信手順
Diameterの通信の手順は次のようになります。
http://itpro.nikkeibp.co.jp/article/COLUMN/20080827/313529/?ST=network
1.通信相手のリストを作る
通信相手は，あらかじめ手動で設定しておく方法のほかに，DNSに問い合わせるというような動的な方法も定義されています。ただし動的な方法は必須ではないので，実装されていない可能性もあります。
手動で設定されたものを参照する
サービス・ロケーション・プロトコル（SLPv2）を使う
DNSのNAPTR（The Naming Authority Pointer）クエリを実行する
DNSのサービス・ロケータ（SRV）クエリを実行する
2.通信相手とのコネクションの作成を開始する
通信する可能性のある通信相手の全てに対してコネクションを作成しておくことは，資源の有効利用を考えると合理的ではありません。最小構成として，同じレルム（領域）に対して，プライマリとセカンダリの二つの通信相手との間にコネクションを作っておくべきとされています。もちろん，必要に応じてコネクションを追加してもかまいません。複数作成したコネクションは，通常はプライマリに送信していて，フェイルオーバー時には，セカンダリに送信するといったような使い方をします。また，二つ以上のコネクションに負荷分散するような実装もあり得ます。
※「セッション」と「コネクション」
セッションというのは，アプリケーション層の概念で，クライアントとサーバ間のエンド・トゥ・エンドで確立されるものです。セッションは，エンドで処理され，Session ID AVPによって，一意に認識されます。一方コネクションというのは，トランスポート層の概念でメッセージを送受信する二つのピアの間で確立されます。
※「レルム」と「コンソーシアム」
レルムとは，あるサービスを提供する主体のことです。企業やプロバイダがその単位となります。例えば，空港で複数のインターネット接続事業者（ISP）のアカウントで接続できる公衆無線LANサービスを使うときに，ユーザーIDとして電子メール形式の「aaa@hoge.ne.jp」のようなIDを使います。公衆無線LANの回線を提供している会社は，「hoge.ne.jp」を見て，どの認証サーバーに問い合わせをすればいいかを知ります。このhoge.ne.jpを提供する会社がレルムとなります。
一方，コンソーシアムはレルムが集まって，ある一つのサービスを提供する場合の括りです。例えば，先ほどのような公衆無線LANサービスは複数のISPで使えますから，この無線LANサービス自体がコンソーシアムと考えます。
3.通信相手と交渉する
コネクションを発行したらすぐに，識別情報や，機能情報（プロトコル・バージョンやサポートするDiameterアプリケーション，セキュリティ・メカニズムなど）を通信相手と交換する必要があります。この交渉は，機能交換メッセージ（Capabilities-Exchange-Request/Answer）をやり取りして行うものです。交渉が決裂すると，切断などの処理を実施します。例えば，通信相手との間のコネクションにおいて共通のセキュリティ・メカニズムをサポートしていないことが判明した場合には交渉が決裂します。これらのメッセージは，コネクションについてのものなので，ピア・トゥ・ピアでやり取りします。プロキシ，リレー，リダイレクトをすることはありません。この交渉が成功するとすぐに，セキュリティ・メカニズムの処理に入ります。TLSを使用する場合ならば，TLSハンドシェイクを開始します。
4.コネクションの管理
こうして用意したコネクションは，交渉を行って判明した機能情報，コネクションの状態を管理しておいて，要求メッセージや，応答メッセージを受信し，転送する必要があるとき，この情報を参照してどこに送信していいかを決めます。管理は，『ピア・テーブル』に情報を蓄積して行います。
※通信相手を「ピア」と呼びます。ピアというのは，対等の立場でネットワークコネクションするものを示します。
ピア・テーブル
ホスト識別子 Origin-Host AVPから取得した値
コネクションの状態 コネクションの状態
Open（コネクションが開始された状態）
Closing（コネクションの切断処理中） など
静的/動的 コネクション相手をどのように決めたか
失効時間 動的に決めたコネクション相手の場合，一定時間で更新/失効させる
TLS使用可否 コネクションにTLSが使用されるかどうか
ピア・テーブルの情報はコネクションが作成された後も機能交換メッセージをやり取りすることにより，常に最新の状態となるように工夫されています。具体的には，状態機械と呼ばれる仕組みで成り立っています。状態機械というのは，現在の状態と，次の状態，次の状態に移るきっかけとなる事象，次の状態に移るときにする動作を様々なケースについて設定しておくものです。必要なケースは全てRFC文書に規定されています。一つの例として，現在の状態が，「Open（コネクションがつながっている状態）」であるときに，システムが再起動されるという事象が発生した場合をあげると，状態を「Closing（コネクションの切断処理中）」に変更し，コネクション相手にこの事象を通知するコマンドのDisconnect-Peer-Requestメッセージを送る，といった具合です。
5.受信したメッセージを処理する
以下の条件のいずれかに当てはまる場合は，ローカル・ホストでメッセージを処理します。
ローカル・ホストが要求の最終的なあて先である
Destination-Host AVPの値にローカル・ホストの識別子が指定されている
ローカルで処理すべきと設定した宛先レルムである
Destination-Realm AVPの値がレルム・ベース・ルーティング・テーブルに，ローカルで処理すべきレルムとして登録されている
宛先が判断できない
Destination-Host AVPも，Destination-Realm AVPも存在しない
処理後，Result-Code AVPに処理結果を指定して，返送します。処理結果は，その名のとおり，コードで管理されていて，以下のような体系をとります。
Result-Codeの定義
1xxx Informational 使用中の認証方式にて複数回のやり取りを要求する場合
2xxx Success 要求が成功し，完了した場合
3xxx Protocol Errors サポートしていないアプリケーションである場合，サポートしていないコマンドである場合など
4xxx Transient Failures 無効なパスワードである，
アカウンティングにおいて，領域の確保ができない場合など
5xxx Permanent Failure 必須のAVPをサポートしていない場合，
認識できないセッションIDを含んでいる場合など
6.受信したメッセージを転送する
ローカル・ホストで処理するケースに当てはまらない場合は，レルム・ベース・ルーティング・テーブルを参照して，転送方法（ロケーション・アクション）を割り出して転送します。転送を実行するのは，次のエージェントです。
レルム・ベース・テーブル
レルム名 テーブル検索の際のプライマリ・キーとなります
アプリケーション識別子 テーブル検索の際のセカンダリ・キーという意味です。アプリケーションのタイプに依存して違うあて先を持てるようにするために存在します。
ロケーション・アクション メッセージがローカルで処理されるべきか，ネクスト・ホップ・サーバへリレーされるべきか，送信者にリダイレクトされるべきかを示すものです。 【LOCAL】
転送せず，ローカルで処理する
【RELAY】
ルーティング関連以外のAVPに変更を加えずに次のサーバへ転送する。以下のフィールドはリレー・エージェントの処理対象
【PROXY】
自身のポリシーにてAVPに変更を加え，次のサーバへ転送する。以下のフィールドはプロキシ・エージェントの処理対象
【REDIRECT】
ホーム・サーバの識別子を通知する。以下のフィールドはリダイレクト・エージェントの処理対象
サーバ識別子 メッセージがルーティングされるべき一つもしくは，複数のサーバーに対する識別子です。
静的／動的，失効時間 ピア・テーブルのものと似たような意味を持ちます。
【リレー・エージェント】（図5）
例えば，共通の地理的領域にある複数のネットワーク・アクセス・サーバーからの要求を集約などに使います。サーバー側で，ネットワーク・アクセス・サーバーの追加や削除などの作業をしなくてもよくなり，クライアント側では，ほかのレルムに存在するDiameterサーバーと通信するために必要なセキュリティ設定が不要になるメリットがあります。アプリケーション・レベルの処理を行わないので，どのアプリケーションについてもリレーすることができます。
図5●リレー・エージェントの動作
[画像のクリックで拡大表示]
【プロキシ・エージェント】
リレー・エージェントと異なるのは，Diameterのメッセージを変更することが可能な点です。具体的には，メッセージの変更によって，資源活用の実施や流入制御の提供，プロビジョニングのために必要なポリシーの施行に使います。利用シーンとしては，呼制御センターや，アクセスISPなどの外部委託によってアクセス・サービスを供給するときに使うことが想定されます。使用中のポートの数や種類を監視し，ポリシーに沿った流入の決断や割当を行います。
【リダイレクト・エージェント】（図6）
Diameterのルーティング設定を中央集権的実施するときに便利です。例えば，レルム間で全てのメッセージをリレーするような負荷は望まないけれども，コンソーシアムのメンバー全員にサービスを提供したいような場合です。あるメンバーのネットワーク構成が変更になったからと言って，ほかのメンバーにおいて，ルーティングの設定の変更などを行う必要がなくなります。リダイレクト・エージェントは，メッセージのリレーは行わず，直接通信するのに必要な情報を含む回答のみを返します。
図6●リダイレクト・エージェントの動作
[画像のクリックで拡大表示]
【トランスレーション・エージェント】（図7）
トランスレーション・エージェントは，二つのプロトコルの間の変換をします。例えば，RADIUSとDiameter，TACAS+とDiameterなどです。ゆっくりシステムの移行を行うようなときに，Diameterインフラと通信するための集約サーバとして利用されるようです。
図7●トランスレーション・エージェントの動作
[画像のクリックで拡大表示]
Diameterのフレーム構造
Diameterのフレームは，（図8）のようになります。大きく分けるとヘッダーとAVPに分かれます。
図8●Diameterのフレーム構造
[画像のクリックで拡大表示]
1．ヘッダーの構造
【バージョン】（1オクテット）
Diameterプロトコルのバージョン情報を指定します。現在は，1です。
【メッセージ長】（3オクテット）
ヘッダ（20オクテット）とAVP（4オクテット×AVPの数）の長さの合計を指定します。
【コマンド・フラグ】（1オクテット）
コマンドとは，そのメッセージを受け取ったDiameterノードがどのように動作すべきかを指示するものです。コマンドは，数値で表されるコードによって識別するもので，RFC文書にコードごとに規定されています。ひとつのコマンドに関する要求と応答では，コードも同一とします。要求か応答かの判断は，このコマンド・フラグで行います。フラグは現在4種類あります。
R P E T r R r R
※rは，現在は未使用で，将来使用するために予約されていることを表します。
・Rフラグ
リクエストフラグ。メッセージが要求なのか，応答なのかを指定します。
・Pフラグ
転送可能フラグ。プロキシ，リレー，リダイレクトなどの転送処理が可能か，ローカルで処理されるべきかを指定します。
・Eフラグ
エラーフラグ。メッセージ・フォーマット・エラーを含むかどうかを指定します。
・Tフラグ
再送フラグ。メッセージが再送可能かどうかを指定します。
【コマンド・コード】（3オクテット）
処理する内容を示す識別子です。基本プロトコルで定義されているコマンド・コードのほかに，Diameterアプリケーションごとに定義されているコマンド・コードがあります。
基本プロトコルのコマンド・コード
コマンド名称 コード
Capabirities-Exchange Request/Response 257
Re-Auth-Request/Answer 258
Accounting-Request/Answer 271
Abort-Session-Request/Answer 274
Session-Termination Request/Answer 275
Device-Watchdog-Request/Answer 280
Disconnect-Peer Request/Answer 282
Diameterアプリケーションのコマンド・コード
コマンド名称 コード
AA-Request/Answer 265
モバイルIPv4アプリケーションのコマンド・コード
コマンド名称 コード
AA-Mobile-Node-Request 260
Home-Agent-MIP-Request 262
【アプリケーション識別子】（4オクテット）
メッセージを送出しているDiameterアプリケーションの識別子を指定します。このメッセージが，どのDiameterアプリケーションのものなのかがわかります。
0 Diameter共通メッセージ（基本プロトコル）
1 NASアプリケーション
2 モバイルIPv4アプリケーション
3 Diameterアカウンティング（基本プロトコル）
【ホップ・バイ・ホップ（hop-by-hop）識別子】（4オクテット）
ホップ間で要求と応答を紐付けるものです。要求の転送時に，各ホップで設定します。いつでもユニーク性が求められます。応答では，必ず対になる要求と同じ識別子を指定します。
【エンド・トゥ・エンド（end-to-end）識別子】（4オクテット）
メッセージの重複検知に利用され余す。最低でも，４分間は，ローカルでユニークである必要があります。重複検知には，この識別子のほかに，Origin-host AVPを利用します。
2．AVPの構造
AVP自体も，ヘッダーとデータ（アトリビュート・データ）に分けて考えられます。
AVPコード（32ビット）
フラグ（8ビット） AVP長（24ビット）
ベンダー識別子（32ビット）※オプション
アトリビュート・データ
ヘッダーに含まれるのは，AVPコード，AVPフラグ，AVP長，ベンダー識別子の4つの項目です。ベンダー識別子はオプションなので，指定しない場合もあります。
【AVPコード】
AVPコードと，ベンダー識別子を用いて，アトリビュートを一意に認識できます。1-255は，RADIUSとの後方互換性の確保（このとき，ベンダー識別子は指定しない）用に予約されているため，256以降がDiameterで使われることになります。なお，AVPコードと関連付いて送られるデータは，最後尾のアトリビュート・データに格納されます。アトリビュート・データに格納するデータの書式（データ・タイプ）は，規格でAVPコードに関連付けられています。データ書式の詳細な構造については，アトリビュート・データの項をご覧ください。
基本プロトコルのＡＶＰコード
アトリビュート名 コード データ・タイプ
Acct-Interim-Interval 85 Unsigned32
Accounting-Realtime-Required 483 Enumerated
Acct-Multi-Session-Id 50 UTF8String
Accounting-Record-Number 485 Unsigned32
Accounting-Record-Type 480 Enumerated
Accounting-Session-Id 44 OctetString
Accounting-Sub-Session-Id 287 Unsigned64
Acct-Application-Id 259 Unsigned32
Auth-Application-Id 258 Unsigned32
Auth-Request-Type 274 Enumerated
Authorization-Lifetime 291 Unsigned32
Auth-Grace-Period 276 Unsigned32
Auth-Session-State 277 Enumerated
Re-Auth-Request-Type 285 Enumerated
Class 25 OctetString
Destination-Host 293 DiamIdent
Destination-Realm 283 DiamIdent
Disconnect-Cause 273 Enumerated
E2E-Sequence 300 Grouped
Error-Message 281 UTF8String
Error-Reporting-Host 294 DiamIdent
Event-Timestamp 55 Time
Experimental-Result 297 Grouped
Experimental-Result-Code 298 Unsigned32
Failed-AVP 279 Grouped
Firmware-Revision 267 Unsigned32
Host-IP-Address 257 Address
Inband-Security-Id 299 Unsigned32
Multi-Round-Time-Out 272 Unsigned32
Origin-Host 264 DiamIdent
Origin-Realm 298 DiamIdent
Origin-State-Id 278 Unsigned32
Product-Name 269 UTF8String
Proxy-Host 280 DiamIdent
Proxy-Info 284 Grouped
Proxy-State 33 OctetString
Redirect-Host 292 DiamURI
Redirect-Host-Usage 261 Enumerated
Redirect-Max-Cache-Time 262 Unsigned32
Result-Code 268 Unsigned32
Route-Record 282 DiamIdent
Session-Id 263 UTF8String
Session-Timeout 27 Unsigned32
Session-Binding 270 Unsigned32
Session-Server-Failover 271 Enumerated
Supported-Vendor-Id 265 Unsigned32
Termination-Cause 295 Enumerated
User-Name 1 UTF8String
Vendor-Id 266 Unsigned32
Vendor-Specific-Application-Id 260 Grouped
【AVPフラグ】
AVPフラグは現在3種類あります。
V M P r r R r R
※rは，現在は未使用で，将来使用するために予約されていることを表します。
・Vフラグ
ベンダ固有フラグ。オプションのベンダ識別子があるかどうかを指定します。
・Mフラグ
必須フラグ。必須かどうかを指定します。必須の場合，受け取ったDiameterノードでサポートしていない場合，拒否応答を返さなければなりません。必須でない場合，無視します。
・Pフラグ
暗号化フラグ。暗号化する必要があるかどうかを指定します。
【AVP長】
ヘッダー（12オクテット，ベンダー識別子がない場合，8オクテット）と指定されたアトリビュート・データの長さを合計した長さを指定します。
【ベンダー識別子】
Vフラグがセットされている場合，ベンダー識別子（SMI Network Management Private Enterprise CodesとしてIANAが割り当て管理している）を指定します。
【アトリビュート・データ】
アトリビュート・データは，以下の基本データ・タイプか基本データ・タイプから派生したデータ・タイプで定義されます。
【データ・タイプ】
基本データタイプ
データ・タイプ 説明 AVP長 AVP長
（ベンダー
識別子が
ある場合）
OctetString 可変長のデータ（4オクテットの倍数に満たない場合は埋める） 8以上 12以上
Integer32 符号付32ビット 12 16
Integer64 符号付64ビット 16 20
Unsigned32 符号なし32ビット 12 16
Unsigned64 符号なし64ビット 16 20
Float32 浮動小数点付32ビット 12 16
Float64 浮動小数点付64ビット 16 20
Grouped データ自体が連続した複数のAVPリスト（ヘッダやパディングを含む） 8+AVPリスト全長 12+AVPリスト全長
派生データタイプ
データ・タイプ 説明 AVP長 AVP長
（ベンダー
識別子が
ある場合）
Address OctetStringからの派生
Ipv4，IPv6アドレスなど
最初の2オクテットがアドレス形式を示す 8以上 12以上
Time OctetStringからの派生
最初の4バイトは，NTPタイム・スタンプ形式でなくてはならない UTCで，1900年1月1日からの秒数 2036年2月7日にオーバーフローするが，この対策はSNTPに示されている。
Diameterもこれに従う。 12 16
UTF8String OctetStringからの派生
RFC 2279で定められた変換形式でコード化 16 20
DiameterIdentity OctetStringからの派生
重複接続や，ループの検知を行うために，Diameterノードを一意に識別する目的。DiameterノードをFQDN で指定する。同一ホストで複数のDiameterノードが動作している場合には，それぞれを一意に認識できるようにしなくてはならない。 12 16
DiameterURI URIの構文で指定する。
トランスポート・セキュリティを用いていない場合，
"aaa://" FQDN [ port ] [ transport ] [ protocol ]
トランスポート・セキュリティを用いている場合，
"aaas://" FQDN [ port ] [ transport ] [ protocol ]
aaa://host.example.com:6666;transpo rt=tcp;protocol=diameter 16 20
Enumerated Integer32からの派生
可能な値のリスト 12 16
IPFilterRule OctetStringからの派生
ASCIIコードを使用する。 16 20
QoSFilterRule OctetStringからの派生
ASCIIコードを使用する。
ルールは順番に評価され，最初にマッチしたところで評価は終了する。何もマッチしなかったら，ベスト・エフォートで処理される。ルールを解釈・適応できないデバイスは，セッションを終端すべきでない。
使用される情報は以下のとおり。
向き
送信元，あて先IPアドレス
プロトコル
送信元，あて先ポート
DSCP値 8+AVP全長 12+AVP全長
吉田 伊津子（よしだ いつこ）
アクセンス・テクノロジー
2001年にアクセンス・テクノロジー（http://accense.com/）入社。RADIUS認証サーバー『fullflex』シリーズの開発およびテクニカル・サポート業務に携わるかたわら， IETF，JANOG，ShowNetなどの国内外のネットワーク関連イベントに積極的に参加し，見識を広める。現在は，システム管理のマネージャーを務め，システムの企画から，設計，導入，運用にまで携わる。
[2008/09/11]
