Hi Warren,
Thanks for all your comments, they'll be included in next revision!
Justin
On 2/7/23 20:31, Warren Kumari wrote:
On Tue, Jan 31, 2023 at 1:03 AM, Jen Linkova <furr...@gmail.com
<mailto:furr...@gmail.com>> wrote:
No comments so far, so I'm going to break the silence.
Some random comments:
1: "This is similar scan and could be perceived as aggressive." — I'm
assuming this should be something like "This is similar *to scanning*,
and …" . This also somewhat implies that scanning is usually viewed as
something negative. Perhaps just change this to "Sometimes these
measurements are viewed as unwelcome or aggressive" (or similar).
2: "a proposes a couple of simple" - I'd suggest "some simple" ("a
couple" often implies two).
3: "Sending unsolicited probes should obviously be done at a rate low
enough to avoid wasting other parties resources." - *Any* unsolicited
scan is wasting my resources, and "low enough" is largely meaningless -
is this one packet per day per AS, or is 1Kpps OK? Perhaps "at a rate
low enough to not unduly impact the other parties resources"? This is
still vary vague, but seems less hand-wavey.
4: "only good-willing researchers" doesn't read very well. Unfortunately
I don't have any other suggestions (other than 'white-hat' which is
unlikely to fly…)
5: "If the URI cannot be placed at the beginning of the payload, then
it should be preceded also by an octet of 0x00." — I think drop the
"also" (or, if you really want it, then "it should also be preceded by an…")
6: "Note: using the above technique produces a valid and legit packet" -
drop 'and legit'. If you really want, you could s/legit/legitimate/, but
it is still unclear what exactly this means…
7: "The node receiving the probe may or may not process the received
packet, but this should cause no harm if the probing rate is very low as
compared to the network bandwidth and to the processing capacity of all
the nodes." — er, what? If you add up "the processing capacity of all
the nodes" in e.g AWS, and sent a very low probing rate to one server,
it would presumably cause harm. This sentence needs work :-P
8: "As the insertion of the URI in the packet may not respect the syntax
of the protocol,
responses may not be received (such a TCP SYN+ACK) and perhaps
an ICMP should be expected or more probably an absence of reply." —
Today's Zen Koan: if a probing packet falls in the forest, and no one
replies, did it get there? (If I'm probing subnet foo for
<some_malware_which_listens_on_port_1337>, and inserting the URI means I
get no reply, then, well,....) Perhaps this needs some wording around
"additional attribution packets" or similar?
W
[no hats]
I've read the document and I have a few comments.
1. SHOULD the document use the normative language? It might be just
me but I do find 'should'/'must' in lower case a bit confusing in RFCs..
2. The Intro says: "Note: it is expected that only good-willing
researchers will use these techniques". Does it mean that we do not
expect bad guys to use it? For a security-related document it's a
very optimistic expectation, IMHO ;)
3. Section 3 says "When it is not possible to include the "probe
description URI" in the probe packet itself, then a specific URI
must be constructed based on the source address of the probe
packet". This sounds like the draft recommends in-band attribution
over out-of-band. I might be wrong but out-of-band attribution is
more reliable as it is less prone to spoofing.
Shall the draft make some recommendations for probe owners (and
probe makers, actually - have you talked to RIPE Atlas guys?)
Maybe the security section shall talk a bit more about what could be
trusted and what could not?
4. Section 3: "following the syntax described in section 3 of
[RFC9116]" - it looks like section 3 of RFC9116 defines the
location, not the format. Did you mean section 4?
5. "Plus, another one "description" which is a URI pointing to a
document describing the measurement."
Are you suggesting that an in- or out-of-band URI points to a probe
description text file which in turns contains another URI pointing
to a document describing the measurement? Can the probe description
text file contains the
5. Accessing a web-page on a probe device might be problematic. It
could be behind a firewall, or the source address might be a random
one from a large prefix. A stupid idea: can we use a camel..sorry, I
meant DNS - as an alternative option? ;)
At least that would provide some sort of authentication.
Nit-picking:
---
Section 2.2:
"Similarly, as in [RFC9116], when a node probes other nodes over the
Internet, it should create a text file following the syntax
described in section 3 of [RFC9116] and should have the following
fields:"
maybe rephrase as '...the probing node administrator should create a
text file following the syntax described in section 3 of [RFC9116].
That file should have the following fields:"?
---
IANA Consideration:
"additional values" - I assume it shouldn't be a list item but a
part of the previous sentence, right?
---
On Wed, Jan 11, 2023 at 11:17 AM Jen Linkova <furr...@gmail.com
<mailto:furr...@gmail.com>> wrote:
Hello,
This email starts the WGLC for draft-ietf-opsec-probe-attribution
(https://datatracker.ietf.org/doc/draft-ietf-opsec-probe-attribution/
<https://datatracker.ietf.org/doc/draft-ietf-opsec-probe-attribution/>).
The WGLC ends on Sun, Jan 29th, 23:59:59UTC.
Please review the draft and send comments/suggestions/opinions
to the list.
Thank you!
--
SY, Jen Linkova aka Furry on behalf of OpSec chairs.
--
SY, Jen Linkova aka Furry
_______________________________________________
OPSEC mailing list
OPSEC@ietf.org <mailto:OPSEC@ietf.org>
https://www.ietf.org/mailman/listinfo/opsec
<https://www.ietf.org/mailman/listinfo/opsec>
_______________________________________________
OPSEC mailing list
OPSEC@ietf.org
https://www.ietf.org/mailman/listinfo/opsec
_______________________________________________
OPSEC mailing list
OPSEC@ietf.org
https://www.ietf.org/mailman/listinfo/opsec
