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

"Valery Smyslov" <smyslov.ietf@gmail.com> Wed, 21 February 2018 15:35 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 1916012D7F4 for <ipsec@ietfa.amsl.com>; Wed, 21 Feb 2018 07:35:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.5
X-Spam-Level:
X-Spam-Status: No, score=-0.5 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_NONE=-0.0001, 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 uIPmEBEGWf7L for <ipsec@ietfa.amsl.com>; Wed, 21 Feb 2018 07:35:11 -0800 (PST)
Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::231]) (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 BB186124B17 for <ipsec@ietf.org>; Wed, 21 Feb 2018 07:35:10 -0800 (PST)
Received: by mail-lf0-x231.google.com with SMTP id 37so2931843lfs.7 for <ipsec@ietf.org>; Wed, 21 Feb 2018 07:35:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=h5f0PVj0lSb86ZLjx8HmI2Ny8MIPpjO7ErQx9erXlRA=; b=VDLuqyGlge4aycPSHfQYuQnZGzl+Es+G6HIkXd73jPbriH24MUixCQeToN+qkdVaKe tSnH0JHpyxe4Dw3AUGPCeZCQSiEdXRlmHNjp0U+u+Hm4pA9+8SZQWM45T1YZm2Jctr0h eWxG11yVXcTjNpEWn3SqCgxk06dx6Uu/8o+jyCpk+Wlc1YSgQZ9ZjLuBG3rpmUeTxUD9 8ZZix5qbD/cRS4Bc4l11CnkYx3l9HQI+rmFhdpbbMM7Ke02IPC/4Nmfd+CY0uDQijPYS 6TdjTb9efnRTvVo88WD9kQuWSmMIAlcVMpnufCDN6RBjyxIsNz1n79MBpQDI17FAHZXK 0gCg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=h5f0PVj0lSb86ZLjx8HmI2Ny8MIPpjO7ErQx9erXlRA=; b=DifU7J9Y4VwM2ex6SugI+Cyzt5Le2lPNSkX+enei5uT7imPFSq0RjzWog0VU0I37ri e4/Q5C7YU2Bmt5rtC7+HqJPpRLBVAUPJz9A7FktCw/228Nv+h6qtHwac1LJJLlEARgMV ZSS8JzQnj8XCeCaOcnormidrDlmNmMQUXtyhU6gaNG7lILL8PPi2251+M6/98OdhNni2 GjJz0yE0hN3YzKn8O02a078HRTvpiVfL18dGB3Tcg0sAkS4wuKWdVi7aiaEPlFf+FO0L vRKfp8Z7mOQVowJQTLKQej2hSA8vMrBcWEHx302g3LossqGclbbfgLV1kG0XPmv81Bfy ttzQ==
X-Gm-Message-State: APf1xPCaULmJnKr62loKHCkeSHwH8QYJzIBCLnwXhQQwm5Pzc/pE3Pc/ SNR0mrWMcZjKtybW70KGTFzL7g==
X-Google-Smtp-Source: AH8x224Gu/oBcyIeqwTwbDgoFuGR3L+QEc0a633/TY0ixQux9wmrjzgOK8lX1u2yDOYmnPNGZmIRuw==
X-Received: by 10.46.112.21 with SMTP id l21mr2505055ljc.45.1519227308362; Wed, 21 Feb 2018 07:35:08 -0800 (PST)
Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id t10sm92671ljt.49.2018.02.21.07.35.06 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 21 Feb 2018 07:35:07 -0800 (PST)
From: "Valery Smyslov" <smyslov.ietf@gmail.com>
To: "'Tero Kivinen'" <kivinen@iki.fi>
Cc: <ipsec@ietf.org>
References: <23175.7252.256625.885691@fireball.acr.fi> <02c501d3a95e$a5d73200$f1859600$@gmail.com> <23179.8656.330909.562547@fireball.acr.fi> <038e01d3aa5e$ec66bc80$c5343580$@gmail.com> <23180.40426.204224.108279@fireball.acr.fi>
In-Reply-To: <23180.40426.204224.108279@fireball.acr.fi>
Date: Wed, 21 Feb 2018 18:35:05 +0300
Message-ID: <043901d3ab29$8c980c20$a5c82460$@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+ZUK7AHZIA6IAi7r5FoC17kq+wLRnswoolj5CBA=
Content-Language: ru
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/TVvAPUOTWpKy1PYPiWL9PSTTspQ>
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: Wed, 21 Feb 2018 15:35:13 -0000

> > If original responder used its address the NAT box has no
> > mapping for yet, the exchange would fail.
> 
> True, but there is nothing in the proposed charter text talking about
> NATs. It seems the issues only appear if there is restricted NAT
> between, and even then it only fails if the initiator does not keep
> ports open in NAT.

The proposed charter text is generic enough, we may make it more specific.

> > In MOBIKE the initiator is not obliged to do this. Section 3.10:
> >
> >    Implementations MAY do path testing even if
> >    the path currently being used is working to, for example, detect when
> >    a better (but previously unavailable) path becomes available.
> 
> But it is allowed to do so. If you want to implementations to be able
> to talk to servers having multiple responder IP address and not cause
> delays, perhaps your implementation should do what it "MAY" do....

The cluster never knows if the client does this or not.
So "my" implementation in this case is a cluster and I cannot
determine if any given client honor this "MAY" or not.

> > > 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.
> >
> > If there is no NAT in between, then there is no problem.
> >
> > In real life there is a NAT in most cases.
> 
> Use IPv6 :-)

Good advice, cap :-)

> Then there will not be problems with NATs...
> 
> Firewalls might be another matter though.

Sure.

> > And while in presence
> > of NAT in theory unmodified MOBIKE _may_ work, there are too many
> > vague places in the RFC that makes this problematic:
> >  - the initiator is not obliged to probe addresses other than the currently used ones
> >  - even if it probes, it may do it too rarely, so that the created NAT mapping
> >    will expire
> 
> There is no timers in the RFC specified for any of these operations,
> all of them are implementation details. This is something that will
> NOT affect interoperability, but will affect how well your
> implementation works. If this is important matter for your
> implementation you should research and study the problem and tune the
> parameters suitable for your normal use case.

We are talking about different things. You are trying to convince 
me that the cluster functionality _can_ be achieved with the current
MOBIKE. I don't disagree, but I'm pointing out, that in this case
it is relied on completely _optional_ features specified in RFC
and there is no indication whether and how peer supports
these features. These features don't affect MOBIKE interoperability, 
but they do affect whether unmodified MOBIKE can be used
for cluster scenario.

Again, I'm not insisting that my proposal is the only and the best
solution. Probably we can use the approach you suggested,
but in this case some extension to the MOBIKE should be added
that will make these features non optional and will add 
a negotiation (or announcement) mechanism, so that 
implementations can rely on peer's behavior.

> > So, there is no guarantee for a cluster that the operation
> > of moving a client from one node to another will succeed.
> > I'd like such operations to be more deterministic.
> 
> Even if we make some changes in the protocol, there will be
> implementations out there which do not implement them, thus there will
> never be full deterministic behavior of ther prosess for all possible
> clients.

If we make these changes to the protocol so that the cluster
is aware of clients capabilities, then the cluster will always know
whether try to move any particular client or let him/her alone.
The situation will be more deterministic.

> > We seem to have different view of what "short" means :-)
> 
> It should detect it in few tens of seconds, and probes should find the
> working path in tens of seconds more, or so. I.e., this should happen
> in well under a minute.

That was my conclusion too. And I don't think that about a minute is a "short delay".

> > The initiator doesn't sent liveness checks continuously.
> 
> Initiator SHOULD NEVER send liveness checks continuously. If it does
> that it is broken. It SHOULD only send liveness checks when there is

[snip]

That's what I said.

[snip]
 
> The delay should be less than minute.
> 
> > I don't think this delay is appropriate for any real-time traffic.
> 
> If you care about real-time traffic, then you should keep your NAT
> mappings up for all peers, so you will get the address update message,
> and can move to new address immediately when you receive it.

It won't help much. The MOBIKE client doesn't know that it must 
switch to a just received additional address once he receives it. The 
event that usually triggers this movement is an availability of current
path. So you still will have a the delay while the client detects that
the current path is not working and the new path works.
You'll still have about 10-20 seconds delay at best.

> > Then the IKE SA state must be transferred to a new node and the
> > current node must stop responding to this client.
> 
> You need to move the IKE SA anyways, and you need to move it before
> you send any update which says there is another IP address to be used.
> And both ends MUST be able to process IKE and IPsec SA packets at the
> same time if we want to make sure no packets are lost during the
> transition (if you really care about real-time traffic).

No, in your case the first node must stop responding to the client,
so that client understands that it should switch to the other address.
With my proposal the client is explicitly asked to do that,
so the whole procedure should take less time and be more reliable.
so that it is easier to make the event atomic from cluster point of view.
 
> > Then the cluster would wait until the client detects the failure and
> > switches itself to a new node. And there is also a chance that there
> > are some IKE exchanges in progress, so if the node stops responding
> > the exchanges could time out the and the IKE SA would be deleted
> > before the movement takes place (in my proposal the MOBIKE is
> > combined with RFC6311 exchange to make this working)...
> 
> If you are using MOBIKE, then the IKE exchange should not time out
> before it has tried all possible addresses, thus there is no issue in
> there.

Can you please point me where RFC4555 requires that 
_any_ exchange must try all possible addresses before 
timing out? Path testing is described in Sections 3.10 and 3.12
and these sections only tell about using INFORMATIONAL 
DPD exchanges for this purpose.

> > > 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.
> >
> > There is absolutely no guarantee that it will work.
> > I'd like to have something more reliable.
> 
> Knowing that there are so broken implementations of IPsec and IKE out
> there that still use periodic liveness checks for example, there will
> never be any guarantee that any of these will work... 

Broken implementations is not an issue here (although it is always big issue :-().
The issue is that RFC4555 in its current form is too vague to be used
for cluster use case. This use case requires some additions to RFC4555
or some clarifications in any case (if the cluster use case is solved
using MOBIKE, that is not the only possible way).

> Even if we defined some new method for transferring this information to the other
> end that will not mean that it will get implemented correctly on the
> clients :-)

Alas. But that is unfortunately true for any new standard.
Should we shutdown IETF then? :-)

> Anyways as the current proposed charter text does not really describe
> the problem you are trying to solve, at least it needs to be updated
> to properly state the problem. I.e., you are not trying to make the
> responder side MOBIKE, you are trying to get responder MOBIKE messages
> through restricted NAT / firewall....

OK. How about the following?

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. 
While the responder can try to instruct the initiator to switch to a different
IP address, the whole process is not reliable enough, especially 
in presence of NAT or firewalls. 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.

Is it better?

Regards,
Valery.

> --
> kivinen@iki.fi