人力検索はてな
ﾓﾊﾞｲﾙ版を表示しています｡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.このﾍﾟｰｼﾞの先頭へ
□対応機種一覧
□お問い合わせ
□ﾍﾙﾌﾟ/お知らせ
□ﾛｸﾞｲﾝ
□無料ﾕｰｻﾞｰ登録
□はてなﾄｯﾌﾟ