Hi Valery,
I agree with you that the newly
active cluster member may receive
an acceptable but mismatched response
message. And in such an case,
the situation will
become unpredictable and may cause
some security risks.
In my opinion, even the above case happens
rarely, we should let developers aware of such a risk.
I think it's better if we can make some updates
to RFC 6311.
BR,
Ruishan Zhang
"Valery Smyslov"
<svanru <at> gmail.com>
发件人: ipsec-bounces <at> ietf.org
2012-06-22 20:39
|
|
收件人
|
"Kalyani Garigipati \(kagarigi\)"
<kagarigi <at> cisco.com>, <zhang.ruishan <at> zte.com.cn>
|
|
抄送
|
ipsec <at> ietf.org, ipsec-bounces <at> ietf.org
|
|
主题
|
Re: [IPsec] Updates to the IKEv2 Extension
for IKEv2/IPsec High Availablity |
|
Hi,
I tend to agree with Zhang, that described
scenario may take place.
It may happen if, for some reason, newly
active member picks M1
lower than the highest value used for request
by previously active member.
Sure, bullet 1 in section 5.1 of RFC6311
says that newly active member
MUST choose M1 larger than any value known
to have been used,
but the question is - how it can reliably
calculate this value?
If synchronization channel between members
is reliable and syncronization messages
are frequent enough (say, for each changes
of Message ID counters),
than no problem here. But if synchronization
between members is not so frequent
or channel allows message loss, than newly
active member can only
estimate the highest sender's Message ID
used by previously active
member. And if its estimation appears to
become wrong (less than
actually used), than 2 scenarious are possible:
1. If last requests made by previously active
member get delayed
on their fly to peer and arrive
there AFTER Message ID syncronization
is finished, than we have Zhang's
scenario - for peer they will look
like generated by newly active
member and it will respond to them
correspondently, but for newly
active member those responses
will be either unexpected (if
it doesn't generate any request yet)
or incorrectly processed (if
it has already made some requests).
In the latter case situation
will become unpredictable.
// That's the point. In this case,
RFC 6311 may end up with a wrong rather than an unsuccessful Message ID
synchronization.
In my opinion, even the above
case happens rarely, we should let developers aware of such a risk.
I think it's better if we can
make some updates to RFC 6311.
2. The other problem in this situation is
that according to bullet 4
in section 5.1 of RFC6311 peer
MUST silently drop any message,
containing M1 less or equal
than the highest value it has seen from
the cluster. Again, if newly
active member incorrectly estimates
the highest value, used by
previously active member and send
smaller value in M1, than peer
will silently drop the message,
that will eventually lead to
IKE SA deletion.
Regards,
Smyslov Valery.
----- Original Message -----
From:
Kalyani
Garigipati (kagarigi)
To:
zhang.ruishan <at> zte.com.cn
Cc:
ipsec <at> ietf.org
;
ipsec-bounces <at> ietf.org
Sent: 20 июня 2012 г.
15:26
Subject: Re: [IPsec] Updates
to the IKEv2 Extension for IKEv2/IPsec High Availablity
Hi Zhang,
For Analysis 1
=========================================================
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
I think there is confusion
above.
I guess what u actually wanted
to convey is
a0[t].x a0's maximum
message ID of the request sent and orderly response received from the peer
b until time t , say if a has received responses for 2 and 3 and 5 ,
this value is 3. So now the window would be 4-8 (inclusive)
a0[t].y a0's next request
message ID to be sent at time t , this value is 6 , if it has already sent
the requests 2,3,4,5,
b[t].x b's maximum
message ID of the orderly response sent to cluster until time t ,
if it has sent response to 2,3 and 5 id requests , it is still 3.
b[t].y b's next message
id of the request to be received, which is 6
I guess the example has wrong
values.
if window size is 5
then
For a concrete example, let's
assume:
a1[T0].x == a0[T0].x = 9
---------------how can x and y vary by 10 when the window size is 5 ?
a1[T0].y == a0[T0].y = 20
b[T0].x = 19 -- same
is the case here..
b[TO].y = 10
Please adjust these values
and then there will be no issues as mentioned by you.
also please refer to the
section 8.1 and 9 of the RFC 6311 which says that when the window moves
to the synchronised value,
all the old pending requests
and to-be retransmitted responses should be deleted. So the below issue
will not happen
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.
For Analysis 2
This is the problem of basic
HA simulatenous fail-over and not just about message ID synchronisation.
when both of the devices
don’t have new sa and just have the old sa.
Then they will continue
with the old sa or bring down the sa based on the administrative control.
the sync time within a cluster
among a and b might be same or different due to which one of them
would have old sa and another would have new sa. in such
cases both the sa would be
deleted eventually and new sa is established.
or even if sync times are
different, one would have old sa with lesser message id's and other have
same old sa with higher message id's and then both will
start from the higher message
id values.
Regards,
kalyani
From: ipsec-bounces <at> ietf.org [mailto:ipsec-bounces <at> ietf.org]
On Behalf Of zhang.ruishan <at> zte.com.cn
Sent: Wednesday, June 20, 2012 7:44 AM
To: Kalyani Garigipati (kagarigi)
Cc: ipsec <at> ietf.org; ipsec-bounces <at> ietf.org
Subject: Re: [IPsec] 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.
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.
please find the comments for each section
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.
Please support your proposal with an example with message id values of
numbers instead of variables.
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,
and proposes some updates. Look forward to your comments.
BR,
Ruishan Zhang_______________________________________________
IPsec mailing list
IPsec <at> ietf.orghttps://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
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
RSS Feed