[IPsec] ikev2 algorithms, Initiator choice preferred over responder ?
Hi , If the initiator proposes three algorithms say alg1, alg2. Alg3 for encryption in SA1. And responders choice is in the order as alg3,alg2,alg1, then finally in SA_INIT response what should be sent as the algorithm. >From the RFC I felt that it is the initiator choice that should be given >preference and so responder MUST send alg1 in response. Or is it that responder MUST be given preference and it MUST send alg3 in response ? I could not locate any paras in RFC which gives clear guidelines on this. Please let me know if anything like this is already mentioned otherwise I think it should be added in clarifications. Regards, Kalyani -Original Message- From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Sean Turner Sent: Monday, October 22, 2012 5:56 PM To: Dan Harkins Cc: ipsec@ietf.org Subject: Re: [IPsec] brainpool summary, suggested way ahead, and comments on draft Dan, I've exchange some emails with with Johannes Merkle about adding cipher suites to TLS. What he's agreed to do is to include only three points (BrainpoolP256r1, BrainpoolP384r1, and BrainpoolP512r1) in the draft. spt On 10/19/12 3:20 AM, Dan Harkins wrote: > >Sean, > >It was a two-part request. I'd like the IESG to follow the same > process they followed for what became RFC 5114. > >Is there a way to get an RFC published to update this registry that > does not need to go through the IESG? If not then the 2nd part is the > critical one; if so then we can just end this fiasco now. > >regards, > >Dan. > > On Thu, October 18, 2012 7:58 am, Sean Turner wrote: >> Dan, >> >> There's not need to ask the IESG about the process to update the >> registry in question it's clear: RFC required. You can get an RFC >> through a WG, through an AD, or through the ISE. >> >> spt >> >> On 10/15/12 10:54 PM, Dan Harkins wrote: >>> >>> Hi Sean, >>> >>> On Mon, October 15, 2012 5:00 pm, Sean Turner wrote: On 10/12/12 2:32 AM, Dan Harkins wrote: > > On Thu, October 11, 2012 5:47 pm, Sean Turner wrote: >> >> I'm going to run my proposal and Michael's by the IESG on an >> informal telechat to see which one's got the best chance of >> getting through the process to resolve the IEEE's request. > > Can you ask the IESG to just do what it has done in the past? > That is, just update the registry to include code points for new > curves without any bizarre notes or pointers? No fuss, no mess, > just a few new rows in a table. > > The worst that could happen if the IESG agrees to do that is > that someone somewhere might use a brainpool curve with IKEv1. The > odds are slim, but they're not zero. And if that happens then so > what? Really. So what? The RFC 5114 example wasn't published to address another SDO request for a code point so I don't think it's the same situation. >>> >>> That's certainly a distinction but I don't see how that matters. >>> You could also note that RFC 5114 added MODP groups as well as ECP >>> groups. Also a distinction that really doesn't matter. >>> >>> Again, the SDO request is a _by-product_ of the opposition to >>> just letting Johannes' draft update the registry. It is this same >>> opposition that is creating these problems about notes and pointers >>> and the concern over whether they will have the desired effect and >>> what we should do to ensure they do. If this opposition had not >>> materialized there never would've been another SDO request. >>> >>> It is the same situation, indulge me here a bit: >>> >>> What we had was another organization (NIST) came up with some >>> new DH groups and there was a proposal to add them to both IKEv1 and >>> IKEv2 registries. And now, quite similarly, there's another >>> organization (the ECC >>> Brainpool) that came up with some new DH groups and there was a >>> proposal to add them to both IKEv1 and IKEv2 registries. >>> >>> When the proposal was made to add the NIST groups to the IKEv1 >>> registry there was no hullabaloo over updating a deprecated >>> protocol's registry and there was no concern that someone somewhere >>> might use the NIST groups with IKEv1. >>> >>> But when Johannes made his proposal to add the ECC Brainpool >>> curves to the IKEv1 registry there was all of a sudden a hullabaloo >>> and much concern that someone somewhere might use the ECC Brainpool >>> groups with IKEv1. >>> >>> So my request to you is to ask that the IESG consider what the >>> process defined for updating this registry is (it's RFC required) >>> and to note that there is precedence to update the registry of this >>> deprecated protocol. >>> So please ask the IESG to just approve a draft (either Johannes' or >>> mine) >>> for publication as an RFC to update this registry in the same manner >>> that RFC 5114 updated it (i.e. no notes, no pointers, no nonsense). >>> >>>
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. 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
Re: [IPsec] Need Info related to simultaneous rekey of IKE/IPSec SAs.
Hi Ramu, You can have a middle router between two ike peers. 1. Establish the ike and ipsec sa 2. Make one of the interfaces on middle router as down. 3. Then ensure ike/ipsec rekey happens simultaneously on both the routers. Since the middle router is down, the packets are don't reach peer, but are retransmitted. 4. Now make the interface up. The ike /ipsec rekey packets cross each other. And simulatenous rekey happens. Regards, Kalyani From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of B Rampullaiah-B22344 Sent: Friday, July 22, 2011 5:35 PM To: ip...@ietfa.amsl.com Subject: [IPsec] Need Info related to simultaneous rekey of IKE/IPSec SAs. Hi, I need some information for the simulation of the following cases related to IKEV2 Exchange Collision Mechanism Implementation as per the RFC-4718. 1. When the host receives a request to rekey - a CHILD_SA pair that the host is currently rekeying: Reply as usual, but prepare to close redundant SAs later based on the nonces. 2. When the host receives a request to rekey - the IKE_SA, and the host is currently rekeying the IKE_SA: Reply as usual, but prepare to close redundant SAs and move inherited CHILD_SAs later based on the nonces. 3. If a host receives a request to create or rekey a CHILD_SA when it is currently rekeying the IKE_SA: Reply with NO_ADDITIONAL_SAS. How to simulate the simultaneous rekeying of IKE/IPSec SAs? Regds, Ramu. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Moving forward with the HA solution draft
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:priik...@iki.fi] 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 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 ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Moving forward with the HA solution draft
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: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] 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 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 ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Comments draft-kagarigi-ipsecme-ikev2-windowsync-04
Hi Pekka, What is the message Id that can be used to send the informational exchange while sending RESET_WINDOW notify? I find that your approach is similar to this draft as 1. Initiator(failover) and responder(peer) agree upon the new range of message Id's and ignore the lost message Id's. Both the approaches define new notifies and need to send a informational exchange to carry the notifies. 1. If window size is say some five and range expected is 4-8, and if peer has got all four requests with values 5,6,7,8 and 4 is lost, then there would be no message id that can be used to send the notify reset_window. The initiator will not know which message Id should be used to send the new notify. And here the problem is not only to send the request, but also to receive the request. The failover device should also know the permissible range in which it can receive the requests from the peer. The idea to send a new informational exchange with message Id zero was thought only because when the failover takes control it would not know what message Id it can use to know the peer window values .This is the basic problem of message Id synchronization, so having new notify itself will not help. Regards, Kalyani -Original Message- From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Pekka Riikonen Sent: Saturday, September 04, 2010 4:14 PM To: ipsec@ietf.org Cc: y...@checkpoint.com; kivi...@iki.fi Subject: Re: [IPsec] Comments draft-kagarigi-ipsecme-ikev2-windowsync-04 On Fri, 3 Sep 2010, Pekka Riikonen wrote: : something like next_message_id += window_size / 2, and be happy. Though, : implementation must ensure it never sends more than the increment (that's why : window size of 1 doesn't work to begin with). Why was the window size defined : by default to 1 anyway? Is there a reason why this wouldn't work? : This doesn't actually work. I think I'm seeing some ambiquity in the spec when window size > 1. But, there's still ways to make this work easier than with new exchange. We could add new RESET_WINDOW notify that, when received inside a valid window will reset the left side of the window to the value requested. In failover (assuming window size > 1), the online node can send the notification to reset the window to the new value. Responder clears the old states in the window as initiator has now deemed them lost. Responder must reply with its N(RESET_WINDOW). At the same time we should add GET_WINDOW_SIZE notify which initiator can use to request/require responder to set the window size. Responder SHOULD respond with SET_WINDOW_SIZE of at least the same size. So when initiator sends its N(SET_WINDOW_SIZE) it could at the same time require the responder to send it too. All these notifications in the ikev2bis should be "MUST be supported". And then of course there's the poor man's way, where implementation after the failover could keep sending empty INFORMATIONAL's with new message ids, and wait until it receives response. It now knows the message ids to both directions. This requires that the message ids are synced in the cluster after every packet, so that node has recent values in the failover. Pekka ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Comments draft-kagarigi-ipsecme-ikev2-windowsync-04
Hi Pekka, Thanks for the comments on draft. Please find my comments inline. Regards, Kalyani -Original Message- From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Pekka Riikonen Sent: Friday, September 03, 2010 2:48 PM To: y...@checkpoint.com Cc: ipsec@ietf.org; kivi...@iki.fi Subject: Re: [IPsec] Comments draft-kagarigi-ipsecme-ikev2-windowsync-04 I am a bit sceptical about the draft as it appears to be solving something that doesn't have to be such a huge problem by introducing a new exchange. First, the ESP sequence number sync. In case of failover the online node should simply increment the sequence number with a large enough number; the anti-replay window can always move forward. Implementations should also perform periodical sequence number sync in the cluster (fe. every 2-5 seconds) to keep the numbers close enough in nodes. I see no reason to sync this information between peers. It will never work perfectly anyway (there is too much traffic). More frequently you sync the sequence numbers in the cluster smaller the increment needs to be (calculate expected pps). Second, the message ID problem in failover is a real problem but isn't the problem really the size of the message window? If everyone would do SET_WINDOW_SIZE with large enough number (like 32), in failover we could do something like next_message_id += window_size / 2, and be happy. Though, implementation must ensure it never sends more than the increment (that's why window size of 1 doesn't work to begin with). Why was the window size defined by default to 1 anyway? Is there a reason why this wouldn't work? (SET_WINDOW_SIZE specifically allows us to move the window) [KALYANI] We can always have the larger window size and send the new request from failover device with the incremented message Id. But the problem with this approach is, In case of windowing unless all the messages are received with in the window range , the window never moves, hence the lost Request will never be sent and eventually the sa will have to be deleted, which can be avoided if this draft is implemented. Any ongoing exchange at the time of the failover can be an issue (rare) but most can be eliminated with careful implementation. For example, the following: - Delete IKE SA or IPSEC SA -> Sync delete to cluster before sending packet to network. Nodes don't actually have to delete the SA, just mark it to be deleted. This applies to both sending delete and receiving delete. [KALYANI] If the message to delete the IKE SA is lost , then this would make the active and failover device to be out-of-sync. - Rekey -> I don't see this as a problem. New CHILD_SA or crash recovery solves the problem either immediately or relatively quickly. It's impossible to make this work perfectly (machines can crash at any point), but important thing is that your implementation can recover (support crash recovery, do DPD when oddities occur). [KALYANI] This draft proposes the synchronization of message Id's using the IKE SA which is present on failover and peer devices. In case of active member crash during IKE SA delete/rekey, the SA at peer and failover device does not match( which means old sa is present on failover and new sa is present on peer). IKE message Id synchronization is not meant to solve such issues. I don't much see need for a new exchange, though a draft that explains best ideas for implementing clustering and HA would be nice. Pekka ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] latest message Id draft
Hi , Please find the latest message id draft in the following link. http://www.ietf.org/staging/draft-kagarigi-ipsecme-ikev2-windowsync-03.t xt regards, Kalyani ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] New draft posted
Hi , I have changed the name of the document as per the naming convention. Please find the draft in the below link and give your comments. http://www.ietf.org/id/draft-kagarigi-ipsecme-ikev2-windowsync-00.txt regards, Kalyani From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Kalyani Garigipati (kagarigi) Sent: Monday, June 14, 2010 9:33 PM To: ipsec@ietf.org Subject: [IPsec] New draft posted Hi All, A new version of I-D, http://www.ietf.org/id/draft-ikev2-windowssync-00.txt has been posted to the IETF repository. Filename: http://www.ietf.org/id/draft-ikev2-windowssync-00.txt Revision: 00 Title:IKEv2 window synchronization among peers Please give your comments. Regards, Kalyani ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] New draft posted
Hi All, A new version of I-D, http://www.ietf.org/id/draft-ikev2-windowssync-00.txt has been posted to the IETF repository. Filename: http://www.ietf.org/id/draft-ikev2-windowssync-00.txt Revision: 00 Title:IKEv2 window synchronization among peers Please give your comments. Regards, Kalyani ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Who is the Initiator of rekeying CHILD SA?
Hi Jaemin, You are right, Since B is initiating the exchange the values of SPIi, Ni, and TSi will be the values of host B Regards, kalyani From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Jaemin Park Sent: Thursday, May 20, 2010 9:07 PM To: ipsec@ietf.org Subject: [IPsec] Who is the Initiator of rekeying CHILD SA? This can be the ridiculous question, but there exist some confusion in the context of initiator of CHILD SA around me. Suppose that host A and host B exist. Host A initiated the exchanges (IKE_SA_INIT & IKE_AUTH) to establish the IKE SA and CHILD SA with host B. (In this case, Host A is the Initiator and Host B is responder.) Then, host B (the responder of previous IKE exchange) initiated the CHILD SA rekeying (CREATE_CHILD_SA) with host A. In this case, who is the Initiator of rekeying CHILD SA? host B? or host A? According to the RFC4306, I think host B is the initiator of CHILD SA. Therefore, the fields such as SPIi, Ni and TSi should be the value of host B. Am I right? ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Ikev2 HA message Id Issue
Hi Yoav, I agree that 2nd solution is easier to implement, but the peer will have to delete the impending requests it might retransmit to the standby device. This will also not catch the message replay attacks which is the major advantage of using message Id's (once the window is reset, earlier windows messages might be replayed which will fall in this window at some point of time). Using a random number as starting message Id after reset, may also cause the same issue with 1st solution we can start from the requests where the active device has stopped . This would ensure a smooth continuation of message Id's . If the peer participating in the HA does not support this extension, then the ordinary method of updating the counters for every exchange has to be followed even though its inefficient. I don't see any other solution with the current ikev2 protocol for this message Id problem. Hence I feel that for efficient updation of counters, this extension should be supported . In case of site to site there will be some cases of single IKE SA and multiple IPSEC SA's but we cannot rule out the case of multiple IKE SA's depending on the deployment. In addition , in case of remote access there might be many . In such cases if dpd is also enabled then solution #2 would create lots of message updations from Active to standbydevice. The concern is not only abt the bandwidth between stand by and active , but the active device would be involved in only doing these updations to the stand-by device. Regards, kalyani From: Yoav Nir [mailto:y...@checkpoint.com] Sent: Thursday, September 03, 2009 8:37 PM To: Kalyani Garigipati (kagarigi) Cc: ipsec@ietf.org Subject: Re: [IPsec] Ikev2 HA message Id Issue Hi Kalyani Of the two, I prefer the 2nd solution, as it is simpler. Reusing message IDs is not that bad, and you can decrease the change by including (in the RESET_MESSAGE_ID notification) a random number as the starting message ID. What I'm not so sure, is that there is a real problem here that needs to be solved now. The IKEv2 documents totally ignore both high-availability solutions and load-sharing solutions. They are just out of scope. So the documents don't specify what data needs to be synched, or how is failover detected and accomplished on the LAN or the WAN. To get there, you'd need to address issues of routing, signaling (between the peers) and AAA for both IKE and IPsec traffic. That's a tall order that you probably don't want to tackle just now (maybe the WG would want this as the next "big" document) So to have a high-availability or load-sharing solution that participates in IKE/IPsec, an implementation needs to somehow pretend that both of these are actually one gateway. This can be done with smart switches, multicast addresses and synchronization links, which are out of scope for the WG (for now) I can think of three levels of synchronizing IKE data between the peers. 1. Synchronize just the IKE SA at creating and deletion 2. Synchronize the IKE SA whenever the counters are updated 3. Synchronize both IKE and Child SAs whenever a packet is sent. #3 is obviously impractical. #1 doesn't work, because after fail-over, the redundant gateway cannot take over the IKE SA, because it doesn't know the message ID counters. #2 can be made to work, although you need to either immediately rekey all the child SAs, or else skip ahead in the IPsec retrans counters. This solution is practical enough, because most gateways have very few Child SAs per IKE SA. With IKEv2 you can have complex traffic selectors that allow one SA to cover all the domain protected by a gateway. So you might have a few SAs because of different QoS classes, and maybe a few if your implementation prefers to deal with whole ranges or subnets, but really, a single IKE SA with thousands of concurrent Child SAs is more of a lab thing than a practical thing. Both your solutions ask peer gateways to assist the HA pair with their fail-over process. To the other gateway it seems as if the (single) peer is requesting information about current message ID numbers (and windows) or else for a reset. It seems strange that the first thing we would do for HA support is to help a private extension to the architecture work better, when that private extension is not really documented. What do you plan to do in your cluster, if the peer does not support this extension? You might also want to ask Paul and Yaron to present this on the Interim meeting on 22-Sep. Yoav On Sep 3, 2009, at 4:06 PM, Kalyani Garigipati (kagarigi) wrote: 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
Re: [IPsec] Ikev2 HA message Id Issue
Hi Pasi, Please find replies inline. Regards, Kalyani From: pasi.ero...@nokia.com [mailto:pasi.ero...@nokia.com] Sent: Thursday, September 03, 2009 9:58 PM To: Kalyani Garigipati (kagarigi); ipsec@ietf.org Subject: RE: Ikev2 HA message Id Issue One obvious approach would be not to sync after every exchange (that could be a lot of messages), but sync, say, every N seconds (say, N=5) in one big batch (for all IKE_SAs that changed in the last N seconds). If sync is done in batches and if active device crashes between the interval sync of the batches, then we again see the same message Id issue. If dpd is enabled then ikev2 counters keep updated frequently. Hence we cannot rule out the possibility of out of sync between stand by and active device with the above approach. Most of the time, almost all IKE_SAs are just sitting there idle (so IKEv2 message ID counters don't change). In case of failure, the stand-by device would have out-of-date information for some small percentage of IKE_SAs (those whose counters changed since last sync) , but that's always going to be the case (for exchanges where something more happened just before/during the failure). With HA, we want to ensure the maximum avoidance of out of sync. In any case of out of sync , the retransmission of messages should take care of the exchanges. In the worst case the SA will have to deleted (which is the case Currently now for IKEV2 when windowing is used and some requests are lost ) I haven't done the math, though, so I don't know what value of N would result in both acceptable bandwidth and acceptable failure rate for the stand-by (depends on how many messages your typical IKE_SAs have per hour on average)... we might like the solution to work in all cases of exchange frequency, hence I think we cannot fix N. Best regards, Pasi From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of ext Kalyani Garigipati (kagarigi) Sent: 03 September, 2009 16:07 To: ipsec@ietf.org Subject: [IPsec] Ikev2 HA message Id Issue 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 ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Ikev2 HA message Id Issue
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
[IPsec] Multiple payloads of same type
Hi, Please validate if the following is true. Apart form Notify, DELETE, Vendor ID, CERT, CERTREQ, PROPOSAL, TRANFORM, TSi and TSr all other payloads like SA1, SA2, IDi, IDr, KE, NONCE, DELETE, AUTH, CONFIG, ENCRYPT should not be sent as multiple payloads. Like if we get packet as HDR, SA1, SA1, KE, N We should reject it ? Regards, kalyani ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Ticket #9
Hi Paul, My question was , during the AUTH exchange if failure happens due to reasons like NO_PROPOSAL_CHOSEN, TS_UNACCEPTABLE, SINGLE_PAIR_REQUIRED, INTERNAL_ADDRESS_FAILURE, and FAILED_CP_REQUIRED, Should we still bring IKEV2 SA as usual? RFC says we can still bring the IKeV2 SA as usual, but my doubt is if this is mandatory or optional? My question was not during Child SA Creation. Regards, kalyani -Original Message- From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Paul Hoffman Sent: Tuesday, March 31, 2009 11:38 PM To: Kalyani Garigipati (kagarigi) Cc: ipsec@ietf.org Subject: Re: [IPsec] Ticket #9 At 5:32 PM +0530 3/31/09, Kalyani Garigipati (kagarigi) wrote: >Hi , > >Please clarify the following . > >1. Is it mandatory or optional (implementation dependent) to create an >IKEV2 sa when IKE_AUTH exchange fails for reason like >NO_PROPOSAL_CHOSEN, TS_UNACCEPTABLE, >SINGLE_PAIR_REQUIRED,INTERNAL_ADDRESS_FAILURE, and FAILED_CP_REQUIRED ? I am unclear on what you are asking. The IKE SA is already set up when the child SA creation fails. Thus, it does not need to be created. --Paul Hoffman, Director --VPN Consortium ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Question on TS_UNACCEPTABLE
Hi,
Please clarify the following.
On the responder , if creating the Child SA during the IKE_AUTH request
processing fails for some reason like NO_PROPOSAL_CHOSEN,
TS_UNACCEPTABLE, SINGLE_PAIR_REQUIRED,INTERNAL_ADDRESS_FAILURE, and
FAILED_CP_REQUIRED, then should we be sending AUTH, IDr and CERT
payloads as usual in AUTH response ?
Something like below flow.
HDR, SK {IDi, [CERT,] [CERTREQ,]
[IDr,] AUTH, SAi2,
TSi, TSr} -->
<-- HDR, SK {IDr, [CERT,] AUTH,
N[TS_UNACCEPTABLE]}
Regards,
Kalyani
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Ticket #9
Hi ,
Please clarify the following .
1. Is it mandatory or optional (implementation dependent) to create an
IKEV2 sa when IKE_AUTH exchange fails for reason like
NO_PROPOSAL_CHOSEN, TS_UNACCEPTABLE,
SINGLE_PAIR_REQUIRED,INTERNAL_ADDRESS_FAILURE, and FAILED_CP_REQUIRED ?
Regards,
Kalyani
-Original Message-
From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf
Of pasi.ero...@nokia.com
Sent: Friday, March 27, 2009 10:55 PM
To: kivi...@iki.fi; wierb...@us.ibm.com
Cc: ipsec@ietf.org
Subject: Re: [IPsec] Ticket #9
Tero Kivinen wrote:
> I am not sure we reached the decision yet, but I think more text is
> needed if that is allowed, thus creating that text might help moving
> things forward (i.e send replacement text).
Here's a first sketch:
Section 1.3.1:
OLD:
Failure of an attempt to create a CHILD SA SHOULD NOT tear down the
IKE SA: there is no reason to lose the work done to set up the IKE
SA. When an IKE SA is not created, the error message return SHOULD
NOT be encrypted because the other party will not be able to
authenticate that message. [[ Note: this text may be changed in the
future. ]]
NEW:
If creating the CHILD SA fails for any reason, the IKE SA stays
up.
(This section is about CREATE_CHILD_SA exchange, so the text about
IKE_SA creation failures is in wrong place)
Section 1.2:
OLD:
{{ Clarif-4.2}} If creating the Child SA during the IKE_AUTH exchange
fails for some reason, the IKE SA is still created as usual. The
list of responses in the IKE_AUTH exchange that do not prevent an IKE
SA from being set up include at least the following:
NO_PROPOSAL_CHOSEN, TS_UNACCEPTABLE, SINGLE_PAIR_REQUIRED,
INTERNAL_ADDRESS_FAILURE, and FAILED_CP_REQUIRED.
NEW:
{{ Clarif-4.2 }} During the IKE_AUTH exchange, two kinds of
failures can happen.
If the failure is related to creating the Child SA, the IKE SA is
still created as usual. The list of responses in the IKE_AUTH
exchange that do not prevent an IKE SA from being set up include at
least the following: NO_PROPOSAL_CHOSEN, TS_UNACCEPTABLE,
SINGLE_PAIR_REQUIRED, INTERNAL_ADDRESS_FAILURE, and
FAILED_CP_REQUIRED. In this case, the error notification is
included in the last IKE_AUTH response, and the SA/TSi/TSr payloads
are omitted from this message.
If the failure is related to creating the IKE SA (for example,
AUTHENTICATION_FAILED), the IKE_SA is not created. Note that
although the IKE_AUTH messages are encrypted and integrity
protected, if the peer receiving this notification has not
authenticated the other end yet, the information needs to be
treated with caution.
Best regards,
Pasi
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
