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.