Re: [IPsec] Comments to draft-mglt-ipsecme-clone-ike-sa-00.txt

"Valery Smyslov" <svanru@gmail.com> Thu, 06 March 2014 07:42 UTC

Return-Path: <svanru@gmail.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99E441A010D for <ipsec@ietfa.amsl.com>; Wed, 5 Mar 2014 23:42:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.561
X-Spam-Level:
X-Spam-Status: No, score=-1.561 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bmGHSq38JrWK for <ipsec@ietfa.amsl.com>; Wed, 5 Mar 2014 23:42:32 -0800 (PST)
Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::232]) by ietfa.amsl.com (Postfix) with ESMTP id 5B8B61A0101 for <ipsec@ietf.org>; Wed, 5 Mar 2014 23:42:32 -0800 (PST)
Received: by mail-lb0-f178.google.com with SMTP id s7so1445064lbd.23 for <ipsec@ietf.org>; Wed, 05 Mar 2014 23:42:28 -0800 (PST)
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=V8VoOM1I9vaeSGnmf8z0pTOBjiXTvdxtHV4hCLbfD+M=; b=jznLeZEdlk3JTVOKmu4lzZokDggLOQ57EHyLoyASRacT/UZJwkEcqaFki1vXQngwUU fln96zpqpTPvDyeXuKcYJV8+wGyyBQZXe2PXYcoHg1ktpFVswn/pXX8c6R9J1/wN5PLY Jpr0VbsSxeixJm2haY+kBv72lbsO9cZt2Uqw2nYsa4XXMbJVcEvWzjnJSd9dZLnojF47 4q+Uc0doRa6vUcgVBT8pN1jHZzdfg0WbP39MykFym03QuyNfg7WZxBs0JZnkF2IvcNK0 z9IeKq+J6i9VTssEQ3sT3tFN0W0L5Rt3+j7lTmCCz0sqZOMo+5yPgVIHVfmQraZC68eu pX5Q==
X-Received: by 10.152.206.42 with SMTP id ll10mr7107504lac.16.1394091747922; Wed, 05 Mar 2014 23:42:27 -0800 (PST)
Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id x5sm5339027lbk.5.2014.03.05.23.42.26 for <multiple recipients> (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 05 Mar 2014 23:42:26 -0800 (PST)
Message-ID: <0ACC9B8EA3184B9FAA2F40EA5173864F@buildpc>
From: "Valery Smyslov" <svanru@gmail.com>
To: "Tero Kivinen" <kivinen@iki.fi>, <ipsec@ietf.org>
References: <21271.44225.752369.306111@fireball.kivinen.iki.fi>
Date: Thu, 6 Mar 2014 11:42:18 +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
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/RjNZusLNfNcCURXJh15LxamvWUo
Cc: Daniel Migault <mglt.ietf@gmail.com>
Subject: Re: [IPsec] Comments to draft-mglt-ipsecme-clone-ike-sa-00.txt
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
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: Thu, 06 Mar 2014 07:42:34 -0000

Hi Tero,

Thanks for reading and commenting the draft.
As I'm now a co-author of the draft, I'll try to answer.


> In the section 4. Protocol Overview, the draft says:
>
>   The current IKE_SA becomes the old IKE_SA and the newly negotiated
>   IKE_SA becomes the new IKE_SA.
>
> What the draft does not specify what happens to the Child SAs present
> on the old IKE SA. Are they moved to the new IKE SA or are they
> staying at the old. I would expect them to stay, as we just create
> clone of the IKE SA, but as in normal IKE SA rekey they move, this
> needs to be specified.

This is important and it is clarified in the next version (not yet 
published).
You are right, Child SAs stay with old IKE SA.

> Also in the sentence:
>
> If the Initiator does not want or
>   does not care that two parallel IKE SA exists, the CLONE_IKE_SA
>   Notify Payload SHOULD be omitted.
>
> Remove the useless SHOULD. If initiator does not want to create IKE SA
> clone, of course it does not include the notify specifying that it
> wants clone. I.e change text to:
>
> If the Initiator does not want or
>   does not care that two parallel IKE SA exists, it will not include
>   CLONE_IKE_SA Notify Payload in the IKE SA rekey exchange.

Agree.

> In the next sentence there is text:
>
>                 The CLONE_IKE_SA Notify Payload is
>   always part of a CREATE_CHILD_SA IKEv2 exchange.
>
> I think it would be good to specify here too that it is always part of
> a CREATE_CHILD_SA IKEv2 exchange rekeying IKE SA.

It is clarified in the next version.

> In the same section there is text saying:
>
>   The responder supports the CLONE_IKE_SA Notify Payload as it provided
>   a CLONE_IKE_SA_SUPPORTED Notify Payload. If the CREATE_CHILD_SA
>   request concerns a IKE_SA rekey. The responder MUST proceed to the
>   IKE_SA rekey, create the new IKE_SA, and keep the old IKE_SA and
>   respond with a CLONE_IKE_SA Notify Payload as represented below:
>
> I would expect there are situations where the responder does not want
> to allow IKE SA to be cloned, for example when it is running out of
> IKE SAs (i.e. too many clones). This text says the responder MUST do
> that... also the first two sentences should be connected to the later
> ones, i.e:
>
>   The responder has already indicated its support to the CLONE_IKE_SA
>   Notify Payload as it provided a CLONE_IKE_SA_SUPPORTED Notify
>   Payload earlier. When the CREATE_CHILD_SA request with the
>   CLONE_IKE_SA notify is received by the responder, it can either
>   return error (for example NO_ADDITIONAL_SAS) or proceed with the
>   IKE_SA cloning, create the new IKE_SA, and keeping the old IKE_SA
>   and respond with a CREATE_CHILD_SA exchange reply with CLONE_IKE_SA
>   Notify Payload as represented below:
>
> Other option would for the responder to just ignore the CLONE_IKE_SA
> notify and return normal IKE SA rekey packet without doing the
> cloning, but doing normal IKE SA rekey instead. I think it is better
> to return NO_ADDITIONAL_SAS in error cases, than to do IKE SA rekey
> (which initiator didn't want).

Actually, this part is redesigned in the next version along the lines you 
suggest.

> In section 5, the text about the critical bit could be clarified
> (there are lots of misunderstanding about it already), i.e. change:
>
>   - Critical Bit (1 bit):  Indicates how the responder handles the
>         Notify Payload.  In this document the Critical Bit is not set.
>
> to:
>
>   - Critical Bit (1 bit):  Indicates how the responder handles the
>         Notify Payload.  As notify payload is mandatory to support in
>         IKEv2, the Critical Bit is not set.

OK.

> In section 7.  IANA Considerations, change the:
>
>   The new fields and number are the following:
>
> to
>
>   This document allocates two new values from the "IKEv2 Notify
>   Message Types - Status Types" registry:
>
> The security considerations section requires some fixes and more text:
>
>   The protocol defined in this document does not modifies IKEv2.  It
>   signalizes what has been implementation dependent on how to manage an
>   old IKE_SA after a rekey.
>
> s/modifies/modify/

Thanks.

> Also I do not think the RFC5996 said that it is implementation
> dependent on how to manage an old IKE_SA after rekey. It says in
> section 2.8 that old IKE SA is deleted (RFC5996):
>
>     After the new equivalent IKE SA is created, the initiator
>   deletes the old IKE SA, and the Delete payload to delete itself MUST
>   be the last request sent over the old IKE SA.
>
> It does not give any indication how much you should wait after the
> creating new IKE SA, but the text saying "initiator deletes the old
> IKE SA" is quite clear...
>
> So I would fix the second sentence to be something better. The
> security considerations section should also list other attacks, i.e.
> this method could allow creating more IKE SAs or Child SAs between
> peers than what would be possible with single IKE SA (for example
> there might be Child SA limit per IKE SA, and this can be used to
> bypass that limit or similar). It also might affect auditing and
> accounting, as now for example only the first IKE SA might cause the
> account start event to be called, but it might be possible that each
> IKE SA destroy even will stop accounting. Also accounting might be
> interested how many clones the IKE SA has, or it might only be
> interested of the very first and very last IKE SA for the same ID.

Agree, this section needs more words.

> In appendix B.1 the text:
>
>   The exchange is completely described in [RFC4555].  First the
>   negotiates the IKE_SA.  In the figure below peers also proceed to NAT
>   detection because of the use of MOBIKE.
>
> Is missing some words in the second sentence (First the negotiates).

Thanks.

> In section B.3 fix:
>
>      Alternatively, the VPN End User MAY uses a different IP
>   address for each interface
>
> s/MAY uses/MAY use/

Thanks again.

> The exchange B.5 is not accoding to the draft, as it has
> N(CLONE_IKE_SA) inside the IKE_AUTH exchange, and the draft says it
> can only be in the CREATE_CHILD_SA exchange doing IKE SA rekey. So
> that kind of optimized negotiation is not possible with current draft.
>
> Also I think adding that kind of complexity in the IKE_AUTH is bad
> idea, so I would simply remove the B.5 example.

Agree and this "reduced" exchanges are already completely removed from the 
draft.

Thanks,
Valery.

> -- 
> kivinen@iki.fi
>
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec