Subject: Re: [IPsec] Comments draft-kagarigi-ipsecme-ikev2-windowsync-04

From: Pekka Riikonen <[email-masked]>
Date: Fri, 3 Sep 2010 11:17:54 +0200 (CEST)

I am a bit sceptical about the draft as it appears to be solving something 
that doesn't have to be such a huge problem by introducing a new exchange.

First, the ESP sequence number sync.  In case of failover the online node 
should simply increment the sequence number with a large enough number; 
the anti-replay window can always move forward.  Implementations should 
also perform periodical sequence number sync in the cluster (fe. every 2-5 
seconds) to keep the numbers close enough in nodes.  I see no reason to 
sync this information between peers.  It will never work perfectly anyway 
(there is too much traffic).  More frequently you sync the sequence 
numbers in the cluster smaller the increment needs to be (calculate 
expected pps).

Second, the message ID problem in failover is a real problem but isn't the 
problem really the size of the message window?  If everyone would do 
SET_WINDOW_SIZE with large enough number (like 32), in failover we could 
do something like next_message_id += window_size / 2, and be happy. 
Though, implementation must ensure it never sends more than the increment 
(that's why window size of 1 doesn't work to begin with).  Why was the 
window size defined by default to 1 anyway?  Is there a reason why this 
wouldn't work? (SET_WINDOW_SIZE specifically allows us to move the 
window)

Any ongoing exchange at the time of the failover can be an issue (rare) 
but most can be eliminated with careful implementation.  For example, the 
following:

  - Delete IKE SA or IPSEC SA
   -> Sync delete to cluster before sending packet to network.  Nodes don't
      actually have to delete the SA, just mark it to be deleted.  This
      applies to both sending delete and receiving delete.

  - Rekey
   -> I don't see this as a problem.  New CHILD_SA or crash recovery solves
      the problem either immediately or relatively quickly.

  It's impossible to make this work perfectly (machines can crash at any
  point), but important thing is that your implementation can recover
  (support crash recovery, do DPD when oddities occur).

I don't much see need for a new exchange, though a draft that explains 
best ideas for implementing clustering and HA would be nice.

 	Pekka

---

From: Pekka Riikonen <[email-masked]>
Date: Sat, 4 Sep 2010 12:43:59 +0200 (CEST)

On Fri, 3 Sep 2010, Pekka Riikonen wrote:

: something like next_message_id += window_size / 2, and be happy. Though,
: implementation must ensure it never sends more than the increment (that's why
: window size of 1 doesn't work to begin with).  Why was the window size defined
: by default to 1 anyway?  Is there a reason why this wouldn't work?
:
This doesn't actually work.  I think I'm seeing some ambiquity in the spec 
when window size > 1.  But, there's still ways to make this work easier 
than with new exchange.

We could add new RESET_WINDOW notify that, when received inside a valid 
window will reset the left side of the window to the value requested.  In 
failover (assuming window size > 1), the online node can send the 
notification to reset the window to the new value.  Responder clears the 
old states in the window as initiator has now deemed them lost.   
Responder must reply with its N(RESET_WINDOW).

At the same time we should add GET_WINDOW_SIZE notify which initiator can 
use to request/require responder to set the window size.  Responder SHOULD 
respond with SET_WINDOW_SIZE of at least the same size.  So when initiator 
sends its N(SET_WINDOW_SIZE) it could at the same time require the 
responder to send it too.

All these notifications in the ikev2bis should be "MUST be supported".  

And then of course there's the poor man's way, where implementation after 
the failover could keep sending empty INFORMATIONAL's with new message 
ids, and wait until it receives response.  It now knows the message ids 
to both directions.  This requires that the message ids are synced in the 
cluster after every packet, so that node has recent values in the 
failover.

	Pekka

---

From: "Kalyani Garigipati (kagarigi)" <[email-masked]>
Date: Sat, 4 Sep 2010 16:46:42 +0530

Hi Pekka,

Thanks for the comments on draft.

Please find my comments inline.

Regards,

Kalyani

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Pekka Riikonen
Sent: Friday, September 03, 2010 2:48 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [IPsec] Comments draft-kagarigi-ipsecme-ikev2-windowsync-04

I am a bit sceptical about the draft as it appears to be solving
something 

that doesn't have to be such a huge problem by introducing a new
exchange.

First, the ESP sequence number sync.  In case of failover the online
node 

also perform periodical sequence number sync in the cluster (fe. every
2-5 

sync this information between peers.  It will never work perfectly
anyway 

expected pps).

Second, the message ID problem in failover is a real problem but isn't
the 

Though, implementation must ensure it never sends more than the
increment 

window)

[KALYANI] We can always have the larger window size and send the new
request from failover device with the incremented message Id.

But the problem with this approach is, In case of windowing unless all
the messages are received 

with in the window range , the window never moves, hence the lost

Request will never be sent and eventually the sa will have to be
deleted, which can be avoided if this draft is implemented.

but most can be eliminated with careful implementation.  For example,
the 

following:

   -> Sync delete to cluster before sending packet to network.  Nodes
don't

[KALYANI] If the message to delete the IKE SA is lost , then this would
make the active and failover device to be out-of-sync.

  - Rekey

   -> I don't see this as a problem.  New CHILD_SA or crash recovery
solves

[KALYANI] This draft proposes the synchronization of message Id's using
the IKE SA which is present on failover and peer devices.

In case of active member crash during IKE SA delete/rekey, the SA at
peer and failover device does not match(

 which means old sa is present on failover and new sa is present on
peer). IKE message Id synchronization is not meant to solve such issues.

      Pekka

_______________________________________________

IPsec mailing list

[email-masked]

https://www.ietf.org/mailman/listinfo/ipsec

---

From: "Kalyani Garigipati (kagarigi)" <[email-masked]>
Date: Sat, 4 Sep 2010 17:31:51 +0530

Hi Pekka,

What is the message Id that can be used to send the informational
exchange while sending RESET_WINDOW notify? I find that your approach is
similar to this draft as 

1. Initiator(failover) and responder(peer) agree upon the new range of
message Id's and ignore the lost message Id's.

Both the approaches define new notifies and need to send a informational
exchange to carry the notifies.

1. If window size is say some five and range expected is 4-8, and if
peer has got all four requests with values 5,6,7,8 and 4 is lost, then
there would be no message id that can be used to send the notify
reset_window.
The initiator will not know which message Id should be used to send the
new notify. 

And here the problem is not only to send the request, but also to
receive the request. The failover device should also know the
permissible range in which it can receive the requests from the peer. 

The idea to send a new informational exchange with message Id zero was
thought only because when the failover takes control it would not know
what message Id it can use to know the peer window values .This is the
basic problem of message Id synchronization, so having new notify itself
will not help.

Regards,
Kalyani

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Pekka Riikonen
Sent: Saturday, September 04, 2010 4:14 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [IPsec] Comments draft-kagarigi-ipsecme-ikev2-windowsync-04

: something like next_message_id += window_size / 2, and be happy.
Though,
: implementation must ensure it never sends more than the increment
(that's why
: window size of 1 doesn't work to begin with).  Why was the window size
defined
: by default to 1 anyway?  Is there a reason why this wouldn't work?
:
This doesn't actually work.  I think I'm seeing some ambiquity in the
spec 
when window size > 1.  But, there's still ways to make this work easier 
than with new exchange.

We could add new RESET_WINDOW notify that, when received inside a valid 
window will reset the left side of the window to the value requested.
In 
failover (assuming window size > 1), the online node can send the 
notification to reset the window to the new value.  Responder clears the

At the same time we should add GET_WINDOW_SIZE notify which initiator
can 
use to request/require responder to set the window size.  Responder
SHOULD 
respond with SET_WINDOW_SIZE of at least the same size.  So when
initiator 
sends its N(SET_WINDOW_SIZE) it could at the same time require the 
responder to send it too.

And then of course there's the poor man's way, where implementation
after 
the failover could keep sending empty INFORMATIONAL's with new message 
ids, and wait until it receives response.  It now knows the message ids 
to both directions.  This requires that the message ids are synced in
the 
cluster after every packet, so that node has recent values in the 
failover.

	Pekka

---

From: Pekka Riikonen <[email-masked]>
Date: Sat, 4 Sep 2010 14:55:34 +0200 (CEST)

On Sat, 4 Sep 2010, Kalyani Garigipati (kagarigi) wrote:

: 1. If window size is say some five and range expected is 4-8, and if
: peer has got all four requests with values 5,6,7,8 and 4 is lost, then
: there would be no message id that can be used to send the notify
: reset_window.
: The initiator will not know which message Id should be used to send the
: new notify. 
: 
It's true, you're right.

: The idea to send a new informational exchange with message Id zero was
: thought only because when the failover takes control it would not know
: what message Id it can use to know the peer window values .This is the
: 
Ah, how could I miss that, I still had the new exchange type back in my 
mind from the -00 draft which I read first and then didn't properly read 
the -04.  I'm currently in the midst of this same problem and started 
yesterday looking for a solution and google gave the -00 draft first, only 
later to notice the new version.  Sorry about that, my confusion.  
INFORMATIONAL exchange with message id 0 is definitely the best solution.

I'll probably implement the draft (need working solution soon), and of 
course will support also the finalized version of the draft.  Will need 
some poor man's message id discovery though with peers that doesn't 
support this (at least try DPDs before tearing down SAs).

Although, I'm still not sure if the ESP/AH seq number sync is needed.  It 
should be enough to start sending packets with new sequence numbers.  The 
anti-replay window will move automatically.  Also, imagine a huge cluster 
with tens of thousands of SAs, the number of notifications will grow 
quickly (not to mention packet size when including lots of them in one 
notify).

	Pekka

---

From: Yoav Nir <[email-masked]>
Date: Sun, 5 Sep 2010 09:26:16 +0300

> The initiator will not know which message Id should be used to send the

It's actually worse than that. If message #4 was missed, and 5-8 were received, then messages 5-8 are stored, but not processed. This has to be so, because suppose message 7 deletes the SA that was created in message 4, you can't process it before message 4. In any case, message 4 has to be processed before 5,6,7, and 8. So it doesn't matter what kind of exchange or notifies you have in the new message, or whether it is within the message window or outside it. As long as message 4 was lost, the IKE SA is toast unless we have some special processing rules.

---

From: Raj Singh <[email-masked]>
Date: Sun, 5 Sep 2010 12:55:46 +0530

On Sun, Sep 5, 2010 at 11:56 AM, Yoav Nir <[email-masked]> wrote:

> It's actually worse than that. If message #4 was missed, and 5-8 were
> received, then messages 5-8 are stored, but not processed. This has to be
> so, because suppose message 7 deletes the SA that was created in message 4,
> you can't process it before message 4. In any case, message 4 has to be
> processed before 5,6,7, and 8. So it doesn't matter what kind of exchange or
> notifies you have in the new message, or whether it is within the message
> window or outside it. As long as message 4 was lost, the IKE SA is toast
> unless we have some special processing rules.
>

According to me, that's not very correct interpretation of windowing. My
implementation goes ahead with the processing of message if the message is
within window. Storing messages and not processing them is not very
beneficial for the purpose of windowing concept.
Related with your example, how an peer can delete an SA in message # 7, if
message # 4 to create the SA was lost, the SA is not established yet.

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 8 Sep 2010 13:50:43 +0300

> message # 4 to create the SA was lost, the SA is not established yet.

IKEv2bis says (in section 2.3. Window Size for Overlapping Requests):

   An IKE endpoint supporting a window size greater than one ought to be
   capable of processing incoming requests out of order to maximize
   performance in the event of network failures or packet reordering.

so both processing the exchanges in order, or processing them out of
order is allowed, but the processing them out of order is the
preferred way. 
-- 
[email-masked]

---

From: Yoav Nir <[email-masked]>
Date: Thu, 9 Sep 2010 23:16:49 +0300

> order is allowed, but the processing them out of order is the

I can't come up with any cases where doing the operations in different order results in a different state, but it seems to me that sequence numbers are there for a reason.

Otherwise, why have sequence numbers at all?