Re: [IPsec] New draft posted

Yaron Sheffer <> Tue, 27 April 2010 12:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BED8A3A6968 for <>; Tue, 27 Apr 2010 05:27:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.339
X-Spam-Status: No, score=-2.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id E4210InMwhPv for <>; Tue, 27 Apr 2010 05:27:29 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 4CAAC3A672E for <>; Tue, 27 Apr 2010 05:27:29 -0700 (PDT)
Received: by wyb35 with SMTP id 35so3568554wyb.31 for <>; Tue, 27 Apr 2010 05:27:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=domainkey-signature:received:received:subject:from:to:cc :in-reply-to:references:content-type:date:message-id:mime-version :x-mailer:content-transfer-encoding; bh=b8+qNgleZb5nQdZWAesR1Zcd3w5dVDeD/U+3t0AEnR8=; b=P7nFSO+cmUXD6GxbS8sSJwJ2mcZpWxZTTiFHefpMk+XgIm7xdfLsQtDp+4Wbt0YghN Dy2PKi7SJCm9UyGibz+v4pfknARQ8FZ9Ze3JBCm7n5OuhG+AUgLjh83k8xqY3Kzx9CYs hUV1g0wYp5Ez2CH6SgC2QDzSq7RBkLlv8U8fk=
DomainKey-Signature: a=rsa-sha1; c=nofws;; s=gamma; h=subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:x-mailer:content-transfer-encoding; b=hCuZSYUpFOK4E/GG7zULhS/t1m2MblrQr4N6ksVhp8fck/iitHNG5kl73yLiQ4nL7f DbmPaEpwph6A3pqMQ+Xs8hmNt3I29E5ju+BdYKLX3K9c37bkgAttWjZJAjKXiZfV1UrL Z+MtUXTX+WdeUv+C9A3FH5LYTFj++0KCjwVaw=
Received: by with SMTP id u53mr5006739wee.184.1272371233525; Tue, 27 Apr 2010 05:27:13 -0700 (PDT)
Received: from [] ( []) by with ESMTPS id z34sm5212447wbv.14.2010. (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 27 Apr 2010 05:27:13 -0700 (PDT)
From: Yaron Sheffer <>
To: Jitender Arora <>
In-Reply-To: <A8F897BE25922348AB562D74E6C686E41F488DA639@mail>
References: <> <A8F897BE25922348AB562D74E6C686E41F457FBA95@mail> <1272187315.22380.46.camel@yaronf-linux> <A8F897BE25922348AB562D74E6C686E41F488DA639@mail>
Content-Type: text/plain; charset="UTF-8"
Date: Tue, 27 Apr 2010 15:27:09 +0300
Message-ID: <1272371229.2347.87.camel@yaronf-linux>
Mime-Version: 1.0
X-Mailer: Evolution 2.28.1
Content-Transfer-Encoding: 7bit
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 12:27:33 -0000

Hi Jitender,

regarding your point #3: I am not sure that if I trust a gateway to
connect to, I also trust it to say that all ESP traffic from an
arbitrary IP address should be treated as a Child SA of this gateway. I
cannot see a concrete attack based on this assumption, but it can surely
result in interesting configuration issues. Just think of two IKE
gateways that (possibly because of misconfiguration) share one IPsec

On Mon, 2010-04-26 at 22:23 -0400, Jitender Arora wrote:
> 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 [] 
> Sent: Sunday, April 25, 2010 5:22 AM
> To: Jitender Arora
> Cc:
> 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
> 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
> >
> >