On Fri, 9 Sep 2022, [email protected] 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
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
