Subject: [IPsec] WG Adoption call for draft-btw-add-ipsecme-ike

From: Tero Kivinen <[email-masked]>
Date: Mon, 8 Nov 2021 16:17:24 +0200

This is the start of 2 week WG adoption call for this document, ending
2021-11-22. Please send your reply about whether you support adopting
this document as WG document or not.
-- 
[email-masked]

---

From: <[email-masked]>
Date: Mon, 8 Nov 2021 14:28:13 +0000

Hi Tero, all, 

I support adoption. 

FWIW, I'm not aware of any IPR related to this I-D.

Cheers,
Med

> -----Message d'origine-----
> De : IPsec <[email-masked]> De la part de Tero Kivinen
> Envoyé : lundi 8 novembre 2021 15:17
> À : [email-masked]
> Objet : [IPsec] WG Adoption call for draft-btw-add-ipsecme-ike
> 
> 2021-11-22. Please send your reply about whether you support adopting this
> document as WG document or not.
> --
> [email-masked]
> 
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

_________________________________________________________________________________________________________________________

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: Mon, 8 Nov 2021 10:19:51 -0500 (EST)

On Mon, 8 Nov 2021, Tero Kivinen wrote:

> Subject: [IPsec] WG Adoption call for draft-btw-add-ipsecme-ike
> 

I support the idea of conveying a list of DNS servers that support
encryption. I am not sure if this draft's format and content is the
right way forward.

Note the text of the draft claims it updates RFC 8598 but doesn't do so
via an Updates: statement. Also, I think the relaxing of the requirement
is actually wrong, as it might cause lack of interop between newer
servers and older clients not being able to negotiate working DNS if
the new servers no longer serve INTERNAL_IP*_DNS CFG payloads.

I am also not clear on the real use of negotiating hash algorithms for
the digest receiving of the ADD server "identity?", as the document
states the authentication happens as per Section 8 of [RFC8310]
which lists WebPKI or DANE authentication against the name and these
methods do not use this digest. I also do not understand the use of the
digest. For authentication, is it not needed as the entire IKEv2 exchange
is authenticated.

Paul

---

From: <[email-masked]>
Date: Mon, 8 Nov 2021 15:48:53 +0000

Hi Paul, 

Please see inline.

Cheers,
Med

> De : IPsec <[email-masked]> De la part de Paul Wouters
> Envoyé : lundi 8 novembre 2021 16:20
> À : Tero Kivinen <[email-masked]>
> Cc : [email-masked]
> Objet : Re: [IPsec] WG Adoption call for draft-btw-add-ipsecme-ike
> 
> encryption. I am not sure if this draft's format and content is the right
> way forward.

[Med] Thanks. The format can always be updated to reflect the feedback from the WG.

> via an Updates: statement.

[Med] We considered to have an "update" header because we were concerned with some MUSTs in 8598. We finally didn't include the update header because of a comment we received from you prior to publishing the first version of the draft. FWIW, here is the exchange we had at that time: 

******
Med: I have a question for you: now that we don't depend anymore on INTERNAL_IP*_DNS and given that a client can be supplied with 8598 attributes and that 8598 says the following:
 
==
If an INTERNAL_DNS_DOMAIN attribute is
   included in the CFG_REPLY, the responder MUST also include one or
   both of the INTERNAL_IP4_DNS and INTERNAL_IP6_DNS attributes in the
   CFG_REPLY. 
 
..
 
   the INTERNAL_DNS_DOMAIN attributes in a CFG_REPLY payload form a
   single list of Split DNS domains that applies to the entire list of
   INTERNAL_IP4_DNS and INTERNAL_IP6_DNS attributes.
 
==

Should we add an update to our daft to indicate that first "MUST" does not apply and that the domains are associated with **ANY** supplied server?

Paul: You cannot update that RFC for that kind of processing. The above really says that it makes no sense to have "internal domains" without providing "internal DNS servers".
****

 Also, I think the relaxing of the requirement
> is actually wrong, as it might cause lack of interop between newer servers
> and older clients not being able to negotiate working DNS if the new
> servers no longer serve INTERNAL_IP*_DNS CFG payloads.

[Med] Older clients can always ask for INTERNAL_IP6_DNS or INTERNAL_IP4_DNS. We will update the note to make this clearer. 

> 
> I am also not clear on the real use of negotiating hash algorithms for the
> digest receiving of the ADD server "identity?", as the document states the
> authentication happens as per Section 8 of [RFC8310] which lists WebPKI or
> DANE authentication against the name and these methods do not use this
> digest. I also do not understand the use of the digest. For
> authentication, is it not needed as the entire IKEv2 exchange is
> authenticated.

[Med] We added the digest to address one of the comments raised in a previous ipsecme meetings: allow to not rely on PKI for validating the encrypted DNS server certificate but convey the end-entity certificate in IKEv2 itself.

---

From: Paul Wouters <[email-masked]>
Date: Mon, 8 Nov 2021 13:06:03 -0500 (EST)

> Paul: You cannot update that RFC for that kind of processing. The above really says that it makes no sense to have "internal domains" without providing "internal DNS servers".

Note that what I said there was that you should not update the _mechanism_
of how CFG requests/responds are done. You should use the existing
mechanism with a new value, but use the same negotation mechanism.

So the client sends FOO(x) and the server respones with FOO(y)

x can be empty (eg the client has no previous notion or preference for
FOO. Or if it has one, it can suggest it. The server takes that value
only as a preference of the client, but the server is the one making
the ultimate decsion if it returns "x" or "y".

So your draft should not say the initiator MUST send a zero size request
for FOO. That is changing the mechanism.

What I was saying in my last email was that making a protocol update
where a server receiving a INTERNAL_IP4_DNS may choose not to return
any INTERNAL_IP4_DNS is an update to the protocol that would require
the Updates: clause to warn implementers to read this document too,
as it updates older RFC text.

> [Med] Older clients can always ask for INTERNAL_IP6_DNS or INTERNAL_IP4_DNS. We will update the note to make this clearer.

They can indeed. So I think you should just stick with the CFG request/response
semantics and not talk about omitting INTERNAL_IP*_DNS replies if the
client asks for those via CFG. This way, the ENC_DNS* payloads are
simply defined as new CFG options, and clients and servers will do the
right thing when encountering them. And it requires no Updates: clause
because it does not modify the behaviour with respect to
INTERNAL_IP*_DNS. You might want to say a client SHOULD prefer ENC_DNS*
servers over INTERNAL_IP*_DNS servers.

> [Med] We added the digest to address one of the comments raised in a previous ipsecme meetings: allow to not rely on PKI for validating the encrypted DNS server certificate but convey the end-entit…

Ah, I see. I would probably use some different terminology then, and
extend the text talking aboyt "as per Section 8 of [RFC8310]" to
clarify that. I'll see about producing some text for you.

Paul

---

From: <[email-masked]>
Date: Tue, 9 Nov 2021 12:03:37 +0000

Hi Paul, 

Please see inline. 

Cheers,
Med

> De : Paul Wouters <[email-masked]>
> Envoyé : lundi 8 novembre 2021 19:06
> À : BOUCADAIR Mohamed INNOV/NET <[email-masked]>
> Cc : Tero Kivinen <[email-masked]>; [email-masked]
> >> Note the text of the draft claims it updates RFC 8598 but doesn't do
> >> so via an Updates: statement.
> >
> > [Med] We considered to have an "update" header because we were concerned
> with some MUSTs in 8598. We finally didn't include the update header
> because of a comment we received from you prior to publishing the first
> version of the draft. FWIW, here is the exchange we had at that time:
> >
> > ******
> > Med: I have a question for you: now that we don't depend anymore on
> INTERNAL_IP*_DNS and given that a client can be supplied with 8598
> attributes and that 8598 says the following:
> >
> > ==
> > Should we add an update to our daft to indicate that first "MUST" does
> not apply and that the domains are associated with **ANY** supplied
> server?
> >
> > Paul: You cannot update that RFC for that kind of processing. The above
> really says that it makes no sense to have "internal domains" without
> providing "internal DNS servers".
> > ****
> 
> FOO. Or if it has one, it can suggest it. The server takes that value only
> as a preference of the client, but the server is the one making the
> ultimate decsion if it returns "x" or "y".
> 
> for FOO.

[Med] We are not saying that in the draft. 

 That is changing the mechanism.
> 
> What I was saying in my last email was that making a protocol update where
> a server receiving a INTERNAL_IP4_DNS may choose not to return any
> INTERNAL_IP4_DNS is an update to the protocol that would require the
> Updates: clause to warn implementers to read this document too, as it
> updates older RFC text.

[Med] OK. 

> > [Med] Older clients can always ask for INTERNAL_IP6_DNS or
> INTERNAL_IP4_DNS. We will update the note to make this clearer.
> 
> They can indeed. So I think you should just stick with the CFG
> request/response semantics and not talk about omitting INTERNAL_IP*_DNS
> replies if the client asks for those via CFG. This way, the ENC_DNS*
> payloads are simply defined as new CFG options, and clients and servers
> will do the right thing when encountering them. And it requires no
> Updates: clause because it does not modify the behaviour with respect to

[Med] That's one approach. The one we have in the draft is to enforce a policy at the responder side:

      The behavior of the responder if it receives both ENCDNS_IP* and
      INTERNAL_IP6_DNS (or INTERNAL_IP4_DNS) attributes is policy-based
      and deployment-specific.  However, it is RECOMMENDED that if the
      responder includes at least one ENCDNS_IP* attribute in the reply,
      it should not include any of INTERNAL_IP4_DNS/INTERNAL_IP6_DNS
      attributes.

This policy allows for more control vs. providing both to the client + let the client decide. 

This is an item for discussion/agreement when the document is adopted. Point recorded. Thanks. 

> 
> 
> 
> >> I am also not clear on the real use of negotiating hash algorithms
> >> for the digest receiving of the ADD server "identity?", as the
> >> document states the authentication happens as per Section 8 of
> >> [RFC8310] which lists WebPKI or DANE authentication against the name
> >> and these methods do not use this digest. I also do not understand
> >> the use of the digest. For authentication, is it not needed as the
> >> entire IKEv2 exchange is authenticated.
> >
> > [Med] We added the digest to address one of the comments raised in a
> previous ipsecme meetings: allow to not rely on PKI for validating the
> encrypted DNS server certificate but convey the end-entity certificate in
> IKEv2 itself.
> 
> extend the text talking aboyt "as per Section 8 of [RFC8310]" to clarify
> that. I'll see about producing some text for you.
> 

[Med] Great. Looking forward receiving your text proposal.

---

From: Paul Wouters <[email-masked]>
Date: Tue, 9 Nov 2021 19:20:10 -0500 (EST)

> [Med] We are not saying that in the draft.

Section 3.1 states:

o  Length (2 octets, unsigned integer) - Length of the data in
       octets.  In particular, this field is set to:

       *  0 if the Configuration payload has types CFG_REQUEST or
          CFG_ACK.

So it says for a CFG_REQUEST the length is 0.

>> Updates: clause to warn implementers to read this document too, as it

But note that I rather that the responder just responds to the received
CFG requests with CFG replies it supports and has data for. So if the
client asks for INTERNAL_IP4_DNS and ENCDNS_IP4, the responder should
return both with values. I also think that in case the encrypted DNS
fails, it would be good for the IKEv2 client to have the INTERNAL_IP4_DNS
as fallback option. Say if the TLS fails for some reason (incompatible
algorithms, expired TLS certificate, DoH server down, etc)

> This policy allows for more control vs. providing both to the client + let the client decide.

The client can just omit asking for ENCDNS_IP* to get INTERNAL_IP*_DNS
anyway. I don't think the policy should be encoded in how we return
Configuration Payload information. If you want to convey policy, you
should make it part of the CFG payload.

> This is an item for discussion/agreement when the document is adopted. Point recorded. Thanks.

We don't need to wait for adoption to discuss this. Others can chime in any time :)

Paul

---

From: <[email-masked]>
Date: Wed, 10 Nov 2021 07:30:31 +0000

Hi Paul, 

Please see inline. 

Cheers,
Med

> Envoyé : mercredi 10 novembre 2021 01:20
> Cc : [email-masked]; [email-masked]; Tero Kivinen
> <[email-masked]>
> >> Note that what I said there was that you should not update the
> >> _mechanism_ of how CFG requests/responds are done. You should use the
> >> existing mechanism with a new value, but use the same negotation
> mechanism.
> >>
> >> x can be empty (eg the client has no previous notion or preference
> >> for FOO. Or if it has one, it can suggest it. The server takes that
> >> value only as a preference of the client, but the server is the one
> >> making the ultimate decsion if it returns "x" or "y".
> >>
> >> So your draft should not say the initiator MUST send a zero size
> >> request for FOO.
> >

[Med] This is the length of the ENCDNS_IP* attribute. This is used in requests to indicate that the client is requesting this attribute. 

> >> the

[Med] The current version allows somehow for this as the behavior is policy-based. However, I understand that you prefer to systematically return both and leave the client decide. I can live with this as well.

---

From: tirumal reddy <[email-masked]>
Date: Wed, 10 Nov 2021 15:10:49 +0530

I support adoption of the draft.

-Tiru

On Mon, 8 Nov 2021 at 19:58, <[email-masked]> wrote:

> 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,
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;

---

From: Paul Wouters <[email-masked]>
Date: Wed, 10 Nov 2021 17:23:35 -0500 (EST)

> [Med] This is the length of the ENCDNS_IP* attribute. This is used in requests to indicate that the client is requesting this attribute.

https://datatracker.ietf.org/doc/html/rfc7296#section-3.15.1

    The CFG_REQUEST and CFG_REPLY pair allows an IKE endpoint to request
    information from its peer.  If an attribute in the CFG_REQUEST
    Configuration payload is not zero-length, it is taken as a suggestion
    for that attribute.  The CFG_REPLY Configuration payload MAY return
    that value, or a new one.  It MAY also add new attributes and not
    include some requested ones.  Unrecognized or unsupported attributes
    MUST be ignored in both requests and responses.

I see no reason why ENCDNS_IP* should do this differently from all the
other CFG attributes, especially INTERNAL_IP*_DNS.

> [Med] The current version allows somehow for this as the behavior is policy-based. However, I understand that you prefer to systematically return both and leave the client decide. I can live with t…

The policy can be enforced by not returning INTERNAL_IP*_DNS payloads in
the CFG_REPLY. Although if the client did not ask for ENCDNS_IP* and the
server does not return INTERNAL_IP*_DNS, the client would not be able
to get functional DNS.

I still believe the CFG mechanism is to exchange network topology
information, and not network policy. But you can (ab)use it for that
if you want. The protocol allows it without requiring the change
that you suggest that the sender MUST use 0 length. And this requirement
would force your policy onto everyone else who would be happy to let
the client suggest something (eg 8.8.8.8 or 9.9.9.9) and have the
responder maybe accept those as trustworthy.

In short, if this document just defines standard CFG REQUEST/REPLY for
ENCDNS_IP* with no additional restrictions, everyone's use case is
supported AND you don't have to Update: RFC 7296 because no existing
behaviour is changed.

Paul

---

From: Michael Richardson <[email-masked]>
Date: Wed, 10 Nov 2021 18:00:35 -0500

> this document as WG document or not.

I have browsed through the document.

I don't know if the mechanism is correct or not.
I think that Paul Wouters' email seems correct to me.

I think that there is an interaction with provisioning domains (PvD) which is
not spelled out.  
The remote access "VPN" is usually a provisioning domain these days.

In general, I don't think that split-DNS is a good thing.
I don't think that sending all traffic through the VPN is a good thing.
Almost everyone that I know, that has any kind of VPN, has more than one
potentially active at the same time. (but my friends are mostly consultants
like me).

So I object to the entire notion that we need to do anything at all: there
are way better solutions than split-dns, and I think we should stop pandering
to enterprises that live in the dark-ages of 1992 IPv4.  Do any of them
actually pay to upgrade/replace their VPN gateway boxes such that they'd actually get
this new code?   Are the split-dns or die enthusiasts running IKEv1 w/3DES+MD5?

Having said this, I do not object to the WG doing this work, but I won't be
taking time to review it.

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: "Valery Smyslov" <[email-masked]>
Date: Thu, 11 Nov 2021 09:15:26 +0300

HI,

Just for the record: as a co-author I (obviously) support adoption or this document.

Regards,
Valery.

---

From: <[email-masked]>
Date: Thu, 11 Nov 2021 09:12:00 +0000

Hi Paul,

Please see inline. 

Cheers,
Med

Orange Restricted

> De : Paul Wouters <[email-masked]>
> Envoyé : mercredi 10 novembre 2021 23:24
> Cc : Paul Wouters <[email-masked]>; [email-masked]; draft-btw-add-
> [email-masked]; Tero Kivinen <[email-masked]>
> > [Med] This is the length of the ENCDNS_IP* attribute. This is used in
> requests to indicate that the client is requesting this attribute.
> 

[Med] Zero-length is allowed for other configuration attributes, e.g., 

   o  SUPPORTED_ATTRIBUTES - When used within a Request, this attribute
      MUST be zero-length and specifies a query to the responder to
      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
      reply back with all of the attributes that it supports.

It is also allowed for INTERNAL_IP*_DNS:  

   o  INTERNAL_IP4_ADDRESS, INTERNAL_IP6_ADDRESS - An address on the
      internal network, sometimes called a red node address or private
      address, and it MAY be a private address on the Internet.  In a
      request message, the address specified is a requested address (or
      a zero-length address if no specific address is requested).
      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

We didn't include a suggested ADN/@ in the proposed ENCDNS_IP* for the sake of simplicity. We are open to relax this if the WG sees so. 

> 
> >> But note that I rather that the responder just responds to the
> >> received CFG requests with CFG replies it supports and has data for.
> >> So if the client asks for INTERNAL_IP4_DNS and ENCDNS_IP4, the
> >> responder should return both with values. I also think that in case
> >> the encrypted DNS fails, it would be good for the IKEv2 client to
> >> have the INTERNAL_IP4_DNS as fallback option. Say if the TLS fails
> >> for some reason (incompatible algorithms, expired TLS certificate,
> >> DoH server down, etc)
> >
> > [Med] The current version allows somehow for this as the behavior is
> policy-based. However, I understand that you prefer to systematically
> return both and leave the client decide. I can live with this as well.
> 
> server does not return INTERNAL_IP*_DNS, the client would not be able to
> get functional DNS.
> 
> information, and not network policy. But you can (ab)use it for that if
> you want. The protocol allows it without requiring the change that you
> suggest that the sender MUST use 0 length. And this requirement would
> force your policy onto everyone else who would be happy to let the client
> suggest something (eg 8.8.8.8 or 9.9.9.9) and have the responder maybe
> accept those as trustworthy.
> 

[Med] I still don't see why you think the document updates RFC 7296.

---

From: Tommy Pauly <[email-masked]>
Date: Thu, 11 Nov 2021 06:07:44 -0800

I support adoption of this work. The mechanism of specifying the authentication domain name and service parameters is sound, and the right direction.

I do agree with Paul Wouter’s comments, and I think the parts of the document that deal with requirements for config requests need work. Ideally, this doesn’t need to update split-DNS, but instead just reference the fact that the encrypted resolvers MUST always be preferred when present.

The text also needs to be careful about not over-mandating behavior. For example, the text currently says the following:

   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.

RFC 8598 has a bit more leeway, explaining that there may be some domains that are prohibited by local policy from being claimed by the IKE tunnel. This needs to be maintained.

For each INTERNAL_DNS_DOMAIN entry in a CFG_REPLY payload that is not
   prohibited by local policy, the client MUST use the provided
   INTERNAL_IP4_DNS or INTERNAL_IP6_DNS DNS servers as the only
   resolvers for the listed domains and its subdomains, and it MUST NOT
   attempt to resolve the provided DNS domains using its external DNS
   servers.

Best,
Tommy

> On Nov 8, 2021, at 6:17 AM, Tero Kivinen <[email-masked]> wrote:
>

---

From: <[email-masked]>
Date: Thu, 11 Nov 2021 15:44:53 +0000

Hi Tommy, 

All good points. Thanks. 

Please see inline. 

Cheers,
Med

> De : IPsec <[email-masked]> De la part de Tommy Pauly
> Envoyé : jeudi 11 novembre 2021 15:08
> À : Tero Kivinen <[email-masked]>; [email-masked]
> I support adoption of this work. The mechanism of specifying the
> authentication domain name and service parameters is sound, and the right
> direction.
> 
> I do agree with Paul Wouter’s comments, and I think the parts of the
> document that deal with requirements for config requests need work.
> Ideally, this doesn’t need to update split-DNS, but instead just reference
> the fact that the encrypted resolvers MUST always be preferred when
> present.

[Med] We will need to decide if we keep this as SHOULD/RECOMMENDED or use a strong language (MUST) as you suggest.  

> 
> The text also needs to be careful about not over-mandating behavior. For
> example, the text currently says the following:
> 

[Med] Agree this should be better worded. The case we had in mind is when INTERNAL_DNS_DOMAIN is negotiated but INTERNAL_*_DNS attributes are not present. In such case, the name are resolved using ENCDNS_IP* servers. There is a MUST in RFC8598 that I do still think is problematic and need to be relaxed in the presence of ENCDNS_IP*. 

> RFC 8598 has a bit more leeway, explaining that there may be some domains
> that are prohibited by local policy from being claimed by the IKE tunnel.
> This needs to be maintained.
>