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

[[e-mail]]

Hi Paul,

Thank you for the comments. 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Paul Wouters [mailto:[e-mail]]
> Envoyé : jeudi 10 septembre 2020 16:37
> À : BOUCADAIR Mohamed TGI/OLN <[e-mail]>
> Cc : [e-mail]; [e-mail]
> Objet : Re: [IPsec] TR: New Version Notification for draft-btw-add-
> ipsecme-ike-01.txt
> 
> On Thu, 10 Sep 2020, [e-mail] 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?

[Med] We used to have one single attribute that is used for all types (with a bitmask). We changed the design as we thought this will simplify the processing of the attributes and allow for more flexibility. 

This is also to echo this comment from Tero (https://www.ietf.org/proceedings/108/minutes/minutes-108-ipsecme-01.pdf):

"Tero: Add configuration attributes, less internal strucutre, more higher level structure"

> 
> The only reason I can think of for this choice is because these
> might be running on non-standard ports,

[Med] Customized port numbers can be accommodated with the single attribute (with bitmask) by retuning multiple instances of the attribute with distinct DNS types.   

The same reasoning applies if one want to terminate DoT/DoH/DoQ on distinct IP addres(es) or one want to use distinct authentication name for each encrypted DNS. 

In that approach, an implementation has to process both the attribute type and sub-type to decide what to do.  

With the sub-type removed, the processing is a little bit simplified. 

 but I think that reason is
> rather weak. DoT and DoQ will run on standard defines ports and

[Med] I tend to agree with you for DoT. 

For DoQ, the situation is a little bit different:
* There is no default port (yet).
* We added the port to the spec to address a comment we received from the authors of DoQ specification: Christian Huitema suggested to have the port configurable. 

> DoH's protocol aims at blending in as web traffic so it really is
> only getting deployed on port 443.

[Med] Fully agree. 

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

[Med] That was the reasoning we had in -00 and my favorite BTW but as an editor of the document I'm also hearing comments asking for more flexibility and simplicity:
* what if the servers terminates on distinct addresses?
* what if distinct authentication names are used?
* what if a non-default port is used?

I'm not sure we can reconcile the desire to return one CP payload vs. attribute simplicity for cases with customized config. 

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

[Med] Agree that it saves bytes for the single server case supporting all DNS types, but not if customized @/AND/port are used.   

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

[Med] We are relying upon RFC8598 as described in the draft:  

   If the IPsec connection is a split-tunnel configuration and the
   initiator negotiated INTERNAL_DNS_DOMAIN as per [RFC8598], the DNS
   client MUST resolve the internal names using ENCDNS_IP*_* DNS
   servers.

      Note: [RFC8598] requires INTERNAL_IP6_DNS (or INTERNAL_IP4_DNS)
      attribute to be mandatory present when INTERNAL_DNS_DOMAIN is
      included.  This specification relaxes that constraint in the
      presence of ENCDNS_IP*_* attributes.

Do you have in mind any specific point not covered in RFC8598 that we need to consider? 

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

[Med] This would apply for INTERNAL_IP*_DNS attributes as well. We can add a generic note. 

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

[Med] Not sure to get this one.

_________________________________________________________________________________________________________________________

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.