On Thu, 10 Sep 2020, mohamed.boucad...@orange.com wrote:
We updated the draft to take into account the comments raised during the last IETF meeting. Instead of multiplexing the attributes, we simplified the design so that types are assigned to each encrypted DNS type (DoT, DoH, DoQ).
Why is this using a seperate CP payload type per encrypted DNS type? This means that for a DNS server supporting DoT, DoH and DoQ, it needs to send 3 separate payloads. Why not send 1 CP payload that contains a bitmask specifying which services it supports? The only reason I can think of for this choice is because these might be running on non-standard ports, but I think that reason is rather weak. DoT and DoQ will run on standard defines ports and DoH's protocol aims at blending in as web traffic so it really is only getting deployed on port 443. So if I build a single server that can do unencrypted and all encrypted flavours, I'd prefer to send and receive just 1 CP payload covering everything. We _could_ leave the port there for non-standard ports, but then we should add a specific port attribute for each bitmask entry. But honestly, the whole non-default port part seems like overengineering. For those who care a lot about minimizing bytes exchanged over IKE, my above proposal would save a lot of bytes. I would also like to see more clarification about split-DNS and how a list of domains is conveyed via IKE as the only domains to be resolved via the given encrypted DNS servers. I would like to see something in the Security Considerations about handing out well known non-VPN reachable encrypted DNS servers. Eg I'd like to avoid that this document can instruct VPN users to use DoT at 8.8.8.8 if it is not going to offer a VPN that covers 8.8.8.8. If we don't do this, then VPN profiles might end up abusing/redirecting users without offering any actual VPN service - like overriding the system or application specific configuration without offering actual VPN servers to the user. I'm also considered about possive abuse by the specification of the authentication domain name. Eg a VPN provider setting up a tunnel covering 1.1.1.1 (dns.cloudflare.com) with an authentication name of "dns.google.com" and basically redirecting all 1.1.1.1 traffic over the VPN to 8.8.8.8. Paul
Please review and share your comments. Thank you. Cheers, Med -----Message d'origine----- De : internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] Envoyé : mercredi 9 septembre 2020 14:03 À : Dan Wing <dwing-i...@fuggles.com>; Valery Smyslov <s...@elvis.ru>; BOUCADAIR Mohamed TGI/OLN <mohamed.boucad...@orange.com>; Tirumaleswar Reddy.K <tirumaleswarreddy_ko...@mcafee.com>; Tirumaleswar Reddy <tirumaleswarreddy_ko...@mcafee.com> Objet : New Version Notification for draft-btw-add-ipsecme-ike-01.txt A new version of I-D, draft-btw-add-ipsecme-ike-01.txt has been successfully submitted by Mohamed Boucadair and posted to the IETF repository. Name: draft-btw-add-ipsecme-ike Revision: 01 Title: Internet Key Exchange Protocol Version 2 (IKEv2) Configuration for Encrypted DNS Document date: 2020-09-09 Group: Individual Submission Pages: 11 URL: https://www.ietf.org/id/draft-btw-add-ipsecme-ike-01.txt Status: https://datatracker.ietf.org/doc/draft-btw-add-ipsecme-ike/ Htmlized: https://datatracker.ietf.org/doc/html/draft-btw-add-ipsecme-ike Htmlized: https://tools.ietf.org/html/draft-btw-add-ipsecme-ike-01 Diff: https://www.ietf.org/rfcdiff?url2=draft-btw-add-ipsecme-ike-01 Abstract: This document specifies a new Internet Key Exchange Protocol Version 2 (IKEv2) Configuration Payload Attribute Types for encrypted DNS with a focus on DNS-over-HTTPS (DoH), DNS-over-TLS (DoT), and DNS- over-QUIC (DoQ). 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. The IETF Secretariat _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
