Hi Yaron, Thanks for the feedback. I will definitely read the draft-ietf-ipsecme-ipsec-ha and will get back to you.
Here are my answers to your suggestions: 1. I will point the section 5.1 in the introduction itself that way the purpose and applications of the draft are clear. 2. We did discuss the NAT scenarios and were of the opinion that if we take care of the NAT scenario's then it will change the IKEv2 protocol in a major way. Here is how we were planning to solve the NAT issues: We were thinking that once the IKE_AUTH exchange is completed and the different tunnel addresses are specified by the VPN client or the Gateway, each side can send the informational IKEv2 message containing the NAT_DETECTION_SOURCE_IP and the NAT_DETECTION_DESTINATION_IP payloads (they will have to send this informational message using the tunnel addresses as the IKEv2 peer addresses) to see if there are NAT devices between them or not. If they determine that there is a NAT device, they can always use NAT addresses as the tunnel address. Using this approach the client or the gateway can determine whether there is a NAT device in the ESP traffic path or not. But using this approach requires that the Client and the gateway also to be able to listen for the IKE packets on the tunnel addresses and also these IKE packets will be protected by the IKE-SA negotiated on the IKE addresses. So this will require a lot of changes in the current implementation, but this is certainly possible. 3. The tunnel addresses are negotiated during the IKE-AUTH or the CREATE_CHILD_SA exchanges. These exchanges are protected using the IKE-SA and also the users are being authenticated by each side before the tunnel addresses are accepted. So once the users are authenticated, the Security Associations will be setup using the tunnel addresses as the tunnel src and the tunnel destination addresses, so the traffic will protected using these SA's. Should not this be enough for the case you mentioned below? Also as in our case all the IKEv2 signaling will be handled by the same gateway (load balancer will just act as a pass-through for IKEv2 traffic and will just choose the gateway), so I am not sure how the sections you mentioned in the RFC 5685 will be applicable. Thanks, Jitender -----Original Message----- From: Yaron Sheffer [mailto:yaronf.i...@gmail.com] Sent: Sunday, April 25, 2010 5:22 AM To: Jitender Arora Cc: ipsec@ietf.org Subject: Re: [IPsec] New draft posted Hi Jitender, this is certainly an interesting approach to the high-availability/load-balancing issue that we are just starting to tackle, as a group. I would appreciate your inputs to the discussion on draft-ietf-ipsecme-ipsec-ha. Below are a few initial comments on your draft: - I suggest moving Sec. 5.1 to the front (or at least pointing to it from the Introduction) so that the motivation becomes clear before the protocol details are presented. - Of course, if there are additional usage scenarios, it would be nice to include them. - Essentially ignoring the issue of NAT severely hurts the applicability of this protocol. Even saying something like "use STUN/TURN" is better than limiting the protocol to closed networks. - The security considerations never discuss the issue that the peer can now claims ownership of ANY IP address. I *think* this is just a denial-of-service issue, but it certainly needs to be analyzed. Which leads to the main issue with this proposal: - This is not just a change to IKEv2, it is a rather major change to the IPsec architecture. So I would expect some discussion of RFC 4301 entities. See the last 2 paragraphs of http://tools.ietf.org/html/rfc5685#section-3 for an example. Thanks, Yaron On Sat, 2010-04-24 at 10:09 -0400, Jitender Arora wrote: > Hi All, > > A new version of I-D, draft-arora-ipsecme-ikev2-alt-tunnel-addresses-00.txt > has been posted to the IETF repository. > > Filename: draft-arora-ipsecme-ikev2-alt-tunnel-addresses > Revision: 00 > Title: Alternate Tunnel Addresses for IKEv2 > > Please take a look and comment. > > Regards, > Jitender > _______________________________________________ > 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