On 1/25/13 10:23 PM, Fernando Gont wrote:
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"?
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.
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
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, 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.
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 -->
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. if the
link is sufficiently stable that it's likely to be there a decade from
now so much the better.
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.
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.
Thanks so much!
Best regards,
_______________________________________________
OPSEC mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsec
