Subject: [IPsec] Review of draft-pauly-ipsecme-split-dns-02

From: Tero Kivinen <[email-masked]>
Date: Tue, 10 Jan 2017 16:24:16 +0200

This document was marked as "waiting for more reviews before taking as
WG draft", so I did my review now. Here are my comments:

----------------------------------------------------------------------

In the section 1 there is text:

       	       The client device
   can use the internal DNS server(s) for any DNS queries within the
   assigned domains, while routing other DNS queries to its regular
   external DNS server.

which would indicate that we can also use internal dns servers for
other DNS queries too.

Then on section 5 there is text saying:

     		  	All other domain
   names MUST be resolved using some other external DNS resolver(s),
   configured independently, and SHOULD NOT be sent to the internal DNS
   resolver(s) listed in that CFG_REPLY message.  

This is bit confusing. First of all all other domain names MUST use
external DNS servers, but then the requirement for ont using internal
DNS is only SHOULD NOT.

What is what we want there. Do we want to have clear splitting of the
DNS servers, i.e. all request for internal names go to the internal
servers, and never external ones, and do we want all request to
external names go to the external servers, and never internal ones.

I think the 1st point (I.e. all requests about internal names go to
the internal servers) is something that is important for security, so
it should perhaps be MUST.

On the other hand the 2nd point is not about security. Quite often
people can and want to use internal DNS server even for external DNS
requests. So I think that should be allowed in both ways, i.e.,
external DNS names can be asked from either internal or external name
servers, or even both.

--
>From section 3.2

   If the CFG_REQUEST included INTERNAL_DNS_DOMAIN attributes with non-
   zero lengths, the CFG_REPLY MUST NOT assign any domains in its
   INTERNAL_DNS_DOMAIN attributes that are not contained within the
   requested domains.  The initiator SHOULD ignore any domains beyond
   its requested list.

This whole thing about restricting the subdomains server can send by
sending the list from client is different than what we normally do. In
normal case the client sends list of suggestions for the configuration
values to the server. Here the client forces server to do something.

I think it would be better to say that client can send list of dns
names it would like to be included, and server can then reply whatever
list it has in its configuration, and client is free to ignore as many
of the items from the list it likes.

This way if you have originally configured company1.com to the
internal dns names, and then company decides to buy another company
called company2.com, teh client can still request company1.com and
server can return both company1.com and company2.com in its reply.
Then it is up to the client whether it will belive the list or not.

--

In section 4.2 it would be useful to repeat the fact that the bytes
after the Length match the DNS wire format of a DS record as specified
in [RFC4034]. The bytes match, but we repeat the definition from the
RFC4034, so it would be good idea to also explictly say it here, and
not only in section 3.2.

--

In section 5 the text:

   For each INTERNAL_DNS_DOMAIN entry in a CFG_REPLY payload, the client
   SHOULD use the provided INTERNAL_IP4_DNS or INTERNAL_IP6_DNS DNS
   servers as the only resolvers for the listed domains and its sub-
   domains and it SHOULD NOT attempt to resolve the provided DNS domains
   using its external DNS servers.

Why is that only SHOULD. I mean if there is INTERNAL_DNS_DOMAIN
specified, shouldn't the client be following it? So why it is not
MUST? And in which cases the SHOULD can be broken? What are the
exceptions where internal domains can be resolved from the outside dns
servers (or actually failed to be resolved).

--

   If the initiator host is configured to block DNS answers containing
   IP addresses from special IP address ranges such as those of
   [RFC1918], the initiator SHOULD allow the DNS domains listed in the
   INTERNAL_DNS_DOMAIN attributes to contain these IP addresses.

I think this is wrong. I think we should say that it should not block
any addresses which are part of the configured INTERNAL_IP*_SUBNETS.
I.e., if the vpn is not configured to pass packets to 10.0.0.0/8
network, then blocking those DNS answers is still fine.

--

   If a CFG_REPLY contains one or more INTERNAL_DNS_DOMAIN attributes,
   the client SHOULD configure its DNS resolver to resolve those domains
   and all their subdomains using only the DNS resolver(s) listed in
   that CFG_REPLY message.

Again why only SHOULD? When should it ignore the instructions from the
server?

--

		If those resolvers fail, those names SHOULD
   NOT be resolved using any other DNS resolvers.  

Should this also be MUST NOT?

--

       	    All other domain
   names MUST be resolved using some other external DNS resolver(s),
   configured independently, and SHOULD NOT be sent to the internal DNS
   resolver(s) listed in that CFG_REPLY message.

This was already in my previous comment.

--

     	 	    For example, if the
   INTERNAL_DNS_DOMAIN attribute specifies "example.com", then
   "example.com", "www.example.com" and "mail.eng.example.com" MUST be
   resolved using the internal DNS resolver(s), but "anotherexample.com"
   and "ample.com" MUST be resolved using the system's external DNS
   resolver(s).

But then in the example there is only MUSTs....

--

   When an IPsec connection is terminated, the DNS forwarding must be
   unconfigured.  The DNS forwarding itself MUST be be deleted.  All
   cached data of the INTERNAL_DNS_DOMAIN provided DNS domainis MUST be
   flushed.  This includes negative cache entries.  Obtained DNSSEC
   trust anchors MUST be removed from the list of trust anchors.  The

This might cause security issues. I.e., if you have mail.example.com
resolved using internal dns server to have IP-address of 10.0.0.1, and
then someone manages to tear down the VPN connection, and suddenly all
these mappings go away, the next time your mail client tries to fetch
email, it does mail.example.com lookup using external DNS servers, and
will get IP-address of 1.1.1.1 from ns.evil.org, then then it will
connect to wrong mail server...

Perhaps we should keep the mappings for some time, just in case the
connection comes back few seconds later when the vpn reconnects...

--

   A domain that is served via INTERNAL_DNS_DOMAIN MUST NOT have
   indirect references to DNS records that point to other Split DNS
   domains that are not served via INTERNAL_DNS_DOMAIN attributes.
   Indirect reference RRtypes include CNAME, DNAME, MX and SRV RR's.

How this going to be done?

I.e., how do you convince the system adminstrator of the company1.com
that adding mail.company2.com CNAME mail.company1.com is against RFC,
and must not be done until all clients are configured to ask
company1.com and company2.com internal dns domains?

I think we can put that text in the security consideration section and
say that adminstrators should take care that the CNAMES etc used in
the internal domains, do not leak out to wrong domain names or
something.

--

In section 6:

   If a host connected to an authenticated IKE peer is connecting to
   another IKE peer that attempts to claim the same domain via the
   INTERNAL_DNS_DOMAIN attribute, the IKE connection should be
   terminated.

Which of the IKE connection should be terminated? Perhaps the first
connection has died and user tried to reconnect to the same server,
which will of course give the same INTERNAL_DNS_DOMAIN. Tearing down
that new connection and not allowing it to be formed until the first
one is timed out is bit annoying.

--

   If the IP address value of the received INTERNAL_IP4_DNS or
   INTERNAL_IP6_DNS attribute is not covered by the proposed IPsec
   connection, then the local DNS should not be reconfigured until a
   CREATE_CHILD Exchange is received that covers these IP addresses.

I think this is dangerous. I.e. if the server returns INTERNAL_IP4_DNS
of 10.0.0.1 and INTERNAL_DNS_DOMAIN of example.com, but initial Child
sa connection fails for some reason (out of resources). Next the email
client trying to resolve the mail.example.com goes out to the external
dns servers to find the name, instead of trying to use 10.0.0.1 dns
server. Note, that when it tries to send packet to 10.0.0.1, then the
IPsec will simply trigger for that packet, and will create the Child
SA needed...

So I think the DNS configuration should be done immediately,
regardless whether the Child SA to cover those IP address is there.
In properly configured system the IP-address will then trigger the SA
to be created when they are first time used.
-- 
[email-masked]

---

From: "Valery Smyslov" <[email-masked]>
Date: Thu, 12 Jan 2017 11:45:47 +0300

Hi Tero,

Why the client would ever not believe to the information from the authenticated server?
I'd go further and say that the initiator MUST use the received internal DNS servers 
for all the requests within the received INTERNAL_DNS_DOMAIN (as you proposed before).

> one is timed out is bit annoying.

I think that tearing down a connection in this case is wrong and inconsistent with
Redirect Mechanism for IKEv2 (RFC5685). There could be several
VPN gateways protecting the internal network and the client
can be redirected from one to another (or even have a concurrent
IKE SAs in case of load sharing scenario).

> to be created when they are first time used.

I completely agree here. As with internal IP address assignment
the failure to create IPsec SA is not a reason not to configure
internal DNS servers. 

Regards,
Valery.

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 12 Jan 2017 15:09:31 +0200

Valery Smyslov writes:
> Why the client would ever not believe to the information from the
> authenticated server? I'd go further and say that the initiator MUST
> use the received internal DNS servers for all the requests within
> the received INTERNAL_DNS_DOMAIN (as you proposed before).

The level of trust might not be complete. I.e., if my laptop is
connecting to both my own VPN gateway, and also one of our partners
VPN gateway, I might trust the VPN gateway of our my company even if
it claims to provide trusted DNS delegation for .com...

I might not want to trust the VPN gateway of our partner claiming to
be authorative for mycompany.com, i.e., I will have policy limiting
what is accepted from the gateway.

Also when using opportunistic authentication we might want to have
even strictier policies.
-- 
[email-masked]

---

From: "Valery Smyslov" <[email-masked]>
Date: Thu, 12 Jan 2017 16:17:34 +0300

> Also when using opportunistic authentication we might want to have

OK, then it contradicts with your own comment that all requests to 
INTERNAL_DNS_DOMAIN MUST be done using internal DNS server.
Quoting your message:

At least it must be clarified.

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 12 Jan 2017 15:39:50 +0200

> At least it must be clarified.

Yes, and No. If the client rejects the INTERNAL_DNS_DOMAIN because of
policy reasons, then it is not internal name anymore, thus it can use
DNS server configured elsewhere. But yes, I agree there should be
clarification explaining that only those internal names client
accepted must use internal servers...
-- 
[email-masked]

---

From: Paul Wouters <[email-masked]>
Date: Thu, 12 Jan 2017 12:02:21 -0500 (EST)

> accepted must use internal servers...

Remember ipsec is peer to peer, not client to server :)

The idea is that the client can convey information of which DNS it will
allow to be stolen and the server can convey which DNS it is serving
that is expected to be an internal dns domain (eg different from outside
worldview).

This is not about the server offering a DNS server to take all your
queries. For that, I believe you can use the existing options, and
those are outside the scope of this document.

Paul

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 13 Jan 2017 11:50:04 +0200

> Remember ipsec is peer to peer, not client to server :)

Yes, but configuration payloads for endpoint from the tunnel endpoint
(section 1.1.3), is not peer to peer, it is client to server :-)

> that is expected to be an internal dns domain (eg different from outside

For endpoint to security gateway setup (RFC7296 section 1.1.3) the
endpoint is usually configured to trust the tunnel endpoint, but
endpoint might also have some of its own configuration for example
from previous runs. I.e. endpoint can offer these are the domains I
configured last time, and server will respond those look good. Or the
server can respond, those look good, but add this new domain, as my
configuration has changed since last time.

The reason client might want to keep track of the old internal dns
domains is that it might want to block the dns for those domains while
the vpn is not up, and even trigger the vpn creation when some
application tries to resolve one of those domains. 

> those are outside the scope of this document.

This is about the server offering a DNS server to take some of your
queries, but not all. And the defintion of some is intersection of the
servers and clients policies. I.e., what server is willing to offer,
and what client is willing to accept.
-- 
[email-masked]