Subject: Re: [IPsec] Review of draft-pauly-ipsecme-split-dns-02

From: Paul Wouters <[email-masked]>
Date: Mon, 13 Mar 2017 08:56:58 -0400 (EDT)

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

---

From: Paul Wouters <[email-masked]>
Date: Mon, 13 Mar 2017 09:38:07 -0400 (EDT)

On Tue, 10 Jan 2017, Tero Kivinen wrote:

>
> In the section 1 there is text:
>
>       	       The client device
>   can use the internal DNS server(s) for any DNS queries within the
>   assigned domains, while routing other DNS queries to its regular
>   external DNS server.
>
> which would indicate that we can also use internal dns servers for
> other DNS queries too.

Clarified.

> Then on section 5 there is text saying:
>
>     		  	All other domain
>   names MUST be resolved using some other external DNS resolver(s),
>   configured independently, and SHOULD NOT be sent to the internal DNS
>   resolver(s) listed in that CFG_REPLY message.
>
> This is bit confusing. First of all all other domain names MUST use
> external DNS servers, but then the requirement for ont using internal
> DNS is only SHOULD NOT.

> What is what we want there. Do we want to have clear splitting of the
> DNS servers, i.e. all request for internal names go to the internal
> servers, and never external ones, and do we want all request to
> external names go to the external servers, and never internal ones.
>
> I think the 1st point (I.e. all requests about internal names go to
> the internal servers) is something that is important for security, so
> it should perhaps be MUST.

Ok, I agree with your point here.

> On the other hand the 2nd point is not about security. Quite often
> people can and want to use internal DNS server even for external DNS
> requests. So I think that should be allowed in both ways, i.e.,
> external DNS names can be asked from either internal or external name
> servers, or even both.

Here I don't agree as much. I think it is a privacy issue if you run
a split-net setup and start sending all your queries to your internal
network. Also, you assume that the network is a trusted remote peer
like a corporation. But these days we have many kinds of IPsec tunnels.
Eg, if I watch netflix and use VPN, I really don't trust them with my
DNS queries other then those needed to watch TV.

I'll think about some text for this.

>> 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.
>

I ran into this issue too when implementing. I realised that there is
really no reason for the server to ever act on what the client sends.
So I wondered if we should send it at all. It seems we might as well
not send anything to the server, and when the server gives us a list,
filter it based on what we will accept. This could be different based
on the kind of ipsec tunnel (corporate vs free proxy)

> In section 4.2 it would be useful to repeat the fact that the bytes
> after the Length match the DNS wire format of a DS record as specified
> in [RFC4034]. The bytes match, but we repeat the definition from the
> RFC4034, so it would be good idea to also explictly say it here, and
> not only in section 3.2.

Okay, will add.

> --
>
> In section 5 the text:
>
>   For each INTERNAL_DNS_DOMAIN entry in a CFG_REPLY payload, the client
>   SHOULD use the provided INTERNAL_IP4_DNS or INTERNAL_IP6_DNS DNS
>   servers as the only resolvers for the listed domains and its sub-
>   domains and it SHOULD NOT attempt to resolve the provided DNS domains
>   using its external DNS servers.
>
> Why is that only SHOULD. I mean if there is INTERNAL_DNS_DOMAIN
> specified, shouldn't the client be following it? So why it is not
> MUST? And in which cases the SHOULD can be broken? What are the
> exceptions where internal domains can be resolved from the outside dns
> servers (or actually failed to be resolved).

Yes, same point you raised above. I agree.

>   If the initiator host is configured to block DNS answers containing
>   IP addresses from special IP address ranges such as those of
>   [RFC1918], the initiator SHOULD allow the DNS domains listed in the
>   INTERNAL_DNS_DOMAIN attributes to contain these IP addresses.
>
> I think this is wrong. I think we should say that it should not block
> any addresses which are part of the configured INTERNAL_IP*_SUBNETS.
> I.e., if the vpn is not configured to pass packets to 10.0.0.0/8
> network, then blocking those DNS answers is still fine.

Agreed. Fixed.

>   If a CFG_REPLY contains one or more INTERNAL_DNS_DOMAIN attributes,
>   the client SHOULD configure its DNS resolver to resolve those domains
>   and all their subdomains using only the DNS resolver(s) listed in
>   that CFG_REPLY message.
>
> Again why only SHOULD? When should it ignore the instructions from the
> server?

Same but I need to think a little further on how to rewrite this.

> 		If those resolvers fail, those names SHOULD
>   NOT be resolved using any other DNS resolvers.
>
> Should this also be MUST NOT?

Yes, same issue.

>       	    All other domain
>   names MUST be resolved using some other external DNS resolver(s),
>   configured independently, and SHOULD NOT be sent to the internal DNS
>   resolver(s) listed in that CFG_REPLY message.
>
> This was already in my previous comment.

Yup.

> --
>
>     	 	    For example, if the
>   INTERNAL_DNS_DOMAIN attribute specifies "example.com", then
>   "example.com", "www.example.com" and "mail.eng.example.com" MUST be
>   resolved using the internal DNS resolver(s), but "anotherexample.com"
>   and "ample.com" MUST be resolved using the system's external DNS
>   resolver(s).
>
> But then in the example there is only MUSTs....

yup yup.

>   When an IPsec connection is terminated, the DNS forwarding must be
>   unconfigured.  The DNS forwarding itself MUST be be deleted.  All
>   cached data of the INTERNAL_DNS_DOMAIN provided DNS domainis MUST be
>   flushed.  This includes negative cache entries.  Obtained DNSSEC
>   trust anchors MUST be removed from the list of trust anchors.  The
>
> This might cause security issues. I.e., if you have mail.example.com
> resolved using internal dns server to have IP-address of 10.0.0.1, and
> then someone manages to tear down the VPN connection, and suddenly all
> these mappings go away, the next time your mail client tries to fetch
> email, it does mail.example.com lookup using external DNS servers, and
> will get IP-address of 1.1.1.1 from ns.evil.org, then then it will
> connect to wrong mail server...

If you are afraid of this attack, deploy DNSSEC on your domain.

> Perhaps we should keep the mappings for some time, just in case the
> connection comes back few seconds later when the vpn reconnects...

I switch regularly from redhat.com to public, and that would really
cause me problems. It is really important to wipe all the now
unreachable cached DNS data.

If you wish to stall for a few seconds, I'd recommend you would be
dropping the DNS packets instead of lingering old state, and I would
say that is a pure local implementation issue and shouldn't go into
the RFC.

>   A domain that is served via INTERNAL_DNS_DOMAIN MUST NOT have
>   indirect references to DNS records that point to other Split DNS
>   domains that are not served via INTERNAL_DNS_DOMAIN attributes.
>   Indirect reference RRtypes include CNAME, DNAME, MX and SRV RR's.
>
> How this going to be done?
>
> I.e., how do you convince the system adminstrator of the company1.com
> that adding mail.company2.com CNAME mail.company1.com is against RFC,
> and must not be done until all clients are configured to ask
> company1.com and company2.com internal dns domains?
>
> I think we can put that text in the security consideration section and
> say that adminstrators should take care that the CNAMES etc used in
> the internal domains, do not leak out to wrong domain names or
> something.

Sounds good. Will make the change.

> one is timed out is bit annoying.

I agree this problem needs some better consideration. I had only thought
of the malicious case, but you are right we might hit some legitimate
case.

>   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...
>

Let's talk in Chicago about this. I see you point but I'm not yey
persuaded this is the way to go.

Paul

---

From: "Hu, Jun (Nokia - US)" <[email-masked]>
Date: Mon, 13 Mar 2017 19:57:06 +0000

> I ran into this issue too when implementing. I realised that there is really no
> reason for the server to ever act on what the client sends.
> So I wondered if we should send it at all. It seems we might as well not send
> anything to the server, and when the server gives us a list, filter it based on
> what we will accept. This could be different based on the kind of ipsec tunnel
> (corporate vs free proxy)

[HJ] I think it is most flexible to still allow client to send what it want in CFG_REQUEST, but it is up to gateway's local policy to decide if it should consider or ignore them; 
For example, the INTERNAL_DNS_DOMAIN could be used by gateway as additional hints for which DNS server address to return in case a gateway is serving multiple types of clients, each has its own internal domains to be resolved via its own DNS sever;
Same applies to CFG_REPLY, it is up to client's local policy to decide whether to accept or ignore. 

In section 3.2,  "If the CFG_REQUEST did not contain an
   INTERNAL_DNS_DOMAIN attribute, the responder MUST NOT include an
   INTERNAL_DNS_DOMAIN attribute in the CFG_REPLY."

If it is agreed that it is essential local policy for what gateway send or accept, then gateway should be allowed to send INTERNAL_DNS_DOMAIN even when client doesn't include it in the CFG_REQUEST;
According to section 2.19 of RFC7296, "the IRAS MAY also send other attributes that  were not included in CP(CFG_REQUEST)", I think it is a general rule for all configuration attributes

---

From: Paul Wouters <[email-masked]>
Date: Mon, 13 Mar 2017 16:41:28 -0400 (EDT)

> Same applies to CFG_REPLY, it is up to client's local policy to decide whether to accept or ignore.

I think though, that the server should return those attributes even if
the client did not ask for them. I cannot think of a good example where
the client provided values would cause the server to return something
different (as the server should not trust the client to begin with)

> If it is agreed that it is essential local policy for what gateway send or accept, then gateway should be allowed to send INTERNAL_DNS_DOMAIN even when client doesn't include it in the CFG_REQUEST;

But the assumption is, if the client does not support it, there is no
point in the server sending it.

I guess in the old IKEv1/ModeCfg we were more strict. You could not
reply with anything not requested. IKEv2 has relaxed this to say
either side can send anything and the other end just has to ignore
what it does not understand.

> According to section 2.19 of RFC7296, "the IRAS MAY also send other attributes that  were not included in CP(CFG_REQUEST)", I think it is a general rule for all configuration attributes

I guess I'm fine with either approach. Since the base IKEv2 RFC states
any side can send/ignore anything, perhaps it is best to copy that
approach in this document as well?

Paul

---

From: "Hu, Jun (Nokia - US)" <[email-masked]>
Date: Mon, 13 Mar 2017 21:34:50 +0000

> -----Original Message-----
> From: Paul Wouters [mailto:[email-masked]]

> > [HJ] I think it is most flexible to still allow client to send what it
> > want in CFG_REQUEST, but it is up to gateway's local policy to decide
> > if it should consider or ignore them; For example, the
> INTERNAL_DNS_DOMAIN could be used by gateway as additional hints for which
> DNS server address to return in case a gateway is serving multiple types of
> clients, each has its own internal domains to be resolved via its own DNS sever;
> I think though, that the server should return those attributes even if the client
> did not ask for them. I cannot think of a good example where the client
> provided values would cause the server to return something different (as the
> server should not trust the client to begin with)

[HJ] I think Tero's example (company1 bought company2) make sense to me; there could be even case where the company1 wants to change the all domain names to company2, if we allow gateway to return different value, it will make such transition much easier;

Just like today a client could send INTERNAL_IP4_ADDRESS in CFG_REQUEST to indicate its preference to get that address, but it doesn't mean gateway has to honor it;

> > If it is agreed that it is essential local policy for what gateway
> > send or accept, then gateway should be allowed to send
> > INTERNAL_DNS_DOMAIN even when client doesn't include it in the
> > CFG_REQUEST;
> 
> But the assumption is, if the client does not support it, there is no point in the
> server sending it.
> 
> I guess in the old IKEv1/ModeCfg we were more strict. You could not reply with
> anything not requested. IKEv2 has relaxed this to say either side can send
> anything and the other end just has to ignore what it does not understand.
> 
[HJ] if client's doesn't support split DNS, of course it will not send these new CFG attributes, but I don't think we should always assume client doesn't support split DNS if it doesn't include these attributes in CFG_REQUEST

> > According to section 2.19 of RFC7296, "the IRAS MAY also send other
> > attributes that  were not included in CP(CFG_REQUEST)", I think it is
> > a general rule for all configuration attributes
> 
> I guess I'm fine with either approach. Since the base IKEv2 RFC states any side
> can send/ignore anything, perhaps it is best to copy that approach in this
> document as well?
[HJ]  I think we should just follow RFC7296

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 23 Mar 2017 11:14:34 +0200

> If you are afraid of this attack, deploy DNSSEC on your domain.

I most likely would have configfured my internal domain with DNSSEC,
bu tthe DNSSEC trust anchors got deleted when tunnel went down, and
when it revers to external DNS that might or might not be signed
depending whether the top level domain or service provider you are
using supports DNSSEC.

> say that is a pure local implementation issue and shouldn't go into

But the MUST delete DNS forwarding etc will not allow me to do that. 
-- 
[email-masked]

---

From: Paul Wouters <[email-masked]>
Date: Thu, 23 Mar 2017 14:55:36 -0400 (EDT)

> depending whether the top level domain or service provider you are

If you are in a split view, we can't really retain DNS cache. When the
split goes away you would not be able to reach these. For example,
bugzilla.redhat.com has an internal and external IP. If DNS cache is
retaining, when my VPN goes down, I can no longer connect to bugzilla.

So I think my use case trumps your use case because you should just
sign your external DNS too :P

> But the MUST delete DNS forwarding etc will not allow me to do that.

That's semantics :P

If you linger the Child SA, you haven't torn it down yet, so you can
also leave your DNS entries.

Paul