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

[Paul Wouters <[e-mail]>]

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