人力検索はてな
モバイル版を表示しています。PC版はこちら
i-mobile

IPsec、IKE v2についての質問です。参考図書はマスタリングTCP/IP IPsec編を使用しています。
念のため、質問のあとにページ番号を入れていますが、回答可能であれば、特にこの本に即している必要はありません。

?手動管理だと、リプレイ防止機能が使えないのはなぜでしょうか?カウンターがフルになるとリセットするため、古いパケットが再送されても見分けがつかなくなるという説明を読みましたが、それは手動でもIKEでも同じことではないのでしょうか?
(p22)

?RFC4301において、IKE v1のISAKMPと異なり、IKE v2のIKE_SAは一方向のSAの2本のペアとなっています。CHILD_SAも一方向のSAの2本のペアと理解しています。
そうすると、IKE_SA_INIT、IKE_AUTHでイニシエータが提示する複数のアルゴリズムの組み合わせから、イニシエータ→レスポンダ用とレスポンダ→イニシエータ用の「2つのSA」を、レスポンダは選択して、レスポンスのメッセージとしてProposalを2つ返すのでしょうか?(p241)

以上です。よろしくお願いいたします。

●質問者: blueblue
●カテゴリ:コンピュータ インターネット
✍キーワード:IPSec TCP/IP V2 けが アルゴリズム
○ 状態 :終了
└ 回答数 : 2/2件

▽最新の回答へ

1 ● たも
●35ポイント

最初の質問だけですが、ぐぐってみたところ、こんな RFC がありました。

http://www.ipa.go.jp/security/rfc/RFC2402JA.html#2.5


これによると、

ということのようです。つまり、おっしゃるとおり「カウンタがゼロに戻るならリプレイ防御ができない」のです。

それで、IKE があれば SA を使い捨てにできるため、カウンタが限界にいく前に新しい SA でゼロからやり直せるわけですね。

この場合、使っている鍵は新しいわけですから、リプレイしたところで無意味です。

◎質問者からの返答

ご回答ありがとうございます。

IKEだとカウンタがフルになる前にリキーを行うということで、リプレイ攻撃防御機能が有効に働くという論理が理解できました。

ご紹介いただいたRFCはAHのものですが、プロトコルに依存する話でもないと思いますので、論理は同じでしょうね。


2 ● たも
●35ポイント

二度目の回答ごめんなさい。

IKEv2 の initiator/responder 間における具体的なやりとりについては

http://www.ipa.go.jp/security/rfc/RFC4306EN.html#102

(IKE_SA_INIT と IKE_AUTH)

http://www.ipa.go.jp/security/rfc/RFC4306EN.html#103

(CREATE_CHILD_SA)

にわかりやすく図示されています。

IKE_SA_INIT や IKE_AUTH が二つぶんのアルゴリズムを返すとは書いていないようですね。

◎質問者からの返答

ご紹介ありがとうございます。

あとでじっくり該当箇所を見てみますが、そうすると、いつイニシエータ→レスポンダ、レスポンダ→イニシエータの別々のSAを交換するのか疑問です。。。

関連質問


●質問をもっと探す●



0.人力検索はてなトップ
8.このページを友達に紹介
9.このページの先頭へ
対応機種一覧
お問い合わせ
ヘルプ/お知らせ
ログイン
無料ユーザー登録
はてなトップ