On Dec 12, 2013, at 6:10 PM, Russ Housley <[email protected]> wrote:
> I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at > <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. > > Please resolve these comments along with any other Last Call comments > you may receive. > > Document: draft-ietf-opsec-vpn-leakages-02 > Reviewer: Russ Housley > Review Date: 2013-12-12 > IETF LC End Date: 2013-12-16 > IESG Telechat date: Unknown > > Summary: The document is almost ready for publication as a > informational RFC. I raise minor concerns that should be resolved > before IESG evaluation. > > Major Concern: > > This document is about encrypted tunnels, and I am asking for this to > be stated very early in the document. Sadly, the IETF uses VPN to mean > two very different things, please tell the reader which one is being > discussed in the abstract and the introduction of the document. IPsec > and L3VPN demonstrate the two very different meanings for VPN, and > "VPN leakage" has meaning in both of them. > Yup — this was also identified during the SecDir review. We have not yet fully figured out how to fix the issue, but it is now becoming clear that there needs to be some more text here. I think we all fell into the trap of automatically knowing which we meant from context and so didn’t consider the other usages. > Personal Observation: > > 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. We often see that folk simply don’t realize that their VPN software does’t do the right thing with IPv6 — I think your summary would be better done as: 1: Figure out if your VPN software supports v6 correctly. 2: If not, disable v6 on all interface when you enable the VPN. But, even if that was the entire message, it is unclear *where* it could be published that would get the necessary visibility — we think it is an important message, folk listen to the IETF, and RFC’s is what we have. Especially for operational issues / items an RFC often seems too heavyweight (“Open recursive resolvers suck. Turn them off”, “Don’t emit packets for space you don’t own”, etc); it would be nice if we had some other document stream that is still relevant, but not quite as heavy. W -- For every complex problem, there is a solution that is simple, neat, and wrong. -- H. L. Mencken _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
