-------------------- Tero Kivinen (2005-07-12): > 1.3 Terminology > > Path > > A particular combination of source IP address and destination IP > address (note: this definition does not consider the route taken > by the packets in the network). Any reason why the draft-ietf-mobike-design-02.txt and this document defined Path differently? The Path from the design draft do include the route, the Path here matches the more or less the (operantional) address pair in the design draft. I think we should try to keep them in sync. > 2. MOBIKE protocol exchanges > > 2.1 Signaling support for MOBIKE > > Implementations that wish to use MOBIKE for a particular IKE_SA MUST > include a MOBIKE_SUPPORTED notification in the IKE_SA_INIT request > and response messages. > > Initiator Responder > ----------- ----------- > HDR, SAi1, KEi, Ni, > N(MOBIKE_SUPPORTED), > [N(NAT_DETECTION_*)] --> > > <-- HDR, SAr1, KEr, Nr, > [N(NAT_DETECTION_*)], > [CERTREQ], > N(MOBIKE_SUPPORTED) As we are probably going to follow the IKEv2 document style, which says that payload MUST come in the order they appear in pictures, I think we might want to keep this and IKEv2 documents consistent. The CERTREQ is mentioned in the IKEv2 document, so it's order is fixed, so I would move NAT_DETECTION_*_IP from the reply to the end, i.e: Initiator Responder ----------- ----------- HDR, SAi1, KEi, Ni, N(MOBIKE_SUPPORTED), [N(NAT_DETECTION_*)] --> <-- HDR, SAr1, KEr, Nr, [CERTREQ], N(MOBIKE_SUPPORTED), [N(NAT_DETECTION_*)] > There is one additional issue that must be taken into account. If > the destination address in the IKE_SA has been updated after the > INFORMATIONAL request was sent, then it is possible that the request > has been sent to several different addresses. In this case, > receiving the INFORMATIONAL response does not tell which address is > the working one; thus, a new INFORMATIONAL request needs to be sent. This should probably be clarified better, i.e. if we fall back to the other addresses, then the malicious peer can take those later messages that did reach him and send them back using different address pair, i.e. faking the reply of return routability check. There is no description here what should be done in that case. We need to send ACK to the N(CHANGE_PATH) quite soon, we cannot wait for the return routability check to finish, as it might be so that the initiator sends N(CHANGE_PATH) and then address pair stops working, thus we cannot do return routability check, but on the other hand initiator cannot do anything to fix the situation as he might have window size of 1, and cannot send another N(CHANGE_PATH) before the one that is being processed is ACK'ed. So we probably want to return ACK to N(CHANGE_PATH) immediately, but update the actual IP-addresses only after the return routability checks finish, and if during that time we get new N(CHANGE_PATH) we simply change the base address where to do return routability checks. -------------------- Pasi Eronen (2005-07-14): The design document also uses the word "path" in senses that don't include the route taken by the packets (see e.g. the definition for "primary path"). Also, some of the terminology in the design document needs a bit revision, since it implicitly assumes the SCTP-like "option 1" for issue 20, instead of the "initiator decides" we chose. I've actually considered this, and checked that the ordering is consistent with IKEv2 :-) (According to IKEv2 Section 2.23, NAT_DETECTION_*_IP in reply comes after Nr but before CERTREQ.) Yes, this was the idea: if we have sent the request to more than one address (==updated the destination address in the IKE_SA, at least currently), we need to send a new INFORMATIONAL request to check RR. I'll rephrase that paragraph to make it clearer... Yes, this was what I had in mind, too (reply to CHANGE_PATH immediately, but update IPsec SAs only after RR check finishes). I'll attempt to clarify this in -01. -------------------- Jari Arkko (2005-07-14): My feeling is that, for practical reasons, we should try to get rid of the term path, unless we use it in the route-included sense. There are too many people that will complain when they will see their favorite term misused :-) -------------------- Pasi Eronen (2005-07-14): Well, it certainly seems so... I've now changed those instances of "path" that don't really consider the route to something else (but I've kept expressions like "paths that contain NATs", "off-path", or "currently used path has stopped working", which are more about the route than just a pair of addresses). CHANGE_PATH notification was renamed to UPDATE_SA_ADDRESSES. Once I get -01 out, let's see if this is better than -00... -------------------- Jari Arkko (2005-07-14): Sounds good. -------------------- Tero Kivinen (2005-07-14): Pasi.Eronen@nokia.com writes: > The design document also uses the word "path" in senses that > don't include the route taken by the packets (see e.g. the > definition for "primary path"). Actually the "primary path" does not say weather the route of the packet is included or not. The definition of "Path" do say that route is included. > Also, some of the terminology in the design document needs a bit > revision, since it implicitly assumes the SCTP-like "option 1" > for issue 20, instead of the "initiator decides" we chose. Better send updates then and say where it mentiones that we selected option 1 so we can fix it. Note, that in multiple places it tries not to say which option we have selected when describing the problem, and only in the end of section mentions which of those options were selected. Also decribing the other problems can still use more generic text, even when we could use less generic one because of the some options we selected in some other places. This way if we decide to select some option, we do not need to modify other parts of the document, as the generic text is still valid there. > I've actually considered this, and checked that the ordering > is consistent with IKEv2 :-) (According to IKEv2 Section 2.23, > NAT_DETECTION_*_IP in reply comes after Nr but before CERTREQ.) True, I didn't remember it was explicitly mentioned in the text. Some of the other optional ones are not mentioned. > Yes, this was the idea: if we have sent the request to more than one > address (==updated the destination address in the IKE_SA, at least > currently), we need to send a new INFORMATIONAL request to check > RR. I'll rephrase that paragraph to make it clearer... Try to include also description of the attack, not only the solution, as it do make the text more understandable to know why it is done that way. -------------------- Pasi Eronen (2005-07-18): Clarified some things, now avoids using the word "path" in senses that don't really consider the route taken by the packets. -------------------- Issue closed on 2005-07-26. --------------------