> On Jul 31, 2015, at 4:12 PM, Tero Kivinen <kivi...@iki.fi> wrote: > > 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.
This is definitely a possibility if the browser manages its own DNS cache and does not monitor network changes to know when to flush the cache. However, since this problem is solved by most mainstream browsers on the major OSes, I think we can just include a note about this in the draft. > >>>> 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. Certainly, the VPN could do this. If the client wants to be more paranoid/restrictive, one interesting option would be to send the requested split domains in the configuration payload, and only apply the domains that the server replies with that are within the requested domains. This would restrict what the server could send, in the same way that the initiator can request restricted traffic selectors. For example, one valid exchange could be: Initiator: SPLIT-DOMAINS: (example.com <http://example.com/>, 0.0.0.0) -> Responder: <- SPLIT-DOMAINS: (mail.example.com <http://mail.example.com/>, 198.51.100.2; other.example.com <http://other.example.com/>, 198.51.100.6) If the responder tried to claim .com, the initiator could ignore or only send example.com <http://example.com/>. > >>> 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? Yes, opportunistic clients may probably want to disable the DNS domains altogether. That should be a recommendation. The reverse DNS case is interesting. We could do it like you suggested, although I do not have a strong opinion on this. Thanks, Tommy > -- > kivi...@iki.fi > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
