Re: [IPsec] New draft posted

Tero Kivinen <kivinen@iki.fi> Tue, 27 April 2010 11:20 UTC

Return-Path: <kivinen@iki.fi>
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E1C03A6896 for <ipsec@core3.amsl.com>; Tue, 27 Apr 2010 04:20:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.11
X-Spam-Level:
X-Spam-Status: No, score=-2.11 tagged_above=-999 required=5 tests=[AWL=0.489, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FEanj2B-zzIV for <ipsec@core3.amsl.com>; Tue, 27 Apr 2010 04:20:47 -0700 (PDT)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 832103A6918 for <ipsec@ietf.org>; Tue, 27 Apr 2010 04:20:10 -0700 (PDT)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id o3RBJqZ0010690 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Apr 2010 14:19:52 +0300 (EEST)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o3RBJpDo024898; Tue, 27 Apr 2010 14:19:51 +0300 (EEST)
X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <19414.51287.786283.875147@fireball.kivinen.iki.fi>
Date: Tue, 27 Apr 2010 14:19:51 +0300
From: Tero Kivinen <kivinen@iki.fi>
To: Jitender Arora <JArora@acmepacket.com>
In-Reply-To: <A8F897BE25922348AB562D74E6C686E41F488DA639@mail>
References: <ea322d4c93b67735a8e6eb26cc9fca41.squirrel@www.trepanning.net> <A8F897BE25922348AB562D74E6C686E41F457FBA95@mail> <1272187315.22380.46.camel@yaronf-linux> <A8F897BE25922348AB562D74E6C686E41F488DA639@mail>
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 5 min
X-Total-Time: 4 min
Cc: "ipsec@ietf.org" <ipsec@ietf.org>
Subject: Re: [IPsec] New draft posted
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 27 Apr 2010 11:20:48 -0000

Jitender Arora writes:
> 1.  I will point the section 5.1 in the introduction itself that way
> the purpose and applications of the draft are clear.

After I read the section 5.1 (I skipped most of the other draft as I
needed to know first WHY this is needed before I care about HOW it is
implemented), and I do not really see enough text there to cause me to
read the HOW part.

So I would need better and more text about WHY this extension is
needed. Why it is important that the IKEv2 SA and Child SA uses
different outer addresses? Who is supposed to terminate the IKEv2 SA
and who is supposed to terminate the Child SAs. Is this assuming that
IKEv2 SA and Child SA are still on the same machine or what? If so,
why not just use the IP address of that host for both IKEv2 SA and
Child SA?

So I think the usage scenarios (WHY part) is much more important than
the actual protocol (HOW part), and it should be clear from the
beginning.

Currently this draft mostly assumes there is problem, but it does not
explain why you think the problem actually exists or what the problem
is. 
-- 
kivinen@iki.fi