Subject: [IPsec] Split DNS in IKEv2 Configuration Payload

From: Tommy Pauly <[email-masked]>
Date: Thu, 23 Jul 2015 14:55:21 +0200

Hello,

I’d like to see if the working group has interest in adding support for a list of split-DNS domains to the configuration payload for IKEv2. Existing split-tunnel VPN solutions often use a configuration in which only a private domain is resolved using the VPN’s DNS server, and all other resolutions use the physical network’s DNS server.

I am aware that there are other solutions to this problem, including:
1. Using DHCP inside the tunnel to get the DNS search domains
2. Use the VPN’s private DNS server for all resolutions
3. Send out all resolutions to both servers
4. Manually configure split domains on client

However, all of these approaches have drawbacks. 
1. We have not seen DHCP within the IKEv2 tunnel widely deployed, especially when almost all of the information is already in the configuration payload (assigned addresses, routes, and DNS server addresses). 
2. Many enterprise’s have DNS servers that only resolve hosts on their private subnet, so using the internal DNS for all resolutions would require a significant infrastructure change.
3. Sending out multiple queries increases network traffic, has privacy concerns (leaking private hostnames on the public network), and performance concerns (how long to wait for each to return?)
4. Manual configuration is what we currently require for our clients on Mac and iOS. This, however, does not allow servers to change the configuration dynamically and is not always exposed as an option to the user.

If people think that it would make sense to add an option to specify multiple private domains to scope the usage of the DNS server assigned in the configuration payload, I’d like to write up a draft and see if we can get server adoption.

Any comments are welcome!

Thanks,
Tommy

---

From: Michael Richardson <[email-masked]>
Date: Thu, 23 Jul 2015 09:36:58 -0400

Tommy Pauly <[email-masked]> wrote:
    > I’d like to see if the working group has interest in adding support for
    > a list of split-DNS domains to the configuration payload for
    > IKEv2. Existing split-tunnel VPN solutions often use a configuration in
    > which only a private domain is resolved using the VPN’s DNS server, and
    > all other resolutions use the physical network’s DNS server.

This falls into the MIF problem space.
The VPN problem is directly called out by the problem statement (RFC6418).

RFC6731 describes how to do what you want using DHCPv4 and DHCPv6 options.
I would suggest that if running DHCP inside the tunnel is not acceptable,
then I suggest tunnelling the DHCP messages inside of IKEv2.

(DHCPv6 is a relatively straightforward application to run, no magic
listening on the raw interfaces required, the DHCPv6 server doesn't need to
be co-located with the IPsec gateway, and given DHCP relays and multicast
destination addresses, the client doesn't even need to be configured)

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Paul Wouters <[email-masked]>
Date: Sat, 25 Jul 2015 09:53:28 -0400 (EDT)

> I’d like to see if the working group has interest in adding support for a list of split-DNS domains to the configuration payload for IKEv2. Existing split-tunnel VPN solutions often use a configura…

Yes, I am interested and would add it to our implementation as we have a
clear need for this.

> 4. Manual configuration is what we currently require for our clients on Mac and iOS. This, however, does not allow servers to change the configuration dynamically and is not always exposed as an op…

Agreed.

> If people think that it would make sense to add an option to specify multiple private domains to scope the usage of the DNS server assigned in the configuration payload, I’d like to write up a draf…

I'd hope to get client adoption as well :)

Should such a document include a section on client usage or just specify
the payload formats?

For example, there are some expected behaviours for client cache flushing
on VPN (dis)connect.

There is also a security concern if a third party VPN specfies to send
DNS queries for apple.com or "." to it.

Paul

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 30 Jul 2015 01:41:24 +0300

> Should such a document include a section on client usage or just specify

If such document is written, it has to defined client usage for the
information, as those have security issues. 

> For example, there are some expected behaviours for client cache flushing

The client needs to flush the local dns-cache (both in local resolver
library, but also in all applications currently running) when the VPN
connection is established.

Otherwise the attacker could return wrong IP-address for
mail.example.com before the VPN connection gets up, and then the mail
client would still use that wrong IP-address, which could cause the
connection to go outside the VPN tunnel.

Using dns to configure anything in the IPsec is inheritly dangerous as
the IPsec policy is based on the IP-addresses, not host names, and if
you use untrusted information to do the mapping this will cause
problems. 

> DNS queries for apple.com or "." to it.

Also if you have multiple VPN connections up and running and all of
them claim that they are the only ones who want to serve ".".

So I think the actual payload formats are easy, but the document would
need to also think about all these cases, and specify how those should
be solved.
-- 
[email-masked]

---

From: Paul Wouters <[email-masked]>
Date: Thu, 30 Jul 2015 06:08:28 -0400 (EDT)

> information, as those have security issues.

That's reasonable.

> connection is established.

Except there is no known mechanism to inform all DNS caching
applications. In practise though, this seems to work fine for me. On
daily basis I roam around coffeeshops and bring my redhat tunnel up
and down while seamlessly accessing bugzilla.redhat.com which switches
between internal/external IPs based on whether the VPN is up or down.
And I'd say browsers are the most common "illegal cachers" out there?

> connection to go outside the VPN tunnel.

right. which is why libreswan will perform a cache and request_list
flush on VPN change. Currently this is limited to one domain name, as
typical (IKEv1 XAUTH) only returns one domain option. There is a clear
need for a (large) list of domains - especially universities seem to
happilly create hundreds of split view domains.

> you use untrusted information to do the mapping this will cause

It won't get much worse then the common "any ip to any ip"
configurations. I've given up my battles against "routing VPNs", system
administrators are just too lazy to securely configure VPNs :)

> them claim that they are the only ones who want to serve ".".

I would say that if you want all DNS traffic (eg "." domain) that would
only be allowed if you also get all the traffic (0.0.0.0/0). Because in
that case the VPN has already taken over your security and you have
configured a trust relationship for everything already.

So that leaves the issue of VPN service Foo claiming bar.com instead of
foo.com DNS. I think for manually configured VPNs (eg classic VPN) this
is not a protocol problem but a management problem. For autoamtic VPNs
(eg opportunistic) I think the client MUST ignore this new option along
with a bunch of other CP payload options - that is it is not a new
problem.

I do have another item I would like put in the payload though. I would
like to be able to also send the DS record or DNSKEY for the domain, so
that we can allow split DNS views where both inside and outside DNS
views are managemd by different DNSSEC keys. This would also allow for
relaying information that the domain name supplied might go from
insecure to secure or from secure to insecure. This would allow support
for "ouside signed, but inside not" and "inside signed but outside not".

Paul

---

From: Tommy Pauly <[email-masked]>
Date: Fri, 31 Jul 2015 08:22:42 -0700

> On Jul 30, 2015, at 3:08 AM, Paul Wouters <[email-masked]> wrote:
> 

I was imagining that the draft would primarily focus on the configuration option format for the domains, which would be very short. But, as Tero pointed out, we will definitely need a section to recommend client implementation details for security, etc.

> And I'd say browsers are the most common "illegal cachers" out there?

On the topic of DNS caching, I think the draft could give recommendations that the cache for a domain assigned to the IKEv2 connection should be flushed, but would not need to go into implementation details. From the perspective of our clients (Mac and iOS), all VPN types other than IKEv2 already support split DNS configurations. We use a single daemon, mDNSResponder, to manage the cache for all applications. Whenever a split DNS configuration is added or removed, the cache for that domain will be flushed. 

> configured a trust relationship for everything already.

Yes, we also generally only let the VPN claim to resolve all DNS traffic if it also claims to route all IP traffic—this is the “full tunnel” mode, and the device clearly trusts the server. 

> with a bunch of other CP payload options - that is it is not a new

I agree that the issue of trusting the VPN server to assign a valid private domain for resolution is a management problem, not a protocol problem. If we trust the server to assign private routes, we can generally trust it to assign private domains. The server could just as easily assign “malicious” routes to capture other services’ traffic as it could assign incorrect domains. It is up to the client to make sure that the source is trusted. I agree that this is clearer for a traditional VPN, and any opportunistic clients must be more cautious. 

> for "ouside signed, but inside not" and "inside signed but outside not”.

Sounds good, I think it would make sense to add this option.

Thanks,
Tommy

---

From: Tero Kivinen <[email-masked]>
Date: Sat, 1 Aug 2015 02:12:48 +0300

Tommy Pauly writes:
> On the topic of DNS caching, I think the draft could give
> recommendations that the cache for a domain assigned to the IKEv2
> connection should be flushed, but would not need to go into
> implementation details. From the perspective of our clients (Mac and
> iOS), all VPN types other than IKEv2 already support split DNS
> configurations. We use a single daemon, mDNSResponder, to manage the
> cache for all applications. Whenever a split DNS configuration is
> added or removed, the cache for that domain will be flushed.

That might be enough. On the other hand applications quite often do
have their own caches too (I do not think web page does dns lookup
from local daemon for every single image on the page, as most likely
they will be from same server, and browser might also reuse old
keepalive tcp connection to the server).

I.e. if browser does dns lookup for www.example.com using global dns,
gets faked reply for IP-address of www.evil.com back, and then starts
loading the page by making connection to the www.evil.com. Now user
notices that oh, I forgot to enable VPN before loading that page,
enables VPN, VPN will flush cache, and then user will reload the page,
but unfortunately as browser still has http connection to www.evil.com
based on faked dns lookup, it will reload everything using that
connection, as there is no way for VPN to tell it to flush its
internal state.

> Yes, we also generally only let the VPN claim to resolve all DNS
> traffic if it also claims to route all IP traffic—this is the “full
> tunnel” mode, and the device clearly trusts the server.

Oh, the evil vpn can ask only for ".com", ".org", ".net" etc domains,
it does not need to ask for "." to gain almost same effect...

I.e. there is all kind details we need to think here. 

> I agree that the issue of trusting the VPN server to assign a valid
> private domain for resolution is a management problem, not a
> protocol problem. If we trust the server to assign private routes,
> we can generally trust it to assign private domains.

That is not true with opprtunistic cases. It is easy to limit the VPN
to only do route adding for only the IP-number that was used to
connect the VPN, but ther eis no way to verify the DNS name list
returned by the server.

When connecting to the trusted domain there is no problem, as the
configuration can be trusted. 

> The server could just as easily assign “malicious” routes to capture
> other services’ traffic as it could assign incorrect domains. It is
> up to the client to make sure that the source is trusted. I agree
> that this is clearer for a traditional VPN, and any opportunistic
> clients must be more cautious.

Yep, or even disable the whole DNS prefix thing. On the other hand how
do plan to handle the reverse dns? Match the dns query of
x.y.z.in-addr.arpa and forward it only to tunnel which has vpn traffic
route to z.y.x network?
-- 
[email-masked]