Re: IKE_SA SPI with a changed address

[Corrado Derenale <derenale@polito.it>]

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