Hi ,
In Ikev2 HA, there is an issue with the message Id and window size.
Standby device-----------------------active
device----------------------------------Peer device
The active device participating in the exchange with the peer will
update its message id counters as per the exchanges done.
This info cannot be synced to the stand-by device for every exchange
done since that would take up all the bandwidth and is not an efficient
way.
The stand-by device when it becomes active will start with the message
Id as 1 and this will not be accepted by the peer, since its message Id
counters are different.
Hence a solution is required to sync the message Id counters to the
standby device.
1. A solution for this is to get the required info from the peer device
since it maintains all these counters.
The abstract details of how this can be done are given in the attached
document.
2. An alternative solution for this could be to send a new notify called
(RESET_MESSAGE_ID) to the peer device as soon as the standby comes up.
But this may lead to
Reuse of message Id's within the same SA which is not desirable.
I think solution 1 should be implemented with Ikev2. Please give your
comments
Regards,
Kalyani
1. Introduction
======================
HA for ikev2 sessions is required to ensure that in case of crash of active
device , the stand by device becomes active immediately.
The stand by device is expected to have the sync of message id's of active
device at the time of crash.
If we dont sync up these fields at the stand-by device then when the session
comes up on the standby device,
it would start the message id from 1. This would make it reject all the requets
from the peer since peer window would have
advanced to some other range.
And also all the requests from stand-by device to the peer would be rejected.
The peer would then bring down the connection and then a new session has to be
established at the standbydevice.
This is not a desirable feature of HA.
One solution for this is to sync the stand-by device with the message id for
every message exchange that happens
between standby and the active device.But this solution is not efficient since
this would take all the bandwidth between the
standby and active device if there are many sessions in the active device .
Hence a mechanism is needed to sync the message id fields from active device to
stand by device efficiently.
This document proposes a solution for this case
2. Usage Scenarios
========================
1. This solution is required in case of HA of ikev2.
2. This is also required for the devices when they are out of sync and wish
to be in sync with the peer.
3. Description of the solution.
==================================
Information to be synced
==========================
Every device participating in the ikev2 exchange maintains the following
information
1. CURR_REQ_MESSAGE_ID-- The message id of the first request in the peer window
, that this device should send.
2. NEXT_REQ_MESSAGE_ID--The message id, this device will use in the packet
while sending the next request to the peer.
3. PEER_CURR_REQ_MESSAGE_ID--The message id of the first request in the my
window, which peer is expected to send to this device.
4. PEER_NEXT_REQ_MESSAGE_ID--The message id peer will use while sending the
next request to this device
5. MY_WINDOW_SIZE---local window size.
6. PEER_WINDOW_SIZE--Window size of the peer
A request with message id X is not sent to the peer when X is outside the
range of (CURR_REQ_MESSAGE_ID, CURR_REQ_MESSAGE_ID + PEER_WINDOW - 1)
A request with message Id X from peer is not accepted when X is outside the
range of (PEER_CURR_REQ_MESSAGE_ID, PEER_CURR_REQ_MESSAGE_ID + MY_WINDOW -1)
(Example, If peer window size is 5 and if this device has sent requests 3, 4, 5
and received responses only for 4,5 ,
CURR_REQ_MESSAGE_ID will be 3 and NEXT_REQ_MESSAGE_ID will be 6 and it can send
requests with message id's ranging from 3 to 7. Upon receiving the
response for message id 3 the window will advance to 6 which means it can
send the request with message id's ranging from 6 to 10.
similarly if local window size is 3, and if request is received from peer with
message id as 4 (assume peer has sent 3 but was lost) , then ,
then PEER_CUR_REQ_MESSAGE_ID is 3 and PEER_NEXT_REQ_MESSAGE_ID is 5, and this
device can receive requests from 3 to 5.)
when the active system crashes, the stand by device can requets this
information from the peer device and update the above fields.
The information about MY_WINDOW_SIZE and PEER_WINDOW_SIZE need not be synced
since it is already passed to the stand by device at the time of
stand-by creation of inactive sa's or during rekey updates from active to
standby device.
States of the active device during crash
=======================================
The CURR_REQ_MESSAGE_ID and NEXT_REQ_MESSAGE_ID on active device would be
PEER_CURR_REQ_MESSAGE_ID and PEER_NEXT_REQ_MESSAGE_ID
respectively on peer and vice-versa . So the stand by device fields are updated
accordingly and then the state of the active device at
the time of crash can be estimated as follows.
1. After updation On stand by device , if CURR_REQ_MESSAGE_ID is equal to
NEXT_REQ_MESSAGE_ID then no requests sent by the active device is
lost and the standby device can start sending requests with message id
CURR_REQ_MESSAGE_ID.
2. After updation On stand by device , If CURR_REQ_MESSAGE_ID is not equal to
NEXT_REQ_MESSAGE_ID, the peer device has received
some requests from active device after CURR_REQ_MESSAGE_ID, but not with
message Id as CURR_REQ_MESSAGE_ID.
In such cases , the stand-by device should send next request with
CURR_REQ_MESSAGE_ID ,
and start sending the consequent requets to the peer with
NEXT_CURR_REQ_MESSAGE_ID.
3. After updation On stand by device , If PEER_CURR_REQ_MESSAGE_ID is equal
to PEER_NEXT_REQ_MESSAGE_ID then , no request sent from the peer is lost.
so the stand by device can accept the request from the peer starting with
message id PEER_CURR_REQ_MESSAGE_ID .
4. After updation On stand by device , If PEER_CURR_REQ_MESSAGE_ID is not
equal to PEER_NEXT_REQ_MESSAGE_ID, then peer has sent a
request to the active device which was lost or the response sent from active to
the peer device was lost.
In either case no specific action is required since peer will retransmit.
4. Exchange flow
=======================
Upon configuration the responder would announce its capability of providing the
message Id info anytime
by sending a VID payload in the INIT response.
The initiator which has received this VID payload should send the below request
to get the message
Id information when needed. Without receiving this VID payload in INIT
response,
the initiator MUST not send this message. If a responder gets this type of
exchange even though it did not send the VID payload,
then it MUST drop this packet with error INVALID_SYNTAX.
If responder does not reply to the Notify GET_MESSAGE_ID_INFO, even though
responder has announced its capability in VID payload.
then the initiator in this case should retransmit the exchange and delete
the SA.
HDR, SK {NOTIFY[GET_MESSAGE_ID_INFO]} ----------->
<---------------------HDR, SK {
NOTIFY[SET_MESSAGE_ID_INFO]}
The exchange type for this message exchange is SYNC_EXCHANGE.The reason for the
new type of exchange is to indicate to the
responder to ignore the message Id.
The message id for this is zero.
The initiator of this exchange can trigger this any time after the SA matures,
when it wants to sync up the message Id information from the peer.
The responder upon receiving this type of exchange should process the message
and ignore the message id in
its window (based on the exchange type) and provide the relevant info to the
peer.
The initiator upon geting the SET_MESSAGE_ID_INFO NOTIFY should update the
fields
5. New Notify Types
========================
1. GET_MESSAGE_ID_INFO-- This notify would be similar to that of
INITIAL_CONTACT but with Notify message type being GET_MESSAGE_ID_INFO
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol ID | SPI Size | Notify Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2. SET_MESSAGE_ID_INFO
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol ID | SPI Size | Notify Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CURR_REQ_MESSAGE_ID |
| |
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
| NEXT_REQ_MESSAGE_ID |
| |
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
|PEER_CURR_REQ_MESSAGE_ID |
| |
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
| PEER_NEX_REQ_MESSAGE_ID |
| |
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
CURR_REQ_MESSAGE_ID --is the CURR_REQ_MESSAGE_ID on peer device.
NEXT_REQ_MESSAGE_ID -- is the NEXT_REQ_MESSAGE_ID on peer device
PEER_CURR_REQ_MESSAGE_ID --is the PEER_CURR_REQ_MESSAGE_ID on peer device.
PEER_NEXT_REQ_MESSAGE_ID -- is the PEER_NEXT_REQ_MESSAGE_ID on peer device
3. Vendor Id Payload
The VID payload is as described in [RFC4306] with a 16-octets data
field as follows:
e2136e7cfec09e1ddec83f811378c1ab
This value was obtained by hashing the string "sync message Id information"
using the MD5 algorithms.
6. Security Considerations
==========================
This may lead to DOS attack , If some hacker in between replays the same NOTIFY
to get the info.
In order to avoid this the responder side can be configured with the number of
times it can accept
this type of exchange for an SA.
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
