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

From: <[email-masked]>
Date: Thu, 10 Sep 2020 07:33:23 +0000

Hi all,

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

Please review and share your comments. 

Thank you. 

Cheers,
Med

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] 
Envoyé : mercredi 9 septembre 2020 14:03
À : Dan Wing <[email-masked]>; Valery Smyslov <[email-masked]>; BOUCADAIR Mohamed TGI/OLN <[email-masked]>; Tirumaleswar Reddy.K <[email-masked]>; Tirumaleswar Reddy <[email-masked]>
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.

---

From: Paul Wouters <[email-masked]>
Date: Thu, 10 Sep 2020 10:36:36 -0400 (EDT)

> 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 encry…

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

> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: <[email-masked]>
Date: Fri, 11 Sep 2020 07:14:07 +0000

Hi Paul,

Thank you for the comments. 

Please see inline. 

Cheers,
Med

> De : Paul Wouters [mailto:[email-masked]]
> Envoyé : jeudi 10 septembre 2020 16:37
> À : BOUCADAIR Mohamed TGI/OLN <[email-masked]>
> Cc : [email-masked]; [email-masked]
> Objet : Re: [IPsec] TR: New Version Notification for draft-btw-add-
> ipsecme-ike-01.txt
> 
> > 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).
> 
> 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. 

> should add a specific port attribute for each bitmask entry. But
> honestly, the whole non-default port part seems like
> overengineering.
> 

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

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

---

From: "Valery Smyslov" <[email-masked]>
Date: Fri, 18 Sep 2020 15:51:11 +0300

Hi Paul,

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

> flavours, I'd prefer to send and receive just 1 CP payload covering

Please, see above.

> my above proposal would save a lot of bytes.

Again, see above.

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

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

> "dns.google.com" and basically redirecting all 1.1.1.1 traffic over the

How can you prevent it?

Regards,
Valery.

> > À : Dan Wing <[email-masked]>; Valery Smyslov <[email-masked]>; BOUCADAIR Mohamed TGI/OLN
> <[email-masked]>; Tirumaleswar Reddy.K <[email-masked]>;
> Tirumaleswar Reddy <[email-masked]>
> > 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.
> >

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 18 Sep 2020 22:09:34 -0700

> 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

---

From: Paul Wouters <[email-masked]>
Date: Sat, 19 Sep 2020 19:01:54 -0400

> (To be fair, I'm not following ADD much at all, though, so I could be

That is not how the CP payloads work. The initiator sends a set it is okay with and the responder picks what it prefers from that set. Or an error if it deems all of it bad.

I would still prefer a single request for encrypted DNS and a reply with servers with capabilities. Asking for all these different types will be more complicated.

Paul

---

From: "Valery Smyslov" <[email-masked]>
Date: Tue, 22 Sep 2020 15:34:04 +0300

Hi Paul,

> That is not how the CP payloads work. The initiator sends a set it is okay with and the responder picks what it
> prefers from that set. Or an error if it deems all of it bad.

Exactly. However, with different attribute types the client can indicate its capabilities too
and can prioritize them (by adding attributes to the request in the order of client's preference).

> I would still prefer a single request for encrypted DNS and a reply with servers with capabilities. Asking for all
> these different types will be more complicated.

I don't think it's really more complicated. I agree, that current solution is more bulky in case you want to 
convey all possible types of encrypted DNS, all sharing the same IP-addresses and authentication domain and 
not counting non-standard ports. In other use cases it's roughly the same in size.

Regards,
Valery.

---

From: Paul Wouters <[email-masked]>
Date: Tue, 22 Sep 2020 12:46:51 -0400 (EDT)

> and can prioritize them (by adding attributes to the request in the order of client's preference).

I don't think the Configuration Payload order significies a preference
for anything? Does RFC 7296 really say that?

> not counting non-standard ports. In other use cases it's roughly the same in size.

The common case will be DNS servers that support the kitchen sink. Let's
make that use case the easiest.

Paul

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 22 Sep 2020 21:38:33 +0300

Paul Wouters writes:
> >> That is not how the CP payloads work. The initiator sends a set
> >> it is okay with and the responder picks what it prefers from that
> >> set. Or an error if it deems all of it bad.
> >
> > Exactly. However, with different attribute types the client can
> > indicate its capabilities too and can prioritize them (by adding
> > attributes to the request in the order of client's preference).
> 
> I don't think the Configuration Payload order significies a
> preference for anything? Does RFC 7296 really say that?

Not exactly. It does say that for Security Association Payloads, and I
think mostly people have been assuming that same applies for other
things too (like CERTREQs, or Hash algorithm negotiation of RFC 7427).
It would be logical to assume same applies to the Configuration
Payloads, for example the first DNS server address is the preferred,
or the first INTERNAL_IP_ADDRESS returned is preferred one and others
are aliases...
-- 
[email-masked]