On Wed, 10 Nov 2021, mohamed.boucad...@orange.com wrote:
So the client sends FOO(x) and the server respones with FOO(y)
x can be empty (eg the client has no previous notion or preference
for FOO. Or if it has one, it can suggest it. The server takes that
value only as a preference of the client, but the server is the one
making the ultimate decsion if it returns "x" or "y".
So your draft should not say the initiator MUST send a zero size
request for FOO.
[Med] We are not saying that in the draft.
Section 3.1 states:
o Length (2 octets, unsigned integer) - Length of the data in
octets. In particular, this field is set to:
* 0 if the Configuration payload has types CFG_REQUEST or
CFG_ACK.
So it says for a CFG_REQUEST the length is 0.
[Med] This is the length of the ENCDNS_IP* attribute. This is used in requests
to indicate that the client is requesting this attribute.
https://datatracker.ietf.org/doc/html/rfc7296#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.
I see no reason why ENCDNS_IP* should do this differently from all the
other CFG attributes, especially INTERNAL_IP*_DNS.
But note that I rather that the responder just responds to the received
CFG requests with CFG replies it supports and has data for. So if the
client asks for INTERNAL_IP4_DNS and ENCDNS_IP4, the responder should
return both with values. I also think that in case the encrypted DNS
fails, it would be good for the IKEv2 client to have the INTERNAL_IP4_DNS
as fallback option. Say if the TLS fails for some reason (incompatible
algorithms, expired TLS certificate, DoH server down, etc)
[Med] The current version allows somehow for this as the behavior is
policy-based. However, I understand that you prefer to systematically return
both and leave the client decide. I can live with this as well.
The policy can be enforced by not returning INTERNAL_IP*_DNS payloads in
the CFG_REPLY. Although if the client did not ask for ENCDNS_IP* and the
server does not return INTERNAL_IP*_DNS, the client would not be able
to get functional DNS.
I still believe the CFG mechanism is to exchange network topology
information, and not network policy. But you can (ab)use it for that
if you want. The protocol allows it without requiring the change
that you suggest that the sender MUST use 0 length. And this requirement
would force your policy onto everyone else who would be happy to let
the client suggest something (eg 8.8.8.8 or 9.9.9.9) and have the
responder maybe accept those as trustworthy.
In short, if this document just defines standard CFG REQUEST/REPLY for
ENCDNS_IP* with no additional restrictions, everyone's use case is
supported AND you don't have to Update: RFC 7296 because no existing
behaviour is changed.
Paul
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
