Skip to main content

Layer 3 Virtual Private Network (VPN) Tunnel Traffic Leakages in Dual-Stack Hosts/Networks
RFC 7359

Revision differences

Document history

Date Rev. By Action
2015-10-14
06 (System) Notify list changed from opsec-chairs@ietf.org, draft-ietf-opsec-vpn-leakages@ietf.org to (None)
2014-09-04
06 Jean Mahoney Closed request for Telechat review by GENART with state 'No Response'
2014-08-26
06 (System) RFC published
2014-08-22
06 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2014-08-19
06 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2014-08-14
06 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2014-07-11
06 Cindy Morgan IESG state changed to RFC Ed Queue from Approved-announcement sent
2014-07-11
06 (System) RFC Editor state changed to EDIT
2014-07-11
06 (System) Announcement was received by RFC Editor
2014-07-10
06 (System) IANA Action state changed to No IC from In Progress
2014-07-10
06 (System) IANA Action state changed to In Progress
2014-07-10
06 Cindy Morgan IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2014-07-10
06 Cindy Morgan IESG has approved the document
2014-07-10
06 Cindy Morgan Closed "Approve" ballot
2014-07-10
06 Cindy Morgan Ballot approval text was generated
2014-07-10
06 Cindy Morgan Ballot writeup was changed
2014-07-10
06 Joel Jaeggli The authors and the working group can be said to be ok with the IESG note.
2014-07-10
06 Joel Jaeggli IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup
2014-06-21
06 Pete Resnick
[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 …
[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.
2014-06-21
06 Pete Resnick [Ballot Position Update] Position for Pete Resnick has been changed to Abstain from Discuss
2014-06-21
06 Joel Jaeggli Ballot writeup was changed
2014-05-15
06 Alia Atlas [Ballot Position Update] New position, Abstain, has been recorded for Alia Atlas
2014-05-14
06 Amanda Baber IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed
2014-05-13
06 Pete Resnick
[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 …
[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.
2014-05-13
06 Pete Resnick
[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 …
[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.
2014-05-13
06 Pete Resnick Ballot comment and discuss text updated for Pete Resnick
2014-05-08
06 Jean Mahoney Request for Telechat review by GENART is assigned to Russ Housley
2014-05-08
06 Jean Mahoney Request for Telechat review by GENART is assigned to Russ Housley
2014-04-24
06 Fernando Gont New version available: draft-ietf-opsec-vpn-leakages-06.txt
2014-04-24
05 Fernando Gont New version available: draft-ietf-opsec-vpn-leakages-05.txt
2014-04-22
04 Joel Jaeggli Pushing back due to the non-arrival of the updated draft.

While I wouldn't expect it to be dramatic, I'd rather dicuss that one.
2014-04-22
04 Joel Jaeggli Telechat date has been changed to 2014-05-15 from 2014-04-24
2014-04-06
04 Joel Jaeggli Telechat date has been changed to 2014-04-24 from 2014-04-10
2014-04-03
04 Jean Mahoney Request for Telechat review by GENART is assigned to Russ Housley
2014-04-03
04 Jean Mahoney Request for Telechat review by GENART is assigned to Russ Housley
2014-03-31
04 Kathleen Moriarty
[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 …
[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.
2014-03-31
04 Kathleen Moriarty [Ballot Position Update] New position, No Objection, has been recorded for Kathleen Moriarty
2014-03-30
04 Joel Jaeggli Telechat date has been changed to 2014-04-10 from 2014-02-20
2014-03-04
04 Adrian Farrel [Ballot comment]
Many thanks for engaging with Martin Vigoureux who tells me that all of his Routing Dir issues have now been resolved.
2014-03-04
04 Adrian Farrel [Ballot Position Update] Position for Adrian Farrel has been changed to No Objection from Discuss
2014-03-03
04 Fernando Gont IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2014-03-03
04 Fernando Gont New version available: draft-ietf-opsec-vpn-leakages-04.txt
2014-02-27
03 Tero Kivinen Closed request for Telechat review by SECDIR with state 'No Response'
2014-02-20
03 Cindy Morgan IESG state changed to IESG Evaluation::AD Followup from IESG Evaluation
2014-02-20
03 Benoît Claise
[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:

  …
[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.
2014-02-20
03 Benoît Claise [Ballot Position Update] Position for Benoit Claise has been changed to No Objection from No Record
2014-02-20
03 Richard Barnes [Ballot Position Update] New position, Yes, has been recorded for Richard Barnes
2014-02-20
03 Sean Turner [Ballot Position Update] New position, Yes, has been recorded for Sean Turner
2014-02-20
03 Adrian Farrel
[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 …
[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.
2014-02-20
03 Adrian Farrel Ballot discuss text updated for Adrian Farrel
2014-02-20
03 Ted Lemon [Ballot comment]
I just can't sign on to another document that recommends turning off IPv6 as a mitigation strategy.  Please take that out.
2014-02-20
03 Ted Lemon [Ballot Position Update] New position, Abstain, has been recorded for Ted Lemon
2014-02-20
03 Benoît Claise
[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:

  …
[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.
2014-02-20
03 Benoît Claise Ballot comment text updated for Benoit Claise
2014-02-20
03 Gonzalo Camarillo [Ballot Position Update] New position, No Objection, has been recorded for Gonzalo Camarillo
2014-02-20
03 Brian Haberman
[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 …
[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.
2014-02-20
03 Brian Haberman [Ballot Position Update] New position, Abstain, has been recorded for Brian Haberman
2014-02-19
03 Pete Resnick
[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 …
[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.
2014-02-19
03 Pete Resnick [Ballot Position Update] New position, Discuss, has been recorded for Pete Resnick
2014-02-19
03 Jari Arkko [Ballot comment]
I'd like to see a new version with the edit that Russ Housley suggested in his Gen-ART review.
2014-02-19
03 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko
2014-02-19
03 Spencer Dawkins
[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 …
[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 ...
2014-02-19
03 Spencer Dawkins [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins
2014-02-19
03 Stewart Bryant [Ballot Position Update] New position, No Objection, has been recorded for Stewart Bryant
2014-02-19
03 Stephen Farrell
[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. …
[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?
2014-02-19
03 Stephen Farrell [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell
2014-02-18
03 Martin Stiemerling [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling
2014-02-17
03 Barry Leiba
[Ballot comment]
-- Section 2 --

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

Eh?  I guess the first was meant to be …
[Ballot comment]
-- Section 2 --

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

Eh?  I guess the first was meant to be spelt out.
2014-02-17
03 Barry Leiba [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba
2014-02-16
03 Gunter Van de Velde Request for Last Call review by OPSDIR Completed: Has Nits. Reviewer: Dan Romascanu.
2014-02-16
03 Adrian Farrel
[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 …
[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.
2014-02-16
03 Adrian Farrel [Ballot Position Update] New position, Discuss, has been recorded for Adrian Farrel
2014-02-13
03 Jean Mahoney Request for Telechat review by GENART is assigned to Russ Housley
2014-02-13
03 Jean Mahoney Request for Telechat review by GENART is assigned to Russ Housley
2014-02-09
03 Joel Jaeggli IESG state changed to IESG Evaluation from Waiting for Writeup::AD Followup
2014-02-06
03 Tero Kivinen Request for Telechat review by SECDIR is assigned to Kathleen Moriarty
2014-02-06
03 Tero Kivinen Request for Telechat review by SECDIR is assigned to Kathleen Moriarty
2014-01-31
03 (System) IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed
2014-01-31
03 Joel Jaeggli Placed on agenda for telechat - 2014-02-20
2014-01-31
03 Joel Jaeggli Changed consensus to Yes from Unknown
2014-01-31
03 Joel Jaeggli Ballot has been issued
2014-01-31
03 Joel Jaeggli [Ballot Position Update] New position, Yes, has been recorded for Joel Jaeggli
2014-01-31
03 Joel Jaeggli Created "Approve" ballot
2014-01-31
03 Joel Jaeggli Ballot writeup was changed
2014-01-23
03 (System) Sub state has been changed to AD Followup from Revised ID Needed
2014-01-23
03 Fernando Gont IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2014-01-23
03 Fernando Gont New version available: draft-ietf-opsec-vpn-leakages-03.txt
2014-01-21
02 Joel Jaeggli State changed to Waiting for Writeup::Revised I-D Needed from Waiting for Writeup
2013-12-16
02 (System) State changed to Waiting for Writeup from In Last Call (ends 2013-12-16)
2013-12-14
02 (System) IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed
2013-12-14
02 (System) IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed
2013-12-14
02 Amanda Baber
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 …
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.
2013-12-12
02 Tero Kivinen Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Kathleen Moriarty.
2013-12-05
02 Jean Mahoney Request for Last Call review by GENART is assigned to Russ Housley
2013-12-05
02 Jean Mahoney Request for Last Call review by GENART is assigned to Russ Housley
2013-12-05
02 Tero Kivinen Request for Last Call review by SECDIR is assigned to Kathleen Moriarty
2013-12-05
02 Tero Kivinen Request for Last Call review by SECDIR is assigned to Kathleen Moriarty
2013-12-02
02 Tina Tsou Request for Last Call review by OPSDIR is assigned to Dan Romascanu
2013-12-02
02 Tina Tsou Request for Last Call review by OPSDIR is assigned to Dan Romascanu
2013-12-02
02 Amy Vezza IANA Review state changed to IANA - Review Needed
2013-12-02
02 Amy Vezza
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 …
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.


2013-12-02
02 Amy Vezza State changed to In Last Call from Last Call Requested
2013-12-02
02 Amy Vezza Last call announcement was generated
2013-12-01
02 Joel Jaeggli Last call was requested
2013-12-01
02 Joel Jaeggli Last call announcement was generated
2013-12-01
02 Joel Jaeggli Ballot approval text was generated
2013-12-01
02 Joel Jaeggli Ballot writeup was generated
2013-12-01
02 Joel Jaeggli State changed to Last Call Requested from AD Evaluation
2013-11-02
02 Joel Jaeggli State changed to AD Evaluation from Publication Requested
2013-10-21
02 Cindy Morgan
(1) What type of RFC is being requested?

Informational -- this document is for the general information of the
Internet community and does not have …
(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.
2013-10-21
02 Warren Kumari IETF WG state changed to Submitted to IESG for Publication
2013-10-21
02 Warren Kumari IESG state changed to Publication Requested
2013-10-21
02 Warren Kumari State Change Notice email list changed to opsec-chairs@tools.ietf.org, draft-ietf-opsec-vpn-leakages@tools.ietf.org
2013-10-21
02 Warren Kumari Responsible AD changed to Joel Jaeggli
2013-10-21
02 Warren Kumari Working group state set to Submitted to IESG for Publication
2013-10-21
02 Warren Kumari IESG state set to Publication Requested
2013-10-21
02 Warren Kumari IESG process started in state Publication Requested
2013-10-21
02 Warren Kumari Intended Status changed to Informational from None
2013-10-21
02 Warren Kumari Changed document writeup
2013-10-21
02 Warren Kumari Document shepherd changed to Warren Kumari
2013-08-22
02 Fernando Gont New version available: draft-ietf-opsec-vpn-leakages-02.txt
2013-08-15
01 Warren Kumari IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call
2013-07-03
01 Warren Kumari IETF WG state changed to In WG Last Call from WG Document
2013-06-24
01 Fernando Gont New version available: draft-ietf-opsec-vpn-leakages-01.txt
2012-12-12
00 Fernando Gont New version available: draft-ietf-opsec-vpn-leakages-00.txt