Hi Linda,
Actually, probes could be whatever you want. It is defined in the draft as:
Many measurement researches ([LARGE_SCALE], [RFC7872], and
[I-D.draft-vyncke-v6ops-james]) are about sending IP packets
(sometimes with extension headers or layer-4 headers) over the public
Internet and those packets can be destined to either collaborating
parties or non-collaborating ones. Such packets are called probes in
this document.
So, basically, a probe is a packet. Let's say, for example, that I'm a
researcher and I want to measure if an IPv6 Hop-by-Hop Extension Header
goes through from my home router towards a random target, with TCP as
layer 4. I'd send some crafted packets (i.e., IPv6/Hbh/TCP), also called
probes in this document. So far so good. Let's now assume that you are
an operator where these probes transit or arrive. As is, you don't
really know why you're receiving them and it could be perceived as
harmful or aggressive. This document proposes simple techniques for a
source (me, in this case) to identify the probes for any third parties
on the path that would want to know (one of them is you, in this case).
In fact, it allows me to say "I'm the origin of these probes and I do
that because ...", so that you are able to understand why you receive
such probes.
Thanks,
Justin
On 7/11/23 22:35, Linda Dunbar wrote:
Justin,
Thank you very much for the explanation.
Is the "Probe" another ICMP message? Does the "probe" have an ICMP Header?
Does it mean that Source can include an "URL" to the ICMP message content?
I reviewed the -08 version, I still can't find answers to my puzzle.
Thank you
Linda
-----Original Message-----
From: Justin Iurman <justin.iurman@xxxxxxxxx>
Sent: Thursday, June 8, 2023 3:28 PM
To: Linda Dunbar <linda.dunbar@xxxxxxxxxxxxx>; ops-dir@xxxxxxxx
Cc: draft-ietf-opsec-probe-attribution.all@xxxxxxxx; last-call@xxxxxxxx; opsec@xxxxxxxx
Subject: Re: Opsdir last call review of draft-ietf-opsec-probe-attribution-05
Hi Linda,
Please see inline ([JI]).
On 6/8/23 18:06, Linda Dunbar via Datatracker wrote:
Reviewer: Linda Dunbar
Review result: Not Ready
I have reviewed this document as part of the Ops area directorate's
ongoing effort to review all IETF documents being processed by the
IESG. These comments were written primarily for the benefit of the Ops area directors.
Document editors and WG chairs should treat these comments just like
any other last-call comments.
Summary:
This document describes the method for any organizations to send
queries to understand the received unsolicited probing packets.
[JI] I think there might be a misunderstanding here. What we define for the in-band technique is just a simple way to include a probe description URI (a link, an email address, a phone number, etc) in probes/packets so that third parties on the path would be able to identify them (what's the reason for such probes? who's responsible for that? what's the purpose? etc). We do *not* define how third parties would verify the probe attribution (at least, we explain how, but we do not define a query to do that automatically).
Issues:
- Are those queries generated automatically?
[JI] Not really sure about what you mean with "queries". See the above explanation. If I missed your point, please shout.
- If the queries are generated automatically, does it require routers
upgrade to support the auto-generating of those queries? - If the
queries are generated manually, the draft should give some detailed
examples since those queries will be generated by people not coming to
IETF. - Today, most routers ignore the Internet probes they don't support. What are the problems of ignoring them?
[JI] No, routers do not need any upgrade. If the out-of-band technique, nothing is included in probes. If the in-band technique, the probe attribution is included in probes, but these bytes are just like data payload.
Thanks,
Justin
Best Regards,
Linda Dunbar
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
