Layer 3 Virtual Private Network (VPN) Tunnel Traffic Leakages in Dual-Stack Hosts/Networks
draft-ietf-opsec-vpn-leakages-06

[Ballot comment]
With the IESG Note, I consider the DISCUSSion of this document complete. I still don't support it's publication, but the IESG Note serves to explain the issue.

[Ballot discuss]
I have moved my technical concerns on the document to the comments section, as I expect that I will be moving to Abstain on this document; whatever the outcome, I can't in good conscience recommend this document. But I want to DISCUSS this one last time on this telechat for two reasons:

- I have read over the OPSEC archive discussion of this document since IESG review, with the WG being specifically pressed to address some of the comments. The response was not impressive.

- It seems to me that from Benoit's comments, he is likely an abstention as well. Even though his change in ballot would not make a formal difference to the outcome (it is an Informational document, and therefore a single "Yes" is sufficient), perhaps 4 abstentions would give Joel pause. (Perhaps not. ;-) )

If this is a substantive problem with VPN deployments, I would have expected OPSEC to be pushing this as a BCP with specific instructions on how to address the problem and harsh words for broken implementations. But I don't see that motivation or urgency. So I continue to doubt the worth of this document, and I think its continued implication that disabling v6 is a reasonable path forward is a shame. But short of a change of heart of the WG or the rest of the IESG, I will not stand alone in front of this document past this telechat.

[Ballot comment]
The scenarios and the solutions in this document strike me as somewhat bogus, and I'd like to hear if the WG had any data on these usage scenarios:

- Most VPN installations I know of secure traffic to particular addresses by employing the VPN to do two things: a) Encrypt the traffic, and b) Get through a firewall that prevents traffic not coming through the VPN to never get to the hosts. In that case, if a non-v6 supporting VPN is used, the v6 traffic never even begins, because the traffic simply can't reach the v6 endpoints behind the firewall. Are most VPNs not employed in the way that I describe?

- The document seems to assume that VPNs are somehow used to generically encrypt traffic that is not encrypted. But the vulnerability here seems to be the use of the VPN for such purposes. To secure traffic to a service, what you want to do is have the application secure the stream of data in some way (e.g., TLS), not have applications that blindly send clear traffic and then hope it goes through the VPN. Are VPNs actually being used to do this generic blind encryption? Are most of the instances of this not also instances of the firewalled scenario I asked about above?

- The document refers to v4 and v6 being "'tied' together by the DNS". However, most VPNs I am aware of actually force the use of a particular DNS server on the user of the VPN. In those cases, if the VPN is v4 only, and that DNS is returning v6 addresses, it seems like the appropriate mitigation is to stop returning v6 addresses through that VPN-configured DNS server, not to disable all v6 interfaces. Are most VPNs not using their own configured DNS?

- The mitigations in 7.1 never say, "Fix the VPN software to support v6", nor does it say, "stop advertising v6 addresses for things that you expect to go through the VPN". Those seems like much more sensible mitigations. The choices in the document are "use v6-enabled VPNs" or "don't use v6". Those seem like lousy choices.

- It does seem clear that many of the problems described in this document are equally applicable to *any* VPN that allows split-tunneling, whether that VPN is allowing only v6 to be split (perhaps accidentally) or purposely allowing any sort of split. The document handwaves at this in section 2, but assumes non-split-tunnels in section 4:

  ...the IPv4 connectivity by, e.g. inserting an IPv4 default
  route that causes all IPv4 traffic to be sent over the VPN connection
  (as opposed to sending the traffic in the clear, employing the local
  router).

and never really addresses in section 7 that split tunnels suffer the same problems.

The analysis in this document seems very weak to me. I'm not a security guy, but the scenarios and mitigations described in this document don't seem truly representative of VPN usage. At the very least, the document never gives any data indicating that the scenarios are the real problem.

[Ballot comment]
Thank you for adding the scope limitations in the terminology section from my SecDir review.  This does help to better narrow and explain the applicability of this draft, it is a definite improvement.  To address Stephen's comment on section 2, you can go back to the SecDir review discussion where detailed explanations were provided by myself, Paul Hoffman, and Steve Kent on the types of VPN and why this is limited to VPN tunnels.  The terminology is specific for TLS vs. IPsec tunnels.

Although several implementations have been corrected as a result of this draft, I also do not think there is a big need for this to become an RFC as we are not aware of any outstanding implementations that need to be fixed, correct?

Is section 4 still true?  I thought from previous exchanges on this draft that the problems in the VPN agents that had this issue were resolved as a result of this draft?

I agree with Pete on the push back related to the DNS statements in section 4.  The draft states the issue is caused by DNS, but I suspect it is actually routing and the VPN software knowing how to handle IPv6 addresses.  If you just address this at a DNS level where IPv4 addresses are returned, you'll wind up with issues when IP addresses only are used and the same problem would continue to occur.

[Ballot comment]
I like the fact that the leakage issue is well described. Thanks for that.

However, Russ' GEN-ART review also resonates with me:

  I do not find this document very helpful.  It can be summarized as:

  If IPv6 is not supported in your VPN software, then disable IPv6
  support in all network interfaces before you try to use it.

  I do not know why the OPSEC WG thinks that this message is worthy
  of an RFC.

This is also in line with Dan Romascanu's OPS DIR review at http://www.ietf.org/mail-archive/web/ops-dir/current/msg00050.html. Please address Dan's review.

As others have said, the resolution should be: fix the VPN software to support IPv6 in a dual-stacked host/network.

[Ballot discuss]
I have yet to do my own review of this document, but I note that during the discussion of Martin Vigoureux's Routing Directorate review, Martin suggested changes to the text in the Abstract and introduction. I have seen no follow-up on these suggestions and the text doesn't appear to have been changed.

===

Fernando,

thanks for following up.

Your explanations clarify a lot, so I think these clarifications need to
be brought to the draft. You are free not to take the suggested text as
is, but I think you need to keep the objective.


I would start by clarifying the Abstract:
OLD:
That is, traffic meant to be transferred over a VPN connection may leak
out of such connection and be transferred in the clear from the local
network to the final destination.
NEW:
That is, traffic meant to be transferred over a VPN connection may leak
out of such connection and be sent in the clear on the local network
towards the final destination.

OLD:
This document discusses some scenarios in which such VPN leakages may
occur, either as a side effect of enabling IPv6 on a local network, or
as a result of a deliberate attack from a local attacker.

NEW:
This document discusses some scenarios in which such VPN leakages may
occur as a result of employing IPv6-unaware VPN software.

Then I believe you need to rework the first paragraph of the
Introduction to clearly and rapidly state your problem space rather than
loosing the reader in the VPN-to-corporate-resources sink. This echoes
the comment you also received from Lee and the original one from KK.

OLD:
    It is a very common practice for employees working at remote
    locations to establish a VPN connection with their office or home
    office.  This is typically done to gain access to some resources only
    available within the company's network, but also to secure the host's
    traffic against attackers that might be connected to the same remote
    location.  The same is true for mobile nodes that establish VPN
    connections to secure their traffic while they roam from one network
    to another.  In some scenarios, it is even assumed that employing a
    VPN connection makes the use of insecure protocols (e.g. that
    transfer sensitive information in the clear) acceptable, as the VPN
    provides security services (such as data integrity and/or
    confidentiality) for all communications made over the VPN.
NEW:
    It is a very common practice for users of a VPN software to
    establish a VPN connection towards a targeted endpoint when their
    terminal, which hosts the VPN software, is itself connected to a
    local network (e.g., a conference network). This is typically done
    to gain access to some resources which are otherwise not accessible,
    but also to secure the terminal's traffic through the local network
    (e.g., against attackers that might be connected to the same local
    network). The latter case constitute the problem space of this
    document. Indeed, it is sometimes assumed that employing a VPN
    connection makes the use of insecure protocols (e.g., that transfer
    sensitive information in the clear) acceptable, as a VPN provides
    security services (such as data integrity and/or confidentiality)
    for all communications made over that VPN. However, this document
    illustrates that under certain circumstances, some traffic might not
    be mapped onto the VPN and thus be sent in the clear on the local
    network.

[Ballot comment]
I like the fact that the leakage issue is well described. Thanks for that.

However, Russ' GEN-ART review also resonates with me:

  I do not find this document very helpful.  It can be summarized as:

  If IPv6 is not supported in your VPN software, then disable IPv6
  support in all network interfaces before you try to use it.

  I do not know why the OPSEC WG thinks that this message is worthy
  of an RFC.

This is also in line with Dan Romascanu's OPS DIR review at http://www.ietf.org/mail-archive/web/ops-dir/current/msg00050.html. Please address Dan's review.

As others have said, the resolution should be: fix the VPN software to support IPv6 in a dual-stacked host/network.

NO-RECORD for now: I would like to listen to the IESG call first.

[Ballot comment]
What Pete said...

This is another example of giving guidance to disable IPv6 rather than guidance on how to address the limitations causing the perceived problem.  I would have liked to have seen, for example, guidance on what DNS record types should be available via a VPN connection running over IPv4.

[Ballot discuss]
The scenarios and the solutions in this document strike me as somewhat bogus, and I'd like to hear if the WG had any data on these usage scenarios:

- Most VPN installations I know of secure traffic to particular addresses by employing the VPN to do two things: a) Encrypt the traffic, and b) Get through a firewall that prevents traffic not coming through the VPN to never get to the hosts. In that case, if a non-v6 supporting VPN is used, the v6 traffic never even begins, because the traffic simply can't reach the v6 endpoints behind the firewall. Are most VPNs not employed in the way that I describe?

- The document seems to assume that VPNs are somehow used to generically encrypt traffic that is not encrypted. But the vulnerability here seems to be the use of the VPN for such purposes. To secure traffic to a service, what you want to do is have the application secure the stream of data in some way (e.g., TLS), not have applications that blindly send clear traffic and then hope it goes through the VPN. Are VPNs actually being used to do this generic blind encryption? Are most of the instances of this not also instances of the firewalled scenario I asked about above?

- The document refers to v4 and v6 being "'tied' together by the DNS". However, most VPNs I am aware of actually force the use of a particular DNS server on the user of the VPN. In those cases, if the VPN is v4 only, and that DNS is returning v6 addresses, it seems like the appropriate mitigation is to stop returning v6 addresses through that VPN-configured DNS server, not to disable all v6 interfaces. Are most VPNs not using their own configured DNS?

- The mitigations in 7.1 never say, "Fix the VPN software to support v6", nor does it say, "stop advertising v6 addresses for things that you expect to go through the VPN". Those seems like much more sensible mitigations. The choices in the document are "use v6-enabled VPNs" or "don't use v6". Those seem like lousy choices.

The analysis in this document seems very weak to me. I'm not a security guy, but the scenarios and mitigations described in this document don't seem truly representative of VPN usage. At the very least, the document never gives any data indicating that the scenarios are the real problem.

[Ballot comment]
I found this document to be pretty clear for the non-expert reader. I did have a couple of comments that you might want to consider, along with any other comments you receive.

In this text:

7.1.  Fixing VPN client software

  Finally, we note that if (eventually) IPv6-only VPN implementations
  become available, they should consider similar issues that would
                    ^^^^
  arise if they do nothing about the IPv4 traffic.
            ^^^^

I'm reading "they" as "IPv6-only VPN implementations", but I'm not sure that's what you intended. I might also have guessed "administrators", if I was guessing. If you meant something else, could you consider using a noun, and not a pronoun?

In this text:

9.  Security Considerations

  Possible ways to mitigate this problem include fixing the VPN client
  software, or disabling IPv6 connectivity on all network interfaces
  when the previous option is not feasible.

These are the recommendations the document is making, are they not? I would have thought what this section is asking for, is what security considerations might arise from following those recommendations.

Finally, Stephen was asking about what else might leak, which is an interesting question, but I'm wondering if that's something different - he's talking about "leaking" (say) a small amount of DHCP traffic that someone could eavesdrop and learn something the eavesdropper shouldn't know, while IIUC, this draft is mostly about 'leaking" potentially a much larger and potentially more revealing amount of traffic (like, all of the email I'm downloading from my mail server), and (in these two examples) potentially "leaking" it over a much larger distance (network-wise).

Is there a better term for what this document is describing?

"No", or "no, that's actually the right term of art on both cases", would be a fine answer ...

[Ballot comment]

- section 2: The terminology section is not very clear as
to how TLS-based tunnels are not the same as TLS VPN
portals. And the slides referenced don't really seem to
cover TLS tunnels for general IP traffic but rather TLS
tunnels from a browser to an entreprise, presumably with
the tunnelled traffic being HTTP/XHR. I think some
additional wording should clear this up.  I saw that this
was discussed as part of the secdir review but I don't
think the text is quite there yet.  Maybe, saying "IPsec
VPNs and VPNs that use TLS for key manamgent, but that
also tunnel general IP" is a way to cover both IPsec and
e.g. OpenVPN?

- section 3: routing also "ties together" different
versions of IP, re-phrasing that might be better.

- section 4: the "underlying problem" is that the
VPN s/w doesn't support v6, not that DNS has both
A and AAAA RRs.

- (niggly nit) Another "turn off v6" recommendation!
(sigh)

- Don't VPNs also "leak" other traffic, e.g. DHCP when
the non-VPN lease needs renewing or already opened
connections? And if a VPN client is badly configured then
lots more could leak too. Why not note these?

[Ballot comment]
-- Section 2 --

  When employing the term VPN (or its acronym, "VPN")

Eh?  I guess the first was meant to be spelt out.

[Ballot discuss]
I have yet to do my own review of this document, but I note that during the discussion of Martin Vigoureux's Routing Directorate review, Martin suggested changes to the text in the Abstract and introduction. I have seen no follow-up on these suggestions and the text doesn't appear to have been changed.
===
Fernando,

thanks for following up.

Your explanations clarify a lot, so I think these clarifications need to
be brought to the draft. You are free not to take the suggested text as
is, but I think you need to keep the objective.


I would start by clarifying the Abstract:
OLD:
That is, traffic meant to be transferred over a VPN connection may leak
out of such connection and be transferred in the clear from the local
network to the final destination.
NEW:
That is, traffic meant to be transferred over a VPN connection may leak
out of such connection and be sent in the clear on the local network
towards the final destination.

OLD:
This document discusses some scenarios in which such VPN leakages may
occur, either as a side effect of enabling IPv6 on a local network, or
as a result of a deliberate attack from a local attacker.

NEW:
This document discusses some scenarios in which such VPN leakages may
occur as a result of employing IPv6-unaware VPN software.

Then I believe you need to rework the first paragraph of the
Introduction to clearly and rapidly state your problem space rather than
loosing the reader in the VPN-to-corporate-resources sink. This echoes
the comment you also received from Lee and the original one from KK.

OLD:
    It is a very common practice for employees working at remote
    locations to establish a VPN connection with their office or home
    office.  This is typically done to gain access to some resources only
    available within the company's network, but also to secure the host's
    traffic against attackers that might be connected to the same remote
    location.  The same is true for mobile nodes that establish VPN
    connections to secure their traffic while they roam from one network
    to another.  In some scenarios, it is even assumed that employing a
    VPN connection makes the use of insecure protocols (e.g. that
    transfer sensitive information in the clear) acceptable, as the VPN
    provides security services (such as data integrity and/or
    confidentiality) for all communications made over the VPN.
NEW:
    It is a very common practice for users of a VPN software to
    establish a VPN connection towards a targeted endpoint when their
    terminal, which hosts the VPN software, is itself connected to a
    local network (e.g., a conference network). This is typically done
    to gain access to some resources which are otherwise not accessible,
    but also to secure the terminal's traffic through the local network
    (e.g., against attackers that might be connected to the same local
    network). The latter case constitute the problem space of this
    document. Indeed, it is sometimes assumed that employing a VPN
    connection makes the use of insecure protocols (e.g., that transfer
    sensitive information in the clear) acceptable, as a VPN provides
    security services (such as data integrity and/or confidentiality)
    for all communications made over that VPN. However, this document
    illustrates that under certain circumstances, some traffic might not
    be mapped onto the VPN and thus be sent in the clear on the local
    network.

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-opsec-vpn-leakages-02, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any IANA actions. IANA requests that the IANA Considerations section of the document remain in place upon publication.

If this assessment is not accurate, please respond as soon as possible.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Virtual Private Network (VPN) traffic leakages in dual-stack hosts/ networks) to Informational RFC


The IESG has received a request from the Operational Security
Capabilities for IP Network Infrastructure WG (opsec) to consider the
following document:
- 'Virtual Private Network (VPN) traffic leakages in dual-stack hosts/
  networks'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-12-16. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  The subtle way in which the IPv6 and IPv4 protocols co-exist in
  typical networks, together with the lack of proper IPv6 support in
  popular Virtual Private Network (VPN) products, may inadvertently
  result in VPN traffic leaks.  That is, traffic meant to be
  transferred over a VPN connection may leak out of such connection and
  be transferred in the clear from the local network to the final
  destination.  This document discusses some scenarios in which such
  VPN leakages may occur, either as a side effect of enabling IPv6 on a
  local network, or as a result of a deliberate attack from a local
  attacker.  Additionally, it discusses possible mitigations for the
  aforementioned issue.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-opsec-vpn-leakages/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-opsec-vpn-leakages/ballot/


No IPR declarations have been submitted directly on this I-D.

(1) What type of RFC is being requested?

Informational -- this document is for the general information of the
Internet community and does not have protocol or requirements.

(2) The IESG approval announcement includes a Document Announcement
Write-Up:

Technical Summary:

Due to the lack of proper IPv6 support in some popular Virtual Private
Network (VPN) products, traffic meant to be transferred over a VPN
connection may leak out of such connection and be transferred in the
clear from the local network to the final destination.

This document discusses some scenarios in which such leakages may
occur and discusses possible mitigations.

Working Group Summary:

There was no drama in the WG regarding this draft.

Document Quality: The document is well written and easy to understand.
There was good support in the WG for progressing this document. Merike
Kaeo in particular provided good review and comments.

Personnel:

Warren Kumari is the Document Shepherd. Joel Jaeggli is RAD.


(3) Briefly describe the review of this document that was performed by
the Document Shepherd. The Document Shepherd followed the document as
it progressed though the WG, and reviewed content as it was revised.


(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed? Nope.


(5) Do portions of the document need review from a particular or from
broader perspective? Nope.


(6) Describe any specific concerns or issues that the Document
Shepherd has with this document that the Responsible Area Director
and/or the IESG should be aware of? None.


(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP
78 and BCP 79 have already been filed. Yes.


(8) Has an IPR disclosure been filed that references this document? No
IPR disclosures have been filed (phew!)


(9) How solid is the WG consensus behind this document? The most
involved / active WG participants did respond and their comments were
supportive. The rest of the WG was silent (we are working on this!).


(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? No one made grumpy face...

(11) Identify any ID nits the Document Shepherd has found in this
document. None.

(12) Describe how the document meets any required formal review
criteria. N/A.

(13) All references normative or informative? Yes.


(14) Are there normative references to unpublished things? No - all
normative references are to (published) RFCs.


(15) Are there downward normative references (see RFC 3967)? If so,
list these downward references to support the Area Director in the
Last Call procedure. None.

(16) Will publication of this document change the status of any
existing RFCs? Nope.

(17) Describe the Document Shepherd's review of the IANA
considerations section. No IANA action requested or required. This
matches the text of the document.


(18) List any new IANA registries that require Expert Review for
future allocations. None.

(19) Describe reviews and automated checks of formal language. N/A.