Subject: [Ipsec] NAT-T in the face of changing IPs

From: Michael Richardson <[email-masked]>
Date: Tue, 24 Jul 2007 23:21:05 -0500

Here on the IETF hotel LAN, I noticed that my IPsec tunnels stopped
working to my SOHO, but some other tunnels remained up.  After doing
some multi-hop SSH logins, I tcpdump'ed as follows from the remote end:

00:16:48.267254 IP 67.97.210.3.500 > 205.150.200.246.500: isakmp: phase 1 I ident
00:16:48.293630 IP 205.150.200.246.500 > 67.97.210.3.500: isakmp: phase 1 R ident
00:16:48.344292 IP 67.97.210.3.500 > 205.150.200.246.500: isakmp: phase 1 I ident
00:16:48.351657 IP 205.150.200.246.500 > 67.97.210.3.500: isakmp: phase 1 R ident
00:16:48.447608 IP 67.97.210.2.5029 > 205.150.200.246.4500: NONESP-encap: isakmp: phase 1 ? ident[E]
00:16:58.442295 IP 205.150.200.246.500 > 67.97.210.3.500: isakmp: phase 1 R ident
00:16:58.486046 IP 67.97.210.2.5029 > 205.150.200.246.4500: NONESP-encap: isakmp: phase 1 ? ident[E]

Note that packets to port 500 are coming from 67.97.210.3.500, while
packets to port 4500 are coming from 67.97.210.2.5029.

I.e. a different UDP port.  Apparently, this is a problem for openswan.

Was this a case that I just didn't code for, or is this a gap in the
specification? 

- -- 
]            Bear: "Me, I'm just the shape of a bear."          |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] [email-masked]      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

---

From: Yoav Nir <[email-masked]>
Date: Wed, 25 Jul 2007 09:47:41 -0500

I would ask that question of the BEHAVE working group.

It's weird that packets from host A to host B would be NATTed through  
different IP addresses depending on a port. If this is acceptable for  
a NAT device, then we need to (1) say in our spec (or a future  
clarifications document) that this could happen, and (2) fix  
implementations to do so.

If it's not acceptable, then we need to do only (2).

The problem can probably be solved by starting out at port 4500. It's  
not specifically allowed by 4306 (I think), but it works with most  
implementations.

On Jul 24, 2007, at 11:21 PM, Michael Richardson wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
> Comment: Finger me for keys
>
> iQEVAwUBRqbPqoCLcPvd0N1lAQK2LggArnil82LcQ0wOEH+cCEPc3oDvmlG300h5
> 4kWtwv/JpyeL8PGNENfEuCqW69gvZyru78anHsrmnzLUIyCOt2bs7fcgu4nDmFX9
> kbKQdyuI7u/FlcUnsweyrEQ8gII017mTiEzs26/pC4frbejTv4y0ty2JR1YzinTI
> McWe4SXf9h21QCy5bWENsoKzB1krgXoZ9E8xJwmSYBWqi5CIazshAoo1fP14WeMk
> fo0D2uwipl/bFX9WG2X5W7WpEol/fxMdjvEkg7tZ7VpiBLPItmkT0iFNTC09Zizw
> tmuGAJD+RVEQh/l5g36JkRnLy5HbJX9Cj7H9hoqjBQOMDPzXDYpqEg==
> =5ZjR
> -----END PGP SIGNATURE-----
>

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 25 Jul 2007 21:38:12 +0300

> I.e. a different UDP port.  Apparently, this is a problem for openswan.

I guess you mean to say different IP-address, not port. The port is of
course different as it is behind NAT.

> Was this a case that I just didn't code for, or is this a gap in the

NAT-T specs do say that it can come from different IP-address. It even
specifies that the IP address can change on the fly.
----------------------------------------------------------------------
Network Working Group                                         T. Kivinen
Request for Comments: 3947                                       SafeNet
Category: Standards Track                                     B. Swander
                                                               Microsoft
                                                             A. Huttunen
                                                    F-Secure Corporation
                                                                V. Volpe
                                                           Cisco Systems
                                                            January 2005

                Negotiation of NAT-Traversal in the IKE
...
4.  Changing to New Ports

    Thus, the IKE packet now looks like this:

         IP UDP(4500,4500) <non-ESP marker> HDR*, IDii, [CERT, ] SIG_I

   This assumes authentication using signatures.  The 4 bytes of non-ESP
   marker are defined in the [RFC3948].

   When the responder gets this packet, the usual decryption and
   processing of the various payloads is performed.  If these are
   successful, the responder MUST update local state so that all
   subsequent packets (including informational notifications) to the
   peer use the new port, and possibly the new IP address obtained from
			  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   the incoming valid packet.  The port will generally be different, as
   the NAT will map UDP(500,500) to UDP(X,500), and UDP(4500,4500) to
   UDP(Y,4500).  The IP address will seldom be different from the pre-
   changed IP address.  The responder MUST respond with all subsequent
   IKE packets to this peer by using UDP(4500,Y).

...

7.  Recovering from the Expiring NAT Mappings

   There are cases where NAT box decides to remove mappings that are
   still alive (for example, when the keepalive interval is too long, or
   when the NAT box is rebooted).  To recover from this, ends that are
   NOT behind NAT SHOULD use the last valid UDP encapsulated IKE or
   IPsec packet from the other end to determine which IP and port
				      ^^^^^^^^^^^^^^^^^^^^^^^^^^^
   addresses should be used.  The host behind dynamic NAT MUST NOT do
   this, as otherwise it opens a DoS attack possibility because the IP
   address or port of the other host will not change (it is not behind
   NAT).

   Keepalives cannot be used for these purposes, as they are not
   authenticated, but any IKE authenticated IKE packet or ESP packet can
   be used to detect whether the IP address or the port has changed.
-- 
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Wed, 25 Jul 2007 15:31:43 -0500

> course different as it is behind NAT.

   Yes, that's what I meant.

> specifies that the IP address can change on the fly.

   Yes, I just didn't expect it to change until after the phase 1 was 
complete. I.e that it would change later on.

   I agree that this behaviour is acceptable. I think I'll have code tested 
soon for this tonight.