要約

  • RFC 10011 の設定モデルは、RESTCONF と Call Home の望ましい接続関係を表現する。設定済みの宛先は、実際に接続された相手の証明ではない。
  • RFC 8071 で反転するのは TCP を始める側だけである。TLS と RESTCONF の役割および相手検証の責任は、その到着によって消えない。
  • 接続意図、TCP 受理、鍵または証明書の検証、RESTCONF 認証、変更判断を別々の記録として保持することが、便利な自動化を権限の飛躍にしない。

逆向きでも、役割は混ざらない

RFC 8071 の Call Home は、管理対象が NAT の内側にいる、動的アドレスを持つ、外から管理ポートを開けられない、あるいは初回起動時に管理系へ自ら現れる必要がある場合に役立つ。装置が TCP を始め、管理システムのクライアント側が待ち受ける。これによって、管理システムが各装置へ到達し続けるという前提を緩められる。

しかしプロトコルの層は、この便利さのために同一化されない。ネットワーク要素は TCP の initiator になる一方で、TLS と RESTCONF では server のままである。管理システムは TLS と RESTCONF の client である。矢印の始点が変わっても、誰が提示物を検証し、誰が独立した期待を持つかは変わらない。

そのため、接続元アドレス、到着した時刻、設定されたポート、予想された再接続周期は、運用上の手掛かりにはなっても本人性の根拠にはならない。これらは「何かがこの listener に届いた」と言う。期待した装置であることは、その後の検証が言うべきことである。

設定と観測の間に、消してはいけない余白がある

RFC 10011 は信頼ストア、鍵ストア、TCP、SSH、TLS、HTTP、NETCONF の YANG モデルと並ぶ RESTCONF の設定語彙を提供する。移行や監査では、この共通の語彙が大きな利点になる。意図した接続構造を、特定の製品の画面や手順に閉じ込めずに確認できるからだ。

ただし YANG の木は実行ログではない。接続先を含む設定は listener が bind されたことを保証せず、bind は到達可能性を保証せず、TCP 受理は TLS 成功を保証しない。TLS 成功は RESTCONF の認証を保証せず、認証成功は変更実施の承認を保証しない。

RFC 8342 の NMDA が配置と運用状態を分けるのは、まさにこの違いを保存するためである。設定データは「何を可能にしたいか」を示す。運用状態は「どのプロセスが何を実際に観測したか」を示す。一つのダッシュボード状態にまとめるなら、表示は簡単になるが、判断に必要な失敗点も消える。

期待した名前は、接続より先に存在しなければならない

RFC 8071 は Call Home client に、server が提示した host key または certificate の検証を求める。事前設定した issuer へのパス検証も、以前に信頼または pin した値との比較も使える。証明書パスを使う場合、client は接続の前から知っていた identifier を確かめなければならない。client 認証で使う credential も、提示された server の鍵または証明書と事前に対応付けられる。

ここで重要なのは「先に知っていた」という順序である。来た相手が持参した名前だけで、その相手を受け入れる基準を作ってはならない。RFC 6125 の reference identifier も、受信物から独立した期待を要求する。この順序は、通信が逆向きになっても変わらない。

RFC 8071 は、広範な認証局と共有秘密の組合せにより、同じように見える identity を持つ別の server へ秘密を送る危険も述べる。これは特定の装置への非難ではない。到達、証明書の提示、本人性の検証を別の事実として扱う理由である。

一つの接続を五つの事実に分ける

第一に、期待した identity、信頼 anchor、listener、transport、設定 revision を記録する。第二に、実際に受理した TCP の時刻と listener を記録する。第三に、提示された鍵または certificate と、独立した reference に対する検証結果を記録する。第四に、RESTCONF の account、認証、capability、request context を記録する。第五に、service owner、承認範囲、実施時刻、rollback 条件を記録する。

この順番は、不必要な停止を命じるものではない。TLS が通って RESTCONF 認証が失敗したなら、transport の問題ではなく session admission の問題として扱える。session が通って操作が拒否されたなら、拒否は制御の失敗ではなく、意図した権限境界かもしれない。意味を急いで広げなければ、調査も復旧も速くなる。

Heng Lu の最小初期仕様という考え方は、この分離を支持する。共有層は相互運用のために必要な形と決定的検証を厳密にする。どの identity を期待するか、どの issuer を受け入れるか、誰が変更を認めるかは、結果を引き受ける各参加者の局所的決定である。互換なモデルは、局所的な承認を代行しない。