Subject: [Add] Network VPN vs Device VPN with Discovery

From: "Vinny Parla (vparla)" <[email-masked]>
Date: Fri, 11 Sep 2020 16:33:01 +0000

Hi,

During the IETF interim the topic of VPN came up a few times.  We should think 
about Network VPNs and Device VPNs as they both present a different set of 
problems in terms of a Discovery solution.

As an example, a CVO (a network VPN device used at home to connect you to your 
enterprise) often use DNS (Do53) to perform routing decisions.

If the CVO were to support DoH and advertise its DoH services to endpoint 
devices, but those endpoint devices chose not use the discovered DoH services 
for *.myenterprise.com domain(s) there would be a few problems depending on 
policy configuration and implementation.

1) The CVO might not route any traffic to the enterprise if the routing engine 
was using DNS as a policy routing framework.
2) The CVO might unintentionally route all the users traffic, including 
personal traffic to the enterprise network if the default policy is route all
     (clearly an undesirable outcome for privacy)
3) May continue to function if routing policy is split-include based 
exclusively on IP addressing and there are no ISP-NAT issues between the CVO 
and the enterprise and the endpoint can somehow correctly resolve private 
address space within the enterprise.

To me it is unclear how Discovery will impact the above use case and if others 
had thoughts on how this would work.

Thanks,

-Vinny

---

From: Paul Wouters <[email-masked]>
Date: Fri, 11 Sep 2020 12:43:36 -0400 (EDT)

On Fri, 11 Sep 2020, Vinny Parla (vparla) wrote:

> Subject: [Add] Network VPN vs Device VPN with Discovery

> had thoughts on how this would work.

Please read RFC 8598

https://datatracker.ietf.org/doc/rfc8598/

The issue is not different from classic DNS servers versus encrypted DNS
servers.

Paul

---

From: "Vinny Parla (vparla)" <[email-masked]>
Date: Fri, 11 Sep 2020 16:49:30 +0000

Hi,
I think it is slightly different in that with classic DNS, the CVO device
can inspect and redirect DNS traffic destined for enterprise to the
enterprise resolvers. This is done by looking for requests with
*.myenterprise.com targeting the enterprise domain space.

-Vinny

-----Original Message-----
From: Add <[email-masked]> On Behalf Of Paul Wouters
Sent: Friday, September 11, 2020 12:44 PM
To: Vinny Parla (vparla) <vparla=[email-masked]>
Cc: ADD Mailing list <[email-masked]>
Subject: Re: [Add] Network VPN vs Device VPN with Discovery

> During the IETF interim the topic of VPN came up a few times.  We 
> should think about Network VPNs and Device VPNs as they both present a 
> different set of problems in terms of a Discovery solution.
>
> If the CVO were to support DoH and advertise its DoH services to 
> endpoint devices, but those endpoint devices chose not use the 
> discovered DoH services for *.myenterprise.com domain(s) there would 
> be a few problems depending on policy configuration and implementation.
>
> 1) The CVO might not route any traffic to the enterprise if the 
> routing engine was using DNS as a policy routing framework.
> 2) The CVO might unintentionally route all the users traffic, 
> including personal traffic to the enterprise network if the default policy
is route all
> exclusively on IP addressing and there are no ISP-NAT issues between 
> the CVO and the enterprise and the endpoint can somehow correctly 
> resolve private address space within the enterprise.
>
> To me it is unclear how Discovery will impact the above use case and 
> if others had thoughts on how this would work.

Please read RFC 8598

Paul

--
Add mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/add

---

From: Paul Wouters <[email-masked]>
Date: Fri, 11 Sep 2020 13:16:48 -0400 (EDT)

> *.myenterprise.com targeting the enterprise domain space.

In both cases, the DNS subsystem is reconfigured by the VPN layer
when the connection establishes, and unconfigured when the
VPN connection goes down.

How the DNS subsystem implements this, does not really matter I think ?

Paul

---

From: "Vinny Parla (vparla)" <[email-masked]>
Date: Fri, 11 Sep 2020 20:29:55 +0000

Hi,

I am not doing a good job of explaining the difference here or conversely
not understanding your response. 
Let me state this differently where I can better convey the problem.

[Client]---[CVO]--------------[ISP RTR]------------(internet)
                      |==========[ISP RTR]=======(enterprise network)

In classic DNS, no matter what the client has accepted/configured for its
DNS, the CVO device is able to see all the DNS requests.
It therefore can still route enterprise targeted traffic to the enterprise
if that (CVO) device supports DNS-policy-based-routing.
The policy simply is 'Route all DNS with *.mycompany.com over CVO tunnel to
the enterprise-configured resolvers for an authoritative answer'
Returned IP addresses are then whatever answers are given by the enterprise
resolvers (likely NAT'd).
Those set of (likely NAT'd) IP addresses are then sent over the tunnel.  All
other traffic is sent outside the tunnel.

For this to continue to function, the client would need to accept the DoH
server hosted on the CVO device and 'advertised/discovered' for resolving
*.mycompany.com.

Does this explain the scenario below any better?
-Vinny

-----Original Message-----
From: Paul Wouters <[email-masked]> 
Sent: Friday, September 11, 2020 1:17 PM
To: Vinny Parla (vparla) <[email-masked]>
Cc: ADD Mailing list <[email-masked]>
Subject: Re: [Add] Network VPN vs Device VPN with Discovery

On Fri, 11 Sep 2020, Vinny Parla (vparla) wrote:

> I think it is slightly different in that with classic DNS, the CVO 
> device can inspect and redirect DNS traffic destined for enterprise to 
> the enterprise resolvers. This is done by looking for requests with 

In both cases, the DNS subsystem is reconfigured by the VPN layer when the
connection establishes, and unconfigured when the VPN connection goes down.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Fri, 11 Sep 2020 19:47:46 -0400 (EDT)

> Does this explain the scenario below any better?

Maybe I don't understand what a CVO device is?

> enterprise) often use DNS (Do53) to perform routing decisions.

I presumed this was a laptop or phone. That is the device that is
setting up a VPN is the actual device, and not some other mediating
device.

In the new diagram above, you have client ----> CVO

Do you mean that "client" is the laptop/phone and CVO is some other
device?

Or do you believe that CVO is the laptop/phone, but "client" is the
application, like a browser running on that device?

I believe for phones and laptops, you would configure the OS DNS
service and applications either use that or use some mechanism to
ask the OS for the service. I understand browsers are now in the
market to ignore the OS when possible (eg firefox) but than for
those browsers to work with VPNs they will need to become aware
and offer a way to receive signaling from a VPN service. Such
signal would follow the split-DNS RFC requirements, such as listing
which domains to resolve with which (encrypted) DNS servers.

Once applications do that, the "CVO" should not need to listen in
to the encrypted DNS stream.

Paul

---

From: "Vinny Parla (vparla)" <[email-masked]>
Date: Fri, 11 Sep 2020 23:56:06 +0000

Hi Paul,

CVO is a router.

-Vinny

-----Original Message-----
From: Add <[email-masked]> On Behalf Of Paul Wouters
Sent: Friday, September 11, 2020 7:48 PM
To: Vinny Parla (vparla) <[email-masked]>
Cc: ADD Mailing list <[email-masked]>
Subject: Re: [Add] Network VPN vs Device VPN with Discovery

On Fri, 11 Sep 2020, Vinny Parla (vparla) wrote:

> I am not doing a good job of explaining the difference here or 
> conversely not understanding your response.
> In classic DNS, no matter what the client has accepted/configured for 
> its DNS, the CVO device is able to see all the DNS requests.
> It therefore can still route enterprise targeted traffic to the 
> enterprise if that (CVO) device supports DNS-policy-based-routing.
> The policy simply is 'Route all DNS with *.mycompany.com over CVO 
> tunnel to the enterprise-configured resolvers for an authoritative answer'
> Returned IP addresses are then whatever answers are given by the 
> enterprise resolvers (likely NAT'd).
> Those set of (likely NAT'd) IP addresses are then sent over the 
> tunnel.  All other traffic is sent outside the tunnel.
>
> For this to continue to function, the client would need to accept the 
> DoH server hosted on the CVO device and 'advertised/discovered' for 
> resolving *.mycompany.com.
>

> enterprise) often use DNS (Do53) to perform routing decisions.

I presumed this was a laptop or phone. That is the device that is setting up
a VPN is the actual device, and not some other mediating device.

Do you mean that "client" is the laptop/phone and CVO is some other device?

I believe for phones and laptops, you would configure the OS DNS service and
applications either use that or use some mechanism to ask the OS for the
service. I understand browsers are now in the market to ignore the OS when
possible (eg firefox) but than for those browsers to work with VPNs they
will need to become aware and offer a way to receive signaling from a VPN
service. Such signal would follow the split-DNS RFC requirements, such as
listing which domains to resolve with which (encrypted) DNS servers.

Once applications do that, the "CVO" should not need to listen in to the
encrypted DNS stream.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Fri, 11 Sep 2020 20:09:38 -0400 (EDT)

> CVO is a router.

Okay, so the CVO is the VPN endpoint. The Client is not even aware it is
connected via a VPN. Clearly it should use the CVO as its DNS recursive
server. And if you want that to be encrypted (which seems a bit silly,
as you are either on a switched ethernet or on a WPA encrypted
connection to the CVO) your CVO should advertise its encrypted DNS
recursive resource to the client like a "regular" DNS recursive
server. You then get two or more encrypted DNS channels. One from client
to CVO. One from CVO to across the VPN DNS servers. and optionally
one from CVO to some trusted encrypted DNS server for the public
internet.

So this VPN setup does not need any specific handling or protocols
compared to regular encrypted recursive DNS server discovery protocols.

Paul

---

From: "Vinny Parla (vparla)" <[email-masked]>
Date: Sat, 12 Sep 2020 00:10:36 +0000

Let me add that for the sake of this discussion (although it can work a
couple of different ways) 
   - we can simply classify this as DNS forwarder in terms of other use
cases I have seen on this thread.

The 'forwarder' is splitting DNS between public and private (enterprise)
paths.

-Vinny

-----Original Message-----
From: Vinny Parla (vparla) 
Sent: Friday, September 11, 2020 7:56 PM
To: Paul Wouters <[email-masked]>
Cc: ADD Mailing list <[email-masked]>
Subject: RE: [Add] Network VPN vs Device VPN with Discovery

Hi Paul,

CVO is a router.

-Vinny

-----Original Message-----
From: Add <[email-masked]> On Behalf Of Paul Wouters
Sent: Friday, September 11, 2020 7:48 PM
To: Vinny Parla (vparla) <[email-masked]>
Cc: ADD Mailing list <[email-masked]>
Subject: Re: [Add] Network VPN vs Device VPN with Discovery

Paul

---

From: "Vinny Parla (vparla)" <[email-masked]>
Date: Sat, 12 Sep 2020 00:28:34 +0000

Hi Paul,

Thanks for your detailed response.

Others have maintained the view that the threat model would not let you
distinguish between knowing you are behind the safety of the trustworthy
network device or not (e.g. from an endpoint view the threat looks the
same).  
So I am simply trying to figure out how to work within that model and the
proposed discovery protocol.

Thanks,

-Vinny

-----Original Message-----
From: Paul Wouters <[email-masked]> 
Sent: Friday, September 11, 2020 8:10 PM
To: Vinny Parla (vparla) <[email-masked]>
Cc: ADD Mailing list <[email-masked]>
Subject: Re: [Add] Network VPN vs Device VPN with Discovery

Okay, so the CVO is the VPN endpoint. The Client is not even aware it is
connected via a VPN. Clearly it should use the CVO as its DNS recursive
server. And if you want that to be encrypted (which seems a bit silly, as
you are either on a switched ethernet or on a WPA encrypted connection to
the CVO) your CVO should advertise its encrypted DNS recursive resource to
the client like a "regular" DNS recursive server. You then get two or more
encrypted DNS channels. One from client to CVO. One from CVO to across the
VPN DNS servers. and optionally one from CVO to some trusted encrypted DNS
server for the public internet.

So this VPN setup does not need any specific handling or protocols compared
to regular encrypted recursive DNS server discovery protocols.

Paul

device.
device?
> service and applications either use that or use some mechanism to ask 
> the OS for the service. I understand browsers are now in the market to 
> ignore the OS when possible (eg firefox) but than for those browsers 
> to work with VPNs they will need to become aware and offer a way to 
> receive signaling from a VPN service. Such signal would follow the 
> split-DNS RFC requirements, such as listing which domains to resolve with
which (encrypted) DNS servers.
>
> Once applications do that, the "CVO" should not need to listen in to 
> the encrypted DNS stream.
>
> Paul
>
> --
> Add mailing list
> [email-masked]