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

[[e-mail]]

Hi Paul,

Please see inline. 

Cheers,
Med


Orange Restricted

> -----Message d'origine-----
> De : Paul Wouters <[e-mail]>
> Envoyé : mercredi 10 novembre 2021 23:24
> À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>
> Cc : Paul Wouters <[e-mail]>; [e-mail]; draft-btw-add-
> [e-mail]; Tero Kivinen <[e-mail]>
> Objet : Re: [IPsec] WG Adoption call for draft-btw-add-ipsecme-ike
> 
> 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.
> 

[Med] Zero-length is allowed for other configuration attributes, e.g., 

   o  SUPPORTED_ATTRIBUTES - When used within a Request, this attribute
      MUST be zero-length and specifies a query to the responder to
      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
      reply back with all of the attributes that it supports.

It is also allowed for INTERNAL_IP*_DNS:  

   o  INTERNAL_IP4_ADDRESS, INTERNAL_IP6_ADDRESS - An address on the
      internal network, sometimes called a red node address or private
      address, and it MAY be a private address on the Internet.  In a
      request message, the address specified is a requested address (or
      a zero-length address if no specific address is requested).
      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

We didn't include a suggested ADN/@ in the proposed ENCDNS_IP* for the sake of simplicity. We are open to relax this if the WG sees so. 

> 
> >> 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.

[Med] I still don't see why you think the document updates RFC 7296.  

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.