Subject: [IPsec] Question regarding security considerations with NAT-T scenario in IKEv2

From: Raj Singh <[email-masked]>
Date: Thu, 30 Jul 2009 10:37:12 +0530

Hi Group,

I have question regarding security considerations with NAT-T scenario in
IKEv2.
According to ikev2-bis-04, section 2.23
---------------------------------------------------------------

      There are cases where a NAT box decides to remove mappings that
      are still alive (for example, the keepalive interval is too long,
      or the NAT box is rebooted).  To recover in these cases, hosts

      that do not support other methods of recovery such as MOBIKE
      [MOBIKE <http://tools.ietf.org/html/draft-ietf-ipsecme-ikev2bis-04#ref-MOBIKE>],
and that are not behind a NAT, SHOULD send all packets

      (including retransmission packets) to the IP address and port from
      the last valid authenticated packet from the other end (that is,
      they should dynamically update the address).  A host behind a NAT

      SHOULD NOT do this because it opens a possible denial-of-service
      attack.  Any authenticated IKE packet or any authenticated UDP-
      encapsulated ESP packet can be used to detect that the IP address

      or the port has changed.  When IKEv2 is used with MOBIKE,
      dynamically updating the addresses described above interferes with
      MOBIKE's way of recovering from the same situation, so this method

      MUST NOT be used when MOBIKE is used.  See Section 3.8
<http://tools.ietf.org/html/draft-ietf-ipsecme-ikev2bis-04#section-3.8>
of [MOBIKE <http://tools.ietf.org/html/draft-ietf-ipsecme-ikev2bis-04#ref-MOBIKE>]

      for more information.

----------------------------------------------------------------------------------------------------------

1. Initiator is behind N(P)AT and float the port to (4500, 4500)

and send IKE_AUTH  with source port 4500 now N(P)AT changes source port
as 1024 but there is a man-in-the-middle who changes the port to other
host behind N(P)AT's port say 1025, still IKE_AUTH packet is authenticated.

The responder establishes the SA with destination port as 1025 instead of
1024 and sends the reply back to destination port 1025, so it will never
reach to original initiator . So the IKE SA will does not get established
on initiator But there is no mention of this DoS attack in the draft ?

2. The draft says the host that is NOT behind NAT SHOULD send packet to
IP address and port from which it received last authenticated packet.
A host behind behind a NAT SHOULD NOT do this because it opens a
DoS attack.

But how the location of host(Behind NAT or NOT) avoid DoS attack, say
when responder is having public IP, send an UDP encapsulated packet, some
man-in-the-middle changes the port, then initiator which is behind NAT wil
use ports from packet and will never reach the responder. This is also a
DoS attack.
Please let me how location of host (behind NAT or not) helps in avoiding
DoS attack ?

Thanks & Regards,
Raj

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 30 Jul 2009 11:46:21 +0300

> on initiator But there is no mention of this DoS attack in the draft

When the initiator does not get packets, it will retrasnmit its packet
and if the man-in-the-middle attacker is no longer there it will reach
the other end and has source port of 1024. This will then be
authenticated retransmission packet for the other end which will then
retransmit its previous packet to the address where port numbers were
swapped. As the packet was not new packet it will not update the SA,
but next packet from the responder will cause it to update the port
numbers.

If the man-in-the-middle is still there then the attack is still
ongoing and he can prevent communications between two peers. He does
not even need to modify the ports, he can simply delete those
packets... 

> A host behind behind a NAT SHOULD NOT do this because it opens a

Yes.

> Please let me how location of host (behind NAT or not) helps in avoiding

If we take the most common case where the initiator / client is behind
NAT and responder/server is not behind the NAT. Now the
responder/server has fixed IP address which will NOT change. Thus if
host which knows that other end is not behind NAT (i.e. initiator /
client in this case) does not update IP-addresses at all, as it knows
the other end has fixed IP-address the attacker cannot force both ends
to change addresses at the same time. If client would take any packet
and change other ends address to be as claimed in the headers then
attacker could simply send one packet that would change client's view
where the server is, and as the client is behind NAT his old NAT
mapping would get destroyed after a time, and after that server cannot
communicate to the client anymore at all. 
-- 
[email-masked]

---

From: Raj Singh <[email-masked]>
Date: Thu, 30 Jul 2009 15:37:43 +0530

Hi Tero,

> not even need to modify the ports, he can simply delete those

Agree. But draft does NOT mention about this DoS attack in security
considerations.
We'll have a mention of it in draft as the parent SA itself will come UP
with wrong ports.

Thanks and Regards,
Raj