Subject: [IPsec] query related to rekey

From: "Prashant Batra (prbatra)" <[email-masked]>
Date: Sat, 21 Jan 2012 01:48:47 +0530

Hi,

Section 2.8 of rfc-5996 states handling for rekeying. The text-

>From a technical correctness and interoperability perspective, the

   responder MAY begin sending on an SA as soon as it sends its response

   to the CREATE_CHILD_SA request.  In some situations, however, this

   could result in packets unnecessarily being dropped, so an

   implementation MAY defer such sending.

   The responder can be assured that the initiator is prepared to

   receive messages on an SA if either (1) it has received a

   cryptographically valid message on the other half of the SA pair, or

   (2) the new SA rekeys an existing SA and it receives an IKE request

   to close the replaced SA.  When rekeying an SA, the responder

   continues to send traffic on the old SA until one of those events

   occurs.  When establishing a new SA, the responder MAY defer sending

   messages on a new SA until either it receives one or a timeout has

   occurred.  If an initiator receives a message on an SA for which it

   has not received a response to its CREATE_CHILD_SA request, it

   interprets that as a likely packet loss and retransmits the

   CREATE_CHILD_SA request.  An initiator MAY send a dummy ESP message

   on a newly created ESP SA if it has no messages queued in order to

   assure the responder that the initiator is ready to receive messages.

After initiating a rekey or responding to a rekey, 

Is it correct to say, that any request should continue to be sent on old
SA until you receive a DELETE request or you send a DELETE request

to delete the rekeyed SA?

The new SA should only be used after the old SA gets deleted.

Regards,

Prashant

---

From: Nico Williams <[email-masked]>
Date: Fri, 20 Jan 2012 14:49:21 -0600

On Fri, Jan 20, 2012 at 2:18 PM, Prashant Batra (prbatra)
<[email-masked]> wrote:
> Is it correct to say, that any request should continue to be sent on old SA
> until you receive a DELETE request or you send a DELETE request

Clearly some interlocking here would be nice, otherwise there will be
a race and high likelihood of dropped packets, with ensuing pain at
higher layers.  IMO the CREATE_CHILD_SA reply indicates that the peer
is ready to receive on that SA, but the local node may not be able to
do so until the CREATE_CHILD_SA reply is processed, so the peer should
NOT send on the new SA until it sees a DELETE of the old child SA.

In other words:

 - assume that the responder to a CREATE_CHILD_SA is ready to receive
ESP/AH on the new SA SPI as soon as the responder's CREATE_CHILD_SA
reply is received, and by corollary the initiator can start sending on
the new SA immediately;

 - assume that the initiator of a CREATE_CHILD_SA exchange is NOT
ready to receive ESP/AH on the new SA SPI until the initiator sends a
DELETE payload deleting the old SA SPI, so the responder should NOT
send on the new SA until it gets that DELETE.

Nico
--

---

From: "Prashant Batra (prbatra)" <[email-masked]>
Date: Sat, 21 Jan 2012 02:40:52 +0530

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Nico Williams
Sent: Saturday, January 21, 2012 2:19 AM
To: Prashant Batra (prbatra)
Cc: [email-masked]
Subject: Re: [IPsec] query related to rekey

[Prashant] That's, from the responder side, but it may happen that the
node initiating IKE_REKEY wants to initiate CHILD_SA_REKEY 
after sending IKE_REKEY_REQUEST as childsa is expired. So, it has to do
it on old IKE_SA as he has not received the response.
So is this case correct?

In other words:

 - assume that the initiator of a CREATE_CHILD_SA exchange is NOT
ready to receive ESP/AH on the new SA SPI until the initiator sends a
DELETE payload deleting the old SA SPI, so the responder should NOT
send on the new SA until it gets that DELETE.
[Prashant] So, what is an ideal implementation that should be followed.
I think, sticking to one standard, that's always send on the old SA
until you send DELETE is a good option.

Nico
--
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Nico Williams <[email-masked]>
Date: Fri, 20 Jan 2012 15:40:16 -0600

> it on old IKE_SA as he has not received the response.

I described both sides.  Again: the initiator should use the new SA as
soon as the responder rekey reply is processed by the initiator, while
the responder should use the old SA until the initiator deletes it.

Obviously, if the old SA expires, well, the responder must use the new
SA.  So initiate rekeys such that there's enough time to complete the
rekey.

As for simultaneous re-keying, well, see section 2.8.1 of RFC5996.

> until you send DELETE is a good option.

On the responder side, yes, subject to the caveats about SA expiration
and simultaneous rekeying.

On the initiator side you should send with the new SA as soon as you install it.

Nico
--

---

From: "Prashant Batra (prbatra)" <[email-masked]>
Date: Sat, 21 Jan 2012 03:25:35 +0530

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Nico Williams
Sent: Saturday, January 21, 2012 3:10 AM
To: Prashant Batra (prbatra)
Cc: [email-masked]
Subject: Re: [IPsec] query related to rekey

[Prashant] Yes, that should be fine.

[Prashant] Still, one case if ikesa and childsa expire at the same time, then assume a node initiates ikesa-rekey, 
and wants to initiate childsa-rekey also, then should it wait for the response of ikesa-rekey to come and then initiate 
chilsa-rekey on the new SA or initiate childsa-rekey on the old SA before processing the ikesa-rekey response.

Nico

---

From: Nico Williams <[email-masked]>
Date: Fri, 20 Jan 2012 16:02:13 -0600

> chilsa-rekey on the new SA or initiate childsa-rekey on the old SA before processing the ikesa-rekey response.

Don't forget RFC6023.

---

From: Yoav Nir <[email-masked]>
Date: Sat, 21 Jan 2012 01:26:54 +0200

> send on the new SA until it gets that DELETE.

There are enough weird implementations out there that either never send the DELETE or send it after a long time (as much as a minute), that I would not go that far. I think the responder should only send on the new SA after either of the following two things happens:
 1. A packet arrives on the new inbound SA
 2. some time has passed (maybe 0.5 second)

You can add reception of the DELETE as a third option if you like, but really nothing bad happens if you send on an SA before the peer was ready. At worst it generates an unknown SPI log on the peer and forces the application or transport layer to retransmit.