Re: [IPsec] WG Adoption call for draft-btw-add-ipsecme-ike
Hi Paul, As a follow-up to: > 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 I wonder whether you had time to check the version we published back in December (https://datatracker.ietf.org/doc/draft-ietf-ipsecme-add-ike/) and identify candidate changes. Thank you. Cheers, Med > -Message d'origine- > De : Paul Wouters > Envoyé : lundi 8 novembre 2021 19:06 > À : BOUCADAIR Mohamed INNOV/NET > Cc : Tero Kivinen ; ipsec@ietf.org > Objet : Re: [IPsec] WG Adoption call for draft-btw-add-ipsecme-ike > ... > > >> 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. > > 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 _ 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] WG Adoption call for draft-btw-add-ipsecme-ike
Tero Kivinen writes: > 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. We had some discussion on the mechanims defined in this draft, but there was also lots of support for including this draft as working group item, so the WG adoption call passed. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] WG Adoption call for draft-btw-add-ipsecme-ike
Hi Tommy, All good points. Thanks. Please see inline. Cheers, Med > -Message d'origine- > De : IPsec De la part de Tommy Pauly > Envoyé : jeudi 11 novembre 2021 15:08 > À : Tero Kivinen ; ipsec@ietf.org > Objet : Re: [IPsec] WG Adoption call for draft-btw-add-ipsecme-ike > > 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: > >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. > [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. > > 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 wrote: > > > > 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. > > -- > > kivi...@iki.fi > > > > ___ > > 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 _ 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
Re: [IPsec] WG Adoption call for draft-btw-add-ipsecme-ike
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 wrote: > > 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. > -- > kivi...@iki.fi > > ___ > 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
Re: [IPsec] WG Adoption call for draft-btw-add-ipsecme-ike
Hi Paul, Please see inline. Cheers, Med Orange Restricted > -Message d'origine- > De : Paul Wouters > Envoyé : mercredi 10 novembre 2021 23:24 > À : BOUCADAIR Mohamed INNOV/NET > Cc : Paul Wouters ; ipsec@ietf.org; draft-btw-add- > ipsecme-...@ietf.org; Tero Kivinen > Objet : Re: [IPsec] WG Adoption call for draft-btw-add-ipsecme-ike > > On Wed, 10 Nov 2021, mohamed.boucad...@orange.com wrote: > > >>>> 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. > >>> > >>> [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. > > > > [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] 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. > > 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. >
Re: [IPsec] WG Adoption call for draft-btw-add-ipsecme-ike
HI, Just for the record: as a co-author I (obviously) support adoption or this document. Regards, Valery. > 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. > -- > kivi...@iki.fi > > ___ > 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
Re: [IPsec] WG Adoption call for draft-btw-add-ipsecme-ike
> 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. 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 , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] WG Adoption call for draft-btw-add-ipsecme-ike
On Wed, 10 Nov 2021, mohamed.boucad...@orange.com wrote: 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. [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. [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. 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. 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 ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] WG Adoption call for draft-btw-add-ipsecme-ike
I support adoption of the draft. -Tiru On Mon, 8 Nov 2021 at 19:58, wrote: > 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 De la part de Tero Kivinen > > Envoyé : lundi 8 novembre 2021 15:17 > > À : ipsec@ietf.org > > Objet : [IPsec] WG Adoption call for draft-btw-add-ipsecme-ike > > > > 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. > > -- > > kivi...@iki.fi > > > > ___ > > IPsec mailing list > > IPsec@ietf.org > > 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. > > ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] WG Adoption call for draft-btw-add-ipsecme-ike
Hi Paul, Please see inline. Cheers, Med > -Message d'origine- > De : Paul Wouters > Envoyé : mercredi 10 novembre 2021 01:20 > À : BOUCADAIR Mohamed INNOV/NET > Cc : ipsec@ietf.org; draft-btw-add-ipsecme-...@ietf.org; Tero Kivinen > > Objet : Re: [IPsec] WG Adoption call for draft-btw-add-ipsecme-ike > > On Tue, 9 Nov 2021, mohamed.boucad...@orange.com wrote: > > >> 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. > > > > [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. [Med] This is the length of the ENCDNS_IP* attribute. This is used in requests to indicate that the client is requesting this attribute. > > > 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. > > 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. _ 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
Re: [IPsec] WG Adoption call for draft-btw-add-ipsecme-ike
On Tue, 9 Nov 2021, mohamed.boucad...@orange.com wrote: 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. [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. 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. 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] 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] 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. 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 ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] WG Adoption call for draft-btw-add-ipsecme-ike
Hi Paul, Please see inline. Cheers, Med > -Message d'origine- > De : Paul Wouters > Envoyé : lundi 8 novembre 2021 19:06 > À : BOUCADAIR Mohamed INNOV/NET > Cc : Tero Kivinen ; ipsec@ietf.org > Objet : Re: [IPsec] WG Adoption call for draft-btw-add-ipsecme-ike > > On Mon, 8 Nov 2021, mohamed.boucad...@orange.com wrote: > > >> 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: > > > > == > > 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". > > > > 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. [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. > > > 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. > > 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] 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 serv
Re: [IPsec] WG Adoption call for draft-btw-add-ipsecme-ike
On Mon, 8 Nov 2021, mohamed.boucad...@orange.com wrote: 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: == 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". 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. 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. 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. 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. 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 ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] WG Adoption call for draft-btw-add-ipsecme-ike
Hi Paul, Please see inline. Cheers, Med > -Message d'origine- > De : IPsec De la part de Paul Wouters > Envoyé : lundi 8 novembre 2021 16:20 > À : Tero Kivinen > Cc : ipsec@ietf.org > Objet : Re: [IPsec] WG Adoption call for draft-btw-add-ipsecme-ike > > On Mon, 8 Nov 2021, Tero Kivinen wrote: > > > Subject: [IPsec] WG Adoption call for draft-btw-add-ipsecme-ike > > > > 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. > > 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. [Med] Thanks. The format can always be updated to reflect the feedback from the WG. > > 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: == 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. > > Paul > > ___ > IPsec mailing list > IPsec@ietf.org > 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. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] WG Adoption call for draft-btw-add-ipsecme-ike
On Mon, 8 Nov 2021, Tero Kivinen wrote: Subject: [IPsec] WG Adoption call for draft-btw-add-ipsecme-ike 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. 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 ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] WG Adoption call for draft-btw-add-ipsecme-ike
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 De la part de Tero Kivinen > Envoyé : lundi 8 novembre 2021 15:17 > À : ipsec@ietf.org > Objet : [IPsec] WG Adoption call for draft-btw-add-ipsecme-ike > > 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. > -- > kivi...@iki.fi > > ___ > IPsec mailing list > IPsec@ietf.org > 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. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] WG Adoption call for draft-btw-add-ipsecme-ike
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. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
