-------------------- Francis Dupont (2005-10-16): https://www.machshav.com/pipermail/mobike/2005-October/001120.html - in 1 page 3 IKEv2 is used for performing mutual authentication and establishing and maintaining IPsec Security Associations (SAs). => too many "and"s - in 3.1 page 5 Making the decision at the initiator is consistent with how normal IKEv2 works: the initiator decides which addresses it uses when contacting the responder. It also makes sense, especially when the initiator is the mobile node: it is in a better position to decide which of its network interfaces should be used for both upstream and downstream traffic. => as this has some limitations IMHO there should be a pointer to the section 3.4 "Limitations". - in 3.2 page 6 and others Initiator Responder ----------- ----------- 1) HDR, SAi1, KEi, Ni, N(NAT_DETECTION_*_IP) --> <-- HDR, SAr1, KEr, Nr, N(NAT_DETECTION_*_IP) ... => I believe the illustration needs the IP addresses and ports from IP and UDP headers. If someone finds a good way to add them, the whole stuff will become far more readable. - in 4.3 page 10 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. => I have a problem with "this document". I propose to relax it in "MOBIKE documents". - in 4.4 page 11 The reasons why the initiator wishes to change the addresses are largely beyond the scope of MOBIKE. Typically, triggers include information received from lower layers, such as changes in IP addresses or link-down indications. Some of this information can be unreliable: for instance, ICMP messages could be spoofed by an attacker. Unreliable information itself MUST NOT be used to conclude than an update is needed: instead, the initiator SHOULD trigger dead peer detection (that is, send an INFORMATIONAL request). => this at the first read seems to conflict with path testing (4.9). IMHO some clarification is needed, I propose something like (after "an update is needed") "because the current path seems to be no more usable"... - in 4.6 page 15 To ensure that the peer cannot generate the correct INFORMATIONAL response without seeing the request, a new payload is added to INFORMATIONAL messages. The sender of an INFORMATIONAL request MAY include a COOKIE2 notification, and if included, the recipient of an INFORMATIONAL request MUST copy the notification as-is to the response. When processing the response, the original sender MUST verify that the value is the same one as sent. If the values do not match, the IKE_SA MUST be closed. => there is no explanation about COOKIE2, I propose an explicit pointer to section 5.6. - in 4.9 page 17 IKEv2 Dead Peer Detection allows the peers to detect if the currently used path has stopped working. However, if either of the peers has several addresses, Dead Peer Detection alone does not tell which of the other paths might work. => this text is fine but perhaps a bit late in the document (i.e., path testing should be in the overview too)? - in 5 => I believe "notification" is better English than "notify" but as the IKEv2 document uses "notify payloads"... - in 6.1 page 20 MOBIKE introduces the NO_NATS_ALLOWED notification that is used to detect modification, by outsiders, of the addresses in the IP header. When this notification is used, communication through NATs and other address translators is impossible, so it is sent only when not doing NAT Traversal. This feature is mainly intended for site-to-site VPN cases, where the administrators may know beforehand that valid NATs are not present, and thus any modification to the packet can be considered an attack. => IPv6 environments are other obvious candidates for NO_NATS_ALLOWED! -------------------- Tero Kivinen (2005-10-17): https://www.machshav.com/pipermail/mobike/2005-October/001123.html > => I believe the illustration needs the IP addresses and ports from > IP and UDP headers. If someone finds a good way to add them, the whole > stuff will become far more readable. Yes. Perhaps something like HDR(IP1:500,IP2:500) would be readable enough? -------------------- Pasi Eronen (2005-10-21): https://www.machshav.com/pipermail/mobike/2005-October/001153.html > - in 1 page 3 > > IKEv2 is used for performing mutual authentication and establishing > and maintaining IPsec Security Associations (SAs). > > => too many "and"s Ok, I'll rephrase that. > - in 3.1 page 5 > > Making the decision at the initiator is consistent with how normal > IKEv2 works: the initiator decides which addresses it uses when > contacting the responder. It also makes sense, especially when the > initiator is the mobile node: it is in a better position to decide > which of its network interfaces should be used for both upstream and > downstream traffic. > > => as this has some limitations IMHO there should be a pointer to > the section 3.4 "Limitations". Earlier I've received comments that the document has too many pointers back and forth, so I've tried to avoid them (unless the paragraph will be difficult to understand with them). Here section 3.4 just provides some additional information the reader doesn't yet need at this point, and she/he will get to that section eventually :) > - in 3.2 page 6 and others > > Initiator Responder > ----------- ----------- > 1) HDR, SAi1, KEi, Ni, > N(NAT_DETECTION_*_IP) --> > > <-- HDR, SAr1, KEr, Nr, > N(NAT_DETECTION_*_IP) > ... > > => I believe the illustration needs the IP addresses and ports from > IP and UDP headers. If someone finds a good way to add them, the > whole stuff will become far more readable. Yes, that's a good suggestion. How about something like this: 1) (IP_I1:500 -> IP_R1:500) HDR, SAi1, KEi, Ni, N(NAT_DETECTION_*_IP) --> <-- (IP_R1:500 -> IP_I1:500) HDR, SAr1, KEr, Nr, N(NAT_DETECTION_*_IP) 3) (IP_I2:500 -> IP_R1:500) HDR, SK { N(UPDATE_SA_ADDRESSES), N(NAT_DETECTION_*_IP) } --> That is, use IP_I1,IP_I2,,.. for initiator addresses and IP_R1,IP_R2,... for responder addresses...? > - in 4.3 page 10 > > 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. > > => I have a problem with "this document". I propose to relax it in > "MOBIKE documents". How about rephrasing that to "...for any other purpose than what is explicitly described either in this document or a future specification updating it" ? > - in 4.4 page 11 > > The reasons why the initiator wishes to change the addresses > are largely beyond the scope of MOBIKE. Typically, triggers > include information received from lower layers, such as changes > in IP addresses or link-down indications. Some of this > information can be unreliable: for instance, ICMP messages > could be spoofed by an attacker. Unreliable information itself > MUST NOT be used to conclude than an update is needed: instead, > the initiator SHOULD trigger dead peer detection (that is, send > an INFORMATIONAL request). > > => this at the first read seems to conflict with path testing > (4.9). IMHO some clarification is needed, I propose something > like (after "an update is needed") "because the current path > seems to be no more usable"... Hmm, yes, the paragraph needs some clarification. In some sense, most of the information available to the host is to some degree unreliable, and there's no way to avoid using some of that. How about rewriting the last sentence as follows? "Unreliable information SHOULD be treated only as a hint that there might be a problem, and the initiator SHOULD trigger dead peer detection (that is, send an INFORMATIONAL request) to determine if the current path is still usable." > - in 4.6 page 15 > > To ensure that the peer cannot generate the correct > INFORMATIONAL response without seeing the request, a new > payload is added to INFORMATIONAL messages. The sender of an > INFORMATIONAL request MAY include a COOKIE2 notification, and > if included, the recipient of an INFORMATIONAL request MUST > copy the notification as-is to the response. When processing > the response, the original sender MUST verify that the value is > the same one as sent. If the values do not match, the IKE_SA > MUST be closed. > > => there is no explanation about COOKIE2, I propose an explicit > pointer to section 5.6. Ok, will be added. > - in 4.9 page 17 > IKEv2 Dead Peer Detection allows the peers to detect if the > currently used path has stopped working. However, if either of > the peers has several addresses, Dead Peer Detection alone does > not tell which of the other paths might work. > > => this text is fine but perhaps a bit late in the document > (i.e., path testing should be in the overview too)? Since this is not really new to MOBIKE, but just explains that the existing Informational exchange works, I'm not sure if adding more forward pointers would make any difference to the reader? > - in 5 > > => I believe "notification" is better English than "notify" but > as the IKEv2 document uses "notify payloads"... I've tried to make this reasonably consistent with the IKEv2 spec (but yes, IKEv2 could have been more consistent itself :-). > - in 6.1 page 20 > > MOBIKE introduces the NO_NATS_ALLOWED notification that is used > to detect modification, by outsiders, of the addresses in the > IP header. When this notification is used, communication > through NATs and other address translators is impossible, so it > is sent only when not doing NAT Traversal. This feature is > mainly intended for site-to-site VPN cases, where the > administrators may know beforehand that valid NATs are not > present, and thus any modification to the packet can be > considered an attack. > > => IPv6 environments are other obvious candidates for > NO_NATS_ALLOWED! Yes, Tero also pointed this out (see issue 59 for my proposal for text). -------------------- Francis Dupont (2005-10-21): https://www.machshav.com/pipermail/mobike/2005-October/001154.html In your previous mail you wrote: > => as this has some limitations IMHO there should be a pointer to > the section 3.4 "Limitations". Earlier I've received comments that the document has too many pointers back and forth, so I've tried to avoid them (unless the paragraph will be difficult to understand with them). => this is a matter of taste: with pointers you have to turn pages when you read the document, without pointers you have to read it twice to catch the whole thing... I don't know what is the best for everybody, for me it is the first (pointers). > => I believe the illustration needs the IP addresses and ports from > IP and UDP headers. If someone finds a good way to add them, the > whole stuff will become far more readable. Yes, that's a good suggestion. How about something like this: 1) (IP_I1:500 -> IP_R1:500) HDR, SAi1, KEi, Ni, N(NAT_DETECTION_*_IP) --> <-- (IP_R1:500 -> IP_I1:500) HDR, SAr1, KEr, Nr, N(NAT_DETECTION_*_IP) 3) (IP_I2:500 -> IP_R1:500) HDR, SK { N(UPDATE_SA_ADDRESSES), N(NAT_DETECTION_*_IP) } --> That is, use IP_I1,IP_I2,,.. for initiator addresses and IP_R1,IP_R2,... for responder addresses...? => this seems fine, thanks! > - in 4.3 page 10 > > 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. > > => I have a problem with "this document". I propose to relax it in > "MOBIKE documents". How about rephrasing that to "...for any other purpose than what is explicitly described either in this document or a future specification updating it" ? => in the documents I thought about the "transport mode" one which uses the additional addresses but can't be qualified as "updating". I believe my proposal is better (and simpler/shorter). Hmm, yes, the paragraph needs some clarification. In some sense, most of the information available to the host is to some degree unreliable, and there's no way to avoid using some of that. How about rewriting the last sentence as follows? "Unreliable information SHOULD be treated only as a hint that there might be a problem, and the initiator SHOULD trigger dead peer detection (that is, send an INFORMATIONAL request) to determine if the current path is still usable." => fine. > - in 4.9 page 17 > IKEv2 Dead Peer Detection allows the peers to detect if the > currently used path has stopped working. However, if either of > the peers has several addresses, Dead Peer Detection alone does > not tell which of the other paths might work. > > => this text is fine but perhaps a bit late in the document > (i.e., path testing should be in the overview too)? Since this is not really new to MOBIKE, but just explains that the existing Informational exchange works, I'm not sure if adding more forward pointers would make any difference to the reader? => it was just a suggession. > => IPv6 environments are other obvious candidates for > NO_NATS_ALLOWED! Yes, Tero also pointed this out (see issue 59 for my proposal for text). => I'll try to reread all the other comments in time. --------------------