-------------------- Marcelo Bagnulo (2005-10-12): https://www.machshav.com/pipermail/mobike/2005-October/001117.html 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? -------------------- Tero Kivinen (2005-10-13): https://www.machshav.com/pipermail/mobike/2005-October/001118.html > 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. -------------------- Marcelo Bagnulo (2005-10-15): https://www.machshav.com/pipermail/mobike/2005-October/001118.html > 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. > 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) -------------------- Tero Kivinen (2005-10-17): https://www.machshav.com/pipermail/mobike/2005-October/001121.html > 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. 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. > 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) 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. -------------------- Jari Arkko (2005-10-24): https://www.machshav.com/pipermail/mobike/2005-October/001180.html It seems that discussion about this particular design choice belongs to the design document. So no text changes to protocol-04. FWIW, I'm at least personally quite happy about this decision. You have good questions, Marcelo, and I hope this will improve our design document! Some further discussion below: >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. > > We need to separate the ability to use different addresses and the protocol's internal process at arriving a decision from each other. Now, just because initiator decides in MOBIKE, it doesn't mean that responder's addresses could not change, or that the responder's input is not taken into account. In other words, its not a constraint that only X can do something, but an arrangement where X gets information and is the party responsible for final decisions and coordination. An analogy may be a distributed system where one of the nodes is elected to be a leader. We found that the arrangement simplifies the operation of the protocol. >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 > > I don't think this is a result of the initiator-decides design. Transport mode has fundamentally different issues, including survivability of transport sessions. >- Only the initiator can be behind a nat > > There are limited cases where the responder can also be behind a nat. However, the question is whether limitations in responder's location are due to design of if they are fundamental limitations caused by NATs. I think the latter. >- no simultaneous movement is supported > > Not sure how well initiator-decides affected this, but at least there's another fundamental issue at the bottom: without a home-agent or DNS or DHT like schemes we can not implement simultaneous movements. (Same applies to SHIM6 too, btw.) >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) > > Well, it only means that the final decision is done by one party - not that the other party would be unable to be a part of an exploration process. Having said that, the exploration process in MOBIKE is very simple compared to some other cases, because we assumed bidirectional connectivity. >- 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? > > I think we tried, but it didn't appear to be simpler. --------------------