Re: [IPsec] New draft posted

Jitender Arora <> Tue, 27 April 2010 02:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D3C3E3A685B for <>; Mon, 26 Apr 2010 19:23:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.855
X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JHD5V3F-UwHF for <>; Mon, 26 Apr 2010 19:23:55 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 56ED63A68DB for <>; Mon, 26 Apr 2010 19:23:55 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 8.1.375.2; Mon, 26 Apr 2010 22:23:41 -0400
Received: from ([]) by mail ([]) with mapi; Mon, 26 Apr 2010 22:23:40 -0400
From: Jitender Arora <>
To: Yaron Sheffer <>
Date: Mon, 26 Apr 2010 22:23:35 -0400
Thread-Topic: [IPsec] New draft posted
Thread-Index: AcrkWM944O1yRC7DREmah50QGGEHTgBVpHgQ
Message-ID: <A8F897BE25922348AB562D74E6C686E41F488DA639@mail>
References: <> <A8F897BE25922348AB562D74E6C686E41F457FBA95@mail> <1272187315.22380.46.camel@yaronf-linux>
In-Reply-To: <1272187315.22380.46.camel@yaronf-linux>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" <>
Subject: Re: [IPsec] New draft posted
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 27 Apr 2010 02:23:57 -0000

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.


-----Original Message-----
From: Yaron Sheffer [] 
Sent: Sunday, April 25, 2010 5:22 AM
To: Jitender Arora
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

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 for an example.


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