FW: Marcelo's review of mobike protocol

I'm forwarding Marcelo's review of the MOBIKE protocol
draft -04. Thank you very much for the review, Marcelo!

Folks, please see his comments below:

------

Below you can find the review of the draft-ietf-mobike-protocol-04.txt 
that you requested.

Please note that i have not been following the work of mobike neither 
the comments received in the last call, so probably some of these 
comments may have been raised before or may simple be the consequence of 
the lack of in-depth understanding of the protocol design.

First of all, i think that the document is in very good shape, and it 
covers all the aspects that i needed to follow it.
In addition, i have the following comments/questions:

1. I think that in the Introduction, a comment about what is the 
difference between mobike and what can be achieved with MIP is. I mean, 
after reading the spec, the difference is clear, but stating it in the 
introduction would make things easier to understand, especially since 
the mobility scenario is described there. In particular, stating the it 
is not a goal of mobike to make changes in the IP address transparent to 
the upper layers (as stated in the charter for instance) would be useful.

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.

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.

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.

5. In the document, it seems that an important design choice that was 
made was that (section 3.1)

   MOBIKE solves this problem by taking a simple approach: the party
   that initiated the IKE_SA (the "client" in a remote access VPN
   scenario) is responsible for deciding which address pair is used for
   the IPsec SAs, and for collecting the information it needs to make
   this decision (such as determining which address pairs work or do not
   work).  The other party (the "gateway" in a remote access VPN
   scenario) simply tells the initiator what addresses it has, but does
   not update the IPsec SAs until it receives a message from the
   initiator to do so.

Now what i would like to understand is what parts of the mobike protocol 
would not support the more general scenario, where both parties can 
change the address pair used for the communication.

As i see it, this was a constraint to simplify the protocol to a case 
like the VPN which was useful. My question at this point is how much of 
the resulting protocol actually relies on this constraint?
As i read it, this resulted in the following constraints:
- Tunnel mode only is supported
- Only the initiator can be behind a nat
- no simultaneous movement is supported

Now, i can see that supporting those may increase the complexity of the 
protocol
However, in addition, it seems that the protocol artificially imposes that
- failure detection, path exploration and path selection can only be 
performed by the initiator (client)
- it includes a couple of corner cases where the responder can change 
its address for dealing with specific cases.
Wouldn't it be simpler to define a symmetric operation of the protocol 
(without corner cases) and simply stating the three constraints above? 
Or are there other constraints imposed by this model that i am missing?

Next, some more text-specific comments:

6. In section 3.2. it would make clearer to me if the messages and 
extensions introduced by mobike (i.e. the actual mobike protocol) where 
highlighted somehow in the examples (so that it can be distinguished 
from general IKE exchange)

7. In section 3.3 it is stated that:

   For simplicity, MOBIKE does not attempt to handle all possible NAT-
   related scenarios.  Instead, MOBIKE assumes that if NATs are present,
   the initiator is the party "behind" the NAT, and does not fully
   support the case where the responder's addresses change.

But later on, in section 4.3. it is stated that

   Note that if some of the initiator's interfaces are behind a NAT
   (from the responder's point of view), the addresses received by the
   responder will be incorrect.  This means the procedure for changing
   responder addresses described in Section 4.5 does not fully work when
   the initiator is behind a NAT.  For the same reason, the peers also
   SHOULD NOT use this information for any other purposes than what is
   explicitly described in this document.

So from the first paragraph it seems that the configuration where the 
initiator is behind a nat is supported, while in the second paragraph 
seems that it isn't. This is quite confusing to me...

8. I think that many other constraints should be listed in the 
Limitations section 3.4

For instance, that the protocol doesn't fully supports the case that the 
responder is behind the nat (i know it is mentioned before, but this is 
a limitation too)
That no simultaneous movement is supported
That no unidirectional paths are supported. (and that in presece of 
ingress filtering this may imply that the protocol will perform poorly)
That only local failures are repaired (and that other more distant 
failures may not be repaired by the protocol)
That a single address pair is supported in all the SAs created through a 
single IKE_SA
That the protocol may not be able to establish a communication if a 
failure has occurred before initial contact

9. In section 4.4 i think that the Dead Path Detection indication should 
be mentioned as one of the events that should lead to an address change 
(perhaps a reference to section 4.9 would be useful too) along with


   o  An IKEv2 request has been re-transmitted several times, but no
      valid reply has been received.  This suggests the current path is
      no longer working.

   o  An INFORMATIONAL request containing ADDITIONAL_IP4/6_ADDRESS
      notifications is received.  This means the peer's addresses may
      have changed.

   o  An UNACCEPTABLE_ADDRESSES notification is received as a response
      to address update request (described below).

   o  The initiator receives a NAT_DETECTION_DESTINATION_IP notification
      that does not match the previous UPDATE_SA_ADDRESSES response (see
      Section 4.7 for a more detailed description).

(included just to point out which part of the doc i was talking about)

10. In section 4.4, it is stated that:

  o  It updates the IPsec SAs associated with this IKE_SA with the new
      addresses (unless this was already done before sending the
      request).

As i understand it, the reason for updating the addresses here is 
because the reply plays the role of a return routability check, right?
It would make sense to state so, for instance adding something like

  o  It updates the IPsec SAs associated with this IKE_SA with the new
      addresses (unless this was already done before sending the
      request i.e. no return routability check was required, see 4.6).

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)

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)

13. Later on, in this section 6.3 it is stated that:

   It should also be noted, as shown in [Bombing], that without ingress
   filtering in the attacker's network, such attacks are already
   possible simply by sending spoofed packets from the attacker to the
   victim directly.

But the whole point of this attack is to achieve amplification, right? I 
mean, the story that an attacker using a 56kbps starts a download from a 
heavy server and the redirects it towards a victim flooding it. The 
point is that the attacker could only send 56kbps, while in this attack, 
it could redirect the whole server flow through the victim. So, i don't 
agree with this comment i would suggest to remove it.

14. In section 6.4 it is stated that:

   Attackers may spoof various indications from lower layers and the
   network in an effort to confuse the peers about which addresses are
   or are not working.  For example, attackers may spoof link-layer
   error messages in an effort to cause the parties to move their
   traffic elsewhere or even to disconnect.  Attackers may also spoof
   information related to network attachments, router discovery, and
   address assignments in an effort to make the parties believe they
   have Internet connectivity when, in reality, they do not.

   This may cause use of non-preferred addresses or even denial-of-
   service.

As i understand this, all non verifiable indications should be used 
merely as hints. When such a hint is received, the node should perform a 
Dead Peer Detection, verifying securely, that the path is no longer 
working.

I don't see that these attacks could actually cause dos attacks, but 
just added DPD traffic.

Well, i hope you find some of this stuff useful,