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
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
