Re: [IPsec] Additional charter items 1/4: Responder MOBIKE
Tero Kivinen <kivinen@iki.fi> Mon, 19 February 2018 19:13 UTC
Return-Path: <kivinen@iki.fi>
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 720751204DA for <ipsec@ietfa.amsl.com>; Mon, 19 Feb 2018 11:13:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.121
X-Spam-Level:
X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=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 UzuLlZp1duPa for <ipsec@ietfa.amsl.com>; Mon, 19 Feb 2018 11:13:24 -0800 (PST)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [212.16.101.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67D00126C26 for <ipsec@ietf.org>; Mon, 19 Feb 2018 11:13:24 -0800 (PST)
Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id w1JJDKPE003795 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 19 Feb 2018 21:13:20 +0200 (EET)
Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id w1JJDKur009645; Mon, 19 Feb 2018 21:13:20 +0200 (EET)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <23179.8656.330909.562547@fireball.acr.fi>
Date: Mon, 19 Feb 2018 21:13:20 +0200
From: Tero Kivinen <kivinen@iki.fi>
To: Valery Smyslov <smyslov.ietf@gmail.com>
Cc: ipsec@ietf.org
In-Reply-To: <02c501d3a95e$a5d73200$f1859600$@gmail.com>
References: <23175.7252.256625.885691@fireball.acr.fi> <02c501d3a95e$a5d73200$f1859600$@gmail.com>
X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd)
X-Edit-Time: 22 min
X-Total-Time: 26 min
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/qMapw-sF_gqAjhZ-Nq0LA4udbxQ>
Subject: Re: [IPsec] Additional charter items 1/4: Responder MOBIKE
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.22
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: <https://mailarchive.ietf.org/arch/browse/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: Mon, 19 Feb 2018 19:13:27 -0000
Valery Smyslov writes: > 3. MOBIKE. In current MOBIKE only initial initiator can initiate change of IP addresses. > If this problem is solved, then this is the best choice for load sharing clusters. Mobike is symmetric in IKEv2 level. Either end can have multiple IP addresses and can change the address at will. The problem is that you want something else than that, i.e., you do not want responder to change IP address and start using that as you can with MOBIKE. I think what you are really wanting is to responder to signal and ask for the initiator to change the address because you assume there is NAT between and if the responder just starts sending packets from new source IP address then they do not reach the initiator? Note, the initiator do select the address pair to be used in the IPsec SA, but for the IKEv2 SA the exchange initiator selects which address pair is used. (RFC4555 section 2.1, last sentence of the 2nd paragraph). Also I think this can also already be done using standard RFC4555 mobike. In the section 3.5 says when the initiator should change the address and one of the examples it gives is: o An INFORMATIONAL request containing an ADDITIONAL_IP4_ADDRESS, ADDITIONAL_IP6_ADDRESS, or NO_ADDITIONAL_ADDRESSES notification is received. This means the peer's addresses may have changed. This is particularly important if the announced set of addresses no longer contains the currently used address. The responder can simply do following describined in the RFC4555 section 3.6: There is one additional complication: when the responder wants to update the address set, the currently used addresses may no longer work. In this case, the responder uses the additional address list received from the initiator, and the list of its own addresses, to determine which addresses to use for sending the INFORMATIONAL request. This is the only time the responder uses the additional address list received from the initiator. I.e., if it wants to move initiator from IP_R1 to IP_R2 it simply sends INFORMATIONAL exchange with source address of IP_R2 to IP_Ix and sends ADDITIONAL_*_ADDRESS or NO_ADDITIONAL_ADDRESSES describing the usable addresses and when initiator sees this it will immediately trigger to change the addresses used for IKEv2 SA and IPsec SA. Of course one of the issues that if there is restricted NAT between hosts then packet from IP_R2 will not reach the initiator, unless the initiator has opened that port pair also in the NAT (which it can do by sending probe/keepalive packets out to the responder using all address from the responder). So at least the charter text is misleading, as I think this can already be done without any problems with MOBIKE as long as there is no NATs between, and even if there is NAT, the initiator can simply send keepalives for all responder addresses, and then it works. Note, that even in that case there is no protocol changes with them, and even if the address update from responder never reaches the initiator the MOBIKE still works, as long as the responders stops responding to the IP_R1 address (i.e., the address where it wants the initiator to move away from). I.e., if responder has IP_R1 and IP_R2 addresses, and initiator is using IP_R1, and responder wants it to stop using it and move to IP_R2, then it is simply enough to stop responding to packets coming to the IP_R1. The initiator will detect this and move to use IP_R2... Yes, there will be short delay causing packets to be lost in this case. This delay will be eliminiated if the address update from responder reached initiator, i.e., if the initiator kept the ports open in NAT or if there is no NAT between. -- kivinen@iki.fi
- [IPsec] Additional charter items 1/4: Responder M… Tero Kivinen
- Re: [IPsec] Additional charter items 1/4: Respond… Paul Wouters
- Re: [IPsec] Additional charter items 1/4: Respond… Valery Smyslov
- Re: [IPsec] Additional charter items 1/4: Respond… Hu, Jun (Nokia - US/Mountain View)
- Re: [IPsec] Additional charter items 1/4: Respond… Tero Kivinen
- Re: [IPsec] Additional charter items 1/4: Respond… Valery Smyslov
- Re: [IPsec] Additional charter items 1/4: Respond… Tero Kivinen
- Re: [IPsec] Additional charter items 1/4: Respond… Valery Smyslov
- Re: [IPsec] Additional charter items 1/4: Respond… Paul Wouters
- [IPsec] Additional charter items 1 thu 4 Michael Richardson
- Re: [IPsec] Additional charter items 1/4: Respond… Tero Kivinen
- Re: [IPsec] Additional charter items 1/4: Respond… Valery Smyslov
- Re: [IPsec] Additional charter items 1/4: Respond… Tero Kivinen
- Re: [IPsec] Additional charter items 1/4: Respond… Valery Smyslov