Re: IKE_SA SPI with a changed address
Corrado Derenale <derenale@polito.it> Thu, 29 May 2003 10:36 UTC
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25380 for <ipsec-archive@lists.ietf.org>; Thu, 29 May 2003 06:36:59 -0400 (EDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA18432 Thu, 29 May 2003 03:48:10 -0400 (EDT)
Message-ID: <3ED59027.3080303@polito.it>
Date: Thu, 29 May 2003 06:44:23 +0200
From: Corrado Derenale <derenale@polito.it>
Reply-To: derenale@polito.it
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020830
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ipsec@lists.tislabs.com
Subject: Re: IKE_SA SPI with a changed address
References: <200305271547.h4RFlnof044936@givry.rennes.enst-bretagne.fr>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit
Hello, Francis Dupont wrote: > In your previous mail you wrote: > > what would happen in IKEv2 if the Initiator and Responder change their > IP adresses after have established an IKE_SA? > > => nothing very good: > - NAT traversal includes an optional automatic peer address update > for all SAs for a peer which is detected to be behind a NAT. > - responses are required to be sent with source/destination address/port > reversed, so received requests will be correctly answered. > - without an explicit peer address update mechanism (there is a WG > agreement to study such a thing in the close future) the best is > just to rekey the IKE_SA. I was against the NAT yet before reading the draft-dupont-transient-pseudonat-01.txt but now, after that reading I'm even more against it! The problem was not for NAT traversal, I hope that with the IPv6 coming all that problems with NAT will vanish with the NAT itself, but with the mobile user. I was thinking about keep-up an IKE_SA even if one of the peers change his network access (change WLAN hot spot) end conseguently its IP address > > It is still possible refernce the SAD with the SPI (the IKE_SA SPI) > > => yes, this is the role of the SPI and any IKEv2 implementation > which uses addresses to look up an IKE_SA should be nuked. This sounds very good to me. > > found in the CREATE_CHILS_SA header in order to retrieve the parametres > to generate a new CHILD_SA? > > => an IKE_SA rekey will use the addresses IKE runs over so this should work. > BTW as the peer addresses are not protected in this case and some attacks > can be built using this security flaw, I think that you refer to some DoS attacks, because only the authenticated peers can negotiate a new CHILD_SA and derive new cryptographic material from the one negotiated and authenticated during the IKE_SA_INIT. Am I right? > it is possible a future draft > will change this... For instance I interpret Jari and Tero's proposal > as keeping the peer addresses seen in the first message where they are > indirectly protected, note the proposal includes an explicit update > mechanism too. That will be very usefull in the mobile/nomadic user scenario. > Nothing is really decided, only my firm intention to > raise a concern if nothing is done about peer address protection > before the last call. > > Thanks > > Francis.Dupont@enst-bretagne.fr > > PS: read draft-dupont-transient-pseudonat-01.txt for an example > of an attack based on the lack of protection, and RFC 3519 for > a defense against a similar problem in Mobile IP which was never > claimed to be a security protocol... :) > Thank you, /cdr
- IKE_SA SPI with a changed address Corrado Derenale
- Re: IKE_SA SPI with a changed address Francis Dupont
- Re: IKE_SA SPI with a changed address Corrado Derenale