On Tue, 9 Nov 2021, mohamed.boucad...@orange.com wrote:
Note that what I said there was that you should not update the _mechanism_
of how CFG requests/responds are done. You should use the existing
mechanism with a new value, but use the same negotation mechanism.
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.
That is changing the mechanism.
What I was saying in my last email was that making a protocol update where
a server receiving a INTERNAL_IP4_DNS may choose not to return any
INTERNAL_IP4_DNS is an update to the protocol that would require the
Updates: clause to warn implementers to read this document too, as it
updates older RFC text.
[Med] OK.
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] Older clients can always ask for INTERNAL_IP6_DNS or
INTERNAL_IP4_DNS. We will update the note to make this clearer.
They can indeed. So I think you should just stick with the CFG
request/response semantics and not talk about omitting INTERNAL_IP*_DNS
replies if the client asks for those via CFG. This way, the ENC_DNS*
payloads are simply defined as new CFG options, and clients and servers
will do the right thing when encountering them. And it requires no
Updates: clause because it does not modify the behaviour with respect to
INTERNAL_IP*_DNS. You might want to say a client SHOULD prefer ENC_DNS*
servers over INTERNAL_IP*_DNS servers.
[Med] That's one approach. The one we have in the draft is to enforce a policy
at the responder side:
The behavior of the responder if it receives both ENCDNS_IP* and
INTERNAL_IP6_DNS (or INTERNAL_IP4_DNS) attributes is policy-based
and deployment-specific. However, it is RECOMMENDED that if the
responder includes at least one ENCDNS_IP* attribute in the reply,
it should not include any of INTERNAL_IP4_DNS/INTERNAL_IP6_DNS
attributes.
This policy allows for more control vs. providing both to the client + let the
client decide.
The client can just omit asking for ENCDNS_IP* to get INTERNAL_IP*_DNS
anyway. I don't think the policy should be encoded in how we return
Configuration Payload information. If you want to convey policy, you
should make it part of the CFG payload.
This is an item for discussion/agreement when the document is adopted. Point
recorded. Thanks.
We don't need to wait for adoption to discuss this. Others can chime in any
time :)
Paul
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
