On Dec 5, 2013, at 11:09 AM, Martin Vigoureux <[email protected]> wrote:
> Hello, > > I have been selected as the Routing Directorate reviewer for this draft. Just a quick note to say think you for the helpful review… W > The Routing Directorate seeks to review all routing or routing-related drafts > as they pass through IETF Last Call and IESG review, and sometimes on special > request. The purpose of the review is to provide assistance to the Routing > ADs. For more information about the Routing Directorate, please see > http://www.ietf.org/iesg/directorate/routing.html > > Although these comments are primarily for the use of the Routing ADs, it > would be helpful if you could consider them along with any other IETF Last > Call comments that you receive, and strive to resolve them through discussion > or by updating the draft. > > Document: draft-ietf-opsec-vpn-leakages-02 > Reviewer: Martin Vigoureux > Review Date: 2013-12-05 > IETF LC End Date: 2013-12-16 > Intended Status: Informational > > Summary: > This document is basically ready for publication, but has nits that should be > considered prior to publication. > > Comments: > This document is short, focussed, and well written. > However it is unclear, beyond that fact that users do not know that traffic > is leaking from (rather not mapped onto) their VPN, what the real issue is. > Yes, a man in the middle, might intercept the leaked traffic but this traffic > is a priori intended to resources only accessible through the VPN. So, > knowing that the leaked traffic will not reach the targeted destination, it > is not clear which critical information it may carry. I believe that it would > be worth giving an example. > Note that this relates to/extends a comment raised against > draft-gont-opsec-vpn-leakages-00 but which was apparently not addressed. > http://www.ietf.org/mail-archive/web/opsec/current/msg01135.html > > Minor Issues: > Abstract: > 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. > I believe this sentence does not exactly reflect the content of the document. > For the first part, I think it is not only because of enabling IPv6 but > because a site has both IPv4 and IPv6 support *and* a VPN client has poor > capabilities in handling securely (i.e., mapping on the VPN) packets which > use one of the two address families. > By the way this is said in section 4: > the resulting VPN traffic leakage is a side-effect of employing > IPv6-unaware VPN software in a dual-stacked host/network. > > Thanks > -m > -- "Does Emacs have the Buddha nature? Why not? It has bloody well everything else..." _______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
