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

[[e-mail]]

Hi Paul, 

Please see inline. 

Cheers,
Med

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

[Med] We are not saying that in the draft. 

 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. 

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

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

This is an item for discussion/agreement when the document is adopted. Point recorded. Thanks. 

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

[Med] Great. Looking forward receiving your text proposal. 


_________________________________________________________________________________________________________________________

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.