Or think of a single IKE gateway that sets up IPsec SAs for multiple IPsec boxes. Like the key server in MSEC.
On Apr 27, 2010, at 3:27 PM, Yaron Sheffer wrote: > Hi Jitender, > > regarding your point #3: I am not sure that if I trust a gateway to > connect to, I also trust it to say that all ESP traffic from an > arbitrary IP address should be treated as a Child SA of this gateway. I > cannot see a concrete attack based on this assumption, but it can surely > result in interesting configuration issues. Just think of two IKE > gateways that (possibly because of misconfiguration) share one IPsec > box. > > Thanks, > Yaron > > On Mon, 2010-04-26 at 22:23 -0400, Jitender Arora wrote: >> 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 > > Scanned by Check Point Total Security Gateway. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
