簡易 DRA の自作を振り返る 2023/02/16 BBSakura Networks 株式会社 金井真澄

● 金井真澄 (@masu_mi) ● 2021年2月から中途入社 ● 学生時代は、完全WKB解析(いまはリサージェンス理論らしい) ● 新卒では、ウェブ企業でバックエンド・プラットフォーム開発 ○ BBS入社前、モバイルコアってなんですか ? ○ BBS入社後、モバイルコアって難しい ● 1歳、3歳のこどもが2人、つくば市在住 自己紹介

はなすこと ● DRAもどき の周辺知識を整理する ○ ターゲットは入社前のわたし ■ モバイル網はじめまして ■ LTEとか一般用語は知っている ○ OCXな人に「バグ直してあげよう」と思ってもらう ● DRAもどきの紹介 ○ 動機と機能と苦労と未達

DRA: Diameter Relay Agent です

DRA: Diameter Relay Agent です ● Diameter (RFC6733)は AAA(認証・認可・課金)のフレームワークプロトコル ● 概念的には2層ある ○ ベースプロトコル: コネクション管理に関わる ○ アプリケーション: 実際に動かしたい AAA 色々 ● EPC (LTEのコアシステム) でも使われている ● TCP, SCTP (+ IPSec/TLS) セッション上で動く ● Server/Client モデルで間に Agent を差し込める ● 各ノードは realm, host で識別される ○ realm defined in RFC4282

Diameterのメッセージの流れる例 Req. Ans. Ans. Req. Client Server Agent Ans. Req. Diameterコネクション Agent Diameter メッセージ Agent Agent Realm start.local Host cli-0.start.local Realm dst.local Host srv-0.dst.local ● 各ノードは Realm, Host で識別される ○ Realm は RFC4282 に定義されている

Diameterのルーティング Req. Req. Client Agent Agent Agent Agent

● どの Diameter Peer にメッセージを送るのか? ○ 少なくとも Destination-Realm、Application-ID に依存させられることが求められてる ● Diameter Peer とのコネクション ○ Diameter Peer は事前に設定されている ○ Diameter Peer はDNSを使って動的に解決される Diameter ルーティングどうする? Req. Req. Client Agent Agent Agent Agent

● どの Diameter Peer にメッセージを送るのか? ○ 少なくとも Destination-Realm、Application-ID に依存させられることが求められてる ● Diameter Peer とのコネクション ○ Diameter Peer は事前に設定されている ○ Diameter Peer はDNSを使って動的に解決される Diameter ルーティングどうする? Req. Req. Client Agent Agent Agent Agent

Diameter Message ref. RFC6733 #3. Diameter Header

Diameter Message Diameter Header Diameterはフレームワーク 色々なアプリケーションが動く 値は IANAのAAA 配下のApplication-ID モバイルは 3GPP TS 29.230 も参考に コマンドのパラメータ Destination-Realm もここ

● どの Diameter Peer にメッセージを送るのか? ○ 少なくとも Destination-Realm、Application-ID に依存させられることが求められてる ● Diameter Peer とのコネクション ○ Diameter Peer は事前に設定されている ○ Diameter Peer はDNSを使って動的に解決される Diameter ルーティングどうする? Req. Req. Client Agent Agent Agent Agent

Diamter コネクションはどの Application ID を流せるか決まっています。 コネクション確立時の Capabilities Exchangeで決まります。 使われる AVP ● Auth-Application-Id ● Acct-Application-Id ● Vendor-Specific-Application-Id なんでも通す relay のアプリケーションIDは 4294967295(0xffffffff) Diameter コネクションの確立 CER Node Node CEA DWR DWA DWR DWA

● RFC6733で4つAgentが定められている ○ Relay: ■ ルーティングに関わる AVP しか参照しない ■ アプリケーションレベルの知識をもって判断しない ● (セッションやサーバーの状態を関知しない ) ○ Proxy: アプリケーションレベルの知識を持って判断する ○ Redirect: ルーティングせず宛先を通知してリダイレクトさせる ■ Result-Code: DIAMETER_REDIRECT_INDICATION ○ Translation: ほかAAAプロトコル(RADIUS, …)との変換 ● モバイル網で追加定義されている ○ Diameter Edge Agent ■ DRA + α (イントラネットワークを隠す : realm/host を書き換え) ○ ref. GSMA IR.88: EPS Roaming Guidelines DRA: Diameter Relay Agent です

● RFC6733で4つAgentが定められている ○ Relay: ■ ルーティングに関わる AVP しか参照しない ■ アプリケーションレベルの知識をもって判断しない ● (セッションやサーバーの状態を関知しない ) ○ Proxy: アプリケーションレベルの知識を持って判断する ○ Redirect: ルーティングせず宛先を通知してリダイレクトさせる ■ Result-Code: DIAMETER_REDIRECT_INDICATION ○ Translation: ほかAAAプロトコル(RADIUS, …)との変換 ● モバイル網で追加定義されている ○ Diameter Edge Agent ■ DRA + α (イントラネットワークを隠す : realm/host を書き換え) ○ ref. GSMA IR.88: EPS Roaming Guidelines DRA: Diameter Relay Agent です

LTE の大雑把な説明 端末 SIM IPサービス (インターネットとか) モバイル網 基地 局

LTE の大雑把な説明 UE SIM IPサービス (インターネットとか) eNB SGW PGW MME HSS E-UTRAN EPC Non-Roaming アーキテクチャ for 3GPP: E-UTRANの例 3GPP TS 23.401 + 3GPP TS 36.300 S6a

LTE の大雑把な説明 UE SIM IPサービス (インターネットとか) eNB SGW PGW MME HSS E-UTRAN EPC Non-Roaming アーキテクチャ for 3GPP: E-UTRANの例 3GPP TS 23.401 + 3GPP TS 36.300 S6a HOとか端末の移動を管理 ユーザー情報を管理

LTE の大雑把な説明 ローミング UE SIM IPサービス (インターネットとか) eNB SGW PGW MME HSS E-UTRAN EPC Roaming アーキテクチャ for 3GPP: E-UTRANの例 3GPP TS 23.401 + 3GPP TS 36.300 S6a HOとか端末の移動を管理 ユーザー情報を管理 HPLMN VPLMN

ローミングアーキテクチャ GSMA IR.80 Bi-lateral アーキテクチャ

DRAを作ってみた動機 ● ちょっとした検証で必要になった ● 自分で書いて知識を増やしたかった ● すでにGoのライブラリの利用例があった ● 拡張したり実験できるものがあると便利 ○ ルーティング設定を自分で拡張しやすい ○ 負荷分散や再送ポリシーも自由にいじれる ○ wasm runtime 入れてみるとか ○ クラスタ化して設定更新を簡単にしたい ○ ノード間通信を単純化したい

どんな機能にしたか ● Realm, Host 用にパターンマッチ ● Peer (対向ノード)のグループ形成 ○ パターンマッチを使う ● Peerグループの用途 ○ ルーティングの送り先 ○ 負荷分散 ○ リトライ ● ルーティングのルール設定 ○ Application-ID ○ Destination/Origin × Realm/Host (簡易のワイルドカード )

パターンマッチ いろんな場所の Realm や Host に対して使う。 ● 2種類のワイルドカードをそれぞれ1つまで使える ○ * : ピリオドを含まない ○ **: ピリオドを含む ● 理由 ○ 現実的なケースを扱える ○ 正規表現より軽い

設定のイメージ グループの設定(yaml) group: local: { realm: "net.test", host: "**" } # == {realm:"net.test"} vnf: { realm: "remote.test", host: "nf*.remote.test" } others: { realm: "**", host: "**" } # == {}

ルーティングの設定(yaml) route: - { dest_realm: "net.local", next: "local" } - { dest_host: "vnf.**.remote.test", next: "vnf" } - { application_id: 10, dest_realm: "**.remote.test", next: "vnf" } - { next: "default" } 設定のイメージ

グルーピング + ルーティングの結果 設定のイメージ local vnf others dest-realm == "net.local" LB realm: net.local dest-host == "nf**" OR application_id == 10 && ... any それ以外

実装で他にやったこと ● フォワード時のループ検知 ○ Route-Record AVP に自分の Host を追記してループ検知可能にする ○ Route-Record AVP をみてループ検知処理 ● 再送処理 ○ タイムアウト起因では Diameterヘッダ内の T フラグを立てる ○ ロードバランスのためにアルゴリズム設定可にする ○ 再送中に発生するイベント対応 ● コネクション断対応 ○ 再送処理に割り込み ○ 再接続

実装で他にやったこと 苦労したこと ● フォワード処理の仕様対応 ○ Route-Record AVP に自分の Host を追記してループ検知可能にする ○ Route-Record AVP をみてループ検知処理 ● 再送処理 ○ タイムアウト起因では Diameterヘッダ内の T フラグを立てる ○ ロードバランスのためにアルゴリズム設定可にする ○ 再送中に発生するイベント対応 ● コネクション断対応 ○ 再送処理に割り込み ○ 再接続

定番の問題で面白みは少ない ● ライブラリ都合で Req/Ans 対応付けが自作 ○ Diameter ヘッダ内の Hop-by-Hop-ID を利用する ● イベントの並行制御とリソース解放の組み合わせ ○ リトライは複数 Diameter コネクションが関わる ■ 互いに関連する管理テーブルがある ○ 再送中に起きるイベントが色々ある ■ Answer 受信 ■ タイムアウト、Txタイムアウト ■ 送信元コネクション切断 ■ 送信先コネクション切断 ■ サーバー停止 苦労したところ: 再送制御

これからのこと ● 純粋な relay になってないので対応 ○ 辞書にない Application IDやAVP のエラーを無視したい ○ ついでにライブラリのインタフェースを整えて Agent 実装を単純化 ● レートリミット機能実装 ● Peer discovery DNS を使った動的なコネクション確立　 ● vrf のようPeer毎にルーティングルールを変更 ● wasm runtime で使えるAPIを拡充する ● 設定をConsul管理にしてクラスタ化 ○ クラスタのノード間通信を単純化 ● 設定の可視化

● だいたい1ヶ月半で一周しました ● 検証環境の変更を設定で吸収できたことがあり満足です ● 自作は勉強なるし楽しいですね ● 時間が許せば合間に育てたい おわり