Subject: [IPsec] Spencer Dawkins' No Objection on draft-ietf-ipsecme-split-dns-14: (with COMMENT)

From: Spencer Dawkins <[email-masked]>
Date: Tue, 20 Nov 2018 13:45:14 -0800

Spencer Dawkins has entered the following ballot position for
draft-ietf-ipsecme-split-dns-14: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-split-dns/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Perhaps it would be helpful to give an example of why

  A client using these configuration payloads will be able to request
   and receive Split DNS configurations using the INTERNAL_DNS_DOMAIN
   and INTERNAL_DNSSEC_TA configuration attributes.  The client device
   can use the internal DNS server(s) for any DNS queries within the
   assigned domains.  DNS queries for other domains SHOULD be sent to
   the regular external DNS server.

DNS queries for other domains might not be sent to the regular external DNS
server? I'm thinking of one, but I'm flat-out guessing.

---

From: Paul Wouters <[email-masked]>
Date: Wed, 21 Nov 2018 00:32:08 -0500 (EST)

I think you are right, and we are mixing up INTERNAL_IP4_DNS with
INTERNAL_DNS_DOMAIN.

the idea is that the client can decide to not only use some
authoritative internal servers, but also use some recursive internal
servers. But I think those should be specified in the exiting
INTERNAL_IP4_DNS / INTERNAL_IP6_DNS attributes.

I suggest we change the above to:

   A client using these configuration payloads will be able to request
    and receive Split DNS configurations using the INTERNAL_DNS_DOMAIN
    and INTERNAL_DNSSEC_TA configuration attributes.  The client device
    can use the internal DNS server(s) for any DNS queries within the
    assigned domains.  DNS queries for other domains MAY be sent to
    an internal recursive DNS server specified in an INTERNAL_IP4_DNS
    or INTERNAL_IP6_DNS Configuration Payload but MAY also be resolved
    using the client's regular DNS resolving mechanisms outside of the
    IPsec connection.

Tommy, let me know what you think about this change?

Paul

---

From: Paul Wouters <[email-masked]>
Date: Wed, 21 Nov 2018 09:48:47 -0500 (EST)

> INTERNAL_IP4_DNS / INTERNAL_IP6_DNS attributes.

Actually, that does not work. The current specification does not allow
a INTERNAL_IP4_DNS or INTERNAL_IP6_DNS to be associated with only some
(or none) of the INTERNAL_DNS_DOMAINS.

>    using the client's regular DNS resolving mechanisms outside of the

So I suggest instead:

    A client using these configuration payloads will be able to request
    and receive Split DNS configurations using the INTERNAL_DNS_DOMAIN
    and INTERNAL_DNSSEC_TA configuration attributes.  These attributes
    MUST be accompanied by one or more INTERNAL_IP4_DNS or
    INTERNAL_IP6_DNS configuration attributes.  The client device can
    then use the internal DNS server(s) for any DNS queries within the
    assigned domains.  DNS queries for other domains MUST be sent to the
    regular DNS service of the client.

Paul

---

From: Tero Kivinen <[email-masked]>
Date: Sat, 24 Nov 2018 23:15:46 +0200

>     regular DNS service of the client.

So the meaning of the INTERNAL_IP*_DNS changs meaning depending
whether you have INTERNAL_DNS_DOMAIN or not. You might want to be bit
more text explaining that in this paragraph. 

Currently if server send INTERNAL_IP*_DNS (and do not include
INTERNAL_DNS_DOMAIN), then clients usually send all dns queries to
that server. Typically enterprice users trust their own DNS servers
more than the DNS server provided by the hotel...

After this change client must have some other DNS server also
configured, and MUST use them for other domains. Of course the general
idea for the Split-DNS is that we do not send all dns traffic to
server, only those internal domains, but one main use for it is also
to provide TAs for those internal domains so DANE etc can work for
internal services.

Anyways I think changing that to say "SHOULD be sent" could work
better, i.e., depending on the policy clients could either send
requests to normal DNS server or to the server provided in IKE.

Note, that the original configuration payload was supposed to provide
similar information than what DHCP does, so client does not need to
have anything preconfigured, but can get the whole network
configuration from the server. This included addresses, dns servers,
etc, and even DHCP server address that it can use to get attributes
not included in the configuration payload. Usually the configuration
parameters received from configuration payload replaced the parameters
they had before.
-- 
[email-masked]

---

From: Paul Wouters <[email-masked]>
Date: Mon, 26 Nov 2018 13:56:17 +0700

> more text explaining that in this paragraph.

I did not really want to do that. It would also require updating RFC 
7296. So instead, I just pushed a change with:

-   assigned domains.  DNS queries for other domains MUST be sent to the
-   regular DNS service of the client.
+   assigned domains.  DNS queries for other domains SHOULD be sent to
+   the regular DNS service of the client unless it prefers to use the
+   IPsec tunnel for all its DNS queries.  For example, the client could
+   trust the IPsec provided DNS servers more than the locally provided
+   DNS servers especially in the case of connecting to unknown or
+   untrusted networks (eg coffee shops or hotel networks).  Or the
+   client could prefer the IPsec based DNS servers because those provide
+   additional features over the local DNS servers.

> requests to normal DNS server or to the server provided in IKE.

Yes, done. see above.

> parameters received from configuration payload replaced the parameters

Yes, but with split-tunnel, the client is clearly stepping in with one 
foot while keeping the other foot dry :)

Paul

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 28 Nov 2018 14:25:40 +0200

> > requests to normal DNS server or to the server provided in IKE.

Looks good. 

> foot while keeping the other foot dry :)

Agreed. My text was mostly to explain people not familiar with
configuration payload what was the original meaning for them in
non-split-tunnel context.
-- 
[email-masked]