要約

  • RFC 3539では、フェイルオーバー、フェイルバック、負荷分散により同一AAAトランザクションの複製が任意の接続から届き得る。代替経路の要求が先着しても、元の要求が消滅した証拠にはならない。
  • 状態に依存する認証では、最初の要求がAccept、複製がRejectになり得る。要求識別、サーバ判断、クライアントの回答選択、NAS適用、アカウンティング、利用者結果は別々に記録しなければならない。

分散システムでは、「切り替え」という語が実態を小さく見せる。ある経路から別の経路へ仕事を移したように聞こえるが、送信者が元の仕事の消滅を証明できない場合、実際には同じ仕事をもう一つ作動可能な場所へ送っている。

2003年6月のRFC 3539は、Authentication, Authorization and Accounting向けトランスポートの問題を扱うProposed Standardである。特定の事業者や障害を記録した文書ではない。本稿が扱うのは、そこで明示された境界、すなわちトランスポートの復旧と認可結果の一意性が別の性質だという点である。

接続の終了は要求の終了ではない

AAAクライアントは複数のエージェントやサーバへ接続し、主系・副系として扱ったり負荷を分散したりできる。元の接続から送ったパケットがネットワークを離れたと保証できる前に別接続へ同じトランザクションを送れば、代替側が先に到達し、その後で元の要求が到達することがある。

そのためRFC 3539は、エージェントとサーバに複製処理の準備を要求し、複製はどの接続からも届くと仮定させる。接続は隣接関係であり、トランザクションの意図そのものではない。接続を閉じても、その接続を通過した意図まで取り消せない。

「主系Down」「副系Up」という表示は経路の状態を示す。元要求がプロキシを通ったか、下流サーバが状態を確定したか、回答が遅れて戻っているかまでは示さない。従って障害レビューでは、peer failure timeとlogical request retirement timeを別々に残す必要がある。

新しい経路が健全であることと、古い経路上の判断が存在しないことは、同時に真とは限らない。

Watchdogが観測するのは直近のpeerである

RFC 3539は、トランスポート障害とアプリケーション機能障害を早く検出するため、アプリケーション層watchdogをAAAプロトコルに求める。ただし、このwatchdogは直近peerのために設計され、下流プロキシやサーバの障害で影響されないようにする。クラスタ全体のheartbeatでもない。

peerから何らかのAAA Responseを受け取れば、peerが生きている証拠になる。一方、通常の認証要求に回答がないだけではpeer Downと結論できない。下流が原因かもしれないからである。記述されたアルゴリズムでは、watchdog要求への無応答が初めてpeer障害判断を支える。

この設計は下流の不安定性が上流全体へ伝播するのを防ぐ。しかし、証拠範囲も直近に限定される。watchdog回答は、home realmの稼働、共有状態の新鮮さ、認可の実行、NASのアクセス許可を証明しない。

タイマを短くしても不確実性は消えない。RFCはjitter前の初期値を既定30秒とし、jitterを除いて6秒まで設定可能とする一方、短い値は複製と誤ったフェイルオーバー／フェイルバックの確率を上げると注意する。真の障害から早く回復する設定は、単に遅いpeerを早く見限る設定でもある。

pending queueが知るのはローカルな未完了だけ

フェイルオーバーには、peerごとのpending message queueが必要になる。対応する回答を受け取ると要求はqueueから除かれ、障害転送を始めると残っているすべてのメッセージが利用可能な代替エージェントへ送られる。

queue entryが残っているという事実は、「このノードが終了回答をまだ見ていない」という意味である。「遠隔で何も実行されていない」という意味ではない。Acceptが確定済みで回答だけが遅れている可能性も、元の代理が下流へ転送済みである可能性もある。

したがって再送記録には、元peer、代替peer、watchdog世代、発動理由、queue snapshot、要求digest、end-to-end identity、再送フラグ、両送信時刻が必要になる。retry=1だけでは、同一バイトの複製、メッセージ再構築、宛先変更、内容変更を区別できない。

RFC 6733のDiameter Base ProtocolもRFC 3539の障害アルゴリズムを引き継ぎ、pending要求を代替エージェントへ送り、再送要求を示し、複数の同一要求または回答が生じ得ると明記する。

二つの識別子は二つの時間境界を持つ

Hop-by-Hop Identifierは隣接hopで回答をpending要求に対応させる。End-to-End IdentifierとOrigin-Hostの組み合わせは、複数のエージェントをまたいで同じ論理要求を複製として認識する。

前者はローカルqueueの終了に役立ち、後者は別経路のメッセージを同じ意図へ束ねる。どちらも全サーバを拘束する分散ロックではない。暗号学的な送信者証明でも、freshness証明でも、効果が一度だけだったという証明でもない。

複製を認識した後、サーバには処理方針が必要になる。既存の永続回答を再送するのか、権威ある決定を待つのか、再評価を拒否するのか、ポリシーをもう一度実行するのか。RFC 6733は複製要求に同じ回答を返すべきだとする。これは、同じ意図が二つ目の判断になるのを抑えるための重要な規則である。

ただし、最初の決定が保存されていなければ同じ回答を取り出せない。複製cacheが短すぎる、別サーバに状態が伝わらない、commit前に応答経路が切れた、といった場合、共通キーは欠けた決定を生成してくれない。

識別、抑止、整合、補償は同じ操作ではない。

AcceptとRejectは異なるstate epochから生まれる

RFC 3539の例は、同時利用数の制限を用いる。最初の認証要求が到着した時点では利用者は未ログインとみなされ、サーバはAcceptを返す。状態が変わった後、複製が別サーバへ到着すると、一セッションだけを許す制約によりRejectになり得る。

各サーバは観測した状態に対して正しく判断しているかもしれない。矛盾の原因は悪意ではなく、状態伝播と非冪等な操作の組み合わせである。

クライアントは同一複製要求についてAcceptとRejectを両方受け取り、結果は先着回答に左右され得る。すると遅延が認可ポリシーの一部になる。副系サーバの配置変更、proxy queueの短縮、経路遅延の変化が、明示したポリシーを変更せずに実際の許可結果を変えてしまう。

この記述は起こり得る機構を示すもので、現実の事故を証明しない。管理上必要なのは、先着優先を明示規則として監査するか、サーバ側で一つのend-to-end identityに一つの永続決定を対応させるか、いずれかを選ぶことである。

選ばれなかった回答を捨ててはならない

最終的に採用したResult-Codeだけを残すlogは、競合そのものを消す。すべての回答について、送信サーバ、要求identity、state epoch、適用制約、複製lookup、決定commit時刻、受信時刻を保存する必要がある。

「先に来た」という表現にも観測点が要る。プロセスが先に読み取った、完全性検証が先に終わった、client stateへ先にcommitした、NASへ先に送った、実際のアクセスへ先に反映した、という順序は一致しない場合がある。

client selection receiptは、受信した全回答、対応付けと検証、採用規則、選択した回答、非選択回答の処分を記す。これにより、単なる再送問題と、サーバstate不整合と、NAS実行競合を分離できる。

Acceptはまだアクセスではない

Acceptはサーバの認可判断である。クライアントが正しいpending要求へ対応させ、NASが属性やprofileを設定し、セッション状態を変更し、data planeでサービスが使えて初めてアクセス結果になる。

Rejectも同じく限定的である。別のAcceptが既に適用されていれば、遅いRejectから「アクセスは一度も許可されなかった」とは言えない。cleanupを起動するか、複製として破棄するか、未解決の競合として残るかは別の判断である。

アカウンティングにはさらに独立したidentityがある。RFC 3539はAccounting Session-Id、Event-Timestamp、NAS identityによる重複排除を例示する。どの記録を破棄・統合・採用し、その結果が請求や監査へどう反映したかを保存しなければならない。

要求作成、peer liveness、queue再送、全サーバ判断、client選択、NAS適用、accounting disposition、利用者結果という鎖が必要になる。上流の成功を下流の証明に使ってはならない。

RADIUSの取引識別とは混ぜない

古典的RADIUSでは、一オクテットのIdentifier、Request Authenticator、transport context、shared secretが応答対応や再送の境界を作る。RFC 2865、RFC 2866、RFC 5080はその仕組みを扱う。

それらはDiameterのHop-by-Hop Identifier、End-to-End Identifier、Origin-Hostの別名ではない。本稿は既存のRADIUS取引識別を再論するのではなく、RFC 3539が示す接続横断複製と、状態依存判断の競合を扱う。

共通する抽象原則は、複製が新しい意図にならないようidentityを保ち、同じ意図が二つの効果にならないようdecision stateを保つ、という点だけである。

レビューで要求すべき証拠鎖

論理要求にはorigin、end-to-end key、immutable digest、利用者／session scope、application、作成時刻を付ける。peer記録にはconnection generation、最後の有効response、watchdog request/answer、timer、jitter、failure classificationを付ける。

再送記録には元peer、代替peer、queue snapshot、retransmission marker、送信時刻を付ける。各decision serverではstate epoch、制約、duplicate lookup、既存判断の有無、回答、commit時刻を残す。

clientは全回答と選択規則を残し、NASは実際に適用したprofileを残す。accountingはsession identity、event time、NAS identity、dedupe dispositionを結ぶ。最後に実際のアクセスまたは拒否を観測する。

経営報告は「この直近peerがこのwatchdogに応答せず、これらpending identityをこの代替先へ再送し、複数判断をこの規則で整合し、NASがこの回答を適用し、このsession結果を観測した」と言える。欠けた節は不明のまま示す。

証拠の限界

本稿は事業者、vendor、AAA realm、RADIUS／Diameter deployment、account、login、NAS、incident、outage、security event、duplicate charge、利用者を特定しない。採用率、現行設定、実測遅延、競合回答の頻度も報告しない。

RFC 3539は2003年6月のProposed Standardとして扱う。RFC 3588は歴史的Diameter文脈でありRFC 6733に置き換えられた。RFC 6733は障害・複製識別機構を維持するが、特定システムの適合を証明しない。RFC 8174は規範語、RFC 6298は再送timerの文脈を与えるだけである。

Lu HengのRunning-Code PrimacyとMinimum Initial Specificationは、文書、実装、ローカル判断、観測結果を分けるための明示した編集視点である。RFC著者の意図や運用事実を証明する資料ではない。

限定結論は明快である。フェイルオーバーは元要求が消える前に同じAAA要求を複製し得る。共通identityは複製を認識可能にする。一つの効果を証明するには、冪等な処分、明示的回答選択、NAS実行、結果観測が別途必要である。

出典