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