Re: [IPsec] IPsec HA problem statement
Hi Yoav, > I have noticed that StrongSwan is [not] implementing clustering. Starting with the recently released 4.4.0, we provide an experimental clustering feature. Using the terms from the draft, it is a "Tight Completely Transparent Load Sharing Cluster". Most work has been done before the HA discussion started on the list, more details are available at [1]. > Have you had a chance to read it? Yes. > If so, I would very much appreciate it, if you could send a short > review to the list. The terminology is very useful. I used the term "node" for a single box in the cluster, but "member" is even better. For "Outbound SA Counters", we use an approach to "count, but not encrypt" the packets on the passive members. And our "Inbound SA Counters" are updated by verifying a packet from time to time. This approach has some requirements to the cluster setup and some problems not trivial to handle. So I'm not sure if we should mention it in the draft. > Mainly, they want to know if the document is ready, or whether there > are some issues that are not yet covered there. I think the draft is good to go. It provides a good overview and states the problems that need to be addressed. Best regards Martin [1]http://wiki.strongswan.org/projects/strongswan/wiki/HighAvailability ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] New draft posted
Jitender Arora writes: > Jitender--> Currently we are using this approach (basically using > the redirect and the Mobike). > > This is causing the following issues: > > 1. If the redirect message is handled by the Load Balancer, the > load balancer needs to be IKEv2 aware and also it needs to know the > IP addresses of the Security Gateways for which it is responsible. > This can cause the performance issues as the Load Balancer should > not be application aware and should do the load balancing based on > the layer 3/layer 4 information. Load balancer by definition needs to know the devices where it is sharing the load to, so I do not consider that a problem. Also if the redirection is done in the IKE_SA_INIT phase then the application support required is very minimal. Also there is no need that the load balancer itself needs to be acting as application gateway, the published IP address for the IKEv2 connections can also be some other IP-address, i.e. that host does not need to be on the path of the real traffic. If this one host is only parsing IKE_SA_INIT packets and sending redirect backs any old 386 box you can find from your junk pile will be able to handle the traffic up to millions of clients (million clients, each connecting for example once per hour means there is 277 connection attempts per second, and any old box can receive 277 udp packets and send 277 udp replies back (in completely stateless manner)). > 2. If the Load Balancer passes this IKEv2 messages directly to the > security gateways using the layer 3 information, the security > gateway will then have to send the redirect to the client back > through the LoadBalancer and telling the client to talk to different > address now. This again causes an extra message exchange to achieve > the load balancing. Those extra messages only happen during the setup phase, and I would expect the load balancer can pass through those less than 300 messages per second. If it cannot, then you have much bigger problems when the real traffic starts to come in... > Jitender--> I think, I did not make this clear, the Load Balancer > will not take care of the IKEv2 traffic, it will just pass through > the IKEv2 traffic to the security gateways without handling them. > But all the IKEv2 traffic will have to go through this load balancer > so that the IKEv2 signaling can take place between the same > addresses. So if the load balancer cannot handle few hundred packets per second to passthrough then I think you should really consider replacing the hardware. For normal IPsec use the IKEv2 packet are not send periodically at all. There is 2+2 packets in the beginning. There might be one DPD exchange over IKEv2 SA when the ESP traffic stops, but after that there shouldn't be anything until the ESP traffic restarts. So there should very little IKEv2 traffic, and in normal case it is limited to about 6 packets in total over the whole lifetime of the IKEv2 SA. > In IKEv2 the IKEv2 SA and IPsec SAs are very closely tied together, > and running them on separate machines is very complicated (We just > had long discussion about this on the list, i.e. what kind of > failure models can happen and what cannot happen). > > Jitender--> If this has been captured somewhere, can you please > point us to that link. http://www.ietf.org/mail-archive/web/ipsec/current/msg06192.html -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Document Action: 'Using Advanced Encryption Standard (AES) Counter Mode with IKEv2' to Informational RFC
The IESG has approved the following document: - 'Using Advanced Encryption Standard (AES) Counter Mode with IKEv2 ' as an Informational RFC This document is the product of the IP Security Maintenance and Extensions Working Group. The IESG contact persons are Sean Turner and Tim Polk. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-aes-ctr-ikev2-07.txt Technical Summary This document describes how to use the AES-CTR mode with an explicit initialization value to protect IKEv2 messages after keys are established. Working Group Summary This is the product of the IPSECME WG. Nothing worth noting: it got a small but adequate amount of review. Document Quality There are already a bunch of implementations based on developers guessing how to do this; to the best of our knowledge, those implementations match what is described in this document. Personnel Paul Hoffman (paul.hoff...@vpnc.org) is the document Shepherd. Sean Turner (turn...@ieca.com) is the Responsible Area Director. The IANA Expert(s) for the registries in this document is Tero Kivinen (kivi...@iki.fi). RFC Editor Note 1) Please remove the following from the 1st page: Updates: RFC4307 (if approved) 2) Please move the reference to [RFC3686] in Section 7.2 to be the 1st reference in 7.1 (i.e., make it a normative reference). 3) Add the following as a new last paragraph in Section 1: Implementers need to carefully consider use of AES-CTR over the mandatory to implement algorithms in [RFC4307] because the performance improvements of AES-CTR are minimal in the context of IKEv2. Furthermore, these performance improvements may be offset by the Counter Mode-specific risk of a minor, hard to detect, implementation issue resulting in total security failure. 4) Please note that this is intended for informational - not standards as indicated in the header of the draft. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
