Subject: [IPsec] Moving forward with the HA solution draft

From: Yaron Sheffer <[email-masked]>
Date: Mon, 13 Sep 2010 10:44:42 +0200

Hi,

we have had a good deal of discussion of the HA solution at the 
Maastricht meeting and during the following weeks. Now, with my co-chair 
hat on, I'd like to suggest a way forward that I believe is in sync (bad 
pun intended) with the WG consensus.

I propose that version -01 of the draft should resolve the following 3 
issues (and if possible, no others):

    * Separate negotiation of synchronization of the IKE SA counters vs.
      the IPsec SA counters. IPsec counter sync should work even when
      used with a "normal" IKE exchange (non-zero Message ID).
    * A scalable solution for the IPsec counter sync: send a delta
      value that applies to all (incoming) child SAs, instead of sending
      one value per child SA.
    * The replay issue that Tero identified at the meeting.

If this is NOT in line with the group's consensus, or if I missed 
something big, let me know.

Thanks,
     Yaron

---

From: Pekka Riikonen <[email-masked]>
Date: Thu, 16 Sep 2010 10:49:07 +0200 (CEST)

On Mon, 13 Sep 2010, Yaron Sheffer wrote:

: I propose that version -01 of the draft should resolve the following 3 issues
: (and if possible, no others):
: 
:    * Separate negotiation of synchronization of the IKE SA counters vs.
:      the IPsec SA counters. IPsec counter sync should work even when
:      used with a "normal" IKE exchange (non-zero Message ID).
:    * A scalable solution for the IPsec counter sync: send a delta
:      value that applies to all (incoming) child SAs, instead of sending
:      one value per child SA.
:    * The replay issue that Tero identified at the meeting.
: 
I started implementing the draft yesterday and here are some of the issues 
that came up (in addition to the issues listed above):

- Error handling.  The draft explains what to do if the nonce in the 
response is wrong but it doesn't mention what to do if the entire 
SYNC_SA_COUNTER_INFO payload is malformed (in request or response).

- The SYNC_SA_COUNTER_INFO payload defined in the draft is sent inside 
Notify Payload, but the draft doesn't mention what to fill into the Notify 
Payload header.  Are the fields zero or should it define the Protocol ID, 
for example?  There's some redundancy between the Notify Payload and the 
SYNC_SA_COUNTER_INFO payload (in the header).

- The draft could also give additional reason for sending 
SYNC_SA_COUNTER_INFO request.  For example, in a cluster setup with two or 
more online nodes that actively handle IKE and IPSEC SAs any load 
balancing change that changes the ownwership of the IKE SA in the cluster 
could trigger the use of this protoocol.  This protocol applies to also 
non-failover cases when ownerships change (protocol may or may not be 
needed depending on the cluster implementation).

- Race condition when both ends are clusters and failover happen at the 
same time in both ends.  In this case both ends may end up sending the 
SYNC_SA_COUNTER_INFO request.  Since both ends now cannot know the window 
reliably some solution for this should be defined in the protocol.  One 
way to do this to say that implementations MUST set their window to the 
values of one and respond with that:

  Cluster A              Cluster B
    request SYNC      -->
                <--      request SYNC
    response (1,1)    -->
                <--      response (1,1)

If you receive SYNC_SA_COUNTER_INFO request while you're waiting for 
response to your own request it means that the remote peer has had 
failover too, and it cannot reliably return to you any valid values.  
Neither can you, so only thing you can do is to return window with values 
one.  (Actually implementation should check whether it has had failover 
(or the IKE SA has changed ownership) when it receives the request, even 
if it hasn't yet sent its own request, and in that case respond with the 
value one and set its own window.  Implementation must also be careful 
not to cancel its own pending request.)

- Validation of SYNC_SA_COUNTER_INFO request.  The draft could more 
clearly define what is the proper way of validating that a packet with 
message id 0 is actually a valid SYNC_SA_COUNTER_INFO request:

  - Message id MUST be 0
  - Exchange type MUST be INFORMATIONAL
  - Packet MUST be encrypted
  - IKE SA MUST be authenticated
  - Packet MUST have Notify Payload
  - The Notify type MUST be SYNC_SA_COUNTER_INFO

>From this it's clear that most implementations will have to do the 
validation in multiple steps.  One before decryption, one after decryption 
and perhaps one after decoding the Notify Payload.

	Pekka

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 16 Sep 2010 10:58:48 +0200

Hi Pekka,

my intention was to focus the work on the draft, so we can move towards 
a complete specification. The current document is incomplete and needs 
quite a few changes, but I also do *not* expect the next revision to be 
ready to implement. Sorry to disappoint you. Error handling, for 
example, is IMHO better left for a later revision.

On the other hand, you are raising valid issues, and I would like to ask 
the draft authors to record them on the issue tracker so that we can 
resolve them later.

Do you consider any of these issues as showstoppers for the next revision?

Thanks,
	Yaron

---

From: "Kalyani Garigipati (kagarigi)" <[email-masked]>
Date: Thu, 16 Sep 2010 14:34:42 +0530

Hi Pekka,

Regarding the race condition, I think instead of starting the message
Id's altogether with 1, we can have the devices sync up to the higher
value among the responses.

  Cluster A              Cluster B
    request SYNC      -->
                <--      request SYNC
    response (4,4)    -->
                <--      response (5,5)

Cluster A should update its values to 5,5 whereas Cluster B should not
update its values since its values are higher than the values at Cluster
A. 
Which means Cluster B has correctly synced its message values  to some
extent when compared with Cluster A.

In the next revision we shall explain this in the draft.

Regards,
kalyani

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Pekka Riikonen
Sent: Thursday, September 16, 2010 2:19 PM
To: Yaron Sheffer
Cc: IPsecme WG
Subject: Re: [IPsec] Moving forward with the HA solution draft

: I propose that version -01 of the draft should resolve the following 3
issues
: (and if possible, no others):
: 
:    * Separate negotiation of synchronization of the IKE SA counters
vs.
:      the IPsec SA counters. IPsec counter sync should work even when
:      used with a "normal" IKE exchange (non-zero Message ID).
:    * A scalable solution for the IPsec counter sync: send a delta
:      value that applies to all (incoming) child SAs, instead of
sending
:      one value per child SA.
:    * The replay issue that Tero identified at the meeting.
: 
I started implementing the draft yesterday and here are some of the
issues 
that came up (in addition to the issues listed above):

- The SYNC_SA_COUNTER_INFO payload defined in the draft is sent inside 
Notify Payload, but the draft doesn't mention what to fill into the
Notify 
Payload header.  Are the fields zero or should it define the Protocol
ID, 
for example?  There's some redundancy between the Notify Payload and the

- The draft could also give additional reason for sending 
SYNC_SA_COUNTER_INFO request.  For example, in a cluster setup with two
or 
more online nodes that actively handle IKE and IPSEC SAs any load 
balancing change that changes the ownwership of the IKE SA in the
cluster 
could trigger the use of this protoocol.  This protocol applies to also 
non-failover cases when ownerships change (protocol may or may not be 
needed depending on the cluster implementation).

SYNC_SA_COUNTER_INFO request.  Since both ends now cannot know the
window 

  Cluster A              Cluster B
    request SYNC      -->
                <--      request SYNC
    response (1,1)    -->
                <--      response (1,1)

Neither can you, so only thing you can do is to return window with
values 

  - Message id MUST be 0

>From this it's clear that most implementations will have to do the 
validation in multiple steps.  One before decryption, one after
decryption 
and perhaps one after decoding the Notify Payload.

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

---

From: Pekka Riikonen <[email-masked]>
Date: Thu, 16 Sep 2010 11:32:10 +0200 (CEST)

On Thu, 16 Sep 2010, Yaron Sheffer wrote:

: my intention was to focus the work on the draft, so we can move towards a
: complete specification. The current document is incomplete and needs quite a
: few changes, but I also do *not* expect the next revision to be ready to
: implement. Sorry to disappoint you. Error handling, for example, is IMHO
: better left for a later revision.
: 
I know, no worries.  We (as in me) need a solution to this problem soon so 
I will implement some version of the protocol and use it with our 
products.  I will support also the final version of the protocol.

: On the other hand, you are raising valid issues, and I would like to ask 
: the draft authors to record them on the issue tracker so that we can 
: resolve them later.
: 
: Do you consider any of these issues as showstoppers for the next revision?
: 
No.

	Pekka

---

From: Pekka Riikonen <[email-masked]>
Date: Thu, 16 Sep 2010 11:43:48 +0200 (CEST)

On Thu, 16 Sep 2010, Kalyani Garigipati (kagarigi) wrote:

: Regarding the race condition, I think instead of starting the message
: Id's altogether with 1, we can have the devices sync up to the higher
: value among the responses.
: 
:   Cluster A              Cluster B
:     request SYNC      -->
:                 <--      request SYNC
:     response (4,4)    -->
:                 <--      response (5,5)
: 
: Cluster A should update its values to 5,5 whereas Cluster B should not
: update its values since its values are higher than the values at Cluster
: A. 
: Which means Cluster B has correctly synced its message values  to some
: extent when compared with Cluster A.
: 
I don't think this can work, because the responses can cross each other in 
the network also, and most likely do if the requests did as well.  That 
is, Cluster A responds same time as Cluster B before it has received the 
response.  The implementation would have to wait for the response before 
sending its own response.  But, what if the other end is waiting it also?  
It's a dead lock.

I think it needs to be a pre-defined value that both end set in this case 
or there needs to be some arbitration between the peers to deicde who 
waits.  I'd go for the simplest solution.

	Pekka

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 16 Sep 2010 11:48:57 +0200

We already have "arbitration" for a similar problem: 
http://tools.ietf.org/html/rfc5996#section-2.8.1

Thanks,
	Yaron

On 09/16/2010 11:43 AM, Pekka Riikonen wrote:
> :<--      request SYNC
> :<--      response (5,5)

---

From: "Kalyani Garigipati (kagarigi)" <[email-masked]>
Date: Thu, 16 Sep 2010 15:22:56 +0530

Hi Pekka,

I think this would work even in the case when the responses are
crossing.

Let each device send its response irrespective of whether it itself has
just sent the request.

Irrespective of who sent/received the response first, if we sync to the
higher values, then eventually both the devices will end up having same
values.

In the approach which I suggested, B need not wait for A to respond. It
can just send its values and ignore (don't update the received values )
the message response received from A

Please correct me if I am missing something. 

While arbitration can also be used, the above approach seems simple.

Regards,

Kalyani

-----Original Message-----
From: Pekka Riikonen [mailto:[email-masked]] 
Sent: Thursday, September 16, 2010 3:14 PM
To: Kalyani Garigipati (kagarigi)
Cc: Yaron Sheffer; IPsecme WG
Subject: RE: [IPsec] Moving forward with the HA solution draft

: 

:   Cluster A              Cluster B

:     request SYNC      -->

:                 <--      request SYNC

:     response (4,4)    -->

:                 <--      response (5,5)

: 

: update its values since its values are higher than the values at
Cluster

: A. 

: 

I don't think this can work, because the responses can cross each other
in 

sending its own response.  But, what if the other end is waiting it
also?  

It's a dead lock.

I think it needs to be a pre-defined value that both end set in this
case 

      Pekka

---

From: Pekka Riikonen <[email-masked]>
Date: Thu, 16 Sep 2010 12:02:59 +0200 (CEST)

: Irrespective of who sent/received the response first, if we sync to the
: higher values, then eventually both the devices will end up having same
: values.
: 
: In the approach which I suggested, B need not wait for A to respond. It
: can just send its values and ignore (don't update the received values )
: the message response received from A
: 
You're right, it works when using always the highest values.

	Pekka