Re: peer address protection and NAT Traversal

Ari Huttunen <Ari.Huttunen@f-secure.com> Mon, 13 January 2003 10:05 UTC

Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0DA5Uo19619; Mon, 13 Jan 2003 02:05:30 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA17222 Mon, 13 Jan 2003 04:42:01 -0500 (EST)
Message-ID: <3E228A71.90701@F-Secure.com>
Date: Mon, 13 Jan 2003 11:44:17 +0200
From: Ari Huttunen <Ari.Huttunen@f-secure.com>
Organization: F-Secure Corporation
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
CC: Charlie_Kaufman@notesdev.ibm.com, ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com
Subject: Re: peer address protection and NAT Traversal
References: <200301121644.h0CGiOof066946@givry.rennes.enst-bretagne.fr>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 13 Jan 2003 09:44:19.0196 (UTC) FILETIME=[580903C0:01C2BAE8]
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk

Francis Dupont wrote:
>  In your previous mail you wrote:
>    
>    I've now read and understood draft-dupont-transient-pseudonat-01.txt. I'd
>    like to propose language in the IKEv2 and NAT traversal documents to
>    address it, but I'm eager to hear from the NAT Traversal folk whether the
>    fix will break too many real cases.
>    
> => My purpose is not to drop the NAT traversal feature but to make it
> optional. This should place the discussion on the default, IMHO we should
> be default enable NAT traversal for IPv4 and disable it for IPv6.

Well, if you don't have a NAT in an IPv6 (or whatever version of IP) case,
no UDP encapsulation will be done. So a better solution is to deploy
IPv6 and not deploy NATs.

> 
>    Francis Dupont <Francis.Dupont@enst-bretagne.fr> wrote:
>    >  The I-D editor has just announced the new version of my I-D about
>    > the transient pseudo-NAT attack and its application to Mobile IPv4
>    > (documented in the security section of the NAT traversal extension)
>    > and to IKE... Its name is draft-dupont-transient-pseudonat-01.txt.
>    >  I believe we should fix the issue (the security flaw) for the next
>    > version of the IKEv2 document.
>    
>    I could imagine lots of clever ways to try to deal with this... all with
>    clever countermeasures that allow an attacker to exploit them.
>    
> => this is my claim: there is no easy defense against the attack which
> keeps the NAT traversal feature...

This is not suprising. If there's somebody who can change traffic between
you and the other guy you want to talk to, all bets are off anyway. Is there
a real case where some hacker may be able to do this for a short while, but
not arbitrarily long?

> 
>    So what I'd like to propose is that IPsec SAs *not* try to survive
>    mid-connection NAT renumberings.

Well, it's intentionally left out of the current NAT traversal drafts.
It was discussed at some point between the authors. Instead we specify
NAT keepalives.

Ari

-- 
I play it cool and dig all jive,
  that's the reason I stay alive.
   My motto as I live and learn,
    is dig and be dug in return. <Langston Hughes>

Ari Huttunen                   phone: +358 9 2520 0700
Software Architect             fax  : +358 9 2520 5001

F-Secure Corporation       http://www.F-Secure.com

F(ully)-Secure products: Securing the Mobile Enterprise