Hi Tero, Please see inline. Cheers, Med > -----Message d'origine----- > De : Tero Kivinen <kivinen@xxxxxx> > Envoyé : vendredi 17 mars 2023 14:29 > À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@xxxxxxxxxx> > Cc : Patrick Mevzek <ietf-datatracker@xxxxxxxxxxxxxxxx>; > dnsdir@xxxxxxxx; draft-ietf-ipsecme-add-ike.all@xxxxxxxx; > ipsec@xxxxxxxx; last-call@xxxxxxxx > Objet : RE: Dnsdir last call review of draft-ietf-ipsecme-add-ike- > 09 > > mohamed.boucadair@xxxxxxxxxx writes: > > > At the IETF process level, which I don't master, because of > last > > > note in §4, shouldn't that document explicitly say it updates > > > RFC8598? > > > > [Med] We discussed this point at the time (and I was personally > for > > adding the header), but we didn't because the convention in > ipsecme WG > > is to not add the Update header if implementations are clearly > able to > > distinguish the cases when an extension is being used even if > the > > extension would change the behavior defined in the existing > RFCs. In > > this spec, if the initiator receives any of ENCDNS_IP* > attributes, it > > will know that it should not expect the INTERNAL_IP*_DNS even if > it > > receives INTERNAL_DNS_DOMAIN too. The note you are referring to > is to > > make that clear. > > I think we usually use updates header if implementations > supporting old RFC but not this, needs to change their behavior. > > I.e., if we just add new attributes, and the implementations of > old RFC simply ignore them then everything is fine. > > But my understanding is that this is not the case here, as if you > send INTERNAL_DNS_DOMAIN without INTERNAL_IP*_DNS but with > ENCDNS_IP* to implementations supporting old RFC, [Med] Responders know when it will break. They will basically supply the encrypted DNS to initiators who indicated support as per: Initiators first indicate support for encrypted DNS by including ENCDNS_IP* attributes in their CFG_REQUEST payloads. Responders supply encrypted DNS configuration by including ENCDNS_IP* attributes in their CFG_REPLY payloads. If responders decide to ignore the capabilities of the initiators, returning **only** the ENCDNS_IP* won't break only split horizon but the full DNS service! then that RFC > will consider this as a fatal error, and tear down the whole IKE > SA, instead of silently ignoring ENCDNS_IP* and > INTERNAL_DNS_DOMAIN attributes. > > So in this case it would be better for the old Split DNS > Configuration for IKEv2 RFC8598 implementations to be changed in a > way that they recognize this situation and do not consider it as a > fatal error. > > Update to the RFC8598 would not be needed if the RFC8598 > implementations would simply ignore both the INTERNAL_DNS_DOMAIN > and > ENCDNS_IP* in configuration payload, but I do not think that is > the case here. > > So question is not whether it is possible to recognize the > situation, it is what happens when you combine new and old > implementations. If things works without a need to change old > implementations then no updates is needed, if you need to update > the old implentations too, then you do need updates header. > -- > kivinen@xxxxxx _________________________________________________________________________________________________________________________ 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. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
