I agree. And whatever we may think of the particular solution, it does present a problem that can and should be in the problem statement draft.
So how about adding teh following sub-section: 3.7. Different IP addresses for IKE and IPsec In many implementations there are separate IP addresses for the cluster, and for each member. While the packets protected by tunnel mode child SAs are encapsulated in IP headers with the cluster IP address, the IKE packets originate from a specific member, and carry that member's IP address. For the peer, this looks weird, as the usual thing is for the IPsec packets to come from the same IP address as the IKE packets. One obvious solution, is to use some fancy capability of the IKE host to change things so that IKE packets also come out of the cluster IP address. This can be achieved through NAT or through assigning multiple addresses to interfaces. This is not, however, possible for all implementations. [ARORA] discusses this problem in greater depth, and proposes another solution, that does involve protocol changes. On Apr 25, 2010, at 12:21 PM, Yaron Sheffer wrote: > 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
