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
