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

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 : 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