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 <p...@nohats.ca> > Envoyé : lundi 12 septembre 2022 14:45 > À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com> > Cc : Paul Wouters <paul.wout...@aiven.io>; Valery Smyslov > <s...@elvis.ru>; ipsec@ietf.org; 'Tero Kivinen' <kivi...@iki.fi>; > 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 <paul.wout...@aiven.io> Envoyé : vendredi 9 > >> septembre 2022 18:23 À : BOUCADAIR Mohamed INNOV/NET > >> <mohamed.boucad...@orange.com> Cc : Valery Smyslov > <s...@elvis.ru>; > >> ipsec@ietf.org; 'Tero Kivinen' <kivi...@iki.fi>; > >> 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 > > _________________________________________________________________________________________________________________________ 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
