On Thu, 12 Jan 2017, Valery Smyslov wrote:
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).
Opportunistic IPsec means that we want to encrypt to those endpoints,
but we have zero trust in them, and we don't allow them to set many
of the IKE/IPsec features that we might allow when we are configured
as a classic access vpn.
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).
That's a good point. I have to think about how to write text that
supports these trusted scenario's versus more untrusted scenarios.
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.
Let me talk to Tommy about this.
We'll bring these issues up for discussion in Chicago in two weeks.
Paul
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
