mohamed.boucadair@xxxxxxxxxx writes:
> > 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!
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.
Note, that RFC8598 says that responder must return INTERNAL_IP*_DNS if
INTERNAL_DNS_DOMAIN is present, but if the initiator does not offer
them it can't add them.
Thats why it would be better for even those RFC8598 implementations
which will not support this RFC to be modified so that they will
understand ENCDNS_IP* at least so much that they understand that they
can ignore INTERNAL_DNS_DOMAIN attribute if there is no
INTERNAL_IP*_DNS, and but there is ENCDNS_IP* instead. If they simply
ignore ENCDNS_IP* (is they should, as they do not understand), and
they ignore the INTERNAL_DNS_DOMAIN also because there is no
INTERNAL_IP*_DNS then the initiator will be able to connect. And then
the initiator can later do another configuration payload to fetch
normal DNS servers ip-addresses if those would be acceptable for it.
Or, have I misunderstood the protocol somehow. I.e., what should old
responder implementation do when it receives the request like above?
--
kivinen@xxxxxx
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
