On Tue, Jan 31, 2023 at 1:03 AM, Jen Linkova <[email protected]> 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 <[email protected]> wrote:
>
> Hello,
>
> This email starts the WGLC for 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
> [email protected]
> https://www.ietf.org/mailman/listinfo/opsec
>
>
_______________________________________________
OPSEC mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsec
