FW: Marcelo's review of mobike protocol

Jari Arkko writes:
> 2. As i understand it, as currently defined, mobike does not supports 
> multiple address pairs simultaneously in a given SA, right? Moreover, as 
> i read it, all the IPSec SAs created with the same IKE SA have the same 
> address pair right? If any of these are so, IMHO this should be 
> explicitly noted in the document, since it would imho have two immediate 
> consequences:
> 2.1 No load sharing, load balancing, traffic engineering or 
> policing/preference setting would be supported, like distributing 
> different traffics through different address pairs/links, which should 
> be noted imho
> 2.2 No unidirectional paths are supported i.e. if a address pair is 
> working in one direction and another address pair is working in the 
> other direction, this cannot work, which should be noted explicitly too 
> in the spec imho.

Most of those things should be covered by the design document, but
short mention in the introduction could be good thing. 

> 3. The previous point brings me to this point, which is about ingress 
> filtering compatibility. There is no mention to ingress filtering 
> comaptibility here. As you know, when multiple addresses are available, 
> packets may be dropped by incompatibility between ingress filters and 
> the selected source address. This document does not considers this as a 
> problem. Becuase of ingress filters, many unidirectional paths may 
> result (packets are dropped when flowing in one direction). However, as 
> i understand it, mobike does not supports unidirectional paths (since 
> the same address pair is used in both directions). So, my point is that 
> in a case where no ingress filtering compatibility mechanism is provided 
> and because no unidirectional paths are supported, the mobike protocol 
> is likely to perform poorly in this scenario. I guess that at least you 
> should mention this, if not fix it.

There should not be problems with the ingress filters, as we always
use the source address associated to the given interface when sending
packets out. I.e. if we have two interfaces A and B, having IPa and
IPb,  when we send packets out using IPa we always select interface A.
The network connected to the interface should allow IPa to pass
through it as it is IP address given by the network to the host for
that interface. Implementations might need to do specific things to
bypass routing of those packets (using default route or similar) to
make use they are really sent out from the host using proper
interface. 

> 4. Establishment of the initial IKE session. No reference is made about 
> how the initial contact between the two parties is made. I mean, in case 
> that both have multiple addresses, and that some of them are not 
> working, the initial contact may not be trivial. Maybe this is out of 
> the scope of mobike, but current specs don't support this scenario, so 
> maybe it would be worth noting it.

I think the assumption is that the initiator knows the IP address (or
IP-addresses) of the other peer before the connection is even
initiated, thus MOBIKE will simply try the different addresses trying
to find working one.

> 
> 5. In the document, it seems that an important design choice that was 
> made was that (section 3.1)
... [about the initiator selects approach]

That discussion about why that approach was selected and what it
causes does not belong to the protocol document. It should be
something that is in the design document. 

> 11. In section 4.5. the NO_ADDITIONAL_ADDRESSES notification is 
> presented. As i understand it, this is the only way to delete addresses 
> from the address set, right?
> This is kind of twisted, i think. I mean, if a node wants to delete one 
> address because is no longer available it, must:
> - delete all the addresses using a NO_ADDITIONAL_ADDRESSES notification 
> message
> - add other addresses with a ADDITIONAL_ADDRESSES notification
> is this so?
> If yes, i think this should be clearly stated imho (at least that the 
> NO_ADDITIONAL_ADDRESSES notification serves to delete addresses)

No, I have not understood that section that way. I assumed that the
new list of addresses (ADDITIONAL_ADDRESSES) always overwrites the
whole previous list. I.e. it is not incremental update, but it is full
list every time. In some cases where you have only one IP-address, the
ADDITIONAL_ADDRESSES notify would not be there, and you need to have
some way to tell that there is no other addresses than the one that is
used in the IP-headers of this packet. 

> 12. In section 4.6 it is stated that:
> 
>    By default, the return routability check SHOULD be done before
>    updating the IPsec SAs.  In environments where the peer is expected
>    to be well-behaved (many corporate VPNs, for instance), or the
>    address can be verified by some other means (e.g., the address is
>    included in the peer's certificate), the return routability check MAY
>    be omitted or postponed until after the IPsec SAs have been updated.
> 
> I am not sure that the example of the certificate is a good example... 
> what if the certificate is self signed? (i don't know if those are 
> supported) but in any case, i don't know how simple is that certificates 
> can prove address ownership (this depends of the checks performed by the 
> CA about address ownership)

If the certificate is self signed, and it is trusted by the recipient
there is no problem. The basic idea is that in the VPN case where
multiple sites are connected together with VPN gateways each having
one or two addresses, each VPN gateway can have certificate which
lists the IP-addresses they have. The VPN gateways are not going to
get new address on the fly, thus they can use IP-addresses from the
certificates. Also the most common case of road warrior will probably
be that the gateway is authenticated with certificate and the client
is authenticated with some EAP method. In that case it would be
useless for clients to do return routability to the server's second
address, when the first address happen to go down. 
-- 
[email protected]