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

From: Tero Kivinen <[email-masked]>
Date: Fri, 16 Feb 2018 20:00:52 +0200

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.
-- 
[email-masked]

---

From: Paul Wouters <[email-masked]>
Date: Fri, 16 Feb 2018 14:52:35 -0500 (EST)

> The proposed charter text is

I support further discussion on this item, but I would like the
discussion to focus first on the goal (failover/redundancy) and then
look at solutions (maybe re-using/extending MOBIKE)

Paul

---

From: "Valery Smyslov" <[email-masked]>
Date: Mon, 19 Feb 2018 11:50:08 +0300

Hi, 

> The proposed charter text is

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.

> --
> [email-masked]
> 
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: "Hu, Jun (Nokia - US/Mountain View)" <[email-masked]>
Date: Mon, 19 Feb 2018 18:25:09 +0000

+1

> -----Original Message-----
> From: IPsec [mailto:[email-masked]] On Behalf Of Paul Wouters

> I support further discussion on this item, but I would like the discussion to
> focus first on the goal (failover/redundancy) and then look at solutions
> (maybe re-using/extending MOBIKE)
> 
> Paul
>

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 19 Feb 2018 21:13:20 +0200

>      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.
-- 
[email-masked]

---

From: "Valery Smyslov" <[email-masked]>
Date: Tue, 20 Feb 2018 18:24:38 +0300

Hi Tero,

> addresses and can change the address at will. 

This is true. However, it is the original initiator who decides which addresses to use.
The original responder mostly plays passive role, only informing the initiator
which addresses are available.

> The problem is that you

Yes.

> pair is used. (RFC4555 section 2.1, last sentence of the 2nd

It states that " the exchange initiator _can_ decide which addresses are used."
While he/she definitely can, the exchange would fail in case of restricted
NAT if the responder initiated the exchange from the IP address 
the NAT box has no mapping for.

>    address list received from the initiator.

If original responder used its address the NAT box has no
mapping for yet, the exchange would fail.

> address from the responder).

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.

> 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. 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

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.

> Note, that even in that case there is no protocol changes with them, and
> case. 

We seem to have different view of what "short" means :-)

The initiator doesn't sent liveness checks continuously.
It start probing current path if it suspects there is something wrong with it,
e.g. there is no IPsec packets from the responder for some period
of time. This period cannot be too short, it is usually tens of seconds 
to minute. Then, when starting probing the current path the initiator 
performs several retransmissions before giving up. And again, the timeout
cannot be too short, it is usually at least ten seconds, more likely 
about a minute. So your "short" delay is at least about a minute,
or even more. 

I don't think this delay is appropriate for any real-time traffic.

Needless to say that this approach also complicates cluster implementation.
To move a client from one node to another the cluster needs first to
send ADDITIONAL_*_ADDRESS that contains only the address of the node
the cluster wants to move client to. Then the IKE SA state must be transferred 
to a new node and the current node must stop responding to this client.
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)...

> This delay will be eliminiated if the address update from

There is absolutely no guarantee that it will work.
I'd like to have something more reliable.

Regards,
Valery.

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 21 Feb 2018 00:15:06 +0200

> 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.

>    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.... 

> In real life there is a NAT in most cases.

Use IPv6 :-)

Then there will not be problems with NATs...

Firewalls might be another matter though.

> And while in presence

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. 

> 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. 

> 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.

Of course if you have bad implementation in the client end which for
example does not detect that traffic changes to unidirectional, and
does not start IKEv2 probe soon after that, then you might have much
longer timers. Also if your IKEv2 retransmission timers are in orders
of minutes, and MOBIKE probes are using them without changes, then it
might take several minutes to fix this issue. 

> 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
some reason to belive there is something funny going on. It might for
example receive ICMP destination port unreachable or unprotected IKE
notify, and that should trigger liveness check (responder can send
this message out when it decides to move the client to another peer,
as it will not be responding to the port 500 / 4500 UDP messages for
that host anymore). It might also detect that traffic changed to be
unidirectional, i.e., no reply packets coming back to any of the IPsec
SAs, and this should again trigger liveness check.

It should not really do any liveness checks on periodic bases, doing
so is just plain stupid (and not specified in the RFC7296).

Section 2.4 of RFC7296:

----------------------------------------------------------------------
    ... If there has only been outgoing traffic on all of the SAs
    associated with an IKE SA, it is essential to confirm liveness of
    the other endpoint to avoid black holes. If no cryptographically
    protected messages have been received on an IKE SA or any of its
    Child SAs recently, the system needs to perform a liveness check
    in order to prevent sending messages to a dead peer.
----------------------------------------------------------------------

Section 2.21.4 of RFC7296:

----------------------------------------------------------------------
    ... A node should treat such a message (and also a network message
    like ICMP destination unreachable) as a hint that there might be
    problems with SAs to that IP address and should initiate a
    liveness check for any such IKE SA.
----------------------------------------------------------------------

> to minute.

In normal case having it in ten seconds or so is quite good value, as
in most cases the traffic is bidirectional (TCP with acks, UDP with
some kind of ACKs / return packets). When traffic changes to be
unidirectional then it can do the liveness check, and if it succeeds
and even if the traffic still stays unidirectional it does not need to
do livenss checks too often, as traffic has not changed to be
unidirectional it is still unidirectional, and then once every few
minutes is good enough.

> Then, when starting probing the current path the initiator 

Initial timeout is usually less than a second (0.5 seconds or so),
doubling after each packet, will give you 5 retransmissions in 10
seconds, and after that you can move to next address, especially if
fast recovery is important for your use case. In most cases you have
only one IP address for yourself (or if you have multiple, all of them
work), and in this case you would have two for responder, so
immediately when you move to 2nd address that will work.

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. 

> the cluster wants to move client to.

This is unavoidable. The responder needs to somehow tell the initiator
where it wants it to move. Whether it does it using standard MOBIKE
message, or some newly defined MOBIKE message, it does not matter. It
still needs to do exactly same thing. Except the first one is already
defined in the RFC4555.

> 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).

Again this is something that must be done in both cases.

> 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. 

> 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... 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 :-)

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....
-- 
[email-masked]

---

From: "Valery Smyslov" <[email-masked]>
Date: Wed, 21 Feb 2018 18:35:05 +0300

> between, and even then it only fails if the initiator does not keep

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

> 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.

> > In real life there is a NAT in most cases.

Good advice, cap :-)

> Firewalls might be another matter though.

Sure.

> 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.

> never be full deterministic behavior of ther prosess for all possible

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.

> working path in tens of seconds more, or so. I.e., this should happen

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

> that it is broken. It SHOULD only send liveness checks when there is

[snip]

That's what I said.

[snip]
 
> 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.

> 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.
 
> before it has tried all possible addresses, thus there is no issue in

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.

> 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

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

> 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.

---

From: Paul Wouters <[email-masked]>
Date: Wed, 21 Feb 2018 11:41:55 -0500 (EST)

> Then there will not be problems with NATs...

Sadly, IPv6 NAT is happening and there is a request to add ESPinUDP
support for IPv6 in the Linux kernel :(

I think the topic is interesting and we should add it to the charter
in some way that does not tie this to MOBIKE. And we can discuss
from there.

Paul

---

From: Michael Richardson <[email-masked]>
Date: Sun, 25 Feb 2018 14:36:08 -0500

Tero asked about:
1) Responder MOBIKE
2) Address Failure Errors
3) Labeled IPsec
4) Mitigating privacy concerns

I read through the discussion about them, and read some of the drafts.
I find that 1,2,3 are all well defined and bounded in time and space.

I found that #4 is not so well understood; in particular it seems to suggest
doing things not just defend against, but subvert government actors.
I don't really object to such work occuring, but I want to suggest that
this is a case of cat-and-mouse arms race.  I suggest that the IETF is
too slow a place to do this.  Do this in open source.

I would not object to seeing a a moderate number (~dozen) of types allocated
for experimental use.  i.e. details to be provided later.  Pretty much all of
our tables are Expert Review. Go out there and try some things with real
code, and then report back in two years which mechanisms scaled and did the
right thing.

I have a concern with #3: while I know that redhat delivers this to
government customers, are there any other vendors will also implement?
If not, then I'm worried we won't have enough interested parties to review,
unless some of the actual customers are brought to the table to review.

I'd like to prioritize #2 as highest.

I think that #1 (Responder MOBIKE) may suffer from lack of actual
implementers being involved today.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-