-------------------- Marcelo Bagnulo (2005-10-12): https://www.machshav.com/pipermail/mobike/2005-October/001117.html 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. 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. 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 -------------------- Tero Kivinen (2005-10-13): https://www.machshav.com/pipermail/mobike/2005-October/001118.html > 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. > 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. -------------------- Marcelo Bagnulo (2005-10-15): https://www.machshav.com/pipermail/mobike/2005-October/001119.html > 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. > 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 -------------------- Tero Kivinen (2005-10-17): https://www.machshav.com/pipermail/mobike/2005-October/001121.html > 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. 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. > 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 Yes, might be good idea explicitly mention this anyways. -------------------- Jari Arkko (2005-10-23): https://www.machshav.com/pipermail/mobike/2005-October/001172.html Thanks again Marcelo for your comments. This is very useful. There was really a number of subissues: 1) Are multiple address pairs allowed? 2) Are unidirectional address pairs allowed? 3) Multihoming for the establishment phase v.s only later? 3b) If MOBIKE retries in establishment phase, does it vary source address? 4) Initiator vs. responder behind NAT limitations and ADDITIONAL_*_ADDR 5) Is simultaneous movement supported? 6) Are only local failures supported? I think the consensus has been that we don't want to go too much in to the reasons of why something is the way it is in this document (that's the job of the design document). However, we do need to describe the limitations. I'll first go through Marcelo's items from above and try to explain what I think the situation is. At the end I'll have suggested text for a new limitations section. 1) Are multiple address pairs allowed? Yes. Multiple pairs are allowed. Their simultaneous use for payload traffic is, however, outside the scope of the document, and would probably need extra mechanisms (e.g. ensure its different TCP streams) to work well. 2) Are unidirectional address pairs allowed? No. Explicit design decision to make things easy. 3) Multihoming for the establishment phase v.s only later? MOBIKE is for later phases only, but we can provide some guidance on what (limited) things can be done in the establishment phase. 3b) If MOBIKE retries in establishment phase, does it vary source address? It should. I'm a bit scared here to step on the area that your future enhanced RFC 3484 version will say, though. Technically, these are components; when 3484bis is available things sudddenly start working better. But I'll suggest something vague about this. 4) Initiator vs. responder behind NAT limitations and ADDITIONAL_*_ADDR This isn't an issue, really, but rather a misunderstanding of the text. There's no problem when the initiator (behind NAT) decides to use new addresses. The problem is when the responder moves; some NAT types don't allow this, and it may even be that the addresses provided for this emergency in ADDITIONAL_*_ADDRESS are internal, and not reachable by peer. I'd say no text changes. 5) Is simultaneous movement supported? No. Needs to be documented. 6) Are only local failures supported? No. MOBIKE, like SHIM6, supports both lower layers telling you that the link went away as well as experienced failures in IP communication (IKE DPD vs. SHIM6 reachability packets not getting through). Ok. So here's an attempt at some new text for Section 1.1, what used to be 3.4 Limitations: 1.1 Limitations This document focuses on the main scenario outlined above, and supports only tunnel mode. The mobility support in MOBIKE allows either party to move, but not both at the same time. This implies that MOBIKE is best suited for client - gateway or gateway - gateway applications. Two mobile clients would find it hard to use MOBIKE directly between themselves, and for such applications a gateway is recommended between the communicating clients. The multihoming support in MOBIKE allows either party to have multiple addresses. This specification does not guarantee that more than pair of such addresses can be used for payload traffic at any one time, however. This implies that load-balancing applications are out of scope in the base protocol. Similarly, due to the nature of the IKEv2 protocol and NAT considerations, MOBIKE is only guaranteed to work correctly over bidirectionally operational address pairs. That is, the same pair of addresses is used in both directions. Indeed, the protocol mechanisms used to determine reachability of the peer ensure that such a pair is in use. The MOBIKE protocol can only be used once the IKE SAs have been established. This implies that movements or additional addresses for the peer can not be discovered until a working connection to the peer has been established. This implies that the IKE SA establishment phase has limitations with regards to initial discovery of alternative addresses, unless those addresses are known in the configuration and/or DNS. For details, see Section 4.0. NATs introduce additional limitations beyond those listed above. For details, refer to Section 3.3. The base version of the MOBIKE protocol may also not cover all potential future use scenarios, such as transport mode, application to securing SCTP, or optimizations desirable in specific circumstances. Future extensions may be defined later to support additional requirements. And a new Section 4.0 between 4. and 4.1: 4.0 Addresses for the Initial IKE Exchange The initiator is responsible for finding a working pair of addresses so that the initial IKE exchange can be carried out. Any information from MOBIKE extensions will only be available later, when the exchange has progressed far enough. IKE initiator may retrieve the peer address(es) from various sources, such as the outgoing packet that triggered the IKE exchange, configuration, or DNS. Similarly, the initiator knows its own address(es). If multiple peer addresses are known, the initiator SHOULD vary the destination address in retranmissions, in case the address used in the first attempt is inoperational. Similarly, if these addresses do not appear to respond, the initiator MAY vary the source address it uses for itself, in case there is a problem in a particular address prefix or the failure is due to an ingress filtering problem. -------------------- Tero Kivinen (2005-10-24): https://www.machshav.com/pipermail/mobike/2005-October/001176.html I think these are mostly questions for the design draft. I tried to check that at least some of those are answered by the new version of design draft, but you might want to check that I didn't miss something (I was a bit hurry when making that draft to get it out before deadline). Perhaps add pointer to the design draft also (to the point where it explains more about these issues, i.e. section 5.1 for choosing addresses, multihoming, unidirectional paths etc, and section 5.2. for NAT, at least). But that text is good summary of the limitations. That is also good section to be added. -------------------- Jari Arkko (2005-10-24): https://www.machshav.com/pipermail/mobike/2005-October/001178.html Yes. -------------------- Pasi Eronen (2005-10-24): https://www.machshav.com/pipermail/mobike/2005-October/001200.html Here's a "slightly" edited version of the text. Does it look ok? -- 1.2. Scope and Limitations This document focuses on the main scenario outlined above, and supports only tunnel mode IPsec SAs. The mobility support in MOBIKE allows both parties to move, but does not provide a "rendezvous" mechanism that would allow simultaneous movement of both parties, or discovering the addresses when the IKE_SA is first established. This implies that MOBIKE is best suited for situations where the address of at least one endpoint is relatively stable, and can be discovered using existing mechanisms such as DNS (see Section 3.1). MOBIKE allows both parties to be multihomed; however, only one pair of addresses is used for an SA at a time. In particular, load balancing is beyond the scope of this specification. MOBIKE follows the IKEv2 practice where a response message is sent to the same address and port from which the request was received. This implies that MOBIKE does not work over unidirectional paths. NATs introduce additional limitations beyond those listed above. For details, refer to Section 2.3. The base version of the MOBIKE protocol does not cover all potential future use scenarios, such as transport mode, application to securing SCTP, or optimizations desirable in specific circumstances. Future extensions may be defined later to support additional requirements. Readers are encouraged to consult the MOBIKE design document [Design] for further information and rationale behind these limitations. -- 3.1. Initial IKE Exchange The initiator is responsible for finding a working pair of addresses so that the initial IKE exchange can be carried out. Any information from MOBIKE extensions will only be available later, when the exchange has progressed far enough. Exactly how the addresses used for the initial exchange are discovered is beyond the scope of this specification; typical sources of information include local configuration and DNS. If either or both of the peers have multiple addresses, some combinations may not work. Thus, the initiator SHOULD try various source and destination address combinations when retransmitting the IKE_SA_INIT request. -------------------- Jari Arkko (2005-10-24): https://www.machshav.com/pipermail/mobike/2005-October/001202.html Looks good to me. -------------------- Marcelo Bagnulo (2005-10-25): https://www.machshav.com/pipermail/mobike/2005-October/001213.html i think that the proposed text looks good. just a couple of clarifications, not really expecting to change the text, but just to explain some points... my point here is that the only tool that seems to be available to mobike is to change the address used for the communication. This is clearly enough to address local failures but it is not clear that this is good enough to deal with other failure modes. In shim, changing the source address is assumed to result in exploring different exit paths (from the multihomed site) this is the case when the source address affects somehow the exit path, which is coherent with the existance of some form of ingress filtering capability in the multihomed site. So, either you assume some form of source address dependent routing so that changing the source address result in different exit paths or the host don't really have the capability of forcing the exit path, so it is probably that it won't be able to cope with remote failures in general (in particular in failures in the egress paths) > Ok. So here's an attempt at some new text for Section 1.1, > what used to be 3.4 Limitations: > this text looks good > IKE initiator may retrieve the peer address(es) from various > sources, such as the outgoing packet that triggered the > IKE exchange, configuration, or DNS. Similarly, the initiator > knows its own address(es). > If multiple peer addresses are known, the initiator SHOULD > vary the destination address in retranmissions, in case the > address used in the first attempt is inoperational. Similarly, > if these addresses do not appear to respond, the initiator > MAY vary the source address it uses for itself, in case there i would suggest a SHOULD here --------------------