Re: [IPsec] Split DNS in IKEv2 Configuration Payload

[Tommy Pauly]

Hello all,

Based on the conversation on the IPSec list previously about supporting Split 
DNS in IKEv2, Paul and I have written up a draft to add support for Split DNS 
(as well as DNSSEC) to the configuration attributes for IKEv2.

We’d like to get feedback from the working group about the level of interest in 
this topic, and if people would like to work on adopting it.

Thanks!
Tommy

===

A new version of I-D, draft-pauly-ipsecme-split-dns-00.txt
has been successfully submitted by Tommy Pauly and posted to the
IETF repository.

Name:   draft-pauly-ipsecme-split-dns
Revision:   00
Title:  Split-DNS Configuration for IKEv2 
Document date:  2015-09-24
Group:  Individual Submission
Pages:  10
URL:
https://www.ietf.org/internet-drafts/draft-pauly-ipsecme-split-dns-00.txt 

Status: https://datatracker.ietf.org/doc/draft-pauly-ipsecme-split-dns/ 

Htmlized:   https://tools.ietf.org/html/draft-pauly-ipsecme-split-dns-00 



Abstract:
  This document defines two new Configuration Payload Attribute Types
  for the IKEv2 protocol that together define a set of private DNS
  domains which should be resolved by DNS servers reachable through an
  IPsec connection, while leaving all other DNS resolution unchanged.
  This allows for split-DNS views for multiple domains and includes
  support for private DNSSEC trust anchors.  The information obtained
  via the new attribute types can be used to reconfigure a locally
  running DNS server with DNS forwarding for specific private domains.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org 
.

The IETF Secretariat

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Split DNS in IKEv2 Configuration Payload

[Paul Wouters]

On Thu, 24 Sep 2015, Tommy Pauly wrote:


We’d like to get feedback from the working group about the level of interest in 
this topic, and if people would like to work on adopting it.


One item we were not sure about is the format of the INTERNAL_DNSSEC_TA.

While a DS record is shorter and nicer and easier to add as configuration
option, it requires the initiator to do an (insecure?) DNS request for
the DNSKEY, then convert/verify it with with the DS record. It would be
easier for the client to be given the DNSKEY.

But DNSKEYs are much bigger and unwielding and would be pretty ugly in
configuration files on the responder side.

Paul

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Split DNS in IKEv2 Configuration Payload

[Tommy Pauly]

 On Jul 30, 2015, at 3:08 AM, Paul Wouters p...@nohats.ca wrote:
 
 On Thu, 30 Jul 2015, Tero Kivinen wrote:
 
 Paul Wouters writes:
 Should such a document include a section on client usage or just specify
 the payload formats?
 
 If such document is written, it has to defined client usage for the
 information, as those have security issues.
 
 That's reasonable.
 

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.


 For example, there are some expected behaviours for client cache flushing
 on VPN (dis)connect.
 
 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.
 
 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?

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. 

 
 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.
 
 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.
 
 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.
 
 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 :)
 
 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 ..
 
 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.

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. 

 
 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 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. 

 
 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”.

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

Thanks,
Tommy
 
 Paul

___
IPsec 

Re: [IPsec] Split DNS in IKEv2 Configuration Payload

[Tero Kivinen]

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.

  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 ..
  
  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.
 
 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. 

  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 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?
-- 
kivi...@iki.fi

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Split DNS in IKEv2 Configuration Payload

[Paul Wouters]

On Thu, 30 Jul 2015, Tero Kivinen wrote:


Paul Wouters writes:

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


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


That's reasonable.


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


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.


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?


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.


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.


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.


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 :)


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 ..


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

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Split DNS in IKEv2 Configuration Payload

[Tero Kivinen]

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

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
 on VPN (dis)connect.

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. 

 There is also a security concern if a third party VPN specfies to send
 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.
-- 
kivi...@iki.fi

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] Split DNS in IKEv2 Configuration Payload

[Tommy Pauly]

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
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec