-------------------- Mohan Parthasarathy (2005-10-03): - Section 6.1 The last paragraph talks about NO_NATS_ALLOWED. The attack of modifying the header to cause DoS attack is only possible if the attacker knows that NO_NATS_ALLOWED is carried within the payload. As payloads are encrypted, it may not be that easy always. It is easy if it is the IKE_SA_INIT message.It might be worth stating when the attack is possible. - Section 6.3 Normally such attacks would expire in a short time frame due to the lack of responses (such as transport layer acknowledgements) from the victim. However, as described in [Aura02], malicious participants would typically be able to spoof such acknowledgements and maintain the traffic flow for an extended period of time. This attack is possible because the victim does not have a valid SA for the incoming ESP traffic and never reaches the TCP layer and hence no TCP RSTs. Might be worth mentioning here. -------------------- Jari Arkko (2005-10-03): Right. Thanks for spotting this! Ok. -------------------- Pasi Eronen (2005-10-03): https://www.machshav.com/pipermail/mobike/2005-October/001091.html Er.. since the last paragraph of Section 6.1 doesn't talk about DoS attacks, what exactly should be changed there? Causing DoS by modifying a packet containing NO_NATS_ALLOWED is mentioned in Section 4.8, but the attacker doesn't need to know which packets contain NO_NATS_ALLOWED: it's probably easier to modify all of them. (And the attacker could also make a pretty good guess just by looking at the unencrypted parts of the message: e.g. exchange type and message length). Probably the packets would not even reach the TCP layer, since their destination IP address was not correct. So TCP RSTs would not happen anyway. Jari, do you have any text to suggest? -------------------- Mohan Parthasarathy (2005-10-03): https://www.machshav.com/pipermail/mobike/2005-October/001095.html If you read the previous paragraph : This attack can only be launched by on-path attackers that are capable of modifying IKEv2 messages carrying NAT detection payloads (such as Dead Peer Detection messages). By modifying the IP header of these packets, the attackers can lead the peers believe a new NAT or a changed NAT binding exists between them. The attack can continue as long as the attacker is on the path, modifying the IKEv2 messages. If this is no longer the case, IKEv2 and MOBIKE mechanisms designed to detect NAT mapping changes will eventually recognize that the intended traffic is not getting through, and update the addresses appropriately.It says when and how the attack can be launched. I just thought it wouldmake sense to do the same for NO_NATS_ALLOWED. -------------------- Mohan Parthasarathy (2005-10-03): https://www.machshav.com/pipermail/mobike/2005-October/001097.html > Er.. since the last paragraph of Section 6.1 doesn't talk about > DoS attacks, what exactly should be changed there? > > Causing DoS by modifying a packet containing NO_NATS_ALLOWED > is mentioned in Section 4.8, but the attacker doesn't need to know > which packets contain NO_NATS_ALLOWED: it's probably easier to > modify all of them. (And the attacker could also make a pretty > good guess just by looking at the unencrypted parts of the > message: e.g. exchange type and message length). > Hmm.. section 6.1 contains: However, just like with normal IKEv2, the actual IP addresses in the IP header are not covered by the integrity protection. This means that a NAT between the parties (or an attacker acting as a NAT) can modify the addresses and cause incorrect tunnel header (outer) IP addresses to be used for IPsec SAs. The scope of this attack is limited mainly to denial-of-service, since all traffic is protected using IPsec. ^ It talks about DoS attack here... This attack can only be launched by on-path attackers that are capable of modifying IKEv2 messages carrying NAT detection payloads (such as Dead Peer Detection messages). By modifying the IP header of these packets, the attackers can lead the peers believe a new NAT or a changed NAT binding exists between them. The attack can continue as long as the attacker is on the path, modifying the IKEv2 messages. If this is no longer the case, IKEv2 and MOBIKE mechanisms designed to detect NAT mapping changes will eventually recognize that the intended traffic is not getting through, and update the addresses appropriately. Here, it talks about how/why an attacker can launch attacks packets that carries NAT-D payloads. So, it might make sense to explain the same for NO_NATS_ALLOWED also. One can modify all ESP packets (without knowing whether NAT-D payload is included or not) to launch the attack described in the previous paragraph, but similar things can be done things outside of MOBIKE also and hence not very interesting.. > Probably the packets would not even reach the TCP layer, since > their destination IP address was not correct. So TCP RSTs would > not happen anyway. > My understanding of this attack is the client establishes the TCP connection, redirects the stream to a victim and sends false acknowledgements ? (Similar attack exists in MIP6 and packets get discarded because of Home address option at the IP layer). -------------------- Jari Arkko (2005-10-23): https://www.machshav.com/pipermail/mobike/2005-October/001168.html Looking at this again... >- Section 6.1 > >The last paragraph talks about NO_NATS_ALLOWED. The attack of >modifying the header to cause DoS attack is only possible if the >attacker knows that NO_NATS_ALLOWED is carried within the payload. As >payloads are encrypted, it may not be that easy always. It is easy if >it is the IKE_SA_INIT message.It might be worth stating when the >attack is possible. > > I think the only thing that Mohan wanted to do was to explain the condition of the attack that NO_NATS_ALLOWED protects against. Here's the simple text modification: MOBIKE introduces the NO_NATS_ALLOWED notification that is used to detect modification, by outsiders, of the addresses in the IP header. ... => MOBIKE introduces the NO_NATS_ALLOWED notification that is used to detect modification, by outsiders, of the addresses in the IP header. Such modifications can only be performed by attackers who are on the path and capable of modifying the IKEv2 and IPsec packets. ... >- Section 6.3 > > Normally such attacks would expire in a short time frame due to the > lack of responses (such as transport layer acknowledgements) from the > victim. However, as described in [Aura02], malicious participants > would typically be able to spoof such acknowledgements and maintain > the traffic flow for an extended period of time. > >This attack is possible because the victim does not have a valid SA >for the incoming ESP traffic and never reaches the TCP layer and hence >no TCP RSTs. Might be worth mentioning here. > > Add the following text to the end of this paragraph: ... Such an attack could also be defeated by use of negative acknowledgements, such as TCP RST and ICMP errors. However, too eager reliance on such acknowledgements has some denial-of-service issues itself. Also, many networks filter ICMP messages, and in our case the lack of a valid SA in the victim prevents TCP processing of incoming ESP packets. -------------------- Pasi Eronen (2005-10-24): https://www.machshav.com/pipermail/mobike/2005-October/001192.html This sounds redundant to me: it basically says that modifications can be performed only by attackers who can modify the packets...?? (And attacks by the IKE peer are discussed in section 6.3, not here) No, this is misleading: the victim sees only a bunch of ESP packets it cannot decrypt, and it doesn't even know who the real sender (e.g., TCP endpoint) is. And if you don't know that, where do you send the TCP RSTs or other negative acks? -------------------- Jari Arkko (2005-10-24): https://www.machshav.com/pipermail/mobike/2005-October/001196.html Ok, lets not add anything here then. Here's another attempt: Such an attack could also be defeated by use of negative acknowledgements, such as TCP RST and ICMP errors. However, in our case the victim lacks a valid SA and, as a result, is incapable providing any other negative acknowledgements than ICMP errors. Such errors may be filtered in many networks, and has some denial-of-service issues itself. -------------------- Pasi Eronen (2005-11-07): https://www.machshav.com/pipermail/mobike/2005-November/001278.html Hmm.. here's my take (add this to the end of the section): The duration of the attack can also be limited if the victim reports the unwanted traffic to the originating IPsec tunnel endpoint using ICMP error messages or INVALID_SPI notifications. As described in [IKEv2] Section 2.21, this SHOULD trigger a liveness test, which also doubles as a return routability check if the COOKIE2 notification is included. And while we're at it, we could also make the 3rd paragraph (the one referring to [Aura02] and transport layer acks) more accurate: If the attack is launched by an outsider, the traffic flow would normally stop soon due to the lack of responses (such as transport layer acknowledgements). However, if the original recipient of the flow is malicious, it could maintain the traffic flow for an extended period of time, since it often would be able to send the required acknowledgements (see [Aura02] for more discussion). Does this look ok? -------------------- Jari Arkko (2005-11-07): https://www.machshav.com/pipermail/mobike/2005-November/001279.html Yes. Thanks. -------------------- Mohan Parthasarathy (2005-11-08) https://www.machshav.com/pipermail/mobike/2005-November/001282.html sounds good to me. --------------------