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:[email protected]]
Sent: Sunday, April 25, 2010 5:22 AM
To: Jitender Arora
Cc: [email protected]
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
> [email protected]
> https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
