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
