Hi Paul, 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? 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
