Subject: [Mobike] FW: Marcelo's review of mobike protocol

From: Jari Arkko <[email-masked]>
Date: Wed, 12 Oct 2005 17:07:47 +0300

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,

_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 13 Oct 2005 15:27:02 +0300

> other direction, this cannot work, which should be noted explicitly too 

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

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

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

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

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

> 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-masked]
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sat, 15 Oct 2005 16:38:38 +0200

> make use they are really sent out from the host using proper

yes in this case there shouldn't be problems with ingress filters. 
However, as i understand it, it is expected that a common multihoming 
scenario is that multiple PA address blocks are assigned to a 
multihomed site (one per isp serving the site), so that there will be 
multiple global addresses assigned to each interface connected to the 
multihomed site.
In this case, selecting the egress interface doesn't help you selecting 
among the multiple addresses assigned to that interface.
However, you still may have problem with ingress filters because each 
address has been assigned by a different ISP, implying that if ingress 
filters are in place, each isp will only route those packets that 
contain the prefix delegated by the particular isp in the source 
address of the packet. hence, we may have ingress filters 
incompatibility issues, so unidirectional paths may be quite frequent 
if no ingress filters compatibility mechanisms are in place (for more 
about this check draft-huitema-shim6-ingress-filtering-00.txt

> initiated, thus MOBIKE will simply try the different addresses trying

i guess that this at least needs to be specified i.e. that mobike will 
try with different addresses.... question: is mobike going to retry 
using only different destination addresses or it will also try with 
different source addresses? i guess it makes sense to try with 
different source addresses as well, in particular, with all the 
possible combinations src and dst addresses available.
However, while it may be quite common that a node retires with 
different dest addresses (hey, rfc3484 says that a node SHOULD do it) 
currently, it is not usual AFAIK retrials with different source 
addresses, hence why mobike should explicitly mention it if you want 
this imho

> something that is in the design document.

right
however, my intention was somehow different than the rationale for this 
choice is included in the doc.

my point was that:
- as i understand it, when designing the protocol, the wg decided to 
assume this asymetrical roles, where the initiator is kind of 
responsible for selecting addresses and so on.
- based on this choice, the protocol was designed.
- now, once that protocol is ready, the assumption is still there.

My point was to identify how this asumption really affects the 
resulting protocol and see if it is still needed.

As i see it, the protocol is quite symetrical and there only a few 
corner cases where this assumption is needed. In particular, for
- simultaneous movement
- responder behind a nat.

OTOH, there are a couple of special cases described in the protocol, in 
order to allow the responder to change addresses to deal with some 
situations.

So my question is:
wouldn't it be easier/simpler to define a symetrical protocol stating 
that simultaneous movement and both aprties behind nat situations are 
not supported.
If this can be done, the protocol would be more general and there 
wouldn't be needed those special situations where one of the parties 
need to do special operations (responder changing addresses)

> used in the IP-headers of this packet.

ok, i think we have identified an important element here: my reading of 
this was that additional addresses are incremental to the set already 
available.

I think that it would be very important to explictly state whether the 
addresses in the additional address is a complete set or an incremental 
update.

> address, when the first address happen to go down.

ok

regards, marcelo

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 17 Oct 2005 13:37:37 +0300

> multiple global addresses assigned to each interface connected to the 

I do not think that will be the case of the roaming laptop case, i.e.
the GPRS, WLAN and fixed ethernet links all give out exctly one
IP-address to the connected interface, and you are only supposed to
use that IP-address through that interface to which it was given to.

> about this check draft-huitema-shim6-ingress-filtering-00.txt

This could be the case in the multihomed VPN case. Note, that MOBIKE
should still work perfect, if that unidirectional path does not work
(i.e. packets does not get back when IP-addresses are reversed), then
that address pair is not used, and we finally end up selecting address
pair which does not have that problem with ingress filters.

> possible combinations src and dst addresses available.

If it has multiple IP addresses associated to the IKE SA (even before
it is created) then it should try all combinations of them through the
normal IKE SA retransmission policy.

> addresses, hence why mobike should explicitly mention it if you want 

Yes, might be good idea explicitly mention this anyways.

> that simultaneous movement and both aprties behind nat situations are 

With fully symmetric protocol we cannot really support NAT-T at all.
Neither for initiator or responder, as with symmetric protocol there
is no difference in that.

The end host which is behind NAT must take asymmetric action and fix
the situation which its addresses change, as the other end cannot send
packets to the new address before host behind NAT has done so. This
means that the protocol will always be asymmetric if NAT-T is desired.

> need to do special operations (responder changing addresses)

This was quite extensively discussed on the list and meetings before
the selection of the "initiator decices" was done. We did try few
protocols that tried to be symmetric, but they did get much more
complicated immediately when NAT-T was added. Actually my initial
protocol was one of those symmetric ones but it didn't support any
NAT traversal.

I still think all the discussion about this belongs to the design
draft. 

> addresses in the additional address is a complete set or an incremental 

Agree on that. (and it is complete set).
-- 
[email-masked]
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Jari Arkko <[email-masked]>
Date: Mon, 17 Oct 2005 13:44:11 +0300

>use that IP-address through that interface to which it was given to.
In IPv6 it is indeed possible that you have multiple
addresses and prefixes on a single interface. Then the
issues that Marcelo refers to become possible. But
from what I understand we can deal with that in an
orthogonal way, i.e., this is an issue in MOBIKE usage,
in SHIM6 usage, and even when no multihoming protocol
is used at all.

--Jari

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 17 Oct 2005 18:14:30 +0200

El 17/10/2005, a las 12:44, Jari Arkko escribió:

>>> However, as i understand it, it is expected that a common 
>>> multihoming scenario is that multiple PA address blocks are assigned 
>>> to a multihomed site (one per isp serving the site), so that there 
>>> will be multiple global addresses assigned to each interface 
>>> connected to the multihomed site.
>>>
>>

right, but supporting unidirectional paths in the protocol makes the 
protocol to perform better in such scenarios
I mean, as i see it, or you assume that there is something that will 
take care of ingress filtering compatibility, in which case, supporting 
unidirectional connectivity support doesn't brings you much, or you 
don't assume some ingress filtering compatibility mechanism and then 
supporting unidirectional paths does buy you some extra performance. 
but the mobike protocol doesn't seems to do none of them afaict (or at 
least it doesn't state anything about this)
regards, marcelo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 17 Oct 2005 18:09:41 +0200

> pair which does not have that problem with ingress filters.

right, if such path exists
It maybe the case, that only disjunct unidirectional paths exists, 
because of ingress filters.
In this case, mobike protocol wouldn't achieve to communicate, even if 
a path exists, and it would be possible to communicate if the mobike 
protocol supported different addresses in the different peers of the 
communication

> normal IKE SA retransmission policy.

does the IKE SA retransmission policy tries different source addresses?

regards, marcelo

---

From: Jari Arkko <[email-masked]>
Date: Mon, 17 Oct 2005 19:23:59 +0300

> protocol to perform better in such scenarios

That's right. But such support is hard (as we have found
out in shim6... which only supports this partially). Perhaps
more importantly, MOBIKE had a discussion about the unidirectional
paths some months ago and made a decision in the WG that
we're not doing it. Reasons behind this included toughness
of supporting it with NAT traversal, among others. I'd rather
not re-open that discussion unless we find a serious problem.
We are already aware that we can't support some scenarios due to
this - that's fine.

--Jari

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 18 Oct 2005 10:43:07 +0300

> right, if such path exists

Yes. We do assume there is working IP-pair that allows us to get
packets in both direction. This does not really matter if this
consists of two unidirectional paths, as long as it is routers who
take care of that (i.e. not MOBIKE).

> protocol supported different addresses in the different peers of the 

If I understand correctly TCP would not work in that case too (i.e.
TCP also assumes you can send and receive packets using same IP-pair
in both ends, just reverse the IP-addresses). Both TCP or MOBIKE can
be made so that they do not really cares which interface was used to
send packet out and from which interface it was received, but that is
operating system issue, not protocol issue. MOBIKE does not try to
work in cases where you need to use different IP-address pair in one
direction and another pair to the other direction.

> does the IKE SA retransmission policy tries different source addresses?

MOBIKE section 4.4. tells what to do if IKEv2 request has been
re-transmited several times with no reply, and when initiator decides
new address, he should go through all possible address combinations
before giving up.
-- 
[email-masked]
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike