http://www.rtpro.yamaha.co.jp/RT/docs/relnote/Rev.07.01/relnote_07_01.16.txt Revision : 07.01.16 Release : Aug 2003, ヤマハ株式会社 RTX1000 Rev.7.01.16 リリースノート ========================================================================== ○ Rev.7.01.15からの変更点 ========================================================================== ■仕様変更 [] IKE SAを削除するときに同時にIPsec SAを削除する動作を無効にできるよ うにした。 [入力形式] ipsec ike restrict-dangling-sa GATEWAY ACTION [パラメータ] - GATEWAY ... セキュリティゲートウェイの識別子 - ACTION - auto ... IKE SAとIPsec SAを同期させる ただし、ダイヤルアップVPNのクライアント側でのみ - off ... IKE SAとIPsec SAを同期させない。 [説明] このコマンドはダイヤルアップVPNのクライアント側で動作している 時の、ダングリングSAの扱い方を設定する。 ダングリングSAとは、対応するIKE SAが寿命などにより消えてしまっ たIPsec SAのことを言う。RTシリーズでは基本的にはダングリングSA を許す方針で実装しており、IKE SAとIPsec SAを独立に管理するが、 ダイヤルアップVPNのクライアント側として動作している場合だけは、 このコマンドでダングリングSAの扱いを変更できる。 このコマンドでautoを設定すると、ダイヤルアップVPNのクライアン ト側でダングリングSAが発生した時には、それを強制的に削除する。 つまり、IKE SAが削除される時には、同時にそのIKE SAに基づいて生 成されたIPsec SAも削除する。 offを設定した時には、IKE SAとIPsec SAは独立に管理され、削除の タイミングは必ずしも同期しない。 ダイヤルアップVPNのクライアント側ではない場合には、このコマン ドの設定に関わらず常にIKE SAとIPsec SAは独立に管理され、削除の タイミングは必ずしも同期しない。 [ノート] ダングリングSAの強制削除が行なわれても、通常は新しいIKE SAに基 づいた新しいIPsec SAが存在するので通信に支障が出ることはない。 ダイヤルアップVPNのクライアント側でダングリングSAを許さないの は、IKEキープアライブを正しく機能させるために必要なことである。 IKEキープアライブでは、IKE SAに基づいてキープアライブを行なう。 ダングリングSAが発生した場合には、そのSAについてはキープアライ ブを行なうIKE SAが存在せず、キープアライブ動作が行なえない。そ のため、IKEキープアライブを有効に動作させるにはダングリングSA が発生したら強制的に削除して、通信は対応するIKE SAが存在する IPsec SAで行なわれるようにしなくてはいけない [ノート2] ダングリングSAの扱いについては、動作モードとリビジョンによって 動作が異なる。 +---------------------+-------------+---------+---------+-------------+ | Rev. | 7.01.05以前 | 7.01.08 | 7.01.15 | 7.01.16以降 | +---------------------+-------------+---------+---------+-------------+ | ダイヤルアップVPNの | (A) | (B) | (C) | | クライアント側 | | | | +---------------------+-------------+---------+---------+-------------+ | それ以外 | (A) | (B) | (A) | +---------------------+-------------+---------+---------+-------------+ (A) ダングリングSAが発生しても何もせず通信を続ける (B) ダングリングSAが発生した時にはそれを消去し、必要であれば新 しいSAを作成して通信を行なう (C) このコマンドにより動作を変更できる [デフォルト値] auto [2] 受信したIKEパケットを処理する前に蓄積するパケットキューの長さを設 定できるようにした。 [入力形式] ipsec ike queue length RECEIVE_QUEUE_LEN [パラメータ] RECEIVE_QUEUE_LEN ... 8 - 64 [説明] 受信したIKEパケットを処理する前に蓄積するキューの長さを設定す る。 このIKEパケット受信キューは、IKEパケットを短時間に集中的に受信 した場合に、処理するIKEパケットの数を制限するために用意されて いる。IKEパケットの処理には比較的長い時間が必要なため、一度に 処理するパケットの数を制限しておかないと、キューの後ろの方で受 信したパケットを処理するころには対向のルータでタイムアウトと検 知され、再送パケットがすでに送られてきている、という状況になっ てしまう。いずれにせよ再送されるならば、キューの長さを制限し早 めにパケットを捨ててしまった方が、ルータのCPU負荷を下げ、安定 した動作を行なわせることができる。 [ノート] Rev.7.01.15以前のファームウェアでは、このキューの長さは8で固定 されていた。 キューの長さを長くすると、一度に受信して処理できるIKEパケット の数を増やすことができる。しかし、あまり大きくすると、ルータ内 部にたまったIKEパケットの処理が遅れ、対向のルータでタイムアウ トと検知されてしまう可能性が増える。そのため、このコマンドの設 定を変更する時には、慎重に行なう必要がある。 通常の運用では、この設定を変更する必要はない。 [デフォルト値] 8 ■バグ修正 [1] IPsecとPPPoEで、暗号化されたパケットがPPPoEに出力されるような構成 で、暗号化された後のパケットをPPPoEインタフェースのMTU値に基づいて フラグメントしなくてはいけない時に、正しくパケットをフラグメントで きずに通信できなくなるバグを修正した。 ip tunnel mtuコマンドでトンネルインタフェースのMTU値を大きくしてい る場合に発生する。ip tunnel mtuコマンドの設定値がデフォルトの1280 である時には、暗号化された後にフラグメントされるということは通常発 生しないため、このバグに出会うことはない。