Re: [IPsec] TR: New Version Notification for draft-btw-add-ipsecme-ike-01.txt

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-drafts@ietf.org [mailto:internet-drafts@ietf.org]
> > > Envoyé : mercredi 9 septembre 2020 14:03
> > > À : Dan Wing <dwing-ietf@fuggles.com>; Valery Smyslov <svan@elvis.ru>; BOUCADAIR Mohamed TGI/OLN
> > <mohamed.boucadair@orange.com>; Tirumaleswar Reddy.K <tirumaleswarreddy_konda@mcafee.com>;
> > Tirumaleswar Reddy <TirumaleswarReddy_Konda@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