Re: [IPsec] I-D Action: draft-ietf-ipsecme-split-dns-11.txt
> On Jul 22, 2018, at 12:01 PM, Paul Wouters wrote: > > On Thu, 19 Jul 2018, Tommy Pauly wrote: > >>> 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. >> >> Good point, agreed on this text. >>> >>> 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. >> >> 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. That sounds fine to me. > > 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? 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 > > Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] I-D Action: draft-ietf-ipsecme-split-dns-11.txt
On Thu, 19 Jul 2018, Tommy Pauly wrote: 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. Good point, agreed on this text. 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. 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 ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] I-D Action: draft-ietf-ipsecme-split-dns-11.txt
> On Jul 19, 2018, at 2:09 PM, Paul Wouters wrote: > > On Thu, 19 Jul 2018, internet-dra...@ietf.org wrote: > >> Subject: [IPsec] I-D Action: draft-ietf-ipsecme-split-dns-11.txt > >> A diff from the previous version is available at: >> 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. Good point, agreed on this text. > > 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. That's fair. Can you propose a sentence here to replace with? Tommy > > Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] I-D Action: draft-ietf-ipsecme-split-dns-11.txt
On Thu, 19 Jul 2018, internet-dra...@ietf.org wrote: Subject: [IPsec] I-D Action: draft-ietf-ipsecme-split-dns-11.txt A diff from the previous version is available at: 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 ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] I-D Action: draft-ietf-ipsecme-split-dns-11.txt
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/ ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
