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-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of
zhang.ruis...@zte.com.cn
Sent: Monday, June 11, 2012 7:36 AM
To: ipsec@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@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
