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

["Valery Smyslov" <[e-mail]>]

> > >     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.
> 
> Yes the mapping for IPr2 needs to work. Note, that if the mapping for
> IPr2 does not work, then this message will get thrown away by NAT, and
> as there is no response to the notify the responder will at some point
> assume that this path it switched to is broken and switch to use
> another IP, and is does not have any other IP, it needs to trigger
> some special code there to add IPr1 back to the list of allowed
> addresses, and then it will retransmit this address again using (IPr1,
> IPi) as addresses. This will then reach the initiator and for his
> point of view this was just removing the IPr2 from the address list.

Yes, quite a lot of movements for a simple task.

> On the other hand after that the responder will know that this method
> will not work as initiator does not keep mappings up, and can give up
> with the load balancing for this client, and rather move the clients
> which support faster redirect.

Again, better to know this beforehand.

> Or if it thinks load balancing is more important than the a minute
> breakage, it can simply keep retransmitting it on the IPr2, and stop
> responding to any packets to IPr1. After a while the initiator will
> notice this and it will try to probe on IPr2 too, and that will create
> the NAT mapping, and then responder can retransmit its notify to that
> port, and it will reach the initiator.

You repeat the scenario I described a couple of messages ago.

Let me cite myself once more - your explanations only support
my opinion, that it _is_ possible to use MOBIKE AS IS for load sharing, 
but it  comes out to be cumbersome and unreliable.

> > 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.
> 
> Load balancing issues are really hard, and I assumed that those have
> been taken care of by the cluster, as otherwise there is no point of
> any of this. As client can at any point decide to use whatever address
> the cluster gives it, the cluster MUST be able to process packets
> arriving to any of its addreses always.

I don't think so. If we define an extension to MOBIKE for cluster, 
then the client will know that the selection of destination IP
is under cluster control and won't randomly switch from one IP to another.
Of course the selection of client's source IP is a client's prerogative.

> > >    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.
> 
> Only if the destination address changes. Usually the client using
> MOBIKE has only one destination address, and multiple source
> addresses, so it will include all of its source addresses in the
> NAT_DETECTION_SOURCE_IP notifies, and the one destination address for
> the NAT_DETECTION_DESTINATION_IP. In that case there is no need to
> change packet after it is sent, and it will be same request
> transmitted over different source IP addresses.
> 
> If client do have multiple destination addresses, then it must assume
> each of those is different, and create separate IKE_SA_INIT messages
> for each of them.

That's what I said.

> > 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).
> 
> It will never re-calculate the packet. It will note this fact, and
> mark this request as failed, thus it will run it through sending it to
> the other end without modification, but after the process finishes, it
> will throw away the result, and immediately start over with correct
> destination address and correctly calculated
> NAT_DETECTION_DESTINATION_IP address field.

So, the first exchange is in fact timed out, but the client just ignores this
fact and instead of deleting IKE SA it starts a new exchange with a next MID, right?
Or do you mean that the new exchange will have the same MID?
RFC is silent about this detail.

Anyway, both cases lead to possible problems unless the responder
is treated these exchanges specially and ignores some RFC7296 rules.

For example, consider that the client first creates exchange with MID=5
and sends it to IP address IP1. Let's assume that the request reaches
the responder and responders sends back a reply, but the reply 
packet cannot get through due to routing asymmetry and the 
client never got it. From responder's point of view the exchange 
has completed successfully and it marks MID=5 as used.
If the client reuses this MID for the new exchange to IP2, then
the responder according to RFC7296 throws away new request
messages, as the MID=5 is already seen.

On the other hand, if the first request fails because the request
messages cannot reach the responder and the client uses next MID (6)
for its second request and this request reaches the responder, 
then the responder would never got the request with MID=5, so it 
will have a gat in its window and according to the RFC7296 
at some point it'll stop responding waiting for that MID.

Well, these issues aren't concerned with our topic of discussion,
they are just MOBIKE's complications not mentioned in the RFC.

> > 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.
> 
> Load balancing was explictly mentioned as out of scope for the MOBIKE,
> we did say that the method we are using in MOBIKE should try to
> support load balancing, but we never meant it to be generic solution
> for load balancing. There are lots of additional issues in the load
> balancing which needs to be solved than just this.
> 
> I.e. RFC4621 says:
> 
>    Note that MOBIKE does not aim to support load balancing between
>    multiple IP addresses. That is, each peer uses only one of the
>    available address pairs at a given point in time.
> ...
>    Load balancing is currently outside the scope of MOBIKE; however,
>    future work might include support for it. The selected format needs
>    to be flexible enough to include additional information in future
>    versions of the protocol (e.g., to enable load balancing). This may
>    be realized with an reserved field, which can later be used to
>    store additional information. As other information may arise that
>    may have to be tied to an address in the future, a reserved field
>    seems like a prudent design in any case.

Excellent quote. That's exactly what I suggest - a "future work that includes
support for load balancing in MOBIKE". And I don't understand why 
you oppose it so strongly.

Regards,
Valery.