Hi Tero, > -- > >From section 3.2 > > If the CFG_REQUEST included INTERNAL_DNS_DOMAIN attributes with non- > zero lengths, the CFG_REPLY MUST NOT assign any domains in its > INTERNAL_DNS_DOMAIN attributes that are not contained within the > requested domains. The initiator SHOULD ignore any domains beyond > its requested list. > > This whole thing about restricting the subdomains server can send by > sending the list from client is different than what we normally do. In > normal case the client sends list of suggestions for the configuration > values to the server. Here the client forces server to do something. > > I think it would be better to say that client can send list of dns > names it would like to be included, and server can then reply whatever > list it has in its configuration, and client is free to ignore as many > of the items from the list it likes. > > This way if you have originally configured company1.com to the > internal dns names, and then company decides to buy another company > called company2.com, teh client can still request company1.com and > server can return both company1.com and company2.com in its reply. > Then it is up to the client whether it will belive the list or not.
Why the client would ever not believe to the information from the authenticated server? I'd go further and say that the initiator MUST use the received internal DNS servers for all the requests within the received INTERNAL_DNS_DOMAIN (as you proposed before). > In section 6: > > If a host connected to an authenticated IKE peer is connecting to > another IKE peer that attempts to claim the same domain via the > INTERNAL_DNS_DOMAIN attribute, the IKE connection should be > terminated. > > Which of the IKE connection should be terminated? Perhaps the first > connection has died and user tried to reconnect to the same server, > which will of course give the same INTERNAL_DNS_DOMAIN. Tearing down > that new connection and not allowing it to be formed until the first > one is timed out is bit annoying. I think that tearing down a connection in this case is wrong and inconsistent with Redirect Mechanism for IKEv2 (RFC5685). There could be several VPN gateways protecting the internal network and the client can be redirected from one to another (or even have a concurrent IKE SAs in case of load sharing scenario). > If the IP address value of the received INTERNAL_IP4_DNS or > INTERNAL_IP6_DNS attribute is not covered by the proposed IPsec > connection, then the local DNS should not be reconfigured until a > CREATE_CHILD Exchange is received that covers these IP addresses. > > I think this is dangerous. I.e. if the server returns INTERNAL_IP4_DNS > of 10.0.0.1 and INTERNAL_DNS_DOMAIN of example.com, but initial Child > sa connection fails for some reason (out of resources). Next the email > client trying to resolve the mail.example.com goes out to the external > dns servers to find the name, instead of trying to use 10.0.0.1 dns > server. Note, that when it tries to send packet to 10.0.0.1, then the > IPsec will simply trigger for that packet, and will create the Child > SA needed... > > So I think the DNS configuration should be done immediately, > regardless whether the Child SA to cover those IP address is there. > In properly configured system the IP-address will then trigger the SA > to be created when they are first time used. I completely agree here. As with internal IP address assignment the failure to create IPsec SA is not a reason not to configure internal DNS servers. Regards, Valery. _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
