IETF Logo Mail Archive

Re: [IPsec] [sunset4] ietf-nat64 - Internet VPN clients

Michael Richardson <mcr+ietf@sandelman.ca> Fri, 09 December 2016 21:39 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E87E61294AB; Fri, 9 Dec 2016 13:39:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.797
X-Spam-Level:
X-Spam-Status: No, score=-4.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ke7-im_wSpnE; Fri, 9 Dec 2016 13:39:14 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32C9C129541; Fri, 9 Dec 2016 13:39:13 -0800 (PST)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 9F352E007; Fri, 9 Dec 2016 16:56:46 -0500 (EST)
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id D4C8563782; Fri, 9 Dec 2016 16:39:11 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net>
In-Reply-To: <D52B781A-39B2-4A74-9484-43DA1C12138C@lists.zabbadoz.net>
References: <6536E263028723489CCD5B6821D4B2132C3DF16D@UK30S005EXS06.EEAD.EEINT.CO.UK> <D45333DE.87DB3%evyncke@cisco.com> <6536E263028723489CCD5B6821D4B2132C401D4E@UK30S005EXS06.EEAD.EEINT.CO.UK> <CAATsVbbRWpscHdRYGDfo04JnWeHE6Fmi1vpF87ox=NnuG9iH7w@mail.gmail.com> <D52B781A-39B2-4A74-9484-43DA1C12138C@lists.zabbadoz.net>
X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Fri, 09 Dec 2016 16:39:11 -0500
Message-ID: <6205.1481319551@obiwan.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/ViU5vGPufN4fVd-Mi87UkRKnF0M>
Cc: ipsec@ietf.org, Bill Fenner <fenner@fenron.com>, "sunset4@ietf.org" <sunset4@ietf.org>
Subject: Re: [IPsec] [sunset4] ietf-nat64 - Internet VPN clients
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Dec 2016 21:39:16 -0000

Bjoern A. Zeeb <bzeeb-lists@lists.zabbadoz.net> wrote:
    > That’s maybe for the ipsec wg but while native IPv6 VPN has been working fine
    > for me for ages, how would a NAT64 policy exchange actually look like (I am
    > thinking about what is done for IPv4 NAT or double NAT within the same

NAT64 depends upon DNS64 to provide a fake IPv6 target for the application to
connect to.

So, for IPsec to work over NAT64 would require:

1) IPsec able to traverse over IPv6 networks (outer IP header being IPv6).
2) An IKEv2 deamon that uses DNS to find it's IPv4-only gateway, so that it
   can be lied to about the returned AAAA record.

In Bill's case, he hasn't got (1), so it's not going to work.
Once he has (1) (the upgrade he mentioned), if his policy lets him use DNS to
find his gateway, and he doesn't do DNSSEC on that, then it ought to work.

Of course, once he has the upgrade, if his gateway would just have an IPv6,
he wouldn't need NAT64. And he can tunnel his company 10.x v4 network over
things as much as he likes... but there is the question about where his
Internet bound v4 traffic will go... likely if his company's VPN wants to
inspect his traffic, the v4 will go through the tunnel, not using the NAT64
at all, and causing him higher latency.  But, that's what would happen in
a pure v4 situation anyway.

    > address family);  I doubt that different AFs on each end as part of the
    > policy are specified to work, so I’d not expect IPsec VPNs to work across a
    > NAT64 (from a v6 to a v4 endpoint);  someone surprise me and say with IKEv2
    > you can?  Someone surprise me and say with a double NAT64 it can work?

I'm not sure IKEv2 even knows or cares how the port-500 packets get there.
I use v6 over X tunnels (where X is usually v4) in order to get v6 to my
laptop from coffee shops regularly.  I haven't tried this over NAT64, but I
will change this to use DNS.  Of course, I wouldn't need this tunnel in a
NAT64 network, since I'd have v6, so I'll setup some v4 IPsec too for the
next IETF and try it out.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-

v2.23.0 | Report a Bug | By Email