20 Jun 2012 04:14

## Re: Updates to the IKEv2 Extension for IKEv2/IPsec High Availablity

Hi Kalyani,

First I'd like to make some clarifications according to your comments, and leave other clarifications to further discussions.

1. Clarification for case C in Section 2.2
(case C is the most troublesome in this section IMO.So I'd like to clarify it.)
1.1 Notation for case C in Section 2.2

x: the maximum message ID received from the peer party
y: the next sender message ID

a0: the old active cluster member
a1: the new active cluster member
b:  the peer

a0[t].x  a0's maximum message ID received from the peer b until time t
a0[t].y  a0's next sender message ID  at time t

a1[t].x  a1's maximum message ID received from the peer b  until time t
a1[t].y  a1's next sender message ID  at time t

b[t].x   b's maximum message ID received from the cluster  until time t
b[t].y   b's next sender message ID at time t

T0: At this time point, the last synchronization between a0 and a1 is carried out

T1: At this time point, the failover event occurs

T2: At this time point, the Message ID synchronization between a1 and b starts

T3: At this time point, the Message ID synchronization between a1 and b ends

SW: the sender window size of the cluster. Let's assume SW is 5.

----T0--------T1----------T2----------T3-------------------------------------

1.2 Analysis for case C in Section 2.2

We know that:

a1[T0].x == a0[T0].x
a1[T0].y == a0[T0].y
(The reaon is that at T0, the synchronization between a0 and a1 is carried out.)

And

a1[T1].x == a0[T0].x
a1[T1].y == a0[T0].y

And

a1[T2].x == a0[T0].x
a1[T2].y == a0[T0].y

(The reaon is that from T0 to T2, the state data of a1 keeps unchanged.)

According to RFC 6311,

"M1 is the next sender's Message ID to be used by the member.  M1
MUST be chosen so that it is larger than any value known to have
been used.  It is RECOMMENDED to increment the known value at
least by the size of the IKE sender window."

At T2, the new active member a1 can set M1=a1[T2].y + SW.

And

"M2 MUST be at least the higher of the received M1, and one more
than the highest sender value received from the cluster.  This
includes any previous received synchronization messages."

At T2, the peer b can set M2 = max(M1, 1 + b[T2].x).

M1==a1[T2].y + SW => M1 == a0[T0].y + SW  => M1 == a0[T0].y + 5

Suppose some message exchanges (i.e., 10 messages) have been carried out from T0 to T2, it's possible that b[T2].x + 1 > a0[T0].y + 5.

Then the peer b sets M2=1 + b[T2].x.

At T3, when the new active member a1 receives the Message ID synchronization response from the peer b, a1  sets a1[T3].y = M2.

a1[T3].y == M2 => a1[T3].y ==1 + b[T2].x.

At T2, a0[T2].y could be b[T2].x+5.
(The reaon is that a0's sent messages with Message IDs b[T2].x+1, b[T2].x+2,b[T2].x+3,b[T2].x+4,b[T2].x+5 may NOT have reached to the peer b.)

This means a1[T3].y < a0[T2].y.

This means the first five messages sent by the new active member a1 will have Message IDs b[T2].x+1, b[T2].x+2,b[T2].x+3,b[T2].x+4,b[T2].x+5.

Suppose after T3, the peer receives the old active member a0's sent messages with Message IDs b[T2].x+1, b[T2].x+2,b[T2].x+3,b[T2].x+4,b[T2].x+5, and sends response messages.

After that, the new active member a1 sends the first five request messages with Message IDs b[T2].x+1, b[T2].x+2,b[T2].x+3,b[T2].x+4,b[T2].x+5.
After receving these request messages, the peer b will regards these requests as resent messages, and returns response messages for
requests of  a0's sent messages with Message IDs b[T2].x+1, b[T2].x+2,b[T2].x+3,b[T2].x+4,b[T2].x+5 to a1.
(My understanding, according to RFC 5996, is that the peer should treat the new active member's request messages as resent reqeusts. )
re-sent
As a result, the peer b receives acceptable but mismatched responses for its request messages with Message IDs a1[T2].x+1, a1[T2].x+2,a1[T2].x+3,a1[T2].x+4,a1[T2].x+5.

For a concrete example, let's assume:

a1[T0].x == a0[T0].x = 9
a1[T0].y == a0[T0].y = 20

b[T0].x = 19
b[TO].y = 10

From T0 to T1, the old active member a0 have sent 10 request messages to the peer b, and 5 messages have been received and acknowledged by the peer b.

This means that a0[T2].y = 30, b[T2].x = 24. Note request messages with Message ID 25,26,27,28,29 have been sent by the old active member a0, but have NOT reached the peer b0. (The sender window size of the cluster is 5.)

According to RFC 6311,

"M1 is the next sender's Message ID to be used by the member.  M1
MUST be chosen so that it is larger than any value known to have
been used.  It is RECOMMENDED to increment the known value at
least by the size of the IKE sender window."

M1 == a1[T2].y + SW == 20 + 5 == 25
(a1[T2].y == a1[T0].y == 20)

And
"M2 MUST be at least the higher of the received M1, and one more
than the highest sender value received from the cluster.  This
includes any previous received synchronization messages."

M2 == max{M1, 1 + b[T2].x)== max(25,1+24) == 25

After the new active member a1 receives M2, a1 sets a1[T2].y == 25 < a0[T2].y == 30.

The Message ID for the new active member a1 numbers from 25.

The first five Message IDs are 25, 26, 27,28,29.

When the new active member a1 sends request messages with Messages IDs 25, 26,27,28,29, since the peer b has processed the request message with the same Message IDs, the peer b will return response messages for the request messages from the old active member a0.

Then a1 receives acceptable but mismacthed response messages.

2. Clarifications for the simultanesous failover case F in Section 2.3
For the simultaneous failover, case F is the most devastating IMO. So I'd like to clarify it first.
2.1 Notation for the simultanesous failover case F in Section 2.3

a0: the old active cluster member of the cluster a
a1: the new active cluster member of the cluster a
b0: the old active cluster member of the cluster b
b1: the new active cluster member of the cluster b

T0: At this time point, the last synchronization between a0/b0 and a1/b1 is carried out,

T1: At this time point, the simultaneous failover event occurs

T2: At this time point, the Message ID synchronization between a1 and b1 starts

T3: At this time point, the Message ID synchronization between a1 and b1 ends

----T0--------T1----------T2----------T3-------------------------------------

2.2 Analysis for the simultanesous failover case F in Section 2.3

It's possible that from T0 to T1, a0 and b0 deletes the old IKE SA sa0 and creates a new IKE SA sa1.
But at T2, a1 and b1 do NOT know what has happened from T0 and T1, and do NOT know the existance of the new IKE SA sa1, and use the old IKE SA sa0 to carry out Message ID synchronization.
This may bring some more seriouse problem. So  when simultaneous failover occurs, a simple two-way synchronization  may not be an appropriate solution.

"Kalyani Garigipati (kagarigi)" <kagarigi <at> cisco.com>

2012-06-14 19:14

 收件人 "zhang.ruishan zte.com.cn" zte.com.cn>, "ipsec ietf.org" ietf.org> 抄送 主题 Re: [IPsec] Updates to the IKEv2 Extension for IKEv2/IPsec        High        Availablity

Hi Zhang,

Thanks for going through the RFC 6311 .

I have gone through your  proposed draft and felt that there is some confusion regarding the message id concept of ikev2.

I have seen that in section 2.3 you were comparing the higer sender value of x2 with y2.
That is wrong. when x2 proposes the next higher message id to be used to send a request ,
then on y2 you shld tally it with the next higher message id of the request to be recieved
(and not with the next higher message id of the request to be sent)

in ikev2 the  message id of requests to be sent are entirely different from message id of requests to be received.
that is why RFC says a message id is used four times on a given device.

1. message id X is used while sending a request
2. message id X is used while receiving the response
3. message id X is used to receive a request
4. message id X is used to send a response.

Section 2.1:  This is a known issue and that is why using RFC 6311,  we are synchronising the message id's

Section 2.2: The peer is assumed to be proper anchor point which has correct info of message id of requests sent and recieved,
even when peer is cluster member , among the two devices one of them would be less wrong and have higher accurate values of message id's .
so we pick up that value. I dont see any issue here.

Section 2.3: First of all there is no relation between M1 and P1.
on a given device.
--- M1 is the proposed message id of the request to be sent
P1 is the proposed message id of the request to be received.

when simulatenous failover happens, x2 might have higher value of M1 when compared to y2 , but x2 might have lower value of P1 when compared to y2.
It does'nt matter. both are independent. what we eventually do is compare the M1 value across x2 and y2 and pick the higer one.
same process is repeated for P1.

case 1 to 6 are already handled by basic ikev2 RFC . like if we receive same message id twice , then we retransmit or drop it if it is outside the window.

Section 3:   during simultaneous failover both the cluster and the peer member would be in unreliable state.
Both of them are wrong , but one of them is less wrong !!! so we want to start from that point to synchronise the message id's.

so we are allowing both the members to announce their message id's and then eventually we would synchronise to the higher number.
I dont see any flaw here. Please explain with an example.

By your proposal in case of simultaneous failover, both the cluster and peer will be in UNSYNED state and
both would end up sending and rejecting the synchronisation request.
This would lead to repeated synchronisation efforts and the problem of message synchronisation is never solved.

so UNSYNED state is not required.

Section 4:

I feel that RFC 6311 already solves the message id synchronisation issue.
I dont think we need to increment M1 by double the window size as proposed by you.
Like M1 is 3 , M2 is 4 etc etc.

Numbers make it more clear.

regards,
kalyani

From: ipsec-bounces <at> ietf.org [mailto:ipsec-bounces <at> ietf.org] On Behalf Of zhang.ruishan <at> zte.com.cn
Sent: Monday, June 11, 2012 7:36 AM
To: ipsec <at> ietf.org
Subject: [IPsec] Updates to the IKEv2 Extension for IKEv2/IPsec High Availablity

Dear All,

I've submitted a new draft " Updates to the IKEv2 Extension for IKEv2/IPsec High Availablity". This draft analyzes some issues in RFC 6311,

BR,

Ruishan Zhang_______________________________________________
IPsec mailing list
IPsec <at> ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

```_______________________________________________
IPsec mailing list
IPsec <at> ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
```

Gmane