Re: [IPsec] I-D Action: draft-nir-ipsecme-cafr-00.txt

"Valery Smyslov" <svanru@gmail.com> Wed, 14 August 2013 14:07 UTC

Return-Path: <svanru@gmail.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F249C21E8097 for <ipsec@ietfa.amsl.com>; Wed, 14 Aug 2013 07:07:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, STOX_REPLY_TYPE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xTFJEIlz41cJ for <ipsec@ietfa.amsl.com>; Wed, 14 Aug 2013 07:07:15 -0700 (PDT)
Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 498F311E816B for <ipsec@ietf.org>; Wed, 14 Aug 2013 07:06:59 -0700 (PDT)
Received: by mail-la0-f49.google.com with SMTP id ev20so6808572lab.36 for <ipsec@ietf.org>; Wed, 14 Aug 2013 07:06:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:subject:date:mime-version :content-type:content-transfer-encoding; bh=8IuSw7Dnoa1SkBMkpwQ+Ry5Cz5QcHz8eAPZgfRuiOLw=; b=gkGcelZcnLl4EDXPalxKn+103FZmzASktMp9YefXflUmwdAae2rRZUn9zyezBZI8Q7 AVlLuqOwmTShLxnHEoHiAqy1sl681SSI9HWbG3wLLtb4gVRF804Hinj6Idx+OY4HQkIf /nE6a65bge6HRr9m+woLCfR/iEiMQY7HLLDifaf9fOk0hI5IQTiJhJLIXjKJcUTklega VpvpD5M1Xrt4zUWW0uuT1hhn7eyRc++/DbS4xVjGTKNwfQLl8giCfmHTt9jwoq9nH9SI G5J35IhI/kQXpX8aY35hph13ISeRHyulv6qKoYnpRtzAS1S4lcYXajvUzvFwNcqwh26B etsg==
X-Received: by 10.152.9.37 with SMTP id w5mr8742789laa.23.1376489218164; Wed, 14 Aug 2013 07:06:58 -0700 (PDT)
Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id i9sm15962710lba.0.2013.08.14.07.06.56 for <multiple recipients> (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 14 Aug 2013 07:06:57 -0700 (PDT)
Message-ID: <FE4D58425F5943FBBFA3AEF73D8951C5@buildpc>
From: Valery Smyslov <svanru@gmail.com>
To: Yoav Nir <ynir@checkpoint.com>
References: <20130812223310.2768.80108.idtracker@ietfa.amsl.com> <482E5FF2-2AD7-469B-9679-A5945E609A5F@checkpoint.com> <69110CB5C30743C4A03CCAB62F7D9843@buildpc> <587E0A87-381F-4950-A495-CC8F1706DE7E@checkpoint.com>
Date: Wed, 14 Aug 2013 18:07:02 +0400
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="iso-8859-1"; reply-type="original"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5931
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157
Cc: ipsec@ietf.org
Subject: Re: [IPsec] I-D Action: draft-nir-ipsecme-cafr-00.txt
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 14 Aug 2013 14:07:21 -0000

>> isn't it better to do Child SAs movement in a separate Informational 
>> Exchange,
>> rather than in IKE_AUTH?
>>
>> Pros:
>> 1. No race conditions
>
>You would then have three operations that you need to do:
> a. Re-authenticate - create a new IKE SA
> b. Move the IPsec SAs
> c. Delete the old IKE SA
>
> Each of (b) and (c) could be done by any peer, not necessarily the same 
> one that did (a). If we get a DELETE before all the IPsec SAs
> were transferred, some SAs could be deleted, or worse - they could be 
> deleted on only one peer.

Well, similar race conditions are already existed in IKEv2 and are covered
in section 2.25. And I believe, if you properly describe all possible 
collisions and
due actions, those situations, when some SAs are transferred and some not 
etc.
will not happen. Note, that code to deal with collisions according with 2.25
is already in IKEv2, you need only to update conditions to send 
TEMPORARY_FAILURE
notification.

>> 2. No additional complication to already over-complicated IKE_AUTH
>
>It adds one more thing for the peers to do during IKE_AUTH, but it doesn't 
>make a difference if the extra thing is within IKE_AUTH or
>immediately after. If the issue is the length of the packet, I believe we 
>are already solving this.

No, size is not an issue here. But complexity of processing logic for 
IKE_AUTH is an issue.

>> 3. More generic solution, so can be used in other situations,
>>   for example in case IKA SA is cloned 
>> (draft-mglt-ipsecme-keep-old-ike-sa).
>
> Interesting point. That draft does not, in fact, state what happens to the 
> child SAs. Since the old SA is kept, I guess they remain, and when
> the old IKE SA does eventually get deleted, the child SAs are also 
> deleted. Nor does it help to specify that they move: the new IKE SA
> might get deleted first.

I remember the author was asked at the meeting what to do with child SAs,
and he answrered that ability to move them is the next step, that is not 
covered in the current
version of the draft (if I got it right).