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

On Thu, 10 Sep 2020, mohamed.boucadair@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-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