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
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
