要約

  • 2001 年の FORCERENEW は、設定済みのクライアントを通常の更新手順に戻す通知だった。通知の受信だけで、新しいアドレスや設定が確定するわけではない。
  • 2012 年の nonce 認証は、事前の別経路による鍵配布を不要にした。一方、最初に nonce を渡す通信を盗み見られないという前提は残った。
  • 機能の合意、通知の認証、更新結果の確認は別々の作業である。共通の番号が割り当てられたことも、一つの通知が正しく検証されたことも、移行の成功を意味しない。

矢印は一度、逆向きになる

サーバーが設定を変えたい。端末はまだ正常に動いており、今すぐ問い合わせる理由がない。このずれを埋めるために用意されたのが、DHCP の FORCERENEW だった。

しかし通信の順序を追うと、遠隔から設定を書き込む命令とは違うことが分かる。サーバーの通知を受けたクライアントは、今度は自分から DHCPREQUEST を送る。新たな設定は、その後の通常のやり取りに委ねられる。最初の通知が担うのは、次の質問を始めさせることだ。

2001 年 12 月の RFC 3203 は、この方法を小さな拡張として設計した。通知はユニキャストで送り、受け取ったクライアントは更新の状態へ移る。クライアントに新しい状態を追加しない点も、文書が挙げる利点だった。

この小ささには意味がある。サーバーに先に話す機会を与えながら、設定を受け入れる手順そのものを別の仕組みに置き換えない。既存の手順へ入る扉を増やすことと、その手順を省略することは同じではない。

早く更新すること自体は新しくなかった

1997 年の RFC 2131 には、すでにリースの更新や再バインドの手順がある。クライアントは T1 より前に更新を試みることもできた。FORCERENEW を「予定時刻より早い更新を初めて可能にした仕組み」と説明するのは正確ではない。

変わったのは、早める判断の出発点である。端末側の必要やタイマーだけでなく、サーバー側の事情からも次のやり取りを始められるようになった。リースがまだ有効でも、別の設定を見直したい状況はあり得る。有効期限と管理者の変更希望は、異なる種類の情報だからだ。

アドレスを変える場合、RFC 3203 が示す道筋はさらに長い。通常の要求に対してサーバーが DHCPNAK を返し、クライアントが初期状態へ戻る。その後に DHCPDISCOVER と DHCPOFFER の交換が続く。FORCERENEW 自体が NAK なのではなく、新しいアドレスを確定させる ACK でもない。

毎回アドレスが変わるとも限らない。更新の結果として同じアドレスを使い続けることも、他のパラメーターだけを見直すことも考えられる。通知の名前から結果を読むのではなく、後続の通信から結果を確かめなければならない。

手動設定には別の返事がある

この限界が最もよく見えるのは、アドレスを手動で設定したホストである。アドレスの割り当てには頼らず、他の情報だけを DHCPINFORM で得ている端末もある。

RFC 3203 は、その端末に FORCERENEW が届いた場合、新たな DHCPINFORM で応答するよう求めている。DHCP で設定可能な項目だけが対象であり、手動の値を上書きすべきではない。サーバーからの呼びかけを受けても、端末の設定全体がそのサーバーの管轄に移るわけではない。

通常の更新と INFORM の区別を消すと、運用上も誤解が生じる。通知の後にアドレス要求が見えないからといって、必ずしも失敗ではない。そもそもその端末が何を DHCP に委ねていたのかを確認する必要がある。

文書は、家庭用ゲートウェイのサービス変更、宿泊施設のネットワーク、管理下でのサブネットの番号変更を用途の例に挙げた。これらは提案の動機であり、当時の普及率や現在の製品対応を示す調査ではない。また、設定変更で進行中のセッションが途切れる可能性も明記された。機能があることと、使う時機が適切であることは別問題だった。

応答がなければ、残るのは再送である

サーバーが通知を送っても、期待する要求が戻らない場合がある。RFC 3203 は指数バックオフによる再送と、回数の制限を求めた。最初の待ち時間はネットワークの条件に応じて選ぶのであり、どの環境にも同じ数値を当てはめる規定ではない。

再送は成功の証拠にはならない。通知が失われたのか、クライアントが処理しなかったのか、検証で拒否されたのかは、要求が来ないという事実だけでは決まらない。記録に残った送信回数を、そのまま設定済み端末数に置き換えることはできない。

また、この拡張はマルチキャストで届いた FORCERENEW を黙って破棄するよう定めている。正常な経路は、個別のクライアントへのユニキャストだ。広く呼びかければ一斉に設定が変わるという理解は、ここでも実際の手順を飛び越えている。

メッセージの識別には既存の枠を使った。RFC 2132 が定める DHCP メッセージ種別のオプション 53 に、新しい値 9 を加えたのである。新しい番号を共有することは、何を受け取ったかを識別するための条件であって、受信後のすべての動作を保証する条件ではない。

時機を選べる相手は、誰なのか

クライアントが質問する時刻を外から選べるなら、その入口は保護が必要になる。RFC 3203 は FORCERENEW の認証を必須とし、失敗した通知を破棄するよう定めた。参照先は同じ年の 6 月に出た RFC 3118 だった。

RFC 3118 には強さの異なる方式が含まれる。平文の設定トークンを照合する方式は弱い識別にとどまり、メッセージ全体の認証を提供しない。遅延認証では共有秘密を用いるが、その秘密は DHCP の交換とは別の方法で配られていることを前提にする。

個々の端末を認証するなら、その端末に対応した鍵の関係も管理する必要がある。サーバーから短い通知を出すだけでも、前段には鍵配布の運用がある。この費用を無視すると、小さなプロトコル変更がなぜ導入しにくいのかを見落とす。

2012 年 8 月の RFC 6704 は、従来の認証条件がこの用途には厳しすぎ、FORCERENEW の採用を妨げてきたと述べた。これはその時点の著者らの問題設定であり、現在の導入状況を測った数字ではない。新しい案は、保護する対象を絞ることで、別経路の鍵配布を不要にしようとした。

最初の ACK に、次の呼びかけの秘密を入れる

案の先例は、2003 年の DHCPv6 を定めた RFC 3315 にある Reconfigure Key だった。ここで重要なのは歴史的な鍵の受け渡し方であり、後に置き換えられた文書を現在の DHCPv6 全体の説明として使うことではない。

RFC 6704 の nonce 方式は、従来の DHCP 認証を使っておらず、双方がこの方式の使用に合意した場合に用いる。クライアントは DISCOVER と REQUEST で対応能力を示し、サーバーは OFFER で意向を示す。能力を知らせるオプションと、後でサーバーが送る認証情報は役割が違う。

必要な場面でサーバーは 128 ビットの十分にランダムな値を作り、REQUEST に対する ACK に載せる。クライアントはその nonce を記憶する。後の FORCERENEW では nonce 自体をもう一度送るのではなく、それを鍵として計算したメッセージ認証コードを送る。受信側は保存した値で確認できる。

対応を表明していないクライアントに、サーバーが一方的にこの認証オプションを付けてはならない。逆に、最初の選択過程で OFFER が方式を示したのに、その後の ACK に有効な対応情報がなければ、クライアントは破棄して初期状態へ戻る。これは交渉の整合性を守る条件だ。初回の相手が外部の信頼基盤で認証されたことを意味しない。

nonce という名称にも注意が要る。一度の通知で使い捨てになる値ではない。通常の更新時には、新しい値を作らない限り ACK に再掲しないのが規範文の指示であり、図に描かれた更新例を「毎回必ず交換する」と読むべきではない。一方、再バインド先が別のサーバーなら、そのサーバーは新しい値を作る必要がある。

認証できても、過去の通知かもしれない

この方式の歴史的な計算には HMAC-MD5 が使われた。これは暗号化ではなく、ここで述べるのも当時の設計であって、現在の暗号方式を推奨する話ではない。メッセージの検証には、保存した秘密のほかに再送攻撃を見分ける情報も関わる。

RFC 3118 の確認済み訂正 3474 は、2013 年にカウンターが「厳密に増加する」必要を明確にした。同じ値を繰り返すことを許さないためである。以前の認証コードが正しいままでも、その通知をもう一度新規のものとして受け入れてよいとは限らない。

こうした状態は、サーバーの入れ替えやクライアントの再初期化と無関係ではない。双方が何を保存し、どの交換でそれを得たかが、後の検証結果を支える。認証欄が存在するという見た目だけでは、必要な状態が引き継がれたかは分からない。

IANA の BOOTP・DHCP パラメーター登録 には、メッセージ種別 9、認証オプション 90、能力オプション 145 が別々に記録されている。これらは同じ欄の競合する番号ではない。共通の語彙を持つこと、実装が対応すること、実際に合意して使うことを区別するためにも、この違いは重要だ。

最初の交換までは守ってくれない

RFC 6704 が主に想定した相手は、通常の DHCP 交換を観察できないネットワーク外の攻撃者だった。nonce を知らなければ、相手の選んだ時刻にクライアントを呼び戻すための認証情報を作れない。保護対象をこの入口に絞ることが、鍵の事前配布を省く理由になった。

しかし最初の ACK を観察して nonce を得られる相手には、その前提が成り立たない。ローカルなリンク上で通信を見られる相手は、もともと通常の要求も観察できる。後の通知が検証できるからといって、最初の設定交換が独立に信頼できるようになるわけではない。

無効な通知を検証する処理にも負荷はかかる。大量の偽メッセージによる資源枯渇まで消えるとは言えない。実際の攻撃や被害の統計を示しているのではなく、設計文書が置いた脅威の境界を読むべき場面である。

FORCERENEW の歴史は、制御を増やす際に何を増やさなかったかを示す。サーバーは次の質問の時機に働きかけられる。だが、手動設定の管轄、通常の更新手順、最初の信頼、変更後のアプリケーションの安全性まで一つの通知で引き受けることはできない。矢印が逆向きになって戻ってくる、その一往復を省略しないことが、この拡張を正しく理解する出発点になる。