Hi Tero,
> 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.
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).
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.
> 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?
I believe so.
Regards,
Valery.
> --
> kivinen@xxxxxx
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
