On Mon, 8 Nov 2021, mohamed.boucad...@orange.com wrote:
Note the text of the draft claims it updates RFC 8598 but doesn't do so
via an Updates: statement.
[Med] We considered to have an "update" header because we were concerned with
some MUSTs in 8598. We finally didn't include the update header because of a comment we
received from you prior to publishing the first version of the draft. FWIW, here is the
exchange we had at that time:
******
Med: I have a question for you: now that we don't depend anymore on
INTERNAL_IP*_DNS and given that a client can be supplied with 8598 attributes
and that 8598 says the following:
==
If an INTERNAL_DNS_DOMAIN attribute is
included in the CFG_REPLY, the responder MUST also include one or
both of the INTERNAL_IP4_DNS and INTERNAL_IP6_DNS attributes in the
CFG_REPLY.
..
the INTERNAL_DNS_DOMAIN attributes in a CFG_REPLY payload form a
single list of Split DNS domains that applies to the entire list of
INTERNAL_IP4_DNS and INTERNAL_IP6_DNS attributes.
==
Should we add an update to our daft to indicate that first "MUST" does not
apply and that the domains are associated with **ANY** supplied server?
Paul: You cannot update that RFC for that kind of processing. The above really says that it makes
no sense to have "internal domains" without providing "internal DNS servers".
****
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. 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.
Also, I think the relaxing of the requirement
is actually wrong, as it might cause lack of interop between newer servers
and older clients not being able to negotiate working DNS if the new
servers no longer serve INTERNAL_IP*_DNS CFG payloads.
[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.
I am also not clear on the real use of negotiating hash algorithms for the
digest receiving of the ADD server "identity?", as the document states the
authentication happens as per Section 8 of [RFC8310] which lists WebPKI or
DANE authentication against the name and these methods do not use this
digest. I also do not understand the use of the digest. For
authentication, is it not needed as the entire IKEv2 exchange is
authenticated.
[Med] We added the digest to address one of the comments raised in a previous
ipsecme meetings: allow to not rely on PKI for validating the encrypted DNS
server certificate but convey the end-entity certificate in IKEv2 itself.
Ah, I see. I would probably use some different terminology then, and
extend the text talking aboyt "as per Section 8 of [RFC8310]" to
clarify that. I'll see about producing some text for you.
Paul
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
