On Fri, Sep 18, 2020 at 03:51:11PM +0300, Valery Smyslov wrote: > 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.
I would expect there to be some people pushing to have this be a capability negotiation that honors the client's preference, not the server's; the scenario you describe is one where the server's preference is used. (To be fair, I'm not following ADD much at all, though, so I could be wrong.) -Ben > 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 : 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 > > _______________________________________________ > 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
