[IPsec] I-D Action:draft-ietf-ipsecme-esp-null-heuristics-01.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF. Title : Heuristics for Detecting ESP-NULL packets Author(s) : T. Kivinen, D. McDonald Filename: draft-ietf-ipsecme-esp-null-heuristics-01.txt Pages : 33 Date: 2009-09-03 This document describes a heuristic approach for distinguishing ESP- NULL (Encapsulating Security Payload without encryption) packets from encrypted ESP packets. The reason for using heuristics instead of modifying ESP is to provide a solution that can be used now without updating all end nodes. With heuristic methods, only the intermediate devices wanting to find ESP-NULL packets need to be updated. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-esp-null-heuristics-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsecme-esp-null-heuristics-01.txt ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] FW: Last Call: draft-ietf-rohc-hcoipsec (Integration of Robust Header Compression (ROHC) over IPsec Security Associations) to Informational RFC
From: ietf-announce-boun...@ietf.org [mailto:ietf-announce-boun...@ietf.org] On Behalf Of The IESG Sent: Thursday, September 03, 2009 16:47 To: IETF-Announce Cc: r...@ietf.org Subject: Last Call: draft-ietf-rohc-hcoipsec (Integration of Robust Header Compression (ROHC) over IPsec Security Associations) to Informational RFC The IESG has received a request from the Robust Header Compression WG (rohc) to consider the following document: - 'Integration of Robust Header Compression (ROHC) over IPsec Security Associations ' draft-ietf-rohc-hcoipsec-11.txt as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2009-09-17. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-rohc-hcoipsec-11.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=1400 2rfc_flag=0 ___ IETF-Announce mailing list ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce Scanned by Check Point Total Security Gateway. smime.p7s Description: S/MIME cryptographic signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Questions to IKEv2bis draft: IVs of retransmitted packets
All in all, the qualifications of being a true retransmitted IKE request/response message is dependent on the* post-encrypted* IKE request/response message being bitwise identical. Naoyoshi, if you don't mind me asking, which implementation are observing this behavior from (I'm not sure if this breaks any rules of engagement of mailing list, so please respond privately to me if possible)? - Jeff Sun On Wed, Sep 2, 2009 at 5:43 AM, Tero Kivinen kivi...@iki.fi wrote: naoyoshi ueda writes: According to ikev2bis-04 section 2.1: A retransmission from the initiator MUST be bitwise identical to the original request. That is, everything starting from the IKE Header (the IKE SA Initiator's SPI onwards) must be bitwise identical; items before it (such as the IP and UDP headers, and the zero non-ESP marker) do not have to be identical. So, IV of retransmitted request must be the same as that of original request. Yes. Meanwhile, ikev2bis-04 section 3.14 says o Initialization Vector - For CBC mode ciphers, the length of the initialization vector (IV) is equal to the block length of the underlying encryption algorithm. Senders MUST select a new unpredictable IV for every message; recipients MUST accept any value. Question 1: Does the statement recipients MUST accept any value. stay true even if retransmitted IV differs from that of original request? Most likely, but it does not matter as the packet will fail window check, thus will be considered as retransmission or old packet, and thrown away (it might trigger retransmission of responders reply in case it was packet in the window). Note, that this can only happen if the other is non-conforming, or there is attacker between which modifies the IV. Conforming implementation will use same IV all time. Question 2: If the answer to Question 1 is no, what should the recipient do? Just ignore it? Abandon the IKE_SA? Or send some Notify? If recipient has already seen the message before (i.e it has already processed it), it can resend its reply. It can also notice that the packet is not bitwise-same as previously and the message id is old, and silently ignore it. So this is implementation depended what will happen. If it has not seen the message before, then it does not know the IV has changed, thus will process the packet normally. Question 3: How about IV of retransmitted RESPONSE? Does it need to be identical to the original one too? The retransmitted response should also be bitwise identical to original one. It seems to me that the following statement in section 2.1 implicitly requires that. But I'm not sure. I would agree you that it implicitly requires that. Actually, I'm now involved in a IKEv2 implementation that sends retransmitted response with different IV from original one and I cannot tell if the behavior is allowed or not. I would say it is not allowed, but on the other hand, the other end should not ever notice this, as it only process one of the responses (the first to reach him), and then ignores rest even before decrypting them (when it checks its message id). I.e. it ignores further responses to requests it has already received response. ikev2bis-04 section 2.1: The responder MUST remember each response until it receives a request whose sequence number is larger than or equal to the sequence number in the response plus its window size (see Section 2.3). -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec -- For relaxing times, make it Suntory time. - Bob Harris, Lost in Translation ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Fwd: Last Call: draft-ietf-ipsecme-ikev2-resumption (IKEv2 Session Resumption) to Proposed Standard
Hi, Yaron: Please check my response inlines: BRG Peny 2009/9/3 Yaron Sheffer yar...@checkpoint.com: Hi Peny, Thank you for reviewing this draft. Please see my comments below. Regards, Yaron -Original Message- From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Peny Yang Sent: Wednesday, September 02, 2009 17:18 To: i...@ietf.org Cc: IPsecme WG Subject: [IPsec] Fwd: Last Call: draft-ietf-ipsecme-ikev2-resumption (IKEv2 Session Resumption) to Proposed Standard Sorry, I should cc IPsec mail list. Comments are sent again. Hi, floks: I have two comments on the draft of IKEv2 Session Resumption: 1) Sorry, I have to talk about my concern on the new IKE_SESSION_RESUME. In WG last call, actually I made this comment. However, no feedback was given, maybe because my comment was a little late for WG last call. So, I just copy it here again as a comment for IESG last call. Well, we've discussed pros and cons of IKE_SA_INIT and IKE_SESSION_RESUME for quite a long time. However, IMHO, the consensus is still not fully achieved on this item. So far, I still prefer to choosing extended IKE_SA_INIT for ticket presenting. This solution is specified in http://tools.ietf.org/html/draft-xu-ike-sa-sync-01 As a summary, the virtues are as follows: - RFC5077 (TLS session resumption) also uses the similar scheme, which extends the message of clienthello with session ticket extension. The extended IKE_SA_INIT solution has the similar way. It's easy to extend the base IKEv2 protocol stack to support session resumption. - Considering the case of failing session resumption, the extended IKE_SA_INIT solution can save one round trip. - As indicated in 4.3.3 IKE_AUTH exchange, IKE_AUTH must be initiated after IKE_SESSION_RESUME. In this sense, the extended IKE_SA_INIT way need less code to be supported compared with IKE_SESSION_RESUME. The down side: - some people thought the way of extended IKE_SA_INIT will make the base IKEv2 protocol stack more complex. IMHO, it's an issue of implementation. Again, I still support to use extended IKE_SA_INIT for ticket presenting instead of IKE_SESSION_RESUME. [YS] I see the merits of extending IKE_SA_INIT to support resumption, and in fact an early version of our work did exactly that. But the working group gave us a clear direction to use a separate exchange , and this is where we disagree: I believe we did have a strong WG consensus that the implementation benefits of having a separate exchange (i.e.) outweigh the benefits of the alternative. [Peny] I know WG chair have the right to judge rough consensus. However, I can't agree that IPsecme WG has achieved the so called strong consensus on this issue. Maybe IESG can further judge it. I also can't agree benefits of having a separate exchange outweigh the benefits of the alternative. Actually, we didn't achieve consensus on it yet. not overloading even more the non-trivial IKE_SA_INIT exchange [Peny] I am sorry. I just can't see any evidence that the solution of extending IKE_SA_INIT extension will *OVERLOAD* current IKE_SA_INIT exchange? Or I missed something? 2) Maybe I missed some discussions. There is the case: responder may receives a ticket for an IKE SA that is still active and if the responder accepts it. In one of previous versions of this draft, there once was some description on this case. [YS] I believe you are referring to the text now in Sec. 4.3.4. [Peny] OK. This is the part I referred to. But, it can't deal with the issue when IPsec client *continuously* believes failure of gateway. I know that how a client detects the need for resumption is out of the scope of this draft. But, there is the possibility that IPsec client may be continuously deceived and believe the fail of IPsec gateway. It may continuously present the ticket and update the ticket. In this sense, IMHO, this draft should take care of this case. [YS] If I understand the scenario correctly, it is similar to an attacker repeatedly sending notifications to an IKE client, making it believe that the IKE exchange has failed and needs to be reinitiated. [Peny] Well, this case may not cause this problem. If attacker has IPsec connection with the client, the client will only believe the attacker fails, not Gateway. Here is one of the cases. Sometimes, temporary unavailability of network access may also cause this problem. For example, in mobile network, mobile terminals may lose radio resources in some time. In this situation, all the packets outward of client will be timeout. Then IKEv2 protocol stack has the possibility to believe failure of gateway. It will send one or more message to initiate the session resumption. However, as far as I know, many cellular card now will not discard the packets when radio resources lose for a while. It will buffer the packets and send them out when radio resources are available. This attack against plain-vanilla IKE
[IPsec] FW: Last Call: draft-ietf-rohc-ikev2-extensions-hcoipsec (IKEv2 Extensions to Support Robust Header Compression over IPsec (ROHCoIPsec)) to Proposed Standard
From: ietf-announce-boun...@ietf.org [mailto:ietf-announce-boun...@ietf.org] On Behalf Of The IESG Sent: Thursday, September 03, 2009 16:47 To: IETF-Announce Cc: r...@ietf.org Subject: Last Call: draft-ietf-rohc-ikev2-extensions-hcoipsec (IKEv2 Extensions to Support Robust Header Compression over IPsec (ROHCoIPsec)) to Proposed Standard The IESG has received a request from the Robust Header Compression WG (rohc) to consider the following document: - 'IKEv2 Extensions to Support Robust Header Compression over IPsec (ROHCoIPsec) ' draft-ietf-rohc-ikev2-extensions-hcoipsec-09.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2009-09-17. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-rohc-ikev2-extensions-hcoipse c-09.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=1520 6rfc_flag=0 ___ IETF-Announce mailing list ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce Scanned by Check Point Total Security Gateway. smime.p7s Description: S/MIME cryptographic signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] FW: Last Call: draft-ietf-rohc-ipsec-extensions-hcoipsec (IPsec Extensions to Support Robust Header Compression over IPsec (ROHCoIPsec)) to Proposed Standard
From: ietf-announce-boun...@ietf.org [mailto:ietf-announce-boun...@ietf.org] On Behalf Of The IESG Sent: Thursday, September 03, 2009 16:48 To: IETF-Announce Cc: r...@ietf.org Subject: Last Call: draft-ietf-rohc-ipsec-extensions-hcoipsec (IPsec Extensions to Support Robust Header Compression over IPsec (ROHCoIPsec)) to Proposed Standard The IESG has received a request from the Robust Header Compression WG (rohc) to consider the following document: - 'IPsec Extensions to Support Robust Header Compression over IPsec (ROHCoIPsec) ' draft-ietf-rohc-ipsec-extensions-hcoipsec-05.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2009-09-17. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-rohc-ipsec-extensions-hcoipse c-05.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=1640 9rfc_flag=0 ___ IETF-Announce mailing list ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce Scanned by Check Point Total Security Gateway. smime.p7s Description: S/MIME cryptographic signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Last Call: draft-ietf-rohc-ikev2-extensions-hcoipsec (IKEv2 Extensions to Support Robust Header Compression over IPsec (ROHCoIPsec)) to Proposed Standard
The IESG has received a request from the Robust Header Compression WG (rohc) to consider the following document: - 'IKEv2 Extensions to Support Robust Header Compression over IPsec (ROHCoIPsec) ' draft-ietf-rohc-ikev2-extensions-hcoipsec-09.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2009-09-17. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-rohc-ikev2-extensions-hcoipsec-09.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=15206rfc_flag=0 ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] CRL checking when selecting a certifcate
Tero, thanks for the comments and the clarification on how to read a lower case must. I do have a few more comments. So implementations cannot just search uppercase MUST/SHOULD/MAY texts and assume it is enough to make sure those are correct. It also needs to do what the text says... I think most implementers focus on the MUST and SHOULDs and then apply common sense to the remaining text. CRL checking is not cheap and performing CRL checking when selecting a certificate seems like an optional usability feature to me. The you probably want to make change to the current text which says you must do it... Correct. I think when selecting a certificate that consulting revocation information is a lower case should or could at best. I agree that on the accepting side a lower case must is appropriate for revocation checking from an interoperability perspective. By that I mean the failure to do so will not hinder interoperability, but from a security perspective it really should be done. Dave Wierbowski z/OS Comm Server Developer Phone: Tie line: 620-4055 External: 607-429-4055 ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Fwd: Last Call: draft-ietf-ipsecme-ikev2-resumption (IKEv2 Session Resumption) to Proposed Standard
On Thu, Sep 3, 2009 at 5:11 PM, Tero Kivinenkivi...@iki.fi wrote: Yaron Sheffer writes: [YS] I see the merits of extending IKE_SA_INIT to support resumption, and in fact an early version of our work did exactly that. But the working group gave us a clear direction to use a separate exchange, and this is where we disagree: I believe we did have a strong WG consensus that the implementation benefits of having a separate exchange (i.e. not overloading even more the non-trivial IKE_SA_INIT exchange) outweigh the benefits of the alternative. I agree on that (both to the WG having consensus and also that using separate exchange is better). I know that how a client detects the need for resumption is out of the scope of this draft. But, there is the possibility that IPsec client may be continuously deceived and believe the fail of IPsec gateway. It may continuously present the ticket and update the ticket. In this sense, IMHO, this draft should take care of this case. [YS] If I understand the scenario correctly, it is similar to an attacker repeatedly sending notifications to an IKE client, making it believe that the IKE exchange has failed and needs to be reinitiated. This attack against plain-vanilla IKE would be much more CPU-intensive to the client and to the (real) gateway, compared to repeated session resumption. Even when you factor in the cost of generating a new ticket. Moreover, the regular IKEv2 anti-DOS cookie mechanism is supported by IKE_SESSION_RESUME as well. Regardless what notifications or ICMP messages you send to any of the IKE end points that MUST NOT cause them to consider IKE SA failed. It MUST conclude that the other endpoind has failed only when repeated attemtps to contact it have gone unanswered for timeout period or when a cryptographically protected INITIAL_CONTACT notification is received on a different IKE SA to the same authenticated identity. (RFC 4306 section 2.4) Notifications and ICMP messages may trigger other end to send empty INFORMATIONAL message to check whether the other end is alive or not and only if that times out then the other end is considered dead. This means this kind of attack is not possible with notifications and ICMP. [Peny] Agree. I did not mean this kind of attacking originally. On the other hand I do agree with Peny that, as resumption draft makes it out of scope for this draft, how a client detects the need of resumption, we might need more text explaining this attack. I.e. we might need to add text to security considerations which says that the client implementations should not trust any untrusted source when they are trying to detect whether the resumption is needed. [Peny] Agree. I also think we need more text to clarify this issue. In this meanwhile, I think the way in section 4.3.4 is not appropriate. Gateway should not silently delete the related SAs in this case. One possible solution is to use the anti-DOS cookie mechanism of IKEv2 to handle this issue. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
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 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
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). Kalyani 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). Kalyani 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)... Kalyani 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
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 the peer will update its message id counters as per the exchanges done. This
Re: [IPsec] Ikev2 HA message Id Issue
Kalyani Garigipati wrote: 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). Kalyani 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. Yes; so N can't be very large. If dpd is enabled then ikev2 counters keep updated frequently. This depends on how often you do DPD... Obviously, you want dead IKE_SAs to go away eventually, but e.g. 30 minute DPD interval would be sufficient for that. If your DPD interval was close to the value of N, that would not work well... but on the other hand, if you have lot of traffic going back and forth, IKEv2 DPD won't get triggered.. Hence we cannot rule out the possibility of out of sync between stand by and active device with the above approach. We cannot rule out this possibility with any approach, I think. 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). Kalyani 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 ) Yes. But this worst case cannot be avoided (since the worst case can occur due to other reasons than message IDs) -- it can be just made less likely to happen. 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)... Kalyani we might like the solution to work in all cases of exchange frequency, hence I think we cannot fix N. I agree; clearly N would be a configurable parameter, not something fixed in some spec. Best regards, Pasi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Issue #26: Missing treatment of error cases
If the error occurs on the initiator, the notification MUST be returned in a separate INFORMATIONAL exchange, with no other payloads. Should an implementation be prohibited from sending an empty delete payload in this case? I would prefer wording like the following: with no other payloads except an optional empty delete payload. Keith Welter IBM z/OS Communications Server Developer 1-415-545-2694 (T/L: 473-2694) ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Issue #26: Missing treatment of error cases
Yes, I will soften the language a bit, but I won't mention a DELETE payload. If some implementations do it. others may come to expect it. We don't want to encourage that by suggesting that it's a good idea. On Sep 3, 2009, at 11:52 PM, Keith Welter wrote: If the error occurs on the initiator, the notification MUST be returned in a separate INFORMATIONAL exchange, with no other payloads. Should an implementation be prohibited from sending an empty delete payload in this case? I would prefer wording like the following: with no other payloads except an optional empty delete payload. Keith Welter IBM z/OS Communications Server Developer 1-415-545-2694 (T/L: 473-2694) ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Comments on draft-ietf-ipsecme-roadmap-03
Hi Yaron/Sean/Julien/Greg/Scott/Yoav, Thank you very much for your comments. We are working on them and we hope to have a new revision out soon. Thanks Sheila and Suresh ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
