Hi, Joel, Thanks so much for your feedback! Please find my comments in-line...
On 01/24/2013 11:17 PM, joel jaeggli wrote: > I reread this document with an eye towards publication. > > generally I think it is good and ready for publication modula the > comments below which obviously you can take at your discretion or not. > > section 1 > > Among such controls is the enforcement of > filtering policies, such that undesirable traffic is blocked. > > is awkward. mmm.. what do you mean by "awkward"? > IPv6 supporting security controls can enforce filtering policy such > that undesirable traffic is blocked. Is this a proposed text to replace the above? Something else? > I take issue with the example in this sentence > > Only > in some exceptional cases (such as military operations networks) > could this approach to mitigating the aforementioned security > implications be thought of as a longer-term strategy. > > the people who find that sort of approach necessary know who they are. > the same applies to a similar stanza in 2.1 Are you suggesting that we should remove this paragraph, or something else? > the citations in section 2 for toolkits. read like advertising and > should be detuned accordingly. citing them as examples is fine. Please suggest how I could rephrease the text to look better -- the text is meant to just provide examples of tools that readers can use to play with this stuff. (FWIW, both toolkits are free software... so nobody is making money out of them). > if the > third citation is factually incorrect in some fashion it should be dropped. > > [Waters2011] provides an example of how this could be achieved > using publicly available tools (besides incorrectly claiming the > discovery of a "0day vulnerability"). Others have complained about it, already. I personally find the example valuable -- modulo the reference to it being a 0-day. -- SHould we leave it in if Alec modifies the text as noted on-list? > section 3. > > Unless properly managed, tunneling mechanisms might result in > negative security implications > > statement is vague even when followed by the citation. > > might result in exposure is more explicit and simpler. Exposure is one factor. They might also help to evade security controls, might contain bugs with security implications, and might contain protocol-based vulnerabilities (think Nakibly et al's paper on routing loops). > drop "therefore" from the second paragraph > > section 3.6 > > It should be noted that dig is part of bind or bindutils it is a > product of ISC and while it comes with lots of unix systems it is not > generic to them. Should I replace it with something else? host? nslookup? Thanks so much! Best regards, -- Fernando Gont SI6 Networks e-mail: [email protected] PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 _______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
