要約

  • RFC 5191のPANA Pingは、最近送った要求に対してPANA peerが有効な応答を返したことを確認する。独立したEPのフィルター、データ経路、遠隔受信、アプリケーション結果までは確認しない。
  • 制御peerの生存をサービス全体の正常性に拡張すると、PAAは緑、EPは赤という実在する故障が隠れる。監視項目には、誰に何を尋ねたのかを残さなければならない。

障害中にもPingは成功し続けた。だから当初の判断は「利用者側の問題」だった。実際には、Pingが質問した相手と、利用者のパケットを止めていた相手が違っていた。

PANAはPaCとPAAの間でEAPを運び、認証・認可セッションを管理する。アクセスフェーズでは、PANA-Notification-RequestとAnswerのPingビットを使ってpeerのlivenessを調べられる。有効なanswerは、最近のrequestに対応するpeer生存の証拠になる。

その証拠は正しい。ただし狭い。RFC 5191は、パケットごとのポリシーを適用するEnforcement PointとPAAが別ノードでもよいとする。PAAが応答できても、EPのルール、経路、アドレス、データ用security association、遠隔アプリケーションは壊れ得る。

正しい証拠を誤った対象へ拡張することが、ここでの失敗である。

Pingが観測したもの

アクセスフェーズのPingはPANAセッションのpeer availabilityを確認する。PANA SAが存在すればAUTHで保護され、偽造や変更への耐性も得られる。直近の別メッセージ交換でpeer生存が分かっていれば、明示的Pingを省略することもできる。

監視記録はこの意味を保つべきだ。送信時刻、Session ID、sequence、AUTH検証、応答時間、相手PAA、PaCのinterfaceを保存する。「PAAがT時点でPANA requestに応答した」は強い事実である。

そこに「EPが加入者ルールを保持していた」「データパケットが通った」「DNSやアプリケーションが応答した」を足すには、別の観測が必要になる。Ping packetはそれらのシステムへ質問していない。

RFCは定期的keepaliveにも注意を促す。過剰な試験は輻輳を生み、誤警報の原因になり得る。Ping失敗も直ちにサービス断の完全証明ではない。制御経路だけが混雑し、データがまだ流れている可能性も区別すべきだ。

認証、認可、実行

PANAの主payloadはEAPである。EAP methodが認証を行い、PAAまたはbackend AAAがネットワークアクセス認可を決める。RFC 5191は、EAP Successが生成されても認可が拒否される場合を明記している。

この場合、PAAはPANA_AUTHORIZATION_REJECTEDを返し、セッションを終了する。MSKが存在して最終交換がAUTHで保護されても、拒否は許可に変わらない。

したがって監視の最初の分離は、EAP結果とPANA認可結果である。次の分離はPAAの決定とEPの実行だ。PAAとEPが別なら、PAA–EP provisionは独立した制御transactionである。RFC 5191はそのprotocolとfilter creationを範囲外に置きつつ、通信には認証、完全性、replay protectionを要求する。

保護された投影命令は、正当な命令の証拠である。EPのtableに正しいruleが入った証拠ではない。対象EP、policy version、PaC/interface binding、acknowledgement、rule fingerprint、readbackが必要になる。

Completeは制御フェーズを閉じる

認証・認可フェーズの最後はCompleteビット付きPANA-Auth交換である。成功ならSession-Lifetimeが与えられ、key-generating EAPならKey-IdとAUTHが使われる。

Completeの意味は、PaCとPAAのPANA exchangeが完了したことにある。複数EPへのinstall、IP reconfiguration、data-plane SA、remote receiptを一括確認した印ではない。

ダッシュボードがこのイベントを「接続完了」に変えると、後続工程は監視から消える。表示すべきなのは段階だ。認証済み、認可済み、PANA完了、EP投影済み、address usable、data protection installed、packet observed、application succeeded。

すべてを一つの緑へ圧縮すれば簡単に見える。しかし障害時には、どの制御者が最後に成功したのか分からなくなる。

成功後のアドレス変更

RFC 5191では、認証と認可が成功した後にPaCがIP addressを再設定する場合がある。PANAに使ったaddressが、EPを通るdata trafficには適切でないためである。PAAはIP Reconfigurationビットで必要性を伝え、実際の再設定方法は範囲外となる。

旧addressへのPANA Pingが成功しても、新addressのneighbor、route、filterが未完成ならアプリケーションは使えない。逆に、databaseがcurrent addressだけを持つと、旧addressで行われた認証exchangeが別deviceの記録に見える。

旧address、interface、reconfiguration指示、新lease、neighbor、route、EP update、最初のdata packetを時間順に残す必要がある。状態を上書きするのではなく、変化を証拠として保存する。

PANA SAとデータ保護

EAPがMSKを出力すると、PANA SAが作られ、PANA_AUTH_KEYでPANA headerとpayload、含まれるEAP messageを保護できる。これは制御signalのauthenticationとintegrityを与える。

data packetのcipheringは別である。下位層が未保護なら、PANA SAからmaterialを導出し、link-layerまたはIPsec型のsecure association protocolで逐包保護を有効化できる。その導出と利用はRFC 5191の外にある。

よってAUTH付きPing成功はdata encryptionを証明しない。データSAについてはendpoint、selector、algorithm、key ID、install state、counter、lifetimeを別に読む。PANA SAとdata SAの間にはderivation edgeを置けるが、同じobjectにはしない。

下位層保護で十分というpolicyなら、それを明示する。二つ目のSAが見えないというだけでは、設計通りか失敗かを判定できない。

Session-Lifetimeはuptimeではない

PANA session lifetimeは現在のauthorization lifetimeに拘束される。期限前のre-authenticationで延長でき、期限切れは切断clientのcleanupにも使われる。

これはpermissionとcontrol stateの時計である。EP rule、address lease、route、data SA、application availabilityが同じ時間だけ続く保証ではない。下位層indicationで切断を早期検出できる場合もあるが、その信頼性はlinkやtopology依存であり、RFCはhintとして扱う。

authorization、PANA session、PANA SA、address、EP rule、data SA、observed serviceの各期限を別々に記録する。差が出たとき、その差が故障の場所を示す。

一時間のSession-Lifetimeを一時間のSLAへ変換するのは、測っていない可用性をprotocol fieldから作る行為である。

終了もEPへ収束しなければならない

PaCまたはPAAはsessionを早期終了できる。終了はPANA stateの削除、accounting停止、EP上のper-PaC state除去を引き起こすものとされる。

しかし分離構成では、AUTHで保護されたtermination messageもPAA側の正当な命令である。各EPが削除したかは、削除transaction、ack、post-delete queryで確認する。

allow ruleの残留は不要なaccessを残す。deny ruleの残留は次回の正当な接続を阻む。どちらも「PAA sessionなし」という一つの読取では発見できない。

termination cause、protected exchange、accounting close、target EP set、delete acknowledgement、rule readbackを一つのchainにする。control objectを早く消し過ぎると、残留ruleの由来が分からなくなる。

Discoveryは信頼ではない

RFC 5192のDHCP optionはPAA addressを知らせ、RFC 6345はRelay Elementを定義する。これらは到達先を見つける仕組みであり、発見されたaddressを認証済みauthorityへ変える仕組みではない。

DHCP server、option、lease、interface、relayを記録し、その後のPANA/EAP validationへ結び付ける。誤ったdiscovery、relay failure、authentication failure、authorization rejection、EP install failureは利用者には同じ「接続不能」に見えても、別のownerを持つ。

候補を知ること、相手を認証すること、permissionを得ること、filterを変えること、packetを届けることは順番のある別の事実だ。

誰が何を証明したか

運用evidence objectはPaC、interface、PAA discovery source、requested serviceから始まる。各PANA messageにはSession ID、sequence、retransmission、validationを付ける。EAP resultとauthorization decisionを別々に保存する。

最終交換にはResult-Code、Complete、Key-Id、AUTH、lifetimeを残す。address変更があれば前後を履歴化する。各EPへのpolicy projection、実rule、必要なdata SAを追加する。最後にpacket capture、remote receipt、application resultを結ぶ。

このchainなら、PANA Pingが成功しているのにserviceが失敗する状況を矛盾なしに説明できる。PAAは生きていた。EPの証拠は失われていた。Pingは嘘をつかなかった。監視が、Pingに尋ねていない質問の答えまで書き足したのである。

出典

  1. RFC 5191 HTML
  2. RFC 5191 text
  3. RFC 5191 record
  4. Datatracker RFC 5191
  5. RFC 5191 history
  6. RFC 5191 references
  7. RFC 5191 errata
  8. RFC 5192
  9. RFC 5192 record
  10. RFC 5193
  11. RFC 5193 record
  12. RFC 4058
  13. RFC 4016
  14. RFC 3748
  15. RFC 4137
  16. RFC 5247
  17. RFC 6345
  18. Heng Lu — On Reality Layers
  19. Heng Lu — Minimum Initial Specification
  20. Heng Lu — Running-Code Primacy