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

[Tero Kivinen <[e-mail]>]

Valery Smyslov writes:
> > 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.
> 
> 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.

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

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

Then there will not be problems with NATs...

Firewalls might be another matter though.

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

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

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

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

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

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. 

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

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. 

> > 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... 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....
-- 
[e-mail]