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
