Hi Tero, As you can see at https://tinyurl.com/add-ike-latest, the note is updated as follows: Note: [RFC8598] requires INTERNAL_IP6_DNS (or INTERNAL_IP4_DNS) attribute to be mandatory present when INTERNAL_DNS_DOMAIN is included. This specification relaxes that constraint in the presence of ENCDNS_IP* attributes. That is, if ENCDNS_IP* attributes are supplied, it is allowed for responders to include ^^^^^^^^^^^^^^ INTERNAL_DNS_DOMAIN even in the absence of INTERNAL_IP6_DNS (or INTERNAL_IP4_DNS) attributes. Thanks for zooming into this. I was expecting to have this discussion during the IESG review. We have now a fresh thread to which we can refer :-) Cheers, Med > -----Message d'origine----- > De : Tero Kivinen <kivinen@xxxxxx> > Envoyé : lundi 20 mars 2023 13:56 > À : Valery Smyslov <svan@xxxxxxxx> > Cc : BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@xxxxxxxxxx>; > '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 > > Valery Smyslov writes: > > > I mean if initiator proposes: > > > > > > CP(CFG_REQUEST) = > > > INTERNAL_IP6_ADDRESS() > > > ENCDNS_IP6() > > > ENCDNS_DIGEST_INFO(0, (SHA2-256, SHA2-384, SHA2-512)) > > > INTERNAL_DNS_DOMAIN() > > > > > > to indicate that it only wants to talk ENCDNS server, and it > does > > > NOT want to have normal DNS server, then responder who do not > > > understand > > > ENCDNS_IP6() will see that this is against MUST in RFC8598 and > as > > > there is no other error to use, it will most likely consider > this a > > > malformed message (==fatal error) and return with > INVALID_SYNTAX. > > > This will tear down the IKE SA and does not specify for the > > > initiator why the connection attempt failed. > > > > The initiator cannot force the responder to do anything (e.g. to > > explicitly provide it with the encrypted DNS info). It can only > > indicate support for this feature. So, in my understanding, the > above > > set of configuration attributes indicates some problems with > initiator > > (in which case fatal error is not a bad solution). > > > > The correct request should be: > > > > CP(CFG_REQUEST) = > > INTERNAL_IP6_ADDRESS() > > INTERNAL_IP6_DNS() > > ENCDNS_IP6() > > ENCDNS_DIGEST_INFO(0, (SHA2-256, SHA2-384, SHA2-512)) > > INTERNAL_DNS_DOMAIN() > > > > If the responder doesn't support this extension, it will ignore > > ENCDNS_IP6 and ENCDNS_DIGEST_INFO and return > INTERNAL_IP6_DNS(...) + > > INTERNAL_DNS_DOMAIN(...). > > > > If the responder supports this extension, it will return either > > ENCDNS_IP6(...) + ENCDNS_DIGEST_INFO(..) + > INTERNAL_DNS_DOMAIN(...) or > > INTERNAL_IP6_DNS(...) + INTERNAL_DNS_DOMAIN(...) depending on > its > > configuration (most probably the former). > > This is all clear. > > > If the initiator is configured to allow only encrypted DNS, it > may > > immediately delete IKE SA in case the responder returns > > INTERNAL_IP6_DNS. There is nothing more the initiator can do in > this > > case. > > > > Note, that with this approach there is no room for fatal errors, > all > > protocol paths are legal with no need to update 8598. > > Ok, so the note for RFC8598 behavior only applies to responder, > i.e., responder is allowed return ENCDNS_IP* and > INTERNAL_DNS_DOMAIN without INTERNAL_IP*_DNS but inititiator needs > to send request that contains both. Perhaps the Note about the > RFC8598 should be updated to say "it is allowed for responder to > include INTERNAL_DNS_DOMAIN even in the absense of > INTERNAL_IP6_DNS (or INTERNAL_IP4_DNS) attributes, provided there > is ENCDNS_IP* attributes in the response." or something like that. > > Then I agree that this does not update RFC8598. > -- > 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
