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 -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
