Re: [IPsec] Additional charter items 1/4: Responder MOBIKE

"Valery Smyslov" <smyslov.ietf@gmail.com> Mon, 19 February 2018 08:50 UTC

Return-Path: <smyslov.ietf@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 789E712426E for <ipsec@ietfa.amsl.com>; Mon, 19 Feb 2018 00:50:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.2
X-Spam-Level:
X-Spam-Status: No, score=-1.2 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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 XEi5y-SWhCcF for <ipsec@ietfa.amsl.com>; Mon, 19 Feb 2018 00:50:15 -0800 (PST)
Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 955D4127058 for <ipsec@ietf.org>; Mon, 19 Feb 2018 00:50:14 -0800 (PST)
Received: by mail-lf0-x233.google.com with SMTP id j193so12014086lfe.0 for <ipsec@ietf.org>; Mon, 19 Feb 2018 00:50:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=opB6G/C7loII3MSGU3vy2XG8hLHrd37JrAkXwVeSgd8=; b=Bf8zpV/aT4Fu/Kn7x63ICVMGWL89NqAHMfYUipqU8K6E64xocBsTC/qMdbwqyhK3im 1h2qoykUJ96pf844koHBoh+9qXtbrTv8SyoDjxNBhyIssCdyO6XyCQa0q0VgBXEhC7xK 5TU5YMKqr1U0wuifepk496XT0ML5l9nF7T7xb0/iLo3kzSql6qh+j8hl1IXPcCZytxHP 6+WwJf2SjTlabTKXX+Rl4pdc8NdcGQmfp1LPo1oZIKZ7zlK2YsGnsdzz7840UX5Cj91z LiiaKPweeG5LphIZfm2Kg+1k4PATlJ9oCkDHJ5mcij1YF0pYzi6aUkrnz6XXD80gP2nz 6isw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=opB6G/C7loII3MSGU3vy2XG8hLHrd37JrAkXwVeSgd8=; b=d90AZ0MLFAxCSMhCj8HeUDR32HseqXptjjAZ5BCD1DVVC7GXOE2td1dn99zaFYnz2P p7qYfJcBoy//HArTMJrCtV7ql3vY0a7f6yhczH2KEsIu5kVNln8ZzoC37ejp7hrfB5MR svAHJ8aIu0wcBXZ/kCwF2LTRUaQAZTFKQMXjpSTrc7EyKV7XO5wPafbIRAdggzb/irhq OWChj3kFv7YgBTo7J3KwmAjOdGmoRt09qxwlqOFYoAtgxBaqbMpVgPj8+++EXTQjfYpC 2Z+Sx4FEok3xDA5KIpchb2v5b8W5ehhJxDNFt3V4EEr4Z9Q4/0LJl20p7hdpB/RDVtLN 00cA==
X-Gm-Message-State: APf1xPCc8T2qXCdKVsoZSJBH4Uf2zElZocsCtXGtwjGmbb9Ep5sMz2u5 YYe+Yxw/kGB3IrHVQtshoCV10w==
X-Google-Smtp-Source: AH8x227nHiPQ63ZsKoU+eR2NUQAIoGRtFD7laG+cJObqf+9eKdJ2A9YKKLDMRmif9uRUSHEsR4lKsQ==
X-Received: by 10.46.44.6 with SMTP id s6mr3764963ljs.111.1519030212277; Mon, 19 Feb 2018 00:50:12 -0800 (PST)
Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id n143sm4920556lfb.87.2018.02.19.00.50.11 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 19 Feb 2018 00:50:11 -0800 (PST)
From: Valery Smyslov <smyslov.ietf@gmail.com>
To: 'Tero Kivinen' <kivinen@iki.fi>, ipsec@ietf.org
References: <23175.7252.256625.885691@fireball.acr.fi>
In-Reply-To: <23175.7252.256625.885691@fireball.acr.fi>
Date: Mon, 19 Feb 2018 11:50:08 +0300
Message-ID: <02c501d3a95e$a5d73200$f1859600$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQJXnlQnOgkoKoWaf0xqED6y+ZUK7KKjeP7Q
Content-Language: ru
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/8DzEoZumMNCX48Pt-K3fXmsDngI>
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 08:50:16 -0000

Hi, 

> This is items we did not manage to reach full consensus in the IETF
> 100 meeting. There were concerns and questions why this is needed and
> why it cannot be done with already existing methods (mostly redirect
> etc, or updating the address lists).
> 
> The proposed charter text is
> 
> ----------------------------------------------------------------------
> 
> MOBIKE protocol [RFC4555] is used to move existing IKE/IPsec SA from
> one IP address to another. However, in MOBIKE it is the initiator of
> the IKE SA (i.e. remote access client) that controls this process. If
> there are several responders each having own IP address and acting
> together as a load sharing cluster, then it is desirable for them to
> have ability to request initiator to switch to a particular member.
> The working group will analyze the possibility to extend MOBIKE
> protocol or to develop new IKE extension that will allow to build load
> sharing clusters in an interoperable way.
> 
> ----------------------------------------------------------------------
> 
> It could be also possible that we first start just researching whether
> we actually need any protocol changes, and if so make specifications
> for them, and if not, we might still want to publish some kind of
> informational document describing how those existing mechanisms can be
> used for this purpose.
> 
> Send your comments and whether you support adding this to the charter
> to the ipsec list in next two weeks.

I obviously support this item. 

The whole idea is that currently there is no interoperable way of building
load-sharing IPsec clusters. To effectively balance their load the nodes 
of such cluster must be able to dynamically move clients from one node
to another on node's discretion. So, in IKE terms, it is responder who 
must decide what another responder the initiator should continue
to communicate with.

What do we have now:
1. IKE redirect. It's the most obvious choice. However, IKE redirect
     requires that the client creates IKE SA with the node it is redirected to 
     from scratch with full authentication. This is:
        1) inefficient from resource consumption point of view
        2) causes delays
        3) most important - it may require user interaction (EAP authentication,
             or entering PIN to access user keys) that is completely unexpected to the user

2. IKE Redirect + IKE Resumption. Currently it is assumed that the client
     resumes to the same server it received the resumption ticket from,
     so some additional tweaking of IKE resumption is needed. 
      This approach is more efficient than 1, however IPsec SAs still need to be recreated.

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.

I think that the problem is important and the WG should address it.
I agree that some research would be useful.

Regards,
Valery.



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