Re: [IPsec] WG Adoption call for draft-btw-add-ipsecme-ike

[Paul Wouters <[e-mail]>]

On Mon, 8 Nov 2021, [e-mail] 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