-------------------- Pekka Savola (2005-09-19): Jari asked me to review the MOBIKE protocol. Beware, I'm not really familiar with IKE, so there are probably things I have wrong or have missed. In any case, I thought the document was in a good shape and written in a manner where it should be easy to get interoperable implementations. It's also short -- good. What troubled me a bit was a significant number of forward references to other places in the spec, but this is understandable in the interest of avoiding text duplication. meta-issues ----------- It is assumed that issues such as transport mode (updating traffic selectors), PFKEY extensions, and tunnel overhead reduction will be handled in separate documents. ==> is transport mode even in the scope of the WG? I thought not, but the charter doesn't seem conclusive either way.. substantial ----------- 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 2.4 does not fully work when the initiator is behind a NAT. [...] ==> this is probably something that needs more air time. What does "does not fully work" mean? This also probably applies to the responder, though in different ways. This may also have security implications (exposing internal topology), and it may affect address selection (if for example smaller scope addresses are preferable, but actually belong to different sites). This probably needs a bunch of more analysis... This specification requires the use of return routability tests (under certain conditions) to limit the duration of any "third party bombing" attacks by off-path (relative to the victim) attackers. ==> this is not true. The spec only says RR _SHOULD_ be done before updating the SAs. There is no "MUST" for RR (whether before or after), but a "MAY skip" under certain conditions. The normativeness requirements need to be reviewed. Further, the procedures for handling the payloads (sections 2.3 and 2.4) should include a bullet point on RR tests and a pointer to 2.5. When the initiator is behind a NAT, it SHOULD include these payloads in DPD messages, and compare the received ... When MOBIKE is in use, the host not behind a NAT SHOULD NOT use the dynamic updates specified ... ==> How does the MOBIKE code know whether you're behind a NAT? Is this done automatically as part of IKEv2 NAT detection? Note that the spec doesn't seem to require running NAT presence detection so with current spec this can't be done. To give the initiator enough time to detect the error, the responder SHOULD use relatively long timeout intervals when, for instance, retransmitting IKEv2 requests or deciding whether to initiate dead peer detection. ==> "relatively long timeout intervals" is pretty ambiguous. While this may not affect the interoperability, shouldn't we be a bit more precise what kind of order of magnitude we're talking about here? Seconds? Ten seconds? 30 sec? Minutes? 10 minutes? Hours? The data associated with this notification is the SHA-1 hash [FIPS180-2] of the following data: ==> this spec is not algorithm-agile. (I can't find the ref right now where this is encouraged.) In this case, maybe it doesn't need to be considering the impact (I don't take a stance on that) -- but this probably deserves at least brief discussion in the security considerations section. semi-editorial -------------- ==> there seem to be a number of assumptions scattered throughout the document (e.g., relating to the responder not being behind a NAT) -- maybe it would be useful to put these as a new subsection of the Introduction? ==> I would also consider splitting out 2.3 in subsections for readability and more exact references. For example, initiator's first steps could be 2.3.1, Responder's reply 2.3.2, initiator's reply 2.3.3, and the exception 2.3.4. ==> It might make sense to spell out, probably in section 1.2, that apparently (AFAICS) the initiator never tells the responder which addresses it takes to use. It just sends UPDATE_SA_ADDRESSES with the updated addresses (inmplicit update). HDR, SK { IDi, [CERT], [IDr], AUTH, [CP(CFG_REQUEST)] SAi2, TSi, TSr, N(MOBIKE_SUPPORTED), [N(ADDITIONAL_*_ADDRESS)+] --> ==> this raises a minor issue of the normativeness of this spec with regard to the non-MOBIKE -related IKE payloads. The above exchange is just an example; some other payloads could be included as well, or some listed above could be omitted. Also the optional/mandatory status might change. Perhaps the document could give a short disclaimer about the IKE exchange examples. o The initiator receives a NAT_DETECTION_DESTINATION_IP payload that does not match the previous UPDATE_SA_ADDRESSES response (see Section 2.6 for a more detailed description). ==> In some cases, you use NAT_DETECTION_*_IP and in some NAT_DETECTION_DESTINATION_IP. I guess this is intentional, but I'd still review the cases carefully.. o Determines whether it has already received a newer UPDATE_SA_ADDRESSES request than this one (if the responder uses a window size greater than one, it is possible that requests are received out of order). If it has, a response message is sent, but no other action is taken. ==> at first, it was not clear to me what "a response message" referred to. An unspecified response? Probably you meant the normal response specified a few bullets down but this was not unambiguous. There is one additional issue that must be taken into account. If the INFORMATIONAL request has been sent to several different addresses (i.e., the destination address in the IKE_SA has been updated after the request was first sent), ... ==> s/If the/If the same/ (?) ==> this is actually a good issue in more general. Is it worth the effort to do so in the first place? That is, couldn't we just specify that the requests be sent with different cookies for each destination. I don't think a hash is computationally all that expensive. That would simplify the spec and eliminate an extra roundtrip in some cases. IKEv2 requires that if an IPsec endpoint discovers a NAT between it and its correspondent, it MUST send all subsequent traffic to and from port 4500. To simplify things, implementations that support both this specification and NAT Traversal MUST change to port 4500 if the correspondent also supports both, even if no NAT was detected between them (this way, there is no need to change the ports later). ==> While this seems to be a logical place to talk about this, I'm troubled. The title is "NAT Prohibition". What about MOBIKE implementations which don't implement NAT prohibition (I guess that's OK). The above requirement is more general though -- not really anything to with NAT prohibition. These kind of more generic requirements should be placed in a much more prominent place in the spec. NO_NATS_ALLOWED payloads can also be included when changing the addresses of IPsec SAs (see Section 2.3) and updating the additional addresses (see Section 2.4). An initiator using this "NAT prohibition" feature includes a NO_NATS_ALLOWED payload in all address update messages. ==> s/includes/MUST include/ or..? 3.1 MOBIKE_SUPPORTED Notification Payload ==> note that the IKEv2 spec refers these as "Notify Payloads" (at least in some places of the spec; "Notification" is also mentioned though)..? The Notify Message Type for MOBIKE_SUPPORTED is TBD-BY- IANA(16396..40959). ==> per http://www.ietf.org/internet-drafts/draft-narten-iana-considerations-rfc2434bis-02.txt, thse types should be named TBD-BY-IANA1, ...., TBD-BY-IANAN (or something like that), so we know IANA has assigned a separate value for each and it can be easily search-n-replaced. I'd also suggest dropping the assignment range from here, and giving that guidance in IANA Considerations. of the stack, such as properly dealing with ICMP errors [ICMPAttacks] ==> some folks may argue that what ICMPattacks proposes may not be "proper". So, maybe find a different word for "proper", or use something like "as validating ICMP errors" which takes no stance on whether it's useful or not. [IPsecArch] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", draft-ietf-ipsec-rfc2401bis-06 (work in progress), March 2005. ==> this should probably be under normative refs? -------------------- Pekka Savola (2005-09-20): This is good description of some of these problems (suitable in the introduction as you put it), but I'm not sure if it addresses all the open questions. If I understand correctly, if the initiator is behind a NAT with IP address 10.0.0.1, it will tell the responder in MOBIKE exchange that its IP address is 10.0.0.1. At least two issues sprang to my mind: a) some people will be (at least slightly) concerned that MOBIKE will reveal the internal topology of the site. This may or may not be a big issue (especially as probably the most IPsec sessions will go to at least semi-trusted nodes), but if we don't state it now, someone is going to invent a fancy MOBIKE "exploit" 5 years down the road. A sentence or two in a separate paragraph in Security Considerations section would probably be sufficient. b) as the conveyed addresses are used for address selection, there might be issues with that. Let's say, the responder tells it has addresses 20.20.20.20 and 10.0.0.2. The initiator has 10.0.0.1, and possibly 30.30.30.30. The initiator and responder are in different sites (a NAT between them). Now the initiator's address selection policy might get skewed if it'd prefer particular kind of addresses. This may be one issue where an explicit warning might be useful. To a person like me who didn't know what kind of NAT detection exchange is done by IKEv2 (and whether that's mandatory to implement or mandatory to enable), this didn't spell out how MOBIKE knows whether it's behind a NAT or not. If it could fit somewhere neatly, it would likely help a bit. > "While no specific timeout lengths are required, it is > suggested that responders continue retransmitting IKEv2 > requests for at least five minutes before giving up." No problem with me, though that doesn't give any help on how aggressive you should be to start with.. As these issues have seen some debate (see the thread starting from http://www1.ietf.org/mail-archive/web/ipv6/current/msg05627.html as an example), this seems to be something that needs to be at least mentioned in security considerations; that may be sufficient, though if one can easily engineer around it without hurting security, that might not be a bad idea either. But the bottom line is that if the algorithm is glued in (which may be OK given that you can only spoof the NAT prohibition), I think it needs to be said explicitly (and it might not hurt to get tentative early review from more folks in the sec area). > This particular assumption is actually mentioned in the > Introduction section (and gets better treatment in the proposed > NAT text above). Were there any others you had in mind..? Maybe minor ones like the assumptions on what other elements need to be implemented (but which aren't specified here, like address selection), but it may be that those don't need to be mentioned up front. > Hmm... as it's currently organized, I'm not sure if splitting > it would actually improve the readability (it might even be > confusing if the subsection suddenly changes in the middle of > the description). If others have no opinion, I'm OK either way. It required a bit more work from the reader to figure out which part of the section you were referring to when saying "see Section 2.3" because that includes a number of different things. Above would have made it shorter and easier to point to, but with more careful reading, the current one should be readable as well. > (Or are you referring to the detail that the addresses are not > contained inside the IKEv2 payload, but in the IP header?) Exactly, only in the IP header. (I haven't analyzed whether this may or may not open any new threats, because the IP address is not secured as it's from the header.. I think those were described at sufficient length already) > to section 1.3, after the first paragraph? Looks excellent. > (MOBIKE in general would be _much_ simpler if the designers of > IKEv2 had done the reliability/windowing parts slightly > differently...:-) That's a bit unfortunate but it's fine with me.. > I think "includes" is correct, since it's describing a logical > necessity, not a choice (where we could discuss whether it > should be a MAY, SHOULD or MUST). My reasoning above was, could an implementer try to optimize the protocol so that it will only send NO_NATS_ALLOWED with some but not all update messages (saving bits). I.e., would the processing be any different for the exchange responder if NO_NATS_ALLOWED was sometimes present and sometimes not. Hence I proposed a MUST implying "if you are going to send NO_NATS_ALLOWED, you have to send it *every time*, instead of just when you feel like it". But if folks want to leave this a bit more open, that's fine with me.. -------------------- Francis Dupont (2005-09-20): Yes, this is done by IKEv2 NAT Traversal already (so saying that it must be done would be redundant). => you don't answer to the question: it is not required to run NAT presence detection. The simplest solution might be just to place the IP addresses in this payload (and mandate comparing them with the IP header)... Any comments from other on this? => so I am not the one which cares about peer address protection (:-). -------------------- Mohan Parthasarathy (2005-09-21): ===> The reason IKEv2 NAT detection payloads includes only the hash and not the actual addresses is to hide the internal addresses. But this is lost with MOBIKE because the initiator has to include these addresses in ADDITIONAL_ADDRESS notification. So, including the hash or real address in the notification payloads doesn't matter. To be consistent (as we are using NAT-D payloads from IKEv2), we might as well use the same hash and also not be algo-agile :-) -------------------- Francis Dupont (2005-09-21): a) some people will be (at least slightly) concerned that MOBIKE will reveal the internal topology of the site. This may or may not be a big issue (especially as probably the most IPsec sessions will go to at least semi-trusted nodes), but if we don't state it now, someone is going to invent a fancy MOBIKE "exploit" 5 years down the road. A sentence or two in a separate paragraph in Security Considerations section would probably be sufficient. => IMHO this problem is only for MOBIKE itself (where a private of a node behind a NAT has no meaning, i.e., it can put anything) but not for NAT detection/prevention: I asked why NAT detection uses a hash and not the addresses themselves and the answer was exactly because some people were concerned that NAT detection would reveal the internal topology (so a) applies in the real world). > Yes, this is done by IKEv2 NAT Traversal already (so saying > that it must be done would be redundant). To a person like me who didn't know what kind of NAT detection exchange is done by IKEv2 (and whether that's mandatory to implement or mandatory to enable), this didn't spell out how MOBIKE knows whether it's behind a NAT or not. If it could fit somewhere neatly, it would likely help a bit. => there is a point about this: I'd like to drop the "middle ground", i.e., to make the usage of either NAT detection or NAT prevention mandatory. My idea is to get a mandatory protection of the addresses in IP headers (as they'll become the endpoint addresses of IPsec SAs) but your argument is good too. > (Or are you referring to the detail that the addresses are not > contained inside the IKEv2 payload, but in the IP header?) Exactly, only in the IP header. (I haven't analyzed whether this may or may not open any new threats, because the IP address is not secured as it's from the header.. I think those were described at sufficient length already) => this opens a threat what I called the "transient pseudo-NAT attack" but it is not a new threat, just an ignored threat. BTW, it is easy to fix: the addresses in the IP header should simply be reflected in some way into the IKE payload. This is why I propose to enforce the usage of NAT detection/prevention which does that for the first exchange. -------------------- Jari Arkko (2005-09-26): > a) some people will be (at least slightly) concerned that MOBIKE will > reveal the internal topology of the site. This may or may not be a big > issue (especially as probably the most IPsec sessions will go to at > least semi-trusted nodes), but if we don't state it now, someone is > going to invent a fancy MOBIKE "exploit" 5 years down the road. A > sentence or two in a separate paragraph in Security Considerations > section would probably be sufficient. Agreed. > b) as the conveyed addresses are used for address selection, there > might be issues with that. Let's say, the responder tells it has > addresses 20.20.20.20 and 10.0.0.2. The initiator has 10.0.0.1, and > possibly 30.30.30.30. The initiator and responder are in different > sites (a NAT between them). Now the initiator's address selection > policy might get skewed if it'd prefer particular kind of addresses. > This may be one issue where an explicit warning might be useful. Yes. I'd be even happier if we were able to know which addresses are behind a NAT, but... >> "While no specific timeout lengths are required, it is >> suggested that responders continue retransmitting IKEv2 >> requests for at least five minutes before giving up." > > > No problem with me, though that doesn't give any help on how > aggressive you should be to start with.. This would be useful to specify, I think. > >>> The data associated with this notification is the SHA-1 >>> hash [FIPS180-2] of the following data: >>> >>> ==> this spec is not algorithm-agile. (I can't find the ref >>> right now where this is encouraged.) In this case, maybe it >>> doesn't need to be considering the impact (I don't take a >>> stance on that) -- but this probably deserves at least brief >>> discussion in the security considerations section. >> >> >> This part is basically copied from IKEv2 NAT detection payloads, >> which also use SHA-1 (and IKEv2 spec didn't include any >> discussion about this either).... >> >> However, here the situation might actually be slightly different, >> since the security implications of NAT_DETECTION_*_IP payloads >> and NO_NATS_ALLOWED are different. The simplest solution might >> be just to place the IP addresses in this payload (and mandate >> comparing them with the IP header)... >> >> Any comments from other on this? > > > As these issues have seen some debate (see the thread starting from > http://www1.ietf.org/mail-archive/web/ipv6/current/msg05627.html as an > example), this seems to be something that needs to be at least > mentioned in security considerations; that may be sufficient, though > if one can easily engineer around it without hurting security, that > might not be a bad idea either. > > But the bottom line is that if the algorithm is glued in (which may be > OK given that you can only spoof the NAT prohibition), I think it > needs to be said explicitly (and it might not hurt to get tentative > early review from more folks in the sec area). I think its fine to say the algorithm is "fixed" and that this is something inherited from main IKEv2 spec. But note that there's a difference in the algorithm being fixed as a part of the the protocol versus fixing an algorithm in an identifier (as in Julien's draft that you pointed) - there may be ways of upgrading the protocol but identifier upgrading is much harder. > >>> ==> I would also consider splitting out 2.3 in subsections for >>> readability and more exact references. For example, >>> initiator's first steps could be 2.3.1, Responder's reply >>> 2.3.2, initiator's reply 2.3.3, and the exception 2.3.4. >> >> >> Hmm... as it's currently organized, I'm not sure if splitting >> it would actually improve the readability (it might even be >> confusing if the subsection suddenly changes in the middle of >> the description). > > > If others have no opinion, I'm OK either way. It required a bit more > work from the reader to figure out which part of the section you were > referring to when saying "see Section 2.3" because that includes a > number of different things. Above would have made it shorter and > easier to point to, but with more careful reading, the current one > should be readable as well. Close call, but I think I'd rather see one big section 2.3 than a set of sub-subsections. >> >> I think "includes" is correct, since it's describing a logical >> necessity, not a choice (where we could discuss whether it >> should be a MAY, SHOULD or MUST). > > > My reasoning above was, could an implementer try to optimize the > protocol so that it will only send NO_NATS_ALLOWED with some but not > all update messages (saving bits). I.e., would the processing be any > different for the exchange responder if NO_NATS_ALLOWED was sometimes > present and sometimes not. > > Hence I proposed a MUST implying "if you are going to send > NO_NATS_ALLOWED, you have to send it *every time*, instead of just > when you feel like it". > > But if folks want to leave this a bit more open, that's fine with me.. I'd rather see the if-you-do-this-then-you-need-to-do-it-in-every-message approach. But I'm not sure if there's need for a MUST; SHOULD appears sufficient here. -------------------- Jari Arkko (2005-09-28): Works for me. >Tero, do you have an opinion about what would a good >recommendation be? Maybe something like > > "While no specific timeout lengths are required, it is > suggested that responders continue retransmitting IKEv2 > requests for at least five minutes before giving up." > > Ok. The key point is that the responder side should not be aggressive in this regard. >However, here the situation might actually be slightly different, >since the security implications of NAT_DETECTION_*_IP payloads >and NO_NATS_ALLOWED are different. The simplest solution might > > Right. >be just to place the IP addresses in this payload (and mandate >comparing them with the IP header)... > > That seems simplest. -------------------- Jari Arkko (2005-09-28): > Yes. I'd be even happier if we were able to know > which addresses are behind a NAT, but... Thinking about this further, it seems that sending the addresses as they currently are is the least bad option here, as long as we have sufficient warnings about that. If we want to support multiple addresses for failover, we need to inform the peer. Yet it would be quite hard to test all these addresses, or pairs really, to find out which one of them have a NAT towards the other peer. --------------------