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