Re: [IPsec] New draft posted

[Yoav Nir <[e-mail]>]

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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ipsec
> 
> 
> _______________________________________________
> IPsec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ipsec
> 
> Scanned by Check Point Total Security Gateway.