Skip to main content

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

Yes

(Joel Jaeggli)
(Richard Barnes)
(Sean Turner)

No Objection

(Gonzalo Camarillo)
(Martin Stiemerling)
(Stewart Bryant)

Abstain

(Alia Atlas)

Note: This ballot was opened for revision 03 and is now closed.

Joel Jaeggli Former IESG member
Yes
Yes (for -03) Unknown

                            
Richard Barnes Former IESG member
Yes
Yes (for -03) Unknown

                            
Sean Turner Former IESG member
Yes
Yes (for -03) Unknown

                            
Adrian Farrel Former IESG member
(was Discuss) No Objection
No Objection (2014-03-04 for -04) Unknown
Many thanks for engaging with Martin Vigoureux who tells me that all of his Routing Dir issues have now been resolved.
Barry Leiba Former IESG member
No Objection
No Objection (2014-02-17 for -03) Unknown
-- Section 2 --

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

Eh?  I guess the first was meant to be spelt out.
Benoît Claise Former IESG member
No Objection
No Objection (2014-02-20 for -03) Unknown
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.
Gonzalo Camarillo Former IESG member
No Objection
No Objection (for -03) Unknown

                            
Jari Arkko Former IESG member
No Objection
No Objection (2014-02-19 for -03) Unknown
I'd like to see a new version with the edit that Russ Housley suggested in his Gen-ART review.
Kathleen Moriarty Former IESG member
No Objection
No Objection (2014-03-31 for -04) Unknown
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.
Martin Stiemerling Former IESG member
No Objection
No Objection (for -03) Unknown

                            
Spencer Dawkins Former IESG member
No Objection
No Objection (2014-02-19 for -03) Unknown
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 ...
Stephen Farrell Former IESG member
No Objection
No Objection (2014-02-19 for -03) Unknown
- 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?
Stewart Bryant Former IESG member
No Objection
No Objection (for -03) Unknown

                            
Alia Atlas Former IESG member
Abstain
Abstain () Unknown

                            
Brian Haberman Former IESG member
Abstain
Abstain (2014-02-20 for -03) Unknown
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.
Pete Resnick Former IESG member
(was Discuss) Abstain
Abstain (2014-06-21) Unknown
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.
Ted Lemon Former IESG member
Abstain
Abstain (2014-02-20 for -03) Unknown
I just can't sign on to another document that recommends turning off IPv6 as a mitigation strategy.   Please take that out.