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

[Paul Wouters <[e-mail]>]

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