[IPsec] Comments to draft-mglt-ipsecme-clone-ike-sa-00.txt
Tero Kivinen <kivinen@iki.fi> Wed, 05 March 2014 23:01 UTC
Return-Path: <kivinen@iki.fi>
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 8DEB71A0242 for <ipsec@ietfa.amsl.com>; Wed, 5 Mar 2014 15:01:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.448
X-Spam-Level:
X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham
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 JAPPQRh3Oe9i for <ipsec@ietfa.amsl.com>; Wed, 5 Mar 2014 15:01:29 -0800 (PST)
Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9E2561A023C for <ipsec@ietf.org>; Wed, 5 Mar 2014 15:01:28 -0800 (PST)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.7/8.14.5) with ESMTP id s25N1Lv4012687 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for <ipsec@ietf.org>; Thu, 6 Mar 2014 01:01:21 +0200 (EET)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id s25N1LDf024188; Thu, 6 Mar 2014 01:01:21 +0200 (EET)
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: <21271.44225.752369.306111@fireball.kivinen.iki.fi>
Date: Thu, 06 Mar 2014 01:01:21 +0200
From: Tero Kivinen <kivinen@iki.fi>
To: ipsec@ietf.org
X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd)
X-Edit-Time: 43 min
X-Total-Time: 47 min
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/l3XndaqRko5ka9ck-NiQlLQhqz8
Subject: [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: Wed, 05 Mar 2014 23:01:31 -0000
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. 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. 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. 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). 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. 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/ 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. 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). In section B.3 fix: Alternatively, the VPN End User MAY uses a different IP address for each interface s/MAY uses/MAY use/ 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. -- kivinen@iki.fi
- [IPsec] Comments to draft-mglt-ipsecme-clone-ike-… Tero Kivinen
- Re: [IPsec] Comments to draft-mglt-ipsecme-clone-… Valery Smyslov