Valery Smyslov writes:
> It's much easier to rate limit responses, say no more than one per second.
> You may also check the length.
True, but this is what some implementations did and perhaps do still.
And the RFC7296 mandates that retransmission must be bitwise identical
(there are other reasons for that too).
> OK, that only justifies my thought that MOBIKE is fragile :-)
> What if both paths work, but the networks are lossy?
In normal cases you do bit more tries for the first IP, before you
move to second or third. I.e., something like 5 retries on first
address (0.5, 1, 2, 4, 8 second intervals using 15.5 seconds or first
address), and then move to 2nd address and so on.
> In this case with high probability your second exchange
> will look like the first: you won't get reply on IP_R1,
> switch to IP_R2, got reply and initiate new exchange again.
> And so on. The process won't converge well.
True. On the other hand you only need to succeed once to converge it,
and you only need to do this if you have so bad connection that you
really start timing out lots of request. In that case there will be
other usage issues anyway....
> Not exactly. The MOBIKE currently is only concerned with IP addresses.
> It doesn't take transport into consideration. If you formally follow MOBIKE
> you don't need to initiate new exchange, because when you switch from
> UDP to TCP the IP will remain the same.
Not true.
> > In tcp encapsulation the situation is same. Once we move to TCP, or
> > from TCP to UDP, that is deteced by the initiator that something
> > changed during UPDATE_SA_ADDRESSES, so after that exchange finishs
> > successfully, it needs to redo it using the path it thinks work, and
> > verify that both ends are in sync.
>
> Again, the path doesn't change, the transport changes.
> So, this must be clarified in the draft...
The rfc4555 does not defined path, but rfc4621 does:
Path
The sequence of routers traversed by the MOBIKE and IPsec
packets exchanged between the two peers. Note that this path may
be affected not only by the involved source and destination IP
addresses, but also by the transport protocol. Since MOBIKE and
IPsec packets have a different appearance on the wire, they
might be routed along a different path, for example, due to load
balancing. This definition is taken from [RFC2960] and adapted
to the MOBIKE context.
So the transport protocol should be taken in to account. Unfortunately
the section 1.3 do not refer to the rfc4621 for terminology, but I
think it should have done that, as I think it defines other terms
too (available address, current path etc).
--
[email protected]
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
