On 01/27/2013 04:48 PM, joel jaeggli wrote: >>> 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"? > I mean if if you read that sentence alone it doesn't make a lot of > sense. I suspect a copy editor would ask you to fix it.
English as non-native language here, but... what this text is supposed to mean is "one of the things that you can do is enforce IPv6 filtering, such that the IPv6-based traffic you don't like is blocked"). Doesn't that sentence convey that information? >>> 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? >> > yes If anything, shouldn't it be "IPv6-supporting security controls..."? (or maybe "IPv6-enabled security controls"..). >>> 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? > I'm suggesting that the authors and contributors don't run military > operations networks so it's speculative, FWIW, this note was added in response to feedback from folks involved in military networks. > and that the people that do run > networks that find this necessary won't find the example relatable, it's > a property of operational requirements, not which industrial vertical > you happen to be in that drives the requiresments. I couldn't parse tis last sentence... Anyway... What's your proposed path to addresss the point you've raised? FWIW, this note was included because the previous paragraph noted that, if anything, this should only be considered as a "short-term" strategy. However, in some networks (in which you only deploy stuff you have no other option to), this could be a longer-term strategy. >>> 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). > So if it's not addressed it likely will be an issue for the IESG review. > > these simples possible answer would be something like. > > 1. This is a toolkit, it does foo --> > 2. this is also a toolkit, it does foo --> I will tweak the I-D as suggested. >>> 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? > alec's suggestion on the list was fine. a citation that says, this like > is great except all the parts we dispute or which are just wrong is less > useful in my book than being able to say foo is a source for bar. Agreed. But we only had the former. > if the > link is sufficiently stable that it's likely to be there a decade from > now so much the better. What I can personally offer is to put it on my personal site. I'll wait and see what Alec has to offer in this respect, anyway. >>> 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). > right so, you could expand on the implications a bit. the text you wrote > above it pretty good for example. Ok, will do. >>> 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? > just cite that it's part of bind. Will do. Thanks! 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
