web-dev-qa-db-ja.com

SPIの詳細を理解する

現在、試験のためにIKEとIPsecを学んでいます。両方のプロトコルでセキュリティパラメータインデックス（SPI）がどのように使用されるかについては多くの情報がありますが、一貫性を理解するのにいくつか問題があります。

まず、IKEでは、両方のパーティがそれぞれのSPI=をそれぞれの他のパーティと共有します。これらはそれぞれ2つのセキュリティアソシエーション（SA）に使用される両方のSPIになると思います。それぞれSAは一方向のみですが、正しいですか？

次に、IPsecの章では、物事はより複雑になります。さまざまなソースを読んで、私はこれがどのように正確に機能するかについての理論を持っていますが、私の理論が正しいかどうかはわかりません。 RFC 4301は言う：

SPI：着信パケットがバインドされる必要があるSAを識別するためにレシーバーによって使用される任意の32ビット値。[...]

IKEでは、各パーティーがSPIを他のパーティーと共有します。これは、SPIパーティーが設定するSPI発信SAではなく、着信SAに使用されますか？

これは、SAデータベース（SAD）に新しいSAを登録することに関して私が持っている別の質問を説明します

  • SAD_ADDは、IKEがSAに使用するSPIをすでに知っている場合に使用されます。
  • SAD_GETSPIは、使用されていないSPIを取得するために使用されます（もちろん、使用されているSPIと使用されていないSPIがわかっているため、SADは使用されていないSPIを返します）。さらに、不完全なSAが既に挿入されています。次に、SAD_UPDATEを使用して、欠落しているSPI=を以前に挿入されたSAに設定します。

さらに、私のメモでは、イニシエーターはSAD_ADDメソッドを使用し、レスポンダーはSAD_GETSPIおよびSAD_UPDATEを使用していると述べています。これは、レスポンダーがSPIを作成するレスポンダーであり、イニシエーターがこのSPIを自分のデータベースに追加するだけの場合です。これは、レスポンダーのIPアドレスと一緒に一意である必要があります。私の理論は正しいですか？

しかし、SAD_UPDATEメソッドが使用される理由がわかりません。私にとってこれは冗長に聞こえます：

  • SAD_GETSPI：「SA xを挿入したいSPI使用できますか？回答：未使用SPI：y。さらに、データベースにxをすでに挿入しています。挿入するSPI挿入する必要があることを教えてください。 "
  • SAD_UPDATE：「SA xを更新してください、SPIをyに設定してください。」
ipsecike
5
Misch

セキュリティパラメータインデックス（SPI）は、IKEおよびIPsecのセキュリティアソシエーション（SA）を参照する場合、異なる意味を持ちます。

  • [〜＃〜] ike [〜＃〜]の場合、2つの64ビットSPIがIKE SAを一意に識別します。 IKEv2 を指定すると、IKE_SA_INITリクエストでは、IKEヘッダーにローカルで一意のイニシエーターSPIのみが設定され、レスポンダーSPIはゼロになります。レスポンダは、その応答で同様にローカルで一意の値に設定します。 2つのSPIは、IKE SAがキー再生成されたときにのみ変更されます。

    現在イニシエーター/レスポンダーSPIと呼ばれるIKEヘッダーの2つのフィールドは、以前は RFC 2408 （ISAKMP）でイニシエーター/レスポンダーCookieと呼ばれていました。 IKEv2がCOOKIE通知ペイロードを使用して サービス拒否攻撃を阻止する であるため、これは混乱を招く可能性があります。

  • IPsecの場合、32ビットSPIは、IPsec SAを半一意的に識別します。これらのSAは単方向であるため、ESP/AHヘッダーには宛先のインバウンドSPIのSAのみが含まれます（常に両方のSPIを含むIKEヘッダーとは異なります）。 SPIはローカルで一意であるため、これと宛先アドレスは通常、SAを一意に識別するのに十分です。しかし、それは問題になる可能性があります。同じNATの背後にある2つのクライアントが同じVPNゲートウェイに接続するときに、同じローカルSPIを割り当てる場合SPIと宛先アドレスの組み合わせは、NATのパブリック側でも同じになるため、 DPカプセル化 が必要です。 UDPポートを使用すると、NATが受信パケットを適切なクライアントに送信できます。同様に、ゲートウェイは2つのSAを区別する手段を講じて、トラフィックを各クライアントに送信するときに正しいSAが使用されるようにする必要があります。

これは、パーティが設定するSPIが、送信SAではなく、受信SAに使用されるSPIであることを意味しますか？

はい、各ピアは受信SPIのSAを他のピアに送信します。

さらに、私のメモでは、イニシエーターはSAD_ADDメソッドを使用し、レスポンダーはSAD_GETSPIおよびSAD_UPDATEを使用していると述べています。

IPsec SAを確立するプロセス。 IKEv2のCREATE_CHILD_SA交換は、おおよそ次のように視覚化できます。

Initiator                               Responder
SAD_GETSPI (inbound SA)  ----------->   {select algorithms and derive keys}
                                        SAD_ADD (outbound SA)
                                        SAD_GETSPI (inbound SA)
{derive keys}            <-----------   SAD_UPDATE (inbound SA) 
SAD_UPDATE (inbound SA)
SAD_ADD (outbound SA)
  1. イニシエーターは、インバウンドSPIのSAを、暗号化アルゴリズムの提案と一緒に送信し、完全転送秘密が使用されている場合は、そのDiffie-Hellman係数をレスポンダーに送信します。
  2. レスポンダは適切なアルゴリズムを選択し、キーを派生させ（オプションでDHを使用）、SAのインストールを続行します。
  3. 次に、インバウンドSPIを、選択したアルゴリズム（およびオプションでそのDH係数）とともにイニシエーターに返します。イニシエーターにSAをインストールできるようになりました。

さらに、2つのピアは、確立されたSAの対象となるネットワークトラフィックを指定するトラフィックセレクターを交換します。

SAD_UPDATE：「SPI xを更新して、SPIをyに設定してください。」

それはSAD_UPDATEが行うことではありません。実際にはSPIはまったく変更されませんが、SAの他の側面のすべて（または一部）は変更されません。これらは主に暗号化/整合性アルゴリズムとキーです（ただし、他のものも含まれる場合があります）。 カプセル化 またはアンチリプレイウィンドウサイズ）。

通常、インバウンドSAに対してSAD_GETSPIの代わりにSAD_UPDATEおよびSAD_ADDを呼び出す必要がある理由は、すべての情報が利用できるレスポンダでも、SADが通常管理されているためです。オペレーティングシステムのカーネルによって、IKEデーモンはユーザーランドで動作します。したがって、SAD_GETSPIを呼び出すと、SPIが実際にローカルで一意になることが保証されます。これは保証されない場合があります。 2つのIKEデーモン（IKEv1とIKEv2用）またはSAを手動で管理するためのツール（ip xfrmやsetkeyなど）も、システムで同時に使用されます。

ただし、一部のシステムでは、レスポンダがSPIを指定せずにSAD_ADDを呼び出せるようにする簡素化があり、SADがSPIを割り当ててSAをインストールし、新しいSPIを返すことが考えられます。ただし、この場合、キーイングデーモンによる特別な処理が必要になります（そうしないと、発信側SAの場合はSAD_ADDを、着信側SAの場合はSAD_GETSPI/SAD_UPDATEを呼び出すことができます。

RFC 2367 （PF_KEYv2）は、これらの操作の詳細を提供します。

10
ecdsa