Sorry for coming in late on this. I meant to send some of this out earlier but slipped my mind and got reminded now on seeing these comments.
+1 on using DNS. Talking about using both in-band and out-of-band together, what would be the use case there and also, the priority of operations? One possible use case I can think of is it can be used as an indirect means of authenticating the probe description URI in the in-band probe. Let’s say the in-band probe contains the URI of https[:]//example[.]net/measurement[.]txt. An out-of-band reverse DNS lookup for the source address can be used to verify whether the source address indeed translates to the same domain. If not, it could be an indication of spoofing or malicious intent. There are obviously several mitigating conditions such as presence of NAT, probe originating node not being the same as the web server hosting the URI, etc. Lastly, considering this can lead to reflection/amplification style attacks, should we considering call this out under “security considerations”? It can also include certain recommendations for performing lookups such caching and rate-limiting of requests. Thanks, Prapanch From: OPSEC <[email protected]> on behalf of Justin Iurman <[email protected]> Date: Thursday, 2 February 2023 at 10:46 PM To: Jen Linkova <[email protected]>, opsec WG <[email protected]> Cc: OpSec Chairs <[email protected]>, [email protected] <[email protected]> Subject: Re: [OPSEC] draft-ietf-opsec-probe-attribution: WGLC 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
_______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
