Hi Paul, Please see inline.
Cheers, Med > -----Message d'origine----- > De : Paul Wouters <paul.wout...@aiven.io> > Envoyé : mercredi 10 novembre 2021 01:20 > À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com> > Cc : ipsec@ietf.org; draft-btw-add-ipsecme-...@ietf.org; Tero Kivinen > <kivi...@iki.fi> > 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
