Hi Jen,
On 1/31/23 07:03, Jen Linkova wrote:
No comments so far, so I'm going to break the silence.
Thanks for breaking the silence!
[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..
SHOULD we? :-) More seriously, I agree and feel the same when I come
across lowercase keywords in RFCs. So either we remove any ambiguity by
replacing them with similar words, or we do as you suggest. Any preference?
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 ;)
Fair point, and that's part of what was discussed during the meeting in
Philly. We should clarify that since anyone (maybe with bad intentions)
could use this in-band technique. Again, this is a compromise solution.
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.
We might rephrase since it was not the goal. Out-of-band is indeed less
prone to spoofing, but sometimes you might find yourself in a situation
where it's not possible to use it. So in-band could be used instead.
Both could also be used "at the same time" if it's possible BTW.
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?
Good point.
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?
Indeed, thx!
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
Well, reading that part again and again, I agree it's not that clear.
We'll clarify that, as I don't even remember what we meant precisely TBH.
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.
+1 :-)
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:"?
---
+1.
IANA Consideration:
"additional values" - I assume it shouldn't be a list item but a part
of the previous sentence, right?
Indeed!
Thanks,
Justin
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.
_______________________________________________
OPSEC mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsec
