-------------------- Tero Kivinen (2005-10-12): https://www.machshav.com/pipermail/mobike/2005-October/001116.html 2) In section 4.2 we should always take the IP-addresses from the IKE_AUTH request, as there might be multiple IKE_SA_INIT request, and some of those might not create state at all (cookie, invalid_ke_payload). I think it would be simplier to say that the IP-addresses are always taken from the IP header of the IKE_AUTH packet having SA payload (regardless of the NAT-T or no NAT-T). In normal IKEv2 this does not matter, as if no NAT-T is used then the IP address must stay same, and if NAT-T is used then we take the last packet seen and use the IP-addresses from there. In Mobike we do need to define the exact time what IP-address is used, and I think the packet having the ADDITIONAL_*_ADDRESSES would be the most logical choise (i.e. the IKE_AUTH packet having the SA payload). 7) The section 4.8 says that NO_NATS_ALLOWED should be put to the IKE_SA_INIT (among other things), but we do want to keep IKE_SA_INIT as small as possible, so I think IKE_AUTH is much better place for that notify. That would also be in sync with my proposed change to the 4.2 where I proposed to say that use the IKE_AUTH packet having SA payload to get the IP address tobe used. NO_NATS_ALLOWED is not needed in the IKE_SA_INIT like NAT_DETECTION_*_IP notifies are, as they do not cause changing of the port numbers for the IKE_AUTH. Also moving that NOFITY to the encrypted IKE_AUTH packet will prevent passive attackers of getting the information about the IP addresses and ports used in case host behind NAT is configured to try first with NO_NATS_ALLOWED before falling back and enabling NAT-T. It will also make the attacker acting as a NAT between two hosts bit harder, as if it is sent inside the IKE_SA_INIT, attacker can simply flip a bit inside the NO_NATS_ALLOWED payload to cause DoS, otherwise he need to flip bit in the IP-address or ports, which requires it to catch the return packet and forward it to the original requestor to cause attack. It is not much, but offers again a bit more protection against attacks. -------------------- Pasi Eronen (2005-10-20): https://www.machshav.com/pipermail/mobike/2005-October/001138.html There's a reason why I wrote it that way: when not doing NAT-T, the address should be taken from the same packet which contains NO_NATS_ALLOWED. And it seems that putting NO_NATS_ALLOWED in IKE_SA_INIT is simpler than IKE_AUTH; see below on this... NO_NATS_ALLOWED takes less space than NAT_DETECTION_*_IP payloads, so IMHO it's not unreasonable to put it in IKE_SA_INIT. The real reason to put NO_NATS_ALLOWED in IKE_SA_INIT is that it's much simpler to retry the request if we get UNEXPECTED_NAT_DETECTED error back. In particular, this text from Section 4.8 would need major revision if we take the address from IKE_AUTH: More specifically, when NAT Traversal is not enabled, all messages that can update the addresses associated with the IKE_SA and/or IPsec SAs (the IKE_SA_INIT request and all INFORMATIONAL requests that contain UPDATE_SA_ADDRESSES and/or ADDITIONAL_IP4/6_ADDRESS notifications) MUST also include a NO_NATS_ALLOWED notification. The exchange responder MUST verify that the contents of the NO_NATS_ALLOWED notification match the addresses in the IP header. If they do not match, a response containing an UNEXPECTED_NAT_DETECTED notification is sent (and in the case of the IKE_SA_INIT exchange, no state is created at the responder). The response message is sent to the address and port that the corresponding request came from, not to the address contained in the NO_NATS_ALLOWED notification. If the exchange initiator receives an UNEXPECTED_NAT_DETECTION notification in response to its request, it SHOULD retry the operation several times using new IKE_SA_INIT/INFORMATIONAL requests. This ensures that an attacker who is able to modify only a single packet does not unnecessarily cause a path to remain unused. > Also moving that NOFITY to the encrypted IKE_AUTH packet will > prevent passive attackers of getting the information about the IP > addresses and ports used in case host behind NAT is configured to > try first with NO_NATS_ALLOWED before falling back and enabling > NAT-T. It will also make the attacker acting as a NAT between two > hosts bit harder, as if it is sent inside the IKE_SA_INIT, attacker > can simply flip a bit inside the NO_NATS_ALLOWED payload to cause > DoS, otherwise he need to flip bit in the IP-address or ports, which > requires it to catch the return packet and forward it to the > original requestor to cause attack. It is not much, but offers again > a bit more protection against attacks. A host that is worried about an attack as obscure as this is IMHO unlikely to have a policy "first try without NAT-T; but if there's a NAT, enable NAT-T". Furthermore, moving the payload doesn't actually prevent anything. If there's no NAT, the addresses are visible in the IP header. If there is a NAT, and the host behind NAT falls back to NAT-T, the eavesdropper can get the addresses anyway with a quite trivial amount of computation (as is already pointed out in the IKEv2 spec, hashing does not prevent NAT detection payloads from leaking the internal addresses). -------------------- Tero Kivinen (2005-10-20): https://www.machshav.com/pipermail/mobike/2005-October/001142.html > There's a reason why I wrote it that way: when not doing NAT-T, > the address should be taken from the same packet which contains > NO_NATS_ALLOWED. And it seems that putting NO_NATS_ALLOWED in > IKE_SA_INIT is simpler than IKE_AUTH; see below on this... That reason is not explained anywhere, thus it is very hard to understand why it is done that way (i.e. why do we have more complicated processing here). > NO_NATS_ALLOWED takes less space than NAT_DETECTION_*_IP payloads, > so IMHO it's not unreasonable to put it in IKE_SA_INIT. True, not unreasonable, but I still unnecessary to put them there. > The real reason to put NO_NATS_ALLOWED in IKE_SA_INIT is that it's > much simpler to retry the request if we get UNEXPECTED_NAT_DETECTED > error back. In particular, this text from Section 4.8 would need major > revision if we take the address from IKE_AUTH: I do not think there is any difference in the complexity of the retry even if the NO_NATS_ALLOWED is in the IKE_AUTH, you simply delete half created IKE SA and start over (from the IKE_SA_INIT) when you get error in both cases. There will be performance penalty, as we need to do Diffie-Hellman again, but on the other hand we do not need to add another test matrix case to test the checking that we take the IP addresses in IKE_AUTH for NAT-T and from IKE_SA_INIT for non-NAT-T case. The question simply is whether this is felt like being important enough to have performance optimizations when trying to revert this attack, and costing more in the code complexity and testing time. Note, that the whole idea of retrying is something that does not really make attack that much harder especially in the initial contact step. If someone can modify one packet he can usually modify all the packets. Also moving them to IKE_AUTH does make the attack a bit harder, as now the attacker must be able to get the return packets and forward them to the real destination. If we know there was no NAT between us in the first place, then it is quite safe to assume that such thing does not appear on the path suddenly, thus retrying is ok for the existing IKE SA (i.e. for the INFORMATIONAL exchanges). If the initial contact seems to have NAT between, then it is must likely going to be real NAT, thus retrying by protocol is not really useful. We could simply say that the IKE SA initiation fails in that case, and then when the next trigger packets comes in (or user retries by pressing "connect" again) we retry the exchange from the beginning again. > If the exchange initiator receives an UNEXPECTED_NAT_DETECTION > notification in response to its request, it SHOULD retry the > operation several times using new IKE_SA_INIT/INFORMATIONAL requests. > This ensures that an attacker who is able to modify only a single > packet does not unnecessarily cause a path to remain unused. The change needed would be something like: If the exchange initiator receives an UNEXPECTED_NAT_DETECTION notification in response to its INFORMATIONAL request, it SHOULD retry the operation several times using new INFORMATIONAL requests. This ensures that an attacker who is able to modify only a single packet does not unnecessarily cause a path to remain unused. If initiator receives UNEXPECTED_NAT_DETECTION during IKE SA creation (i.e. in IKE_AUTH state), then it should abort the IKE SA creation, and retry it later when it gets next trigger for that connection. >From the code point of view, that retry does not need any new code, simply fail the IKE SA and other parts of the code will already take care of the retry. Actually sending UNEXPECTED_NAT_DETECTION during IKE SA creation is quite useless, as it cannot be authenticated, and also if the initiator wants to ignore those error notifications and continue retrying regardless of them. So why do we send those notifies in the first place? Only benefit they will give is to inform the initiator that there was attacker between him and the responder. There is really nothing initiator can do for that, except retry. If his policy does not allow NATs between, then he will not enable NAT-T even when there would be NAT between, thus he will be just out of connectivity. > > Also moving that NOFITY to the encrypted IKE_AUTH packet will > > prevent passive attackers of getting the information about the IP > > addresses and ports used in case host behind NAT is configured to > > try first with NO_NATS_ALLOWED before falling back and enabling > > NAT-T. It will also make the attacker acting as a NAT between two > > hosts bit harder, as if it is sent inside the IKE_SA_INIT, attacker > > can simply flip a bit inside the NO_NATS_ALLOWED payload to cause > > DoS, otherwise he need to flip bit in the IP-address or ports, which > > requires it to catch the return packet and forward it to the > > original requestor to cause attack. It is not much, but offers again > > a bit more protection against attacks. > > A host that is worried about an attack as obscure as this is IMHO > unlikely to have a policy "first try without NAT-T; but if there's > a NAT, enable NAT-T". I agree that the revealing of the IP addresses is not very serious case, but there are people who consider that unacceptable (that is why the NAT-T uses hashes, as people did consider leaking the IP-addresses a problem). If we leak them again here, there needs to be at least security considerations section explaining the issue, and also explain why we require them to be sent in clear when they could also be sent as encrypted (i.e. hidden from passive attackers). > Furthermore, moving the payload doesn't actually prevent anything. > If there's no NAT, the addresses are visible in the IP header. > If there is a NAT, and the host behind NAT falls back to NAT-T, > the eavesdropper can get the addresses anyway with a quite trivial > amount of computation (as is already pointed out in the IKEv2 spec, > hashing does not prevent NAT detection payloads from leaking the > internal addresses). True, that is mentioned in the IKEv2 spec, and its implications are explained there. We are now adding another case, so we need to explain it in the security considerations section. There is nothing about NO_NATS_ALLOWED in the security considerations now. Hmm... I got completely new idea, dont know if it is good or bad, but how about adding the flag in the IKE generic header flags field to tell that include IP-addresses and ports to the MAC. Then we wouldn't need to send those IP-addresses/ports at all, and the responder would simply ignore all packets having wrong MAC (i.e. modified IP-addresses or ports). Either end could put that bit in case they want to make sure the IP-addresses are protected (i.e when they would send NO_NATS_ALLOWED). Hmm.. the problem with that is that it is not backward compatible, i.e. if the other end does not support MOBIKE, then he do not know about flag, thus will not be able to calculate the MAC correctly. So ignore that suggestion (this would probably have been the way to do it if we would still be modifying IKEv2 draft). -------------------- Jari Arkko (2005-10-23): https://www.machshav.com/pipermail/mobike/2005-October/001161.html >I agree that the revealing of the IP addresses is not very serious >case, but there are people who consider that unacceptable (that is why >the NAT-T uses hashes, as people did consider leaking the IP-addresses >a problem). If we leak them again here, there needs to be at least >security considerations section explaining the issue, and also explain >why we require them to be sent in clear when they could also be sent >as encrypted (i.e. hidden from passive attackers). > > We probably need the security considerations text in any case, because we have ADDITIONAL_*_ADDRESS. -------------------- Jari Arkko (2005-10-23): https://www.machshav.com/pipermail/mobike/2005-October/001163.html Having read through this thread, I tend to agree with Pasi on this, i.e., take the addresses from where they are currently taken from and use NO_NATS_ALLOWED where its currently in. I do not think the leakage of addresses is an issue, and if it is, we are already doing it in ADDITIONAL_*_ADDRESS. The rest of the issue is really a debate about aesthetics and complexity of variant 1 or variant 2; personally I think what's in the document right now seems better. Here's a suggested addition to the Security Considerations, Section 6.5, after the fourth paragraph: The use of NO_NATS_ALLOWED will also disclose the internal address to the peer, in case NAT was in the path. However, this has relevance only if the node is configured to first try with NO_NATS_ALLOWED and only then fallback to the use of NAT traversal if that fails. -------------------- Tero Kivinen (2005-10-24): https://www.machshav.com/pipermail/mobike/2005-October/001175.html > I do not think the leakage of addresses is an issue, and > if it is, we are already doing it in ADDITIONAL_*_ADDRESS. > The rest of the issue is really a debate about aesthetics > and complexity of variant 1 or variant 2; personally I think > what's in the document right now seems better. I have really started to hate different variations in the protocol. It causes lots of different new tests to be done. In the last interop we already did around 50 different tests to get through the basic exchanges. That didn't include testing different ciphers or macs, only different variations of the IKE protocol (auth methods, rekeying, cookies, invalid ke notify, liveness, basic NAT). The more versions of protocol we have for mobike, the more complex test matrix we need to generate for it too. > Here's a suggested addition to the Security Considerations, > Section 6.5, after the fourth paragraph: > > The use of NO_NATS_ALLOWED will also disclose the > internal address to the peer, in case NAT was in the path. > However, this has relevance only if the node is configured to first > try with NO_NATS_ALLOWED and only then fallback to > the use of NAT traversal if that fails. NO_NATS_ALLOWED discloses the internal address to the WORLD, not to the peer. It relevant in case NO_NATS_ALLOWED is ever configured, and that node is ever behind NAT whose IP-addresses adminstrators are not willing to disclose. The fallback case is not the only case it is also about misconfigurations. -------------------- Jari Arkko (2005-10-24): https://www.machshav.com/pipermail/mobike/2005-October/001179.html >I have really started to hate different variations in the protocol. > > I hate that too, but is there something we can do in this specific issue about that? Are you saying that your option would not create a new variant? >NO_NATS_ALLOWED discloses the internal address to the WORLD, not to >the peer. > > Hm. I missed this. Why does it reveal the address to the world? Because its sent in a too early IKE message that is not yet encrypted? -------------------- Tero Kivinen (2005-10-24): https://www.machshav.com/pipermail/mobike/2005-October/001184.html > I hate that too, but is there something we can do in this > specific issue about that? Are you saying that your option > would not create a new variant? At least we take the IP-addresses from the same place regardless if there is NAT-T enabled or not. Testing whether the MOBIKE will take the IP-addresses from the correct packet is going to be painfull anyways (i.e. requires changing the IP-addresses during the exchange itself and so on). Not sure how big the real impact will be, but still would avoid it if possible. > Hm. I missed this. Why does it reveal the address to the world? > Because its sent in a too early IKE message that is not yet > encrypted? Yes, it is sent in the IKE_SA_INIT thus it is not encrypted nor authenticated. It will be authenticated at the end of IKE_AUTH phase, but not before that. It will not be encrypted at all, thus everybody along the path can see it. Moving it to the IKE_AUTH will get it encrypted, thus reading it requires man in the middle attack, and also changes the protocol so we can always take the IP address from the IKE_AUTH packet (no need to separate processing for NAT-T allowed or no NAT-T allowed). -------------------- Jari Arkko (2005-10-24): https://www.machshav.com/pipermail/mobike/2005-October/001185.html >Moving it to the IKE_AUTH will get it encrypted, thus reading it >requires man in the middle attack, and also changes the protocol so we >can always take the IP address from the IKE_AUTH packet (no need to >separate processing for NAT-T allowed or no NAT-T allowed). > > Hmm... OK, now I'm starting to like this better. Pasi? -------------------- Pasi Eronen (2005-11-14): https://www.machshav.com/pipermail/mobike/2005-November/001298.html Hmm, this is true:if there's an attack, we cannot really detect it at the IKE_SA_INIT stage anyway.... So as I already said in the meeting last week, I've changed my opinion and support your proposal (take addresses from 1st IKE_AUTH exchange, NAT-T or no NAT-T). -------------------- Pasi Eronen (2005-11-16): https://www.machshav.com/pipermail/mobike/2005-November/001313.html Here's proposed text for issue 60. Rephrase Section 3.3 (Initial Tunnel Header Addresses [...] The addresses in the IKE_SA are initialized from the IP header of the first IKE_AUTH request. The addresses are taken from the IKE_AUTH request because IKEv2 requires changing from port 500 to 4500 if a NAT is discovered. [...] And in Section 3.9 (NAT Prohibition): [...] all messages that can update the addresses associated with the IKE_SA and/or IPsec SAs (the first IKE_AUTH request and all INFORMATIONAL requests that contain any of the following notifications: UPDATE_SA_ADDRESSES, ADDITIONAL_IP4/6_ADDRESS, NO_ADDITIONAL_ADDRESSES) MUST also include a NO_NATS_ALLOWED notification. [...] If they do not match, a response containing an UNEXPECTED_NAT_DETECTED notification is sent. [...] If the exchange initiator receives an UNEXPECTED_NAT_DETECTED notification in response to its INFORMATIONAL request, it SHOULD retry the operation several times using new INFORMATIONAL requests. Similarly, if the initiator receives UNEXPECTED_NAT_DETECTED in the IKE_AUTH exchange, it SHOULD retry IKE_SA establishment several times, starting from a new IKE_SA_INIT request. [...] Does this look OK? -------------------- Tero Kivinen (2005-11-16) https://www.machshav.com/pipermail/mobike/2005-November/001316.html Looks ok for me. -------------------- Jari Arkko (2005-11-16): https://www.machshav.com/pipermail/mobike/2005-November/001318.html Ok for me too. --------------------