Re: [IPsec] New Version Notification for draft-ietf-ipsecme-add-ike-04.txt
On Mon, 12 Sep 2022, mohamed.boucad...@orange.com wrote: Thanks for the feedback. The initial reasoning was to be tolerant to some misbehaving initiators that might send a mix of empty and no empty attributes (which is odd) and for which empty attribute will win because we do already have: " If the initiator does not want to request specific DNS resolvers, it sets the Length field to 0 for the attribute." We can consider changing the text to "(i.e., the attributes are all distinct non-empty attributes)", but then we need to say explicitly what a responder will do when receiving a request with a mix of attributes: declare the request as malformed? ignore the empty one? ignore the non-empty ones? The responder is allowed to ignore the requester's suggestion in every case anyway, so I am not sure if you need to say anything further? But I would prefer the text to say basically "either send an empty one, or a list of preferred/desired ones" and "respnder answers based on their local policy". I don't think it needs further "SHOULD NOT send empty and non-empty" and "SHOULD ignore if empty and non-empty". Paul Cheers, Med -Message d'origine- De : Paul Wouters Envoyé : vendredi 9 septembre 2022 18:23 À : BOUCADAIR Mohamed INNOV/NET Cc : Valery Smyslov ; ipsec@ietf.org; 'Tero Kivinen' ; draft-ietf-ipsecme-add-...@ietf.org Objet : Re: [IPsec] New Version Notification for draft-ietf- ipsecme-add-ike-04.txt On Fri, 9 Sep 2022, mohamed.boucad...@orange.com wrote: FWIW, I just submitted a new version (-05) to remove the ambiguity about multiple distinct attributes you raised. So the next now states: If the initiator supports encrypted DNS, it includes either or both of the ENCDNS_IP4 and ENCDNS_IP6 attributes in its CFG_REQUEST. If the initiator does not want to request specific DNS resolvers, it sets the Length field to 0 for the attribute. If the initiator sends multiple attributes of a particular type in the request, all of them MUST be distinct (i.e., at most one attribute can be empty while the other remaining attributes are all distinct non-empty attributes). The initiator MAY send one or more attributes that include addresses and/or ADN values to request specific resolvers. Normally, with CP payloads if you request some property with a value, you are requesting the value. If empty, you indicate you accept any value returned. So sending multiple ones in a set that contains an empty one is odd. https://www.rfc-editor.org/rfc/rfc7296.html#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. So to me that still seems that one either sends 1 empty ENCDNS_IP4, or one or more non-empty ones. But not an empty and a non-empty one mixed. The non-empty one already means "suggestion, may receive another value back". 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 mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] New Version Notification for draft-ietf-ipsecme-add-ike-04.txt
Re-, OK, let's then test this change: https://tinyurl.com/add-ike-latest. Better? I don't think we need to touch the responder side as we already gave a provision to accommodate policies. Cheers, Med > -Message d'origine- > De : Paul Wouters > Envoyé : lundi 12 septembre 2022 14:45 > À : BOUCADAIR Mohamed INNOV/NET > Cc : Paul Wouters ; Valery Smyslov > ; ipsec@ietf.org; 'Tero Kivinen' ; > draft-ietf-ipsecme-add-...@ietf.org > Objet : Re: [IPsec] New Version Notification for draft-ietf- > ipsecme-add-ike-04.txt > > On Mon, 12 Sep 2022, mohamed.boucad...@orange.com wrote: > > > Thanks for the feedback. > > > > The initial reasoning was to be tolerant to some misbehaving > initiators that might send a mix of empty and no empty attributes > (which is odd) and for which empty attribute will win because we > do already have: > > > > " If the initiator does not want to request specific DNS > resolvers, > > it sets the Length field to 0 for the attribute." > > > > We can consider changing the text to "(i.e., the attributes are > all distinct non-empty attributes)", but then we need to say > explicitly what a responder will do when receiving a request with > a mix of attributes: declare the request as malformed? ignore the > empty one? ignore the non-empty ones? > > The responder is allowed to ignore the requester's suggestion in > every case anyway, so I am not sure if you need to say anything > further? > > But I would prefer the text to say basically "either send an empty > one, or a list of preferred/desired ones" and "respnder answers > based on their local policy". I don't think it needs further > "SHOULD NOT send empty and non-empty" and "SHOULD ignore if empty > and non-empty". > > Paul > > > Cheers, > > Med > > > >> -Message d'origine- > >> De : Paul Wouters Envoyé : vendredi 9 > >> septembre 2022 18:23 À : BOUCADAIR Mohamed INNOV/NET > >> Cc : Valery Smyslov > ; > >> ipsec@ietf.org; 'Tero Kivinen' ; > >> draft-ietf-ipsecme-add-...@ietf.org > >> Objet : Re: [IPsec] New Version Notification for draft-ietf- > >> ipsecme-add-ike-04.txt > >> > >> On Fri, 9 Sep 2022, mohamed.boucad...@orange.com wrote: > >> > >>> FWIW, I just submitted a new version (-05) to remove the > >> ambiguity about multiple distinct attributes you raised. > >> > >> So the next now states: > >> > >>If the initiator supports encrypted DNS, it includes > either or > >>both of the ENCDNS_IP4 and ENCDNS_IP6 attributes in its > >>CFG_REQUEST. If the initiator does not want to request > >> specific > >>DNS resolvers, it sets the Length field to 0 for the > >> attribute. > >>If the initiator sends multiple attributes of a > particular > >> type in > >>the request, all of them MUST be distinct (i.e., at most > one > >>attribute can be empty while the other remaining > attributes > >> are > >>all distinct non-empty attributes). The initiator MAY > send > >> one or > >>more attributes that include addresses and/or ADN values > to > >>request specific resolvers. > >> > >> Normally, with CP payloads if you request some property with a > value, > >> you are requesting the value. If empty, you indicate you accept > any > >> value returned. So sending multiple ones in a set that contains > an > >> empty one is odd. > >> > >> https://www.rfc-editor.org/rfc/rfc7296.html#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. > >> > >> So to me that still seems that one either sends 1 empty > ENCDNS_IP4, > >> or one or more non-empty ones. But not an empty and a non-empty > one > >> mixed. > >> The non-empty one already means "suggestion, may receive > another > >> value back". > >> > >> 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 > n
Re: [IPsec] New Version Notification for draft-ietf-ipsecme-add-ike-04.txt
On Mon, 12 Sep 2022, mohamed.boucad...@orange.com wrote: OK, let's then test this change: https://tinyurl.com/add-ike-latest. Better? I don't think we need to touch the responder side as we already gave a provision to accommodate policies. Yes, both are fine with me. thanks! Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] New Version Notification for draft-ietf-ipsecme-add-ike-04.txt
Re-, Deal! The new version with the changes will be made pubic SOON. Cheers, Med > -Message d'origine- > De : IPsec De la part de Paul Wouters > Envoyé : lundi 12 septembre 2022 15:31 > À : BOUCADAIR Mohamed INNOV/NET > Cc : Paul Wouters ; Valery Smyslov > ; ipsec@ietf.org; 'Tero Kivinen' ; > draft-ietf-ipsecme-add-...@ietf.org > Objet : Re: [IPsec] New Version Notification for draft-ietf- > ipsecme-add-ike-04.txt > > On Mon, 12 Sep 2022, mohamed.boucad...@orange.com wrote: > > > OK, let's then test this change: https://tinyurl.com/add-ike- > latest. Better? > > > > I don't think we need to touch the responder side as we already > gave a provision to accommodate policies. > > Yes, both are fine with me. thanks! > > 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
[IPsec] I-D Action: draft-ietf-ipsecme-add-ike-06.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions WG of the IETF. Title : Internet Key Exchange Protocol Version 2 (IKEv2) Configuration for Encrypted DNS Authors : Mohamed Boucadair Tirumaleswar Reddy Dan Wing Valery Smyslov Filename: draft-ietf-ipsecme-add-ike-06.txt Pages : 14 Date: 2022-09-12 Abstract: This document specifies new Internet Key Exchange Protocol Version 2 (IKEv2) Configuration Payload Attribute Types to assign DNS resolvers that support encrypted DNS protocols, such as DNS-over-HTTPS (DoH), DNS-over-TLS (DoT), and DNS-over-QUIC (DoQ). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-add-ike/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-add-ike-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-add-ike-06 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
