[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipsec
Subject:    Re: [IPsec] Split DNS in IKEv2 Configuration Payload
From:       Tero Kivinen <kivinen () iki ! fi>
Date:       2015-07-31 23:12:48
Message-ID: 21948.240.780663.729327 () fireball ! acr ! fi
[Download RAW message or body]

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

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

[prev in list] [next in list] [prev in thread] [next in thread]