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

"Valery Smyslov" <smyslov.ietf@gmail.com> Mon, 12 March 2018 08:23 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 96ED612706D for <ipsec@ietfa.amsl.com>; Mon, 12 Mar 2018 01:23:10 -0700 (PDT)
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 6dM75MQIVHOr for <ipsec@ietfa.amsl.com>; Mon, 12 Mar 2018 01:23:09 -0700 (PDT)
Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::22f]) (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 115F7126BFD for <ipsec@ietf.org>; Mon, 12 Mar 2018 01:23:07 -0700 (PDT)
Received: by mail-lf0-x22f.google.com with SMTP id e28-v6so12886748lfc.3 for <ipsec@ietf.org>; Mon, 12 Mar 2018 01:23:07 -0700 (PDT)
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=WLBaOVi1ar9HjbNYLHjqH7q+6Q/vRPfA9STnlrzjjM8=; b=Eoh9ThgcbSOp8Dk9Wl55DubzANFzVUaxndeXJyFK55B/pFJ+aBk5J9wRhJxgsO9EoG O4fo55fXVjo2PjkOI654HkekaZT4S0k1SBEG+rWMv1DvxU24tDgVAb4usv/y7sV5XDkU +MgCUWfQT1U54LUsFThQ8M6EJCsdkdLZXkch07+8y0e4qrVHUhv0x9m9gJLMRA5s9oUa St3kqGzCd7uQ7fkhylOZWFexePjs1HejvQnBB5SNvesdN2WDViTJFcJF44w0frOncpq5 YLrmCo3t1iWJkb0P15AU761LCcuuvYYTe6bnOwFEIeAtm2+EL/9aErNHQQ+doePpLs9I GFag==
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=WLBaOVi1ar9HjbNYLHjqH7q+6Q/vRPfA9STnlrzjjM8=; b=hfjvezlDFn/7gjWiEDfM7qrvqJDFzSHPI77Aa6lKSOzoP13lS+1KQlKHyQPDGAoFvy Q4xAkizhHwSH1KHbkKisxOSEE3WFRjCRsCN9QuAkJLzvg4/htxvgZeMsGu5pOduzZSVR 7mKGKJZC7PbffpfVL1DflYb7tufhH/YnchgcgD0aW4yj1sEtgtz0WPvsTnPqUwrMiBZ+ gXQigskekN2eiHe6l4Jt78p+rYhxM8rD8RYx6OyukNsSqClOuI5tdnN2qUH1l2Q1m62r DBzagkiuSWMXjbd5G9siIPHYzQtOF90nPBs07+h/XbATT588wHt81iH1pQZK1bVtMLtm 7iIg==
X-Gm-Message-State: AElRT7EKADcXTzwMyawLY/PGjxUdT5MEJmFw6fyy1NrBRmmJWe7HTqCB kOXsYbLDumQpJ/126Cqo4Yfnxw==
X-Google-Smtp-Source: AG47ELtNM1zyb8TatbEOVEyppqk60XKV/lF+o+AfgQz/zV9QDJ6oFSrW/2CKqLrUiOJgxY4eQ4/Fdw==
X-Received: by 2002:a19:590c:: with SMTP id n12-v6mr4642468lfb.10.1520842985704; Mon, 12 Mar 2018 01:23:05 -0700 (PDT)
Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id p67sm1593471ljb.95.2018.03.12.01.23.04 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 12 Mar 2018 01:23:04 -0700 (PDT)
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> <043901d3ab29$8c980c20$a5c82460$@gmail.com> <23200.22423.300448.949259@fireball.acr.fi>
In-Reply-To: <23200.22423.300448.949259@fireball.acr.fi>
Date: Mon, 12 Mar 2018 11:23:04 +0300
Message-ID: <0a2601d3b9db$58583af0$0908b0d0$@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+wLRnswoAqvC3IYB4aweT6JSblWQ
Content-Language: ru
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/eK1bDh2xkA6vMUpvMzfOY3SJQSc>
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, 12 Mar 2018 08:23:11 -0000

Hi,

[I trimmed the message]

> > 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.
> 
> No. The switch will be triggered immediately when the cluster / server
> sends MOBIKE update using the 2nd ip address and does NOT include the
> currently used IP address in the address list. If that message goes
> through the client will start switch immediately, and probing the that
> it works is just one round trip, so the delay should be less than
> second.

I believe this interpretation is wrong. The IP address from the IP
is always implicitly included into the list of host's IP addresses (Section 3.6):

   If the exchange initiator has only a single IP address, it is placed
   in the IP header, and the message contains the
   NO_ADDITIONAL_ADDRESSES notification.  If the exchange initiator has
   several addresses, one of them is placed in the IP header, and the
   rest in ADDITIONAL_IP4_ADDRESS/ADDITIONAL_IP6_ADDRESS notifications.

So, according to the RFC4555 the currently used IP address must not be included
into the ADDITIONAL_IP*_ADDRESS notification. So, the client won't switch
to a new address immediately, it's first test an old path and if it works
it'll most probably do nothing.

>     Initiator                              Responder
>     ---------                              ---------
>                  <-- HDR(IPr2, IPi), SK { N(NO_ADDITIONAL_ADDRESSES) }
>     HDR(IPi, IPr2), SK { } -->
> 
> This will immediately trigger the initiator to switch to IPr2, as IPr1
> is no longer available. Note, that IPsec traffic can be switched to
> new address at this point already.

With NO_ADDITIONAL_ADDRESSES it will work, but only in case the mapping 
for IPr2 exists. That's the issue.

> and after that move is finished. So if client is keeping NAT mappings
> alive address change can be done without any lost packets. And the
> fact that it keeps mappings alive can either be tested, or you can use
> the fact that you get keepalive packets to the 2nd address as
> indication of that.

You are oversimplifying the problem. To make periodic tests by responder you 
must have a copy of IKE SA on all the cluster nodes and continuously sync them.
And the client won't send any NAT keepalives until it gets reply from the cluster, 
so the IKE SA again needs to be present (and synced!) on all cluster nodes all the time.
While this is possible, it is a headache and to some extent it makes the 
whole idea of the load-sharing cluster meaningless.

Another problem is that with MOBIKE the initiator is free to switch to any path
it wants in any moment. So, to encourage the client to send NAT KA to all cluster's
addresses you must include all of them into ADDITIONAL_IP*_ADDRESS
notification, so that the client knows all of them.  You must also reply
to requests sent to any of these addresses, otherwise the client won't
start sending NAT KA. But it means that now the client can switch 
to any of these addresses on its own discretion - that's completely 
kill the idea of load sharing cluster: it is the cluster that must control 
when and where to move client.

> > 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.
> 
> I do not think it says that directly, but that is only way to get
> MOBIKE working. It does that explictly for the initial IKE exchange:
> 
> 3.1. Initial IKE Exchange
> ...
>    If either or both of the peers have multiple addresses, some
>    combinations may not work. Thus, the initiator SHOULD try various
>    source and destination address combinations when retransmitting the
>    IKE_SA_INIT request.

These must be different requests (with different SPIs), at least if the initiator 
changes a destination IP, since the NAT_DETECTION_DESTINATION_IP would
be different. So it is not a retransmission, it's a new request.
Section 2.1 of RFC7296:

   A retransmission from the initiator MUST be
   bitwise identical to the original request.  That is, everything
   starting from the IKE header (the IKE SA initiator's SPI onwards)
   must be bitwise identical; items before it (such as the IP and UDP
   headers) do not have to be identical.

> For the other exchanges this can be seen in the section 3.5.
> 
> I.e. one of the triggers for the address change is:
> 
>    o  An IKEv2 request has been re-transmitted several times, but no
>       valid reply has been received. This suggests the current path is
>       no longer working.
> 
> Note, that this is done BEFORE the exchange times out.
> 
> So in the next step you pick address you want to try next, and go
> forward, and update IKE SA with new addresses, and then:
> 
>    o  If there are outstanding IKEv2 requests (requests for which the
>       initiator has not yet received a reply), continues
>       retransmitting them using the addresses in the IKE_SA (the new
>       addresses).
> 
> I.e., you start sending them out with new IP address. If you have
> space in your window you might also send address update, but quite
> often implementations only support window size of 1, so you send your
> original packet for 2nd IP address pair for some time, and if it still
> does not work, you go back to beginning, and notice this address pair
> does not work, lets pick next one. And you continue doing that until
> you time out the whole exchange after several minutes. Note, that you
> might run out of ip-address pairs during the process so you might end
> up going back to beginning again.

There are additional complications not mentioned in the RFC.
If the exchange is a MOBIKE probe and NAT is supported, then 
it will include NAT_DETECTION_DESTINATION_IP. When the exchange
initiator tries  different destination IP addresses it must re-calculate
this notification, so that NAT is detected properly. This leads to a direct 
violation of Section 2.1 of RFC7296 (see above).

> > 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).
> 
> I am not sure about that. Note, that we did work quite long to get the
> rules in section 3.5 correct, and there are things there that will
> make things work correctly if you follow the rules, even if not
> everything is explained there (i.e., it does not explain why you need
> to do things exactly like it says, it just assumes you do).
> 
> RFC4621 explains the design rational behind the MOBIKE, and it
> explains why we did some things in RFC4555. For example the section
> 6.2 of the RFC4621 explains that we need to use any existing IKE
> exchange as path testing message and explains why we did it.

Sorry, but there are still some unclear places.
And I don't think in its current form it suites well for building
load-sharing cluster. You are trying to convince me otherwise, 
and I agree that it would probably _somehow_ work in _some_ 
situations, but the quality of such a solution leaves much to be desired, IMHO.

> > 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?
> 
> Much better, but I still think that this can be done without
> modification to the MOBIKE itself, and you already implement it in the
> cluster end without any need to modify client end. It will work better
> if the client will send keepalives for all IP-addresses instead of
> just using the one, or if the client probes other paths than what is
> used every now and then.

Too many "if" for which the cluster end cannot be sure - 
client does it or not on its own discretion. That's what I'm complaining about.

> --
> kivinen@iki.fi

Regards,
Valery.