> On Jul 30, 2015, at 3:08 AM, Paul Wouters <[email protected]> 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 mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
