Subject: [secdir] Sec-Dir review of draft-ietf-opsec-vpn-leakages-02

From: "Moriarty, Kathleen" <[email-masked]>
Date: Mon, 9 Dec 2013 17:21:23 -0500

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

The document is almost ready for publication, but could benefit from proving better descriptions in the introduction of the work.  The Security Considerations probably has the most crisp statement of the draft purpose.

The reference to VPN, never distinguishes if the document is referring to an IPSec or TLS VPN.  I suspect IPSec from the document, but making this clear would be helpful to the reader.  TLS has become popular when providing restricted access and may be just an encrypted session to a particular service as opposed to a full VPN with routed traffic using IPSec.  Unfortunately, language has blurred here, mostly because of marketing, so clarity would be helpful to avoid possible confusion for the reader.

I would recommend introducing the comparison of slit-tunneling earlier in the document as this is a similar issue (IPv6 getting routed separately from the VPN traffic), although split-tunneling is an intentional configuration option.

Is the draft intended for developers/implementers or operational teams/VPN users -- or both?  The proposed fixes could be done by the VPN software or operators could disable interfaces, the former would obviously be preferred and the abstract mentions products, so you may want to repeat that preference later in the document.  

Thank you,
Kathleen

---

From: Fernando Gont <[email-masked]>
Date: Tue, 10 Dec 2013 04:53:39 -0300

Hi, Kathleen,

Thanks so much for your feedback! Please find my comments in-line...

On 12/09/2013 07:21 PM, Moriarty, Kathleen wrote:
> The reference to VPN, never distinguishes if the document is
> referring to an IPSec or TLS VPN. 

That's intentional. At the end of the day, what you use to tunnel your
packets  does not really affect the underlying issues.

> I suspect IPSec from the document,
> but making this clear would be helpful to the reader.  TLS has become
> popular when providing restricted access and may be just an encrypted
> session to a particular service as opposed to a full VPN with routed
> traffic using IPSec.  Unfortunately, language has blurred here,
> mostly because of marketing, so clarity would be helpful to avoid
> possible confusion for the reader.

As noted above, this is actually intentional, and I'd personally leave
this "as is" -- put please let me know what you think.

> I would recommend introducing the comparison of slit-tunneling
> earlier in the document as this is a similar issue (IPv6 getting
> routed separately from the VPN traffic), although split-tunneling is
> an intentional configuration option.

Could you please clarify what you have in mind?

> Is the draft intended for developers/implementers or operational
> teams/VPN users -- or both?

Both.

> The proposed fixes could be done by the
> VPN software or operators could disable interfaces, the former would
> obviously be preferred and the abstract mentions products, so you may
> want to repeat that preference later in the document.

So far, the I-D proposes that the fixes should be implemented by the VPN
client. ONly the "Security Considerations" section mentions "disabling
IPv6" as a mitigation (i.e., "last resort" thing).

I guess possible options are:

1) Leaving the I-D "as is", or,

2) Have a "Mitigations" section where the current Section 6
("Mitigations to VPN traffic-leakage vulnerabilities") is incorporated
as subsection 6.1 (and possibly renamed "Fixing VPN client software"),
and then adding another subsection entitled "Operational mitigations" or
the like, essentially discussing manually disabling IPv6 on the local
system.

I'm inclined to "1)", but nevertheless open to "2)".

Thoughts?

Thanks!

Best regards,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Stephen Kent <[email-masked]>
Date: Tue, 10 Dec 2013 10:22:54 -0500

Fernando,

A quick look at your I-D suggests that the SSL VPN vs. IPsec VPN 
distinction is meaningful, and ought to be addressed. For example, in an 
SSL VPN the security
model is based on higher level identifiers. Thus there are other ways that
a user may find that traffic he thought was protected is not. I realize that
your doc focuses only on the IPv6 vs. v4 issue, but given the title, a 
reader
might be mislead by the lack of context.

Steve

---

From: "Moriarty, Kathleen" <[email-masked]>
Date: Tue, 10 Dec 2013 11:25:04 -0500

Hi Fernando,

Thank you for the quick response! I'll answer in-line and do think it will be important to address TLS vs. IPsec tunnels separately and will explain my reasoning to help you improve the draft.

-----Original Message-----
From: Fernando Gont [mailto:[email-masked]] 
Sent: Tuesday, December 10, 2013 2:54 AM
To: Moriarty, Kathleen; [email-masked]; [email-masked]; [email-masked]
Subject: Re: Sec-Dir review of draft-ietf-opsec-vpn-leakages-02

Hi, Kathleen,

On 12/09/2013 07:21 PM, Moriarty, Kathleen wrote:
> The reference to VPN, never distinguishes if the document is referring 
> to an IPSec or TLS VPN.

That's intentional. At the end of the day, what you use to tunnel your packets  does not really affect the underlying issues.

KM> IPsec and TLS VPNs operate on different levels of the stack, hence the issue you seek to address will be handled differently in each case.  The use cases you describe are very specific to IPsec VPN tunnels in that IPsec VPNs are intended to route all traffic from the client endpoint that has an installed agent to a VPN gateway.  This provides an opportunity for controls to be managed through that application as well as on the client endpoint.  If you think about the split-tunneling example, this is a common configuration option for an IPsec VPN tunnel.

A TLS VPN is typically application specific, wrapping the specific TCP protocols, like HTTP to provide access to specific services on a network.  TLS VPNs are used when you want to restrict access and only provide remote users to very specific services on the network.  TLS VPN services don't require an agent and the policy is typically more liberal from organizations allowing access from anywhere via this access method.  All other traffic on the system may be routed directly to the destination, whether it is IPv4, IPv6, or even other service level (HTTP) destination addresses.

For these reasons, I think it is important to distinguish the type of VPN considered in the draft as it seems to be applicable to IPsec only.

This can get a little confusing as vendors like Cisco developed methods to transport IPsec traffic over TCP ports 80 and 443, but are still IPsec.  Other vendors may have used similar approaches to get around firewall issues (Cisco Tunnel Control Protocol or cTCP), but the protocol is still IPsec and traffic is still routed through the gateway allowing for the options you have specified in the draft as opposed to application level traffic to specific services using HTTP/TLS for the VPN.

> traffic using IPSec.  Unfortunately, language has blurred here, mostly 
> because of marketing, so clarity would be helpful to avoid possible 
> confusion for the reader.

As noted above, this is actually intentional, and I'd personally leave this "as is" -- put please let me know what you think.

KM> See above, thanks!

> I would recommend introducing the comparison of slit-tunneling earlier 
> in the document as this is a similar issue (IPv6 getting routed 
> separately from the VPN traffic), although split-tunneling is an 
> intentional configuration option.

KM> Split-tunneling allows you to route traffic that is destined for the network you connect to with the VPN through the VPN and other traffic to reach its destination with a direct routing path.  If you think about the IPv4 vs. IPv6 traffic, you are in a similar situation if the IPv6 traffic is not intended for the network on the other end of the VPN.  Many organizations will prevent split-tunneling in their VPN configurations if they would like to make sure the users data goes through a gateway with protections (malware detection, URL filtering, etc.), but others are more interested in performance of the user's access or the ability for researchers to have options to access sites they may not be able to through the gateway (I led security for a research organization in the past and there are valid reasons that would surprise some for this usage).

Providing an up-front description could be helpful to the reader.

Both.

KM> OK, great, you may want to call out the specific recommendations for each, state when it applies to both, or state that all options apply to developers/implementers, operational teams, and VPN end users.

> The proposed fixes could be done by the VPN software or operators 
> could disable interfaces, the former would obviously be preferred and 
> the abstract mentions products, so you may want to repeat that 
> preference later in the document.

So far, the I-D proposes that the fixes should be implemented by the VPN client. ONly the "Security Considerations" section mentions "disabling IPv6" as a mitigation (i.e., "last resort" thing).

KM> I would suggest that you add in a statement then to make the objective clear that the recommendations are for improvements in the VPN client to prevent this issue and may involve configuration settings on the VPN gateway that could apply out to all clients if they get updated over time.

2) Have a "Mitigations" section where the current Section 6 ("Mitigations to VPN traffic-leakage vulnerabilities") is incorporated as subsection 6.1 (and possibly renamed "Fixing VPN client software"), and then adding another subsection entitled "Operational mitigations" or the like, essentially discussing manually disabling IPv6 on the local system.

KM> If you want to target all user groups as stated above, then I think #2 is the only option.  If you want to restrict the draft to developers and VPN client configuration options, then you can leave this part of the draft as-is and add that statement.

Thank you,
Kathleen

Thoughts?

Thanks!

Best regards,

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 10 Dec 2013 09:16:57 -0800

<VPN Consortium diretor hat on>

On Dec 10, 2013, at 8:25 AM, Moriarty, Kathleen <[email-masked]> wrote:

> KM> IPsec and TLS VPNs operate on different levels of the stack

That really depends on what you mean by "TLS VPN" (more commonly still called "SSL VPNs"). There are two architecturally different technologies that both are called "SSL VPNs":

- An SSL VPN portal is a front-end provided by the middlebox to add security to a normally-unsecured site. A portal does not require any changes to the browser: you connect to the portal just as you would any https: URL.

- An SSL VPN tunnel encapsulates traffic from a client to the middlebox. In essence, an SSL VPN tunnel acts just like an IPsec client and server, but is instead running TLS for encryption and some unspecified, proprietary mumbly thing for encapsulation and routing. In order to do this, the SSL VPN needs to push a proprietary plug-in / add-in / application to the browser.

The current SSL VPN market is split into two factions. Low-end SSL VPN boxes do just SSL VPN tunnels and not portals; many of these tunnel clients only work with IE as a browser. The middle- and high-end SSL boxes all do both portal and tunnel mode, with the tunnel clients working in many different browsers; the administrator decides which mode to use for particular destinations. Many (but definitely not all) of the latter boxes offer both IPsec and SSL VPNs; those that do usually have them in the same admin GUI.

Please note that I am *not* defending the amount of confusion sown by mixing the two very different architectures under one name. SSL VPN tunnel clients were originally created because IPsec clients were too complicated, and these could just be pushed down with a single click in a browser. Now these clients are often *more complicated* that IPsec clients because they interact with browsers and operating systems in more odd ways. For example, one company whom I work with uses a popular SSL VPN system in tunnel mode. But I can't reach them now because they have not updated the tunnel client to work with Windows 8 (much less 8.1) because the client the vendor messed up that client and it no longer works with XP. So this company has a company-wide rule that you cannot upgrade to Windows 8 until the vendor fixes the SSL VPN client, although the vendor says it already has. (The Mac client has never worked reliably.) Yay for progress. 

> , hence the issue you seek to address will be handled differently in each case.  The use cases you describe are very specific to IPsec VPN tunnels in that IPsec VPNs are intended to route all traffic from the client endpoint that has an installed agent to a VPN gateway.  

...and so are SSL VPN tunnels.

> This provides an opportunity for controls to be managed through that application as well as on the client endpoint.  If you think about the split-tunneling example, this is a common configuration option for an IPsec VPN tunnel.

...and usually (but, unfortunately, not always) for SSL VPN tunnels.

> A TLS VPN

*in portal mode*

> is typically application specific, wrapping the specific TCP protocols, like HTTP to provide access to specific services on a network.  TLS VPNs are used when you want to restrict access and only provide remote users to very specific services on the network.  TLS VPN services don't require an agent and the policy is typically more liberal from organizations allowing access from anywhere via this access method.  All other traffic on the system may be routed directly to the destination, whether it is IPv4, IPv6, or even other service level (HTTP) destination addresses.
> 

...as well as the quite common SSL VPNs in tunnel mode.

> Providing an up-front description could be helpful to the reader.

+1. Split tunneling (destined for the inside network / destined for the Internet) confuses many security admins, and layering IPv4 / IPv6 on top is also confusing, but it is definitely worth trying to explain. Just don't make it IPsec specific, because some SSL VPN vendors use exactly the same logic in the SSL VPNs as they do in the IPsec VPNs.

--Paul Hoffman

---

From: Fernando Gont <[email-masked]>
Date: Tue, 10 Dec 2013 14:32:54 -0300

Hi, Kathleen,

Thanks so much for your prompt response! Please find my comments in-line...

On 12/10/2013 01:25 PM, Moriarty, Kathleen wrote:
> That's intentional. At the end of the day, what you use to tunnel
> your packets  does not really affect the underlying issues.
> 
> KM> IPsec and TLS VPNs operate on different levels of the stack,
> hence the issue you seek to address will be handled differently in
> each case.

Both cases seem to "capture" traffic by installing more specific entries
in the routing table (or replacing the existing ones) and employing e.g.
a tun device....

> The use cases you describe are very specific to IPsec VPN
> tunnels in that IPsec VPNs are intended to route all traffic from the
> client endpoint that has an installed agent to a VPN gateway.

Actually, this came up as a result with my experience with TLS-based
OpenVPN... but the issues are very similar with IPsec -- e.g. this I-D
resulted in corresponding patches in the OpenBSD IPsec implementation.

[....]
>> I suspect IPSec from the document, but making this clear would be
>> helpful to the reader.  TLS has become popular when providing
>> restricted access and may be just an encrypted session to a
>> particular service as opposed to a full VPN with routed traffic
>> using IPSec.  Unfortunately, language has blurred here, mostly 
> As noted above, this is actually intentional, and I'd personally
> leave this "as is" -- put please let me know what you think.
> 
> KM> See above, thanks!

Please check the above. That said, for fairness sake, I'll love the
input from others..

And, in case we go forward with your proposed change, what are the
specific changes you envision?

> KM> OK, great, you may want to call out the specific recommendations
> for each, state when it applies to both, or state that all options
> apply to developers/implementers, operational teams, and VPN end
> users.

This I-D boils down to "When thinking about securiing data transfer t a
remote site, you must keep both IPv6 and IPv4 in mind".

I'm not sure I can see a real difference between what's the specific
underlying technology you employ...

>> could disable interfaces, the former would obviously be preferred
>> and the abstract mentions products, so you may want to repeat that
> So far, the I-D proposes that the fixes should be implemented by the
> VPN client. ONly the "Security Considerations" section mentions
> "disabling IPv6" as a mitigation (i.e., "last resort" thing).
> 
> KM> I would suggest that you add in a statement then to make the
> objective clear that the recommendations are for improvements in the
> VPN client to prevent this issue and may involve configuration
> settings on the VPN gateway that could apply out to all clients if
> they get updated over time.

With "VPN ateway" you're referring to a single VPN "client" that is
tunneling traffic for all local nodes?

> ("Mitigations to VPN traffic-leakage vulnerabilities") is
> incorporated as subsection 6.1 (and possibly renamed "Fixing VPN
> client software"), and then adding another subsection entitled
> "Operational mitigations" or the like, essentially discussing
> manually disabling IPv6 on the local system.
> 
> KM> If you want to target all user groups as stated above, then I
> think #2 is the only option.  If you want to restrict the draft to
> developers and VPN client configuration options, then you can leave
> this part of the draft as-is and add that statement.

The only thing is that I can hear people complaining about the "disable
IPv6" option... Although reality-wise, at times that the only option you
have at hand (e.g., that's what I do when employing OpenVPN).

Thoughts?

Thanks!

Best regards,

---

From: "Moriarty, Kathleen" <[email-masked]>
Date: Tue, 10 Dec 2013 13:29:02 -0500

Thanks for the additional input Paul.  I am adding Fernando back to the discussion as well since these distinctions are important and your summary could be helpful to him.

Fernando - in the description, adding in the SSL Tunnel mode, which also uses a client or an agent in a similar way to the IPsec VPN would be important.  I had actually done a search to find out if there was usage of TLS/SSL to enable routing of traffic and didn't see anything, thanks Paul!  I had previously configured the IPsec over TCP port 80/443 in the past, so I was able to confirm that easily.  Documentation that covers VPN options from a few sources did not cover the SSL Tunnel mode, which I think makes it more important to ensure this background is included as well as how it may apply to the draft (any time you are routing traffic in a VPN).

I'll respond to your (Fernando) message a little later as I have to do my day job for a bit.  :-)

Thank you,
Kathleen

-----Original Message-----
From: secdir [mailto:[email-masked]] On Behalf Of Paul Hoffman
Sent: Tuesday, December 10, 2013 12:17 PM
To: [email-masked]
Cc: [email-masked]; secdir
Subject: Re: [secdir] Sec-Dir review of draft-ietf-opsec-vpn-leakages-02

*in portal mode*

--Paul Hoffman
_______________________________________________
secdir mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/secdir
wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview

---

From: "Moriarty, Kathleen" <[email-masked]>
Date: Wed, 11 Dec 2013 11:44:47 -0500

Hello, Fernando.

I believe you have also seen Paul & Steve's responses to this thread and I'll respond in-line.

-----Original Message-----
From: Fernando Gont [mailto:[email-masked]] 
Sent: Tuesday, December 10, 2013 12:33 PM
To: Moriarty, Kathleen; [email-masked]; [email-masked]; [email-masked]
Subject: Re: Sec-Dir review of draft-ietf-opsec-vpn-leakages-02

Hi, Kathleen,

> hence the issue you seek to address will be handled differently in 

Both cases seem to "capture" traffic by installing more specific entries in the routing table (or replacing the existing ones) and employing e.g.
a tun device....

KM> OK, yes, an IPsec or an SSL Tunnel mode VPN are both subject to these issues.  It would be helpful to note that and include a description on the VPN types that apply.  It would also be helpful to narrow the scope to the areas where you would like this solution to apply (I believe, agents or software at the client system).

> The use cases you describe are very specific to IPsec VPN tunnels in 
> that IPsec VPNs are intended to route all traffic from the client 
> endpoint that has an installed agent to a VPN gateway.

Actually, this came up as a result with my experience with TLS-based OpenVPN... but the issues are very similar with IPsec -- e.g. this I-D resulted in corresponding patches in the OpenBSD IPsec implementation.

KM> Thank you, I had tried searching for solutions that used TLS to route all traffic before sending my first message assuming someone had implemented a solution, but only found the use of IPsec over TCP 80 and 443, so I stand corrected.  I'll provide some text below with your request as I think it is important to address these points to fully explain where this is applicable for it to be useful.  If I had a hard time finding materials and knew what I was looking for ('interesting' uses of protocols), then others will also have a problem.

[....]
>> particular service as opposed to a full VPN with routed traffic using 
>> IPSec.  Unfortunately, language has blurred here, mostly because of 
>> marketing, so clarity would be helpful to avoid possible  confusion 
>> for the reader.
> 

Please check the above. That said, for fairness sake, I'll love the input from others..

KM> I think you saw the response from Paul & Steve already.

And, in case we go forward with your proposed change, what are the specific changes you envision?

KM> In the introduction, please add in a description of split-tunneling along with the description of this issue as there are similarities.  

I recommend adding in a description of the types of VPNs for which this is applicable at the start of the second paragraph.  If you don't want to restrict the applicable types of VPN for this draft, listing the known applicable types as examples will be a very helpful stating point.  Something like the following could proceed the current text in that paragraph:

In some cases, VPNs solutions are designed to route traffic at the IP layer through to the destination gateway.  Typically, these solutions are agent-based, meaning that software is required on the client end point to establish the tunnel and manage access control or routing rules.  Split-tunneling is an example of a routing option typically provided that can be set on the gateway and pushed out to each of the attached clients.  When enabled, split-tunneling routes traffic destined for the network attached to the gateway through the VPN and all other traffic is routed directly to through the Internet or default route for the client.  The VPN gateway administrator may choose to enable split-tunneling if performance is a primary concern for end users Internet access.  The administrator may choose to prevent split-tunneling if they have security concerns such as information leakage or would prefer all client Internet traffic is screened for malware, for instance, as it passes through the corporate firewall to access the Internet.  Similarly, issues have been discovered with VPN solutions that route traffic at the IP layer when IPv6 is in use at the client.

<description of problem for routing at client with IPv4 and IPv6 - paragraph 2 of introduction>

<before the last paragraph of introduction>
Since this issue is specific to VPN solutions that route IP layer traffic, it may be applicable to the following types of VPN technologies:
    o IPsec VPN (include description)
    o SSL Tunnel VPN (include description and I recommend mentioning VPN Portal to make sure readers don't get confused)

> apply to developers/implementers, operational teams, and VPN end 

This I-D boils down to "When thinking about securiing data transfer t a remote site, you must keep both IPv6 and IPv4 in mind".

I'm not sure I can see a real difference between what's the specific underlying technology you employ...

KM> I think this should be more clear now with Paul's response.  An agent vs. browser based VPNs are an important distinction as the solutions that route IP layer traffic use an agent and provide a point at which mitigation options should be provided (like split-tunneling).

> they get updated over time.

With "VPN ateway" you're referring to a single VPN "client" that is tunneling traffic for all local nodes?

KM> Feel free to replace the term with something else.  When I use the term VPN Gateway, I am referring to the end-point that clients connect to establish the VPN session.  The network being accessed by the clients is on the other side of the gateway.  Typically, options can be set at the gateway, like the ability to prevent split-tunneling, so that a policy can be set for access to the network being accessed.  The configuration may get pushed to the agents or may also be checked through the connect process to ensure policy is met (NAC).

> and then adding another subsection entitled "Operational mitigations" 
> or the like, essentially discussing manually disabling IPv6 on the 
> local system.
> 

The only thing is that I can hear people complaining about the "disable IPv6" option... Although reality-wise, at times that the only option you have at hand (e.g., that's what I do when employing OpenVPN).

KM> Since it is one of the options, I agree that it should be listed.  If people disagree with that option and want to address this another way for their business requirements, that is fine too.  This draft is meant to raise awareness, provide options for software implementations to resolve the issue, resulting in options in software for operators to meet their policy needs.  Just like split-tunneling, operators/administrators will choose the options that work for their policy constraints.

Thank you,
Kathleen

Thoughts?

Thanks!

Best regards,