要約

  • 10月28日の個人草案は、IPv4・IPv6プレフィックスを直接載せるclient_ip_rangesと、HTTPSのJSON文書を指すclient_ip_ranges_uriを提案する。二つは併用できない。登録や取得に成功しても、認可サーバーがその範囲を受け入れたことにはならない。
  • 取得失敗、不正な文書、申告の取り下げだけで、以前拒否していた送信元を通してはならない。サーバーは旧集合を維持し、審査中の新集合との共通部分まで狭め、保存期限を設けられる。期限が切れたら、受入れか明示的な運用判断までクライアントの要求を拒む。

申告書は届いても、入場判定は残る

クラウドの出口を替えたクライアントが、新しいIP一覧をHTTPSで公開する。認可サーバーの取得ログは成功。それでも新しい出口からのトークン要求は通らない。草案はこの時間差を前提にしている。文書の取得と、そこに書かれた範囲を受け入れる判断を分けた。広すぎるプレフィックスが突然追加されても、更新時刻だけで許可にはならない。

申告の形式は二つ。メタデータに直接アドレスを書き込むか、JSON文書のHTTPS URLを示すかだ。どちらもない場合は申告なし。空配列は「許す送信元が一つもない」という申告になる。RFC 7592の更新処理との関係でも、草案は空配列をフィールド削除の指示として扱わせない。空集合を受け入れて適用するサーバーなら、どの送信元も通さない。

新しい集合の受入れは旧集合の全面置換であり、差分の逐次追加ではない。検証済みの新集合が承認待ちなら、サーバーは旧集合を両者の共通部分まで狭めてもよい。古い出口だけ先に閉じ、新しい出口は審査が終わってから開けられる。クライアント側は移行前に新しい範囲を申告し、古い出口から実際に送らなくなるまでそれを残す必要がある。HTTPの再取得間隔と承認の待ち時間は切替日程に入る。

文書が取れなかったからといって門は全開にならない。不正なデータや申告の取り下げでも、従来拒んだIPを自動的に通せない。取り下げ後に制限を緩めるなら、運用者の明示的な判断が要る。サーバーは、障害、取り下げ、未承認の置換中に旧集合をいつまで使うか期限を定めるべきだ。期限後は現在の申告に基づく集合を受け入れるか、明示的に適用を終えるまで要求を拒む。未承認の候補を再検証しても、その時計は巻き戻らない。

古い許可を抱え続けるのも危うい。クライアントが手放したIPは別の利用者に割り当てられ得る。旧集合の共通部分への縮小と保存期限は、この取り違えを短くする。RFC 9111が扱うHTTPキャッシュと、サーバーが受け入れたIP集合は別の状態だ。304 Not Modifiedは内容の再確認であって、運用上の承認ではない。

トークン窓口の手前のファイアウォールに見えるのは送信元IPであり、OAuthクライアントの身元ではない。そこでは複数クライアントの範囲を合わせた制御しかできない。認可サーバーはクライアントを特定してから個別の集合を適用できる。URLを署名したソフトウェア声明も、そのURL先の将来の内容までは保証しない。文書を預かる側が空集合を出したり長く停止したりすれば、クライアントを締め出せる。

IETFの記録は個人草案を示し、実運用の測定結果はない。移行を試すなら、取得した版、受け入れた集合、承認時刻、古い範囲の終了時刻、前後のトークン要求結果を並べるべきだ。

資料：草案；IETFの状態；RFC 7592；RFC 9111。