Subject: [IPsec] I-D Action: draft-ietf-ipsecme-split-dns-11.txt

From: [email-masked]
Date: Thu, 19 Jul 2018 07:47:15 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Security Maintenance and Extensions WG of the IETF.

        Title           : Split DNS Configuration for IKEv2
        Authors         : Tommy Pauly
                          Paul Wouters
	Filename        : draft-ietf-ipsecme-split-dns-11.txt
	Pages           : 13
	Date            : 2018-07-19

Abstract:
   This document defines two Configuration Payload Attribute Types for
   the IKEv2 protocol that add support for private DNS domains.  These
   domains are intended to be resolved using DNS servers reachable
   through an IPsec connection, while leaving all other DNS resolution
   unchanged.  This approach of resolving a subset of domains using non-
   public DNS servers is referred to as "Split DNS".

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-split-dns/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-ipsecme-split-dns-11
https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-split-dns-11

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-split-dns-11

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Paul Wouters <[email-masked]>
Date: Thu, 19 Jul 2018 14:09:21 -0400 (EDT)

On Thu, 19 Jul 2018, [email-masked] wrote:

> Subject: [IPsec] I-D Action: draft-ietf-ipsecme-split-dns-11.txt

> https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-split-dns-11

This is probably wrong:

 	Any INTERNAL_DNSSEC_TA attribute that is not immediately preceded by an
 	INTERNAL_DNS_DOMAIN attribute MUST be ignored and treated as aprotocol error.

Because you can have more then one INTERNAL_DNSSEC_TA for one domain.
Instead, it should read:

 	Any INTERNAL_DNSSEC_TA attribute that is not immediately preceded by an
 	INTERNAL_DNS_DOMAIN or another INTERNAL_DNSSEC_TA attribute applying to
 	the same domain name MUST be ignored and treated as a protocol error.

>From the previous diff, I'm confused about:

 	IKE clients MUST use a preconfigured whitelist of one or more domain
 	which it will allow INTERNAL_DNSSEC_TA updates.

It could have an empty white list and use direct IP without split-dns ?
Or use the VPN as an "encrypted DNS" provider for everything (which is
allowed according to the spec, that is it does not violate a MUST NOT)

Also, since we allow signaling of "upgrade your IKE config out of band"
if you see a new unconfigured domain name in the reply, it could be that
you start with 0 and get a new one. Which also requires an empty list.

Paul

---

From: Tommy Pauly <[email-masked]>
Date: Thu, 19 Jul 2018 16:22:27 -0400

> On Jul 19, 2018, at 2:09 PM, Paul Wouters <[email-masked]> wrote:
> 

Good point, agreed on this text.
> you start with 0 and get a new one. Which also requires an empty list.

That's fair. Can you propose a sentence here to replace with?

Tommy

---

From: Paul Wouters <[email-masked]>
Date: Sun, 22 Jul 2018 15:01:16 -0400 (EDT)

> That's fair. Can you propose a sentence here to replace with?

How about:

IKE clients willing to accept INTERNAL_DNSSEC_TA updates MUST use a
whitelist of one or more domains that can be updated. IKE clients with
an empty whitelist MUST NOT accept any INTERNAL_DNSSEC_TA and MUST NOT
use any INTERNAL_DNSSEC_TA received over IKE. Such clients MAY interpret
receiving a INTERNAL_DNSSEC_TA for a non-whitelisted domain as a trigger
to update their local configuration out of band.

the only issue left I see is that it is kind of weird that we would
allow domain redirection (eg google.com to 192.168.1.1) but not
INTERNAL_DNSSEC_TA redirection. So my question is still, should this
whitelist text apply to INTERNAL_DNSSEC_TA or to both INTERNAL_DNS_DOMAIN
and INTERNAL_DNSSEC_TA?

Paul

---

From: Tommy Pauly <[email-masked]>
Date: Sun, 22 Jul 2018 12:41:23 -0700

> On Jul 22, 2018, at 12:01 PM, Paul Wouters <[email-masked]> wrote:
> 

That sounds fine to me.
> whitelist text apply to INTERNAL_DNSSEC_TA or to both INTERNAL_DNS_DOMAIN

I'd rather not add this restriction to the normal DNS domain redirection, since claiming a DNS
domain for resolution does not imply changing the trust/validation properties of that domain.
Moreover, since by default, all DNS queries will be sent to the VPN's DNS server,
INTERNAL_DNS_DOMAIN strictly reduces the set of domains that will be resolved using
The VPN's DNS server. INTERNAL_DNSSEC_TA does add some new properties, and
thus is not merely a reduction.

Thanks,
Tommy