Hi Paul, > 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?
Well, from my understanding of ADD (I'm not an expert), there must not be substantial difference between different types of encrypted DNS servers in terms of provided service (ADD folks use term "equivalent" reolvers, emphasizing that no matter which resolver the client reaches the response will be the same). If my understanding is correct, then I see little sense in configuring all types of encrypted DNS servers. So, DoT, DoH, DoQ is more a capability negotiation: the client asks for those types of encrypted DNS it supports and the server returns server(s) of one type, based on its configuration. In this case there is no difference in message size if we use separate attributes or a single attribute with bitmask. And several simple attributes are a bit easier to process... > 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. Please, see above. > 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. Again, see above. > 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. What problems are with the current text? I believe almost all from RFC8598 remains valid, we only replace Do53 servers IP addresses with Encrypted DNS ones. > 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. What is your proposal? Restrict DNS servers IP addresses to always be within Tri/TSr ranges? > 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. How can you prevent it? Regards, Valery. > Paul > > > > > > Please review and share your comments. > > > > Thank you. > > > > Cheers, > > Med > > > > -----Message d'origine----- > > De : [email protected] [mailto:[email protected]] > > Envoyé : mercredi 9 septembre 2020 14:03 > > À : Dan Wing <[email protected]>; Valery Smyslov <[email protected]>; > > BOUCADAIR Mohamed TGI/OLN > <[email protected]>; Tirumaleswar Reddy.K > <[email protected]>; > Tirumaleswar Reddy <[email protected]> > > 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 > > [email protected] > > https://www.ietf.org/mailman/listinfo/ipsec > > _______________________________________________ > IPsec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
